Which arm to use with can bus and ease of use in mind - Page 1
Forum section: electronics / general

author: Simon
author_rank: Unknown
timestamp: February 04, 2017, 08:58:54 pm
content: 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.

author: jnz
author_rank: Frequent Contributor
timestamp: February 05, 2017, 05:40:20 am
content: 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?

author: SKPang
author_rank: Unknown
timestamp: February 05, 2017, 10:49:04 am
content: If you want something easy to use and have a great library look at Teensy 3.2I'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.

author: Simon
author_rank: Unknown
timestamp: February 05, 2017, 01:19:11 pm
content: 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.

author: JPortici
author_rank: Super Contributor
timestamp: February 05, 2017, 01:54:41 pm
content: 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

author: Simon
author_rank: Unknown
timestamp: February 05, 2017, 01:58:17 pm
content: 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.

author: JPortici
author_rank: Super Contributor
timestamp: February 05, 2017, 02:17:53 pm
content: 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

author: MagicSmoker
author_rank: Super Contributor
timestamp: February 05, 2017, 02:32:59 pm
content: Quote from: Simon on February 05, 2017, 01:19:11 pmCheck out this guy's work:https://github.com/collin80/due_canHe 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.

author: Simon
author_rank: Unknown
timestamp: February 05, 2017, 02:37:51 pm
content: I see yes the Arduino due ARM has CAN a periphery but no library for it. This might be an option.

author: langwadt
author_rank: Super Contributor
timestamp: February 05, 2017, 04:48:15 pm
content: CAN is straight forward with the standard STM library and with a $10 nucleo board you get a proper debugger

author: Simon
author_rank: Unknown
timestamp: February 05, 2017, 09:39:20 pm
content: Quote from: langwadt on February 05, 2017, 04:48:15 pmI 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.

author: nctnico
author_rank: Super Contributor
timestamp: February 05, 2017, 10:19:10 pm
content: 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.

author: langwadt
author_rank: Super Contributor
timestamp: February 05, 2017, 10:30:00 pm
content: Quote from: Simon on February 05, 2017, 09:39:20 pmit is a bit silly that they require an account to download stuff but I've never had problems creating an accountthe STM'ified eclipse is here:http://www.openstm32.org/

author: Simon
author_rank: Unknown
timestamp: February 06, 2017, 07:33:31 am
content: Quote from: nctnico on February 05, 2017, 10:19:10 pmcurrently 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.

author: Simon
author_rank: Unknown
timestamp: February 06, 2017, 07:35:50 am
content: Quote from: langwadt on February 05, 2017, 10:30:00 pmThanks, 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 ?

author: langwadt
author_rank: Super Contributor
timestamp: February 06, 2017, 09:18:56 am
content: Quote from: Simon on February 06, 2017, 07:35:50 amIt 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

author: nctnico
author_rank: Super Contributor
timestamp: February 06, 2017, 10:18:12 am
content: Quote from: Simon on February 06, 2017, 07:33:31 amIn 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.

author: JPortici
author_rank: Super Contributor
timestamp: February 06, 2017, 10:55:15 am
content: (also, i find LPCXpresso to be so much better than any free/open source STM IDE counterpart)

author: Simon
author_rank: Unknown
timestamp: February 06, 2017, 12:53:32 pm
content: Quote from: SKPang on February 05, 2017, 10:49:04 amApparently it can only receive CAN messages and needs an external CAN controller to do proper CAN bus comms

author: Simon
author_rank: Unknown
timestamp: February 06, 2017, 12:55:59 pm
content: Although according to the datasheet the LPC11C22/C24 have a CAN transceiver

author: SKPang
author_rank: Unknown
timestamp: February 06, 2017, 12:58:00 pm
content: Quote from: Simon on February 06, 2017, 12:53:32 pmThat is not quite correct. The Teensy has built in controller already. You need an external CAN transceiver.

author: SKPang
author_rank: Unknown
timestamp: February 06, 2017, 01:00:13 pm
content: Quote from: Simon on February 06, 2017, 12:55:59 pmCorrect. The LPCXPresso IDE has some nice examples for the chip.

author: Simon
author_rank: Unknown
timestamp: February 06, 2017, 01:00:31 pm
content: Quote from: SKPang on February 06, 2017, 12:58:00 pmAre 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?

author: SKPang
author_rank: Unknown
timestamp: February 06, 2017, 01:02:41 pm
content: You need a CAN transceiver, something like a SN65HVD231http://www.ti.com/product/SN65HVD231

author: Simon
author_rank: Unknown
timestamp: February 06, 2017, 01:50:45 pm
content: OK the line driver not the controller that is in the uCSent from my phone so mind the autocorrect.

author: jnz
author_rank: Frequent Contributor
timestamp: February 06, 2017, 05:56:24 pm
content: Quote from: JPortici on February 05, 2017, 01:54:41 pmMicrochip'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.

author: jnz
author_rank: Frequent Contributor
timestamp: February 06, 2017, 06:07:42 pm
content: Quote from: SKPang on February 06, 2017, 01:00:13 pmFWIW... 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.

