Hello, I wonder if we have automotive engineers here? What microcontrollers and what RTOS do you use for CAN connected systems? I know that some manufacturers have a list of approved micros. So far my investigation ended on Freescale/ST SPC56 family and Renesas RH850, both running AUTOSAR from VECTOR. Are there any other widely used micros?
BR Tomas D.
I worked with automotive 5 years ago.
We used Renesas micro. CAN app layers was bought from a German company, can't remember the name right now. But the CAN stack worked flawlessly out of the box, with practically no modifications
Cheers
Klaus
It's not exactly the hardest protocol in the world
teach it yourself in a week
tim
As long as you are talking about CAN by itself, it's easy to do. But if someone wants one of the layers above, like CANOpen or DeviceNet, things quickly get complicated and massively time-consuming.
Am 01.10.2015 um 21:49 schrieb tim.....:
There would be no point. CAN itself is handled completely in hardware, anyway.
What you would have to learn, instead, are things like
*) the particular CAN IP cell integrated with your microcontroller (and its quirks) *) its integration with the rest of the microcontroller (and its quirks) *) electronic requirements, i.e. the choice and details of the physical layer used/required by the car maker *) which other protocols on top of CAN they use for higher functions (ISO-TP, UDS, OBD-II, GM-LAN, BAP) *) how they organize start-up and shut-down procedures of individual nodes, and/or the entire CAN network. *) specifications that arrive in formats neither meant nor suitable for human consumption (dbc, arxml), which will change faster than you can manually update *) hundreds of very specific, in-depth requirements, different for every car maker, coming on top of all the aboveFor a professional project, you do not want to do all that by yourself. Companies like Vector, KVaser, MentorGraphics and a couple others offer valuable assistance.
Am 29.09.2015 um 22:04 schrieb Tomas D.:
I believe they all do. Which kind of renders the first question moot, if you're trying to do this professionally: you use what they allow you to.
Spansion, NXP and Infineon are in this field, too. ARM is expanding. But 16-bit cores, and even some 8-bitters are still in use.
The trend is to make this question as irrelevant as possible. All the big players participate in the AUTOSAR movement, which promises that a software system (and its components) should be portable from one micro family to another without too much ado. Interfaces and functionalities of CAN drivers, transport protocols and data abstractions are just a few of the things AUTOSAR standardizes.
news: snipped-for-privacy@mid.dfncis.de...
It was the job of designing that hardware I was referring to (someone has to do it, it doesn't just "appear")
(the PP said "hardware ... which surprisingly worked without errors")
tim
I think he said, "the CAN stack worked flawlessly out of the box, with practically no modifications". The stack is the part implemented in software, no?
-- Rick
OH,
But it still makes my point for me
that the PP's correction of my post was wrong
tim
Am 04.10.2015 um 10:26 schrieb tim.....:
Someone _had_ to do it. As in: about 20 years ago. That work is done, and the result is found as a tick mark in the "CAN support: [ ]" box of the feature list of your micro.
I'm not certain who you mean by "the PP", but no. Nobody said that.
If you keep telling yourself that, maybe it'll come true.
You do, but if you can choose from the list, maybe you want to avoid something has tripped on and had many issues? E.g. one dual core ST micro had an issue on one pin being transitioned from low to high during POR - this ended up in a continuous reset loop... The bug was not documented in the PDF.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.