> 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.
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.
Reply by Hans-Bernhard Bröker●October 4, 20152015-10-04
Am 04.10.2015 um 12:00 schrieb tim.....:
> "rickman" <gnuarm@gmail.com> wrote in message
> news:muqolu$7ki$1@dont-email.me...
>> On 10/4/2015 4:26 AM, tim..... wrote:
>>> 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
If you keep telling yourself that, maybe it'll come true.
Reply by Hans-Bernhard Bröker●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.
Reply by tim.....●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 rickman●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 tim.....●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 Hans-Bernhard Bröker●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 Hans-Bernhard Bröker●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 week
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 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 David Brown●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 tim.....●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 modifications
It's not exactly the hardest protocol in the world
teach it yourself in a week
tim