author: JPortici
author_rank: Super Contributor
timestamp: February 06, 2017, 06:22:11 pm
content: Quote from: jnz on February 06, 2017, 05:56:24 pmNever claimed it was simpleI 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.

author: kaz911
author_rank: Super Contributor
timestamp: February 06, 2017, 07:26:53 pm
content: 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)...

author: jnz
author_rank: Frequent Contributor
timestamp: February 06, 2017, 07:30:35 pm
content: Quote from: JPortici on February 06, 2017, 06:22:11 pmThat's OK, neither is MicrochipQuoteOh 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.

author: SKPang
author_rank: Unknown
timestamp: February 06, 2017, 07:40:12 pm
content: 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

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: February 06, 2017, 10:16:45 pm
content: Quote from: nctnico on February 06, 2017, 10:18:12 amUnfortunately, 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.

author: JPortici
author_rank: Super Contributor
timestamp: February 07, 2017, 07:26:59 am
content: Quote from: jnz on February 06, 2017, 07:30:35 pmthe 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.QuoteAnd i saw so many mcp2551 in products that i thought it was the max232 of can transceivers.. I'm too new ain't I?

author: Simon
author_rank: Unknown
timestamp: February 07, 2017, 07:45:00 am
content: 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.

author: DBecker
author_rank: Frequent Contributor
timestamp: February 07, 2017, 08:59:31 pm
content: 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.

author: langwadt
author_rank: Super Contributor
timestamp: February 07, 2017, 10:26:34 pm
content: Quote from: DBecker on February 07, 2017, 08:59:31 pmhttp://www.ti.com/lit/an/slla337/slla337.pdf

author: DBecker
author_rank: Frequent Contributor
timestamp: February 09, 2017, 07:35:57 am
content: Quote from: langwadt on February 07, 2017, 10:26:34 pmRead 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.

author: JPortici
author_rank: Super Contributor
timestamp: February 09, 2017, 10:27:35 am
content: Quote from: DBecker on February 07, 2017, 08:59:31 pmgood 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..

author: Simon
author_rank: Unknown
timestamp: February 09, 2017, 08:28:01 pm
content: my teensy 3.2 arrived today, the 3.6 supports two can busses.

author: jnz
author_rank: Frequent Contributor
timestamp: February 09, 2017, 10:58:51 pm
content: Quote from: Simon on February 07, 2017, 07:45:00 amYou 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.Quote from: DBeckerExactly. 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.Quote from: DBecker on February 07, 2017, 08:59:31 pmThere 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!

author: jnz
author_rank: Frequent Contributor
timestamp: February 09, 2017, 11:02:36 pm
content: Quote from: SKPang on February 06, 2017, 07:40:12 pmWhoa. 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.

author: SKPang
author_rank: Unknown
timestamp: February 09, 2017, 11:12:27 pm
content: 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.

author: DBecker
author_rank: Frequent Contributor
timestamp: February 09, 2017, 11:55:45 pm
content: Quote from: SKPang on February 09, 2017, 11:12:27 pmHmmm, 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.

author: JPortici
author_rank: Super Contributor
timestamp: February 10, 2017, 06:31:15 am
content: 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)

author: kaz911
author_rank: Super Contributor
timestamp: February 10, 2017, 07:30:25 am
content: 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

author: jnz
author_rank: Frequent Contributor
timestamp: February 10, 2017, 07:00:50 pm
content: Quote from: SKPang on February 09, 2017, 11:12:27 pmRead 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:201xWhen 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)

author: SKPang
author_rank: Unknown
timestamp: February 10, 2017, 07:31:35 pm
content: Looking at the data sheet for the SAMV70Q20http://www.atmel.com/Images/Atmel-11297-32-bit-Cortex-M7-Microcontroller-SAM-V70Q-SAM-V70N-SAM-V70J_Datasheet.pdfIt implies it is to ISO 11898-1Not sure the difference between ISO 11898-1 and ISO 11898-1:201x though.

author: jnz
author_rank: Frequent Contributor
timestamp: February 11, 2017, 06:13:20 am
content: Quote from: SKPang on February 10, 2017, 07:31:35 pmWell 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:NISO: Non-ISO OperationIf 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.0That'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.

author: DBecker
author_rank: Frequent Contributor
timestamp: February 11, 2017, 05:38:14 pm
content: 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.

author: JPortici
author_rank: Super Contributor
timestamp: February 11, 2017, 06:00:59 pm
content: Quote from: DBecker on February 11, 2017, 05:38:14 pmnot 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

author: jnz
author_rank: Frequent Contributor
timestamp: February 11, 2017, 11:05:39 pm
content: Quote from: DBecker on February 11, 2017, 05:38:14 pmTotally 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.

author: jnz
author_rank: Frequent Contributor
timestamp: February 11, 2017, 11:12:03 pm
content: Quote from: JPortici on February 11, 2017, 06:00:59 pmSort 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.