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.
Automotive micros
Started by ●September 29, 2015
Reply by ●October 1, 20152015-10-01
On Tuesday, September 29, 2015 at 10:05:00 PM UTC+2, Tomas D. wrote:> 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? >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
Reply by ●October 1, 20152015-10-01
"Klaus Kragelund" <klauskvik@hotmail.com> wrote in message news:a3862803-83c9-4f8b-b04a-a81662d1bd16@googlegroups.com...> On Tuesday, September 29, 2015 at 10:05:00 PM UTC+2, Tomas D. wrote: >> 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? >> > 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 modificationsIt's not exactly the hardest protocol in the world teach it yourself in a week tim
Reply by ●October 2, 20152015-10-02
On 01/10/15 21:49, tim..... wrote:> > "Klaus Kragelund" <klauskvik@hotmail.com> wrote in message > news:a3862803-83c9-4f8b-b04a-a81662d1bd16@googlegroups.com... >> On Tuesday, September 29, 2015 at 10:05:00 PM UTC+2, Tomas D. wrote: >>> 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? >>> >> 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 > > It's not exactly the hardest protocol in the world > > teach it yourself in a week >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.
Reply by ●October 3, 20152015-10-03
Am 01.10.2015 um 21:49 schrieb tim.....:> It's not exactly the hardest protocol in the world > > teach it yourself in a weekThere 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 above For 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.
Reply by ●October 3, 20152015-10-03
Am 29.09.2015 um 22:04 schrieb Tomas D.:> What microcontrollers and what RTOS do you use for CAN connected systems? I > know that some manufacturers have a list of approved micros.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.> So far my > investigation ended on Freescale/ST SPC56 family and Renesas RH850, both > running AUTOSAR from VECTOR.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.> Are there any other widely used micros?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.
Reply by ●October 4, 20152015-10-04
"Hans-Bernhard Br�ker" <HBBroeker@t-online.de> wrote in message news:d7aprcF4q8lU1@mid.dfncis.de...> Am 01.10.2015 um 21:49 schrieb tim.....: > >> It's not exactly the hardest protocol in the world >> >> teach it yourself in a week > > There would be no point. CAN itself is handled completely in hardware, > anyway.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
Reply by ●October 4, 20152015-10-04
On 10/4/2015 4:26 AM, tim..... wrote:> > "Hans-Bernhard Br�ker" <HBBroeker@t-online.de> wrote in message > news:d7aprcF4q8lU1@mid.dfncis.de... >> Am 01.10.2015 um 21:49 schrieb tim.....: >> >>> It's not exactly the hardest protocol in the world >>> >>> teach it yourself in a week >> >> There would be no point. CAN itself is handled completely in >> hardware, anyway. > > 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")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
Reply by ●October 4, 20152015-10-04
"rickman" <gnuarm@gmail.com> wrote in message news:muqolu$7ki$1@dont-email.me...> On 10/4/2015 4:26 AM, tim..... wrote: >> >> "Hans-Bernhard Br�ker" <HBBroeker@t-online.de> wrote in message >> news:d7aprcF4q8lU1@mid.dfncis.de... >>> Am 01.10.2015 um 21:49 schrieb tim.....: >>> >>>> It's not exactly the hardest protocol in the world >>>> >>>> teach it yourself in a week >>> >>> There would be no point. CAN itself is handled completely in >>> hardware, anyway. >> >> 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") > > 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?OH, But it still makes my point for me that the PP's correction of my post was wrong tim
Reply by ●October 4, 20152015-10-04
Am 04.10.2015 um 10:26 schrieb tim.....:> "Hans-Bernhard Br�ker" <HBBroeker@t-online.de> wrote in message > news:d7aprcF4q8lU1@mid.dfncis.de...>> There would be no point. CAN itself is handled completely in >> hardware, anyway.> It was the job of designing that hardware I was referring to (someone > has to do it, it doesn't just "appear")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.> (the PP said "hardware ... which surprisingly worked without errors")I'm not certain who you mean by "the PP", but no. Nobody said that.
