Which arm to use with can bus and ease of use in mind

[Simon]

As I've only scratched the surface with microcontrollers and my eyes opening to things like can bus which would be very useful in the future. What would be the best option? I'm looking for something that has the best support and is the easiest to use as last thing I like doing is trying to decipher somebody's documentation where they dance around and say absolutely nothing about the nitty-gritty.

Obviously packaging wise I've been looking at something that is easy to work with with hand assembly. ST Micro seem to have a nice range that goes right down to a 20 pin which would be ideal for me although using AVR at the moment I am curious as to whether the Atmel range is worth looking at. Or anybody else's for that matter.

[jnz]

I use the STM32s, you can send me a PM and I'll try and direct you to some experiences. Are you trying to do industrial, aero or auto?

[SKPang]

If you want something easy to use and have a great library look at Teensy 3.2
I've done a CAN-bus ECU reader project on it:
https://www.skptechnology.co.uk/teensy-canbus-ecu-reader-with-oled-display/

A smaller ARM chip with CAN worth a look is the LPC11C24. You can get a dev board(OM13012) for use with LPXpresso IDE.

[Simon]

I like the idea of an Arduino type system. I did get off the Arduino as fast as I could as on an AVR it is limiting. It was an excellent environment for me to learn and get comfortable with writing C programs but I soon found that I wanted direct access to the chips hardware to do different things like have different PWM frequencies.

However on something that has the power of an ARM processor I would not be surprised if something like the Arduino environment could be a lot more flexible and if there is library support that sounds like a good idea to me. I had started writing my own macros for the AVR but having had a look at 1 of the AVR chips that does have a built in can transceiver the pages and pages of registry settings look pretty daunting. So once again I think I higher-level programming environment sounds like a good idea.

[JPortici]

