Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Let the hacking begin... (Model S parts on the bench)

This site may earn commission on affiliate links.
@wk057 regarding your pdf and message ID 0x0102, I have a single motor 60 and the messages are all 8 bytes, not 6. Also seeing battery pack current of ~995A using the decoding in that document, which seems extremely high. I'll have to dig more later, there may already be an answer around somewhere, but it's pretty late and I've done enough coding for one day, perhaps two :)
 
@wk057 regarding your pdf and message ID 0x0102, I have a single motor 60 and the messages are all 8 bytes, not 6. Also seeing battery pack current of ~995A using the decoding in that document, which seems extremely high. I'll have to dig more later, there may already be an answer around somewhere, but it's pretty late and I've done enough coding for one day, perhaps two :)

At some point Tesla changed all cars to the 8-byte format.
 
How is the car itself receiving and processing the CAN data? It seems to me that using a general purpose CPU that can't walk (pick a nav route) and chew bubblegum (play music) at the same time shouldn't also be used for safety of life tasks, but I haven't seen the thing up close, just bits n pieces.

I'm not convinced a microcontroller is up to processing 4 busses at once for logging either. Been considering digging out one of my FPGA dev boards.
 
thenaimis,
The different CAN busses are used as broadcast space for different module sets within the car. The chassis CAN bus is normally the one I am interested in as it contains broadcast data from driveline components like motor units, ABS controllers and the like. It tends to be one of the, if not the, fastest bus and contains the performance related information I am normally interested in. There are reasons to look at other busses if you are interested in how lights are turned on, suspension height is controlled and the like but that is not my bag. I'm not sure there is any need to log all the busses at the same time but then there is no reason not to give it a try if it turns your crank :)

I have not verified this but I would be incredibly surprised if something like the dash units and infotainment systems are not on completely separated busses. There is likely a gateway somewhere that passes information from the infotainment system to the various car system critical busses but there would be protections in place to prevent any kind of a main screen crash from having an effect on the fundamental vehicle functionality. This is how MB, VAG and BMW do it.
 
It seems to me that using a general purpose CPU that can't walk (pick a nav route) and chew bubblegum (play music) at the same time shouldn't also be used for safety of life tasks, but I haven't seen the thing up close, just bits n pieces.

Is that a problem? I've never had a problem with the MCU Nav system interfering with the media player (or anything else for that matter).
 
Is that a problem? I've never had a problem with the MCU Nav system interfering with the media player (or anything else for that matter).

OT, but I've had all kinds of problems with the mp3 player. I don't really use spotify or tunein or the radio. I don't know how common it is, but yeah, if I request directions the music playback may stutter.

That's what the gateway is for. It receives all CAN traffic and runs a separate CPU with an RTOS.

Ah, ok. That makes a lot more sense. I tried to find a block diagram of the gateway online, without any luck unfortunately. Haven't found much detail searching the forums yet either. I'm awfully curious as to what's in that circuit.
 
The Gateway is implemented on an NXP (Freescale) SPC5668GVMG. It lives inside the MCU and runs FreeRTOS and and has 6 CAN interfaces to the car. It also has an Ethernet interface and talks to the IC and CID over that acting like a CAN-IP bridge/firewall. It's also responsible for much of the logging and handles all the firmware updates in the car for all the modules. It's a critical device in the car, and you cannot drive without it.

The CID is running the GUI, Nav, and Media stuff. It is not needed to drive. Both the CID and the GW are physically part of the MCU.
 
How is the car itself receiving and processing the CAN data? It seems to me that using a general purpose CPU that can't walk (pick a nav route) and chew bubblegum (play music) at the same time shouldn't also be used for safety of life tasks, but I haven't seen the thing up close, just bits n pieces.

I'm not convinced a microcontroller is up to processing 4 busses at once for logging either. Been considering digging out one of my FPGA dev boards.
Don't be deceived. Microcontrollers aren't "general purpose" as in cheap crap that can be used in anything but is good at nothing. Quite the opposite: they are general purpose because a microcontroller can take any relatively simple data-handling task and do it highly reliably in real time. Ever had your PC freeze for a moment before doing something? You don't want that to happen when airbags are supposed to go off or your brake lights are supposed to go on. Perfect job for a microcontroller, which has no cares in the world except, "Is that CAN message for me? OK, what's that? Consider it done!" rather than all the cares of an operation system: "User input. System tick. Update GUI! Cue the next MP3 byte from memory. Wait, did I forget something? Right, user input."

Now that wk057 is back, I'm still hoping this thread will come to life again. :rolleyes:
 
Except my limited understanding is that if a driver is programmed into the kernel of an OS it can exclusively handle interrupts and therefore function just like an RTOS for that specific process. I understand microcontrollers but I really don't understand an RTOS.
 
Except my limited understanding is that if a driver is programmed into the kernel of an OS it can exclusively handle interrupts and therefore function just like an RTOS for that specific process. I understand microcontrollers but I really don't understand an RTOS.

Only if the driver disables interrupts for the period of time it does its work, and even then you have the problem of non-maskable interrupts preempting it. Also, if you leave interrupts disabled too long the OS watchdog timer will fire and bring the whole system down.

Emulating an RTOS on a general OS just isn't a great thing.
 
In a word:
The BeagleBone's I/O pins: inside the software stack that makes them work
The fourth image down is an oscilloscope screenshot which clearly illustrates why a general OS is no match for a µcontroller running an RTOS, and why it's bad to have a pacemaker run Linux, or a critical healthcare machine run Windows. That would be using a tool for a propose other than the one for which it was designed. :)