I've started working with CAN some months ago (with the microchip ECAN module)
What i suggest you do is put a series of abstraction layers.
Highest, optional, you have the action you want to do (ie: get_rpm() which will send and receive messages in the obd2 format)
Then, a second architecture-independend layer where you generate the message in a friendly format (i have a structure type called can_t with all the data in a user friendly format (id, id format bit (byte), rtr bit, dlc, data bytes, padding bytes to make the structure aligned to the memory bus width) and then the processor-specific interface, that rearrange the bytes in the way the can module wants and vice/versa.
On a dspic there is not much overhead and it's a great way to preserve sanity

[Simon]

Well I think there is a lot that can be done in preprocessing when it comes to layering in user friendly language. A lot of it can be done through macros so that the actual code on the chip is not resource hungry anyway. If I move into something like arm then performance is the last of my worries because it would be 32 bit which would be an enormous performance boost as I'm normally working on 16 bit values anyway on an 8 bit processor and anything that has a can bus is a minimum of 48 MHz and often they don't start having canvases until you have a 72 MHz chip so performance won't be a problem. What I'm mainly worried about is the simplicity of setting the can bus up on the hardware. Obviously if I'm dealing with a vehicle at some point I would have to buy J 1939 standard.

[JPortici]

You have to understand the concepts of filter and masks and, most important, of bit time quanta. The microchip application notes are very good at explaining (it was called a discussion on can physical layer or something like that)
Then it will be simple to set up the peripheral, from almost any vendor.
Check of course the reference manual/code examples

[MagicSmoker]

...
However on something that has the power of an ARM processor I would not be surprised if something like the Arduino environment could be a lot more flexible and if there is library support that sounds like a good idea to me. ...

Check out this guy's work: https://github.com/collin80/due_can

He pretty much wrote an entire CAN library for the Arduino Due (which is the 32b ARM big brother to the original 8b AVR Arduino).

I don't have any experience using this myself so take recommendation with the usual grain of salt, etc.

[Simon]

I see yes the Arduino due ARM has CAN a periphery but no library for it. This might be an option.

[langwadt]

CAN is straight forward with the standard STM library  and with a $10 nucleo board you get a proper debugger

[Simon]

CAN is straight forward with the standard STM library  and with a $10 nucleo board you get a proper debugger

I can only but believe you. I've just spent the last half hour blundering around the ST website. My attempts at creating an account have failed so I can't ask their forum. And I have not found any obvious link to a development environment or any further information about the drivers or libraries available for particular microcontrollers. It looks like the goodness of ST is the best kept secret in the world.

[nctnico]

If your abilities are at the Arduino level then using any kind of library + bare metal C programming is going to be troublesome. So the choice is to either learn how to program C/C++ on a microcontroller or get an Arduino compatible eco system running on an ARM controller.

[langwadt]

CAN is straight forward with the standard STM library  and with a $10 nucleo board you get a proper debugger

I can only but believe you. I've just spent the last half hour blundering around the ST website. My attempts at creating an account have failed so I can't ask their forum. And I have not found any obvious link to a development environment or any further information about the drivers or libraries available for particular microcontrollers. It looks like the goodness of ST is the best kept secret in the world.

it is a bit silly that they require an account to download stuff but I've never had problems creating an account

the STM'ified eclipse is here: http://www.openstm32.org/

[Simon]

If your abilities are at the Arduino level then using any kind of library + bare metal C programming is going to be troublesome. So the choice is to either learn how to program C/C++ on a microcontroller or get an Arduino compatible eco system running on an ARM controller.

currently I write C on AVR after getting to grips with C on arduino it helped me into doing bare metals programming by slowly learning to set each periphery i use up. But knowing how long that takes and considering ARM is more complex something a bit more abstract would be welcome.

[Simon]

CAN is straight forward with the standard STM library  and with a $10 nucleo board you get a proper debugger

I can only but believe you. I've just spent the last half hour blundering around the ST website. My attempts at creating an account have failed so I can't ask their forum. And I have not found any obvious link to a development environment or any further information about the drivers or libraries available for particular microcontrollers. It looks like the goodness of ST is the best kept secret in the world.

it is a bit silly that they require an account to download stuff but I've never had problems creating an account

the STM'ified eclipse is here: http://www.openstm32.org/

Thanks, it seemed to work eventually the website was acting a bit unresponsive. So is your link to a seperate community or is it still ST software ?

[langwadt]

CAN is straight forward with the standard STM library  and with a $10 nucleo board you get a proper debugger

I can only but believe you. I've just spent the last half hour blundering around the ST website. My attempts at creating an account have failed so I can't ask their forum. And I have not found any obvious link to a development environment or any further information about the drivers or libraries available for particular microcontrollers. It looks like the goodness of ST is the best kept secret in the world.

it is a bit silly that they require an account to download stuff but I've never had problems creating an account

the STM'ified eclipse is here: http://www.openstm32.org/

Thanks, it seemed to work eventually the website was acting a bit unresponsive. So is your link to a seperate community or is it still ST software ?

It is made by a company called AC6 I'm not sure what the actual relation with ST is but it is the free gcc/eclipse based IDE ST links to and provides examples for

[nctnico]

If your abilities are at the Arduino level then using any kind of library + bare metal C programming is going to be troublesome. So the choice is to either learn how to program C/C++ on a microcontroller or get an Arduino compatible eco system running on an ARM controller.

currently I write C on AVR after getting to grips with C on arduino it helped me into doing bare metals programming by slowly learning to set each periphery i use up. But knowing how long that takes and considering ARM is more complex something a bit more abstract would be welcome.

In that case you should look into ARM controllers with simpler and more consistent peripherals: the NXP LPC ARM Cortex series. If you know one then you know 90% of the rest. ST is a huge mess in comparison and I don't use ST's ARM controllers because of that.

[JPortici]

(also, i find LPCXpresso to be so much better than any free/open source STM IDE counterpart)

[Simon]

If you want something easy to use and have a great library look at Teensy 3.2
I've done a CAN-bus ECU reader project on it:
https://www.skptechnology.co.uk/teensy-canbus-ecu-reader-with-oled-display/

A smaller ARM chip with CAN worth a look is the LPC11C24. You can get a dev board(OM13012) for use with LPXpresso IDE.

Apparently it can only receive CAN messages and needs an external CAN controller to do proper CAN bus comms

[Simon]

Although according to the datasheet the  LPC11C22/C24 have a CAN transceiver

[SKPang]

Apparently it can only receive CAN messages and needs an external CAN controller to do proper CAN bus comms

That is not quite correct. The Teensy has built in controller already. You need an external CAN transceiver.

[SKPang]

Although according to the datasheet the  LPC11C22/C24 have a CAN transceiver

Correct. The LPCXPresso IDE has some nice examples for the chip.

[Simon]

Apparently it can only receive CAN messages and needs an external CAN controller to do proper CAN bus comms

That is not quite correct. The Teensy has built in controller already. You need an external CAN transceiver.

Are we talking about a full transceiver that requires as any other controller a seperate driver chip to does the logic level translation and provides good strong drive for the bus?

[SKPang]

You need a CAN transceiver, something like a SN65HVD231
http://www.ti.com/product/SN65HVD231

[Simon]

OK the line driver not the controller that is in the uC

Sent from my phone so mind the autocorrect.

[jnz]

I've started working with CAN some months ago (with the microchip ECAN module)

Microchip's ECAN module.... One of those worst. I mean... it works, but their filter setup is overly complicated, their FIFO works well when you understand it but not a single working example existed anywhere when I looked last, silicon bugs, and a really great bug where you can get mirror messages automatically sent out everytime you receive one.  One of the main reasons I left Microchip for good!

It's no surprise all of their new CAN is Kvaser's IP and not their own. That's one thing about Microchip, when they know something they make sucks, they just buy something better.

[jnz]

Although according to the datasheet the  LPC11C22/C24 have a CAN transceiver

Correct. The LPCXPresso IDE has some nice examples for the chip.

FWIW... Even if with the LPC11C22/24 and it's built in CAN transceiver, you do need to supply 5V to it. A small gotcha if you think you're going to be working with a 3.3V part. It's literally just their 1040 series transceiver put in with their micro die.  Microchip has a product with the same thing, but they were a little lazier about it you need to loop/connect the external CAN TX RX pins to other external TRANSCEIVER TX RX pins.

[JPortici]

I've started working with CAN some months ago (with the microchip ECAN module)

Microchip's ECAN module.... One of those worst. I mean... it works, but their filter setup is overly complicated, their FIFO works well when you understand it but not a single working example existed anywhere when I looked last, silicon bugs, and a really great bug where you can get mirror messages automatically sent out everytime you receive one.  One of the main reasons I left Microchip for good!

It's no surprise all of their new CAN is Kvaser's IP and not their own. That's one thing about Microchip, when they know something they make sucks, they just buy something better.

Never claimed it was simple

I am using a 3 years old chip, no serious silicon bugs on CAN.
The examples on the reference manual and on the demo board (can-lin starter kit) worked out of the box.
I'm not completely sure of some of the functions...

Interestingly enough we have a product from before i came on board thqt uses an older dspic and yes it has a couple of facepalm bugs.

You mentioned kvaser... seeing from the advanced configuration of a kvaser unit i figured it used microchip at its heart... but it was the other way around.

[kaz911]

I like the TI Tiva's CAN with ISO1050 CAN transceiver - very compatible. Nice interrupt handling on special messages.

I think they have also launched a new version of the 1050 for the new super high speed CAN bus speeds - but I have not looked into it.

[edit: the ISO1050 is for isolated CAN)...

[jnz]

I'm not completely sure of some of the functions...

That's OK, neither is Microchip

Interestingly enough we have a product from before i came on board thqt uses an older dspic and yes it has a couple of facepalm bugs.
You mentioned kvaser... seeing from the advanced configuration of a kvaser unit i figured it used microchip at its heart... but it was the other way around.

Oh man, the first gen dsPics can module was SO BAD. Their DMA was required and entirely a mystery to everyone at the company. So many support ticket before I just dumped that whole line.

Kvaser is one of the industry leaders in CAN, Microchip was smart to just adopt their IP. It's the only reason I'd even remotely consider a new Microchip CAN Transceiver, their first ones were out of spec enough to cause incompatibility with the rest of the market. I still wouldn't say Microchip has their stuff together with CAN, but at least it's clearly getting better. They're making a big deal about CAN FD, lots of noise, no support yet.

[SKPang]

Microchip meant to be bringing out the MCP2517FD CAN-FD controller but its all gone quiet.

Even the Kvaser presentation has removed mentioning the MCP2517FD chip.
https://www.kvaser.com/wp-content/uploads/2016/10/comparing-can-fd-with-classical-can.pdf

[Sal Ammoniac]

In that case you should look into ARM controllers with simpler and more consistent peripherals: the NXP LPC ARM Cortex series. If you know one then you know 90% of the rest. ST is a huge mess in comparison and I don't use ST's ARM controllers because of that.

Unfortunately, NXP's CAN peripheral is one of the lamest I've encountered. ST's CAN implementation is much nicer.

If you're not wedded to ARM, the Microchip PIC32 has a nice CAN peripheral.

[JPortici]

Oh man, the first gen dsPics can module was SO BAD. Their DMA was required and entirely a mystery to everyone at the company. So many support ticket before I just dumped that whole line.

the other product was using the dspic FJ GP708.. I KNOW. now it uses the 'A' version that just has to have a reserved bit set in order to work.

Kvaser is one of the industry leaders in CAN, Microchip was smart to just adopt their IP. It's the only reason I'd even remotely consider a new Microchip CAN Transceiver, their first ones were out of spec enough to cause incompatibility with the rest of the market. I still wouldn't say Microchip has their stuff together with CAN, but at least it's clearly getting better. They're making a big deal about CAN FD, lots of noise, no support yet.

And i saw so many mcp2551 in products that i thought it was the max232 of can transceivers.. I'm too new ain't I?

[Simon]

I know a giy that uses the MCP2551 in all his stuff. I think it's a case of once you have found it and written the libraries for it you just keep using it. I've ordered a teensy 3.2 to have a play with.

[DBecker]

A CAN transceiver requires a much different semiconductor process than typical logic in order to provide the full protection.  The LPC part is the only one that include the transceiver in the package, with higher price and reduced functionality in other aspects.

The least expensive way to start with CAN is buying one of the inexpensive FleaBay modules that has a MC2515 CAN controller and transceiver.  It needs a 5V supply (as do all CAN transceivers that meet the spec), but can work with 3V or 3.3V I/O on any microcontroller you choose.

I'm not a huge fan MC2515, but it works well enough.  Once you get to the point of doing your own board, it's easy enough to change the code to work with a built-in CAN controller with external transceiver.  Most of my boards have used the STM32.  The only quirk there is that the older parts, before the STM32F4, can't use the CAN controller and USB at the same time.  That's bitten may people because it's a unexpected and absurd limitation.

[langwadt]

A CAN transceiver requires a much different semiconductor process than typical logic in order to provide the full protection.  The LPC part is the only one that include the transceiver in the package, with higher price and reduced functionality in other aspects.

The least expensive way to start with CAN is buying one of the inexpensive FleaBay modules that has a MC2515 CAN controller and transceiver.  It needs a 5V supply (as do all CAN transceivers that meet the spec), but can work with 3V or 3.3V I/O on any microcontroller you choose.

I'm not a huge fan MC2515, but it works well enough.  Once you get to the point of doing your own board, it's easy enough to change the code to work with a built-in CAN controller with external transceiver.  Most of my boards have used the STM32.  The only quirk there is that the older parts, before the STM32F4, can't use the CAN controller and USB at the same time.  That's bitten may people because it's a unexpected and absurd limitation.

http://www.ti.com/lit/an/slla337/slla337.pdf

[DBecker]

A CAN transceiver requires a much different semiconductor process than typical logic in order to provide the full protection.  The LPC part is the only one that include the transceiver in the package, with higher price and reduced functionality in other aspects.

The least expensive way to start with CAN is buying one of the inexpensive FleaBay modules that has a MC2515 CAN controller and transceiver.  It needs a 5V supply (as do all CAN transceivers that meet the spec), but can work with 3V or 3.3V I/O on any microcontroller you choose.

I'm not a huge fan MC2515, but it works well enough.  Once you get to the point of doing your own board, it's easy enough to change the code to work with a built-in CAN controller with external transceiver.  Most of my boards have used the STM32.  The only quirk there is that the older parts, before the STM32F4, can't use the CAN controller and USB at the same time.  That's bitten may people because it's a unexpected and absurd limitation.

http://www.ti.com/lit/an/slla337/slla337.pdf

Read that App note carefully. They have a 3.3V supply transceiver that is functional, and it works when put on a network with other devices.  But it's not generating a symmetric differential signal.  It's driving the high line much less than the low line.  That doesn't meet the specs.   It will produce unpredictable distortion when confronted with nodes that have symmetrical noise filters. There will be marginal cases where a spec-compliant CAN  transceiver works and a skeezy "it works on the bench" approach doesn't.

[JPortici]

The only quirk there is that the older parts, before the STM32F4, can't use the CAN controller and USB at the same time.  That's bitten may people because it's a unexpected and absurd limitation.

good to know, i'm in the early stage of a new gadget that needs two separate can busses, usb and that occupies as little pcb area as possible, not many other peripherals. i can't seem to find anything smaller than 64 pin tqfp (dspic/pic32/stm32f2) without entering the BGA realm. I was considering STM but after this I think i'll stay with a dspic..

[Simon]

my teensy 3.2 arrived today, the 3.6 supports two can busses.

[jnz]

I know a giy that uses the MCP2551 in all his stuff. I think it's a case of once you have found it and written the libraries for it you just keep using it. I've ordered a teensy 3.2 to have a play with.

You mean the 2515 can controller. The 2551 is a transceiver and it's a POS. Don't ever use it. Bad part! Their "second gen" transceivers are better I think.

Read that App note carefully. They have a 3.3V supply transceiver that is functional, and it [only] works when put on a network with other devices [of the same type]. 

Exactly. Maxim also has a 3.3V CAN Transceiver, but these do not work with other in the CAN standard parts. Only works when all the parts are the same stupid 3.3V type. Definitely outside of spec.

The LPC part is the only one that include the transceiver in the package, with higher price and reduced functionality in other aspects.

The only quirk there is that the older [STM32] parts , before the STM32F4, can't use the CAN controller and USB at the same time.  That's bitten may people because it's a unexpected and absurd limitation.

There is also the MCP25625 which is a 2515 controller with an integrated transceiver, but like you, I'm not a big fan of the 2515. I have it in a product we've made a few thousand of, but it's doing so little work I'm not terribly concerned with it.

Ah yes, the STM32F1 CAN + USB... they share the same memory because... I don't know why. The later F2/F3 parts are better and I think even the F3 doesn't have that issue, don't know, I don't use USB.

You and I should be CAN friends!

[jnz]

Microchip meant to be bringing out the MCP2517FD CAN-FD controller but its all gone quiet.

Even the Kvaser presentation has removed mentioning the MCP2517FD chip.
https://www.kvaser.com/wp-content/uploads/2016/10/comparing-can-fd-with-classical-can.pdf

Whoa. That's EXACTLY what I'm looking for. Even had a call in with Microchip about it.  Wonder why they went dark!?

Best I can think of is that FD is a mess right now! There is Bosch FD and ISO 11898 FD... Looks like all the micro mfgs that offer FD solution are using the Bosch spec, but all the cars and equipment want to use the ISO spec. Best I can tell, all the FD controllers on the market right now are about to be obsolete when ISO-FD comes about. Maybe new parts have a bit for which mode to use, maybe there is just unfortunate fragmentation.

I kind of wonder if Microchip/Kvaser put together a part and realized they were about to be burned with the incompability - shelved it until ISO ratified their spec (done I think) and now need to make new parts? Only reason I can think of.

[SKPang]

There are some CAN-FD controller available but they are all inside a big micro-controller.

I've got a CAN-FD USB interface from Peak System. Took it apart and see what they used. They implemented the CAN-FD in FPGA.

[DBecker]

There are some CAN-FD controller available but they are all inside a big micro-controller.

I've got a CAN-FD USB interface from Peak System. Took it apart and see what they used. They implemented the CAN-FD in FPGA.

Hmmm, interesting approach.  It sounds programming intensive, but it may be the best approach if you have the manpower and need an early CAN-FD product.

Personally, I don't see the value of CAN-FD.  It's like adding 7.1 digital sound to composite video.  It keep all of the oddness and limitations of CAN, while adding full-redesign complexity for only a minor boost in speed.

[JPortici]

according to a kvaser rep, a great boost in speed when you have to push firmware updates to the ECUs, not much else.
Still a PITA because all nodes must be updated with a can-fd transceiver (even if the controller doesn't support it) but guess who's gonna do it first (yep, three letter car manufacturer)

[kaz911]

CAN-FD is okay for large data that does not occur on a regular basis. In NMEA-2000 CAN-BUS there is something similar called FastPacket - which was one of the only differences from "normal" CAN bus Device Net standard. I have not read the CAN-FD specs in detail but similar purpose.

TI CAN-FD transceiver(s): http://www.ti.com/product/SN65HVD266

[jnz]

There are some CAN-FD controller available but they are all inside a big micro-controller.
I've got a CAN-FD USB interface from Peak System. Took it apart and see what they used. They implemented the CAN-FD in FPGA.

Read my post above. BE CAREFUL.

CAN-FD even in the big micros right now, is Bosch FD 1.0 it is NOT ISO 11898-1:201x

When FD gets adopted it'll be used mostly with the ISOspec. The Non-ISO won't see much use imo. The real fun will be that I'm betting in the near future there will be a bit in new micros to switch between the FD 1.0 spec and the ISO spec. (iirc, the difference is in bit stuffing numbers)

[SKPang]

Looking at the data sheet for the SAMV70Q20
http://www.atmel.com/Images/Atmel-11297-32-bit-Cortex-M7-Microcontroller-SAM-V70Q-SAM-V70N-SAM-V70J_Datasheet.pdf

It implies it is to ISO 11898-1

Not sure the difference between ISO 11898-1 and ISO 11898-1:201x though.

 

[jnz]

Looking at the data sheet for the SAMV70Q20
http://www.atmel.com/Images/Atmel-11297-32-bit-Cortex-M7-Microcontroller-SAM-V70Q-SAM-V70N-SAM-V70J_Datasheet.pdf

It implies it is to ISO 11898-1

Not sure the difference between ISO 11898-1 and ISO 11898-1:201x though.

Well how about that!!! First one I've seen! A switch bit, just like I said. Even the new STM H7 is locked to Bosch spec only.

Code: [Select]

NISO: Non-ISO Operation
If this bit is set, the MCAN uses the CAN FD frame format as specified by the Bosch CAN FD Specification V1.0.
0: CAN FD frame format according to ISO11898-1 (default).
1: CAN FD frame format according to Bosch CAN FD Spec 1.0

That's pretty shocking actually. Because if you look at the ATMEL C21 series which was made at about the same time as the V70, it has no such bit. So they have two CAN FD peripherals made at about the same time and they have different default and potential functions.

Makes me jealous of the M7s, and also makes me think that the C21 is a dog.

11898-1 is CAN 2.0 A/B, 11898-1:2015 is the same but adds the an FD spec, it's just slightly different from what the CAN group thought FD should be.

[DBecker]

Wow, this turned into a really useful thread.

I do have to wonder if CAN-FD will gain traction.  It's up against Automotive Ethernet.  Between raw speed and lower overhead, Automotive Ethernet is at least 100x faster.  If the only place CAN-FD makes sense is offline updating ECU firmware (e.g. a vehicle sitting in a service bay), that's a pretty narrow use case.  Especially when the market may be switching over to online updates.  Dropping last generation's 20-40 minute firmware update to 2-5 minutes is appealing.  But firmware size only grows, making CAN-FD a solution that has missed its window.

[JPortici]

Wow, this turned into a really useful thread.

I do have to wonder if CAN-FD will gain traction.  It's up against Automotive Ethernet.  Between raw speed and lower overhead, Automotive Ethernet is at least 100x faster.  If the only place CAN-FD makes sense is offline updating ECU firmware (e.g. a vehicle sitting in a service bay), that's a pretty narrow use case.  Especially when the market may be switching over to online updates.  Dropping last generation's 20-40 minute firmware update to 2-5 minutes is appealing.  But firmware size only grows, making CAN-FD a solution that has missed its window.

not really, when for example Audi and VW push out minor updates every month or so.. everytime a car need servicing there is at least one update pending.
I think that can FD will slowly gain traction. the network is already there, from what i understand you just have to replace the transceiver in the nodes, they don't have to be equipped with a FD controller and it should be an almost painless transition. switching to etherned could mean to rethink the entire network

[jnz]

Wow, this turned into a really useful thread.

I do have to wonder if CAN-FD will gain traction.  It's up against Automotive Ethernet.  Between raw speed and lower overhead, Automotive Ethernet is at least 100x faster.  If the only place CAN-FD makes sense is offline updating ECU firmware (e.g. a vehicle sitting in a service bay), that's a pretty narrow use case.  Especially when the market may be switching over to online updates.  Dropping last generation's 20-40 minute firmware update to 2-5 minutes is appealing.  But firmware size only grows, making CAN-FD a solution that has missed its window.

Totally different deal. Auto Ethernet is still point to point connection, not a star network. CAN-FD will replace Flex which was a mistake-protocol. So right now, the usefulness is in flashing. Soon, it'll be a dedicated large packet or bit rate switched protocol used to run the critical systems. Another topic on ethernet is that there isn't even remotely a clear standard yet, broadcom has the edge but they'll figure out a way to license it poorly and get passed by something else. People forget how well CAN works in harsh environments. You're going to see CAN-FD in fighter jets.

CAN-FD missed it's window? I disagree. I'm pretty sure it's going to remain the absolute standard for harsh environment "high speed" communication for some. Considering we're mostly all happy using UART still, raw speed isn't the only factor that makes or breaks a protocol.

[jnz]

not really, when for example Audi and VW push out minor updates every month or so.. everytime a car need servicing there is at least one update pending.
I think that can FD will slowly gain traction. the network is already there, from what i understand you just have to replace the transceiver in the nodes, they don't have to be equipped with a FD controller and it should be an almost painless transition. switching to etherned could mean to rethink the entire network

Sort of. There are a couple ways to get CAN-FD into a system without a tear-up of modules that don't need FD frames.

1. A PARTIAL NETWORKING transceiver. This allows the module to sleep while FD frames are being transmitted and allow for special wake-up frames to be sent when the FD traffic is gone. These aren't just normal 8pin transceivers, they're much "smarter" modules that are SPI driven. More expensive.

2. NXP has an "FD SHIELD" transceiver. This prevents FD frames that hit a CAN 2.0 / NonFD module from causing errors on the bus. The module still sees there was a bad CAN message sent by someone (an FD frame it can't understand) but it won't try and shut the bus down.

That said, Atmel's C21 chip I wrote about a few posts ago has errata notes that despite it being an FD chip can not work in mixed frames mode. Ugh.

Soon enough FD modules will hit the market in smaller M0/M3/M4 parts, but the ISO spec was only recently ratified so it may be a little while. Vehicles and applications that use gateways will be the first to adopt on those gateway lines, but it won't do anything downstream to non-FD module.