CAN (arduino) Kickstarter, what do you think?

[JohanHoltby]

Hi all,
I have followed EEVblog from about #72 but have not engaged in this forum until now. I work as a test engineer and designs production tests for electronics. I'm investigating how to make a Kickstarter project and would like to have some feed back and would like to have your thoughts and why you think so. Of course I have thought very much about this topics but would greatly appreciate your thoughts.

Short description
I'm making a CAN based Atmega board to allow programming of multiple units through the CAN bus using a boat loader (CAN and serial based). This should also be Arduino compatible.
Benefits (not in order):
a. No JTAG daisy chain is needed (programming only using a USB cable and a serial boat-loader (will have a ISP/debug wire connector not mounted)).
b. Can program devices spread out over a long distance.
c. No need to worry about jamming of wireless solutions.
d. CAN is a very stable protocol.
e. This is a easy step stone to start using CAN and it will be open hardware.

My questions:
1. Should I make it?
2. Should I make the board small with only some of the pins exposed or more complex and maybe include a small prototyping board area?
3. Should I keep the price low and only use 16kb unit or higher?
4. Should I have a DC to DC converter mounted on the board and should it handle higher currents like 0.5A to drive external electronics?
5. Should I ship the board with the connector mounted or not to allow for flexibility?
6. Should all units be the same or should I have a Interface unit to connect to the CAN bus and have simpler units without USB capability?
7. What is a good price point?

I guess that is enough to start with

Thank you very much for your feedback
/Johan

[tron9000]

I'm making a CAN based Atmega board to allow programming of multiple units through the CAN bus using a boat loader (CAN and serial based). This should also be Arduino compatible.

Bit unwieldy to stick on your project! I've seen shields for everything, but this!

I think there are CAN shields already out there for the arduino range, but with regards to your questions:
1. up to you. Buidling a prototype should gauge complexity and feasibility
4. that's more up to your power requirements of the board and if you choose to have a prototyping area.
7. I think Dave did do a video on planning and costing your project, have a look on the youtube channel.

[JohanHoltby]

Bit unwieldy to stick on your project! I've seen shields for everything, but this!

Thank you for your response.
It's not intended to be something to stick on your project rather to be something which is the core.

I think there are CAN shields already out there for the arduino range, but with regards to your questions:
1. up to you. Buidling a prototype should gauge complexity and feasibility
4. that's more up to your power requirements of the board and if you choose to have a prototyping area.
7. I think Dave did do a video on planning and costing your project, have a look on the youtube channel.

1. The feasibility is not really a problem since it's a fairly simple project.
4. So if I have no prototyping area I should not have a strong (0.5A) DC to DC converter?
7. Do you mean "Open Source Hardware Explained - EEVblog #195" or do you mean one of the once in regards to uCurrent project (#127 or  #239)?

Thank you for your thoughts!

[tron9000]

erm...#127 and #239 would probably be useful for you. If you are thinking about producing these.

with regards to the DC-DC power supply: I would say your "customers" would find it useful to have a decent amount of power to play with for prototyping, but on the other hand, an on board DC-DC converter would push up price per unit...

BTW, CAN is commonly found in vehicles to communicate between devices - are you planning on targeting this area too?

[Wilksey]

Bit unwieldy to stick on your project! I've seen shields for everything, but this!

Thank you for your response.
It's not intended to be something to stick on your project rather to be something which is the core.

I think you missed the boat with this one.

[JohanHoltby]

BTW, CAN is commonly found in vehicles to communicate between devices - are you planning on targeting this area too?

I intend to make it as modular as I can but it will not be the target market.

I think you missed the boat with this one.

Pleas elaborate . (I understand the joke with the image, but pleas do elaborate).
How do you normally handle when you have multiple units which interacts and you want to program them through one connection?

[max_torque]

Like most things, the Hardware development task for a CAN bootloader device is pretty simple, but the Software side is certainly not!  Loads of project fall over on crappy interface between the user and the device.  Assuming you are going to write your own CAN protocol for sending the flash data over the network, then you'll also need some sort of front end software on the PC etc?

[max_torque]

BTW, CAN is commonly found in vehicles to communicate between devices - are you planning on targeting this area too?

I intend to make it as modular as I can but it will not be the target market.

I think you missed the boat with this one.

Pleas elaborate . (I understand the joke with the image, but pleas do elaborate).
How do you normally handle when you have multiple units which interacts and you want to program them through one connection?

Research and understand CCP (Can Calibration protocol), as a good starter for data transmission over CAN.   Using an already defined protocol could be an advantage, but also comes with a lot of baggage, and is not that useful for in-vehicle use where pretty much all modules are locked and need a handshake seed/key exchange before they can be reprogrammed etc

[JohanHoltby]

Like most things, the Hardware development task for a CAN bootloader device is pretty simple, but the Software side is certainly not!  Loads of project fall over on crappy interface between the user and the device.  Assuming you are going to write your own CAN protocol for sending the flash data over the network, then you'll also need some sort of front end software on the PC etc?

I intend to have a serial command you can run to tell the USB to CAN controller (avr chip with code) to forward the ISP programming commands over can to a set address.
I also intend to have a serial command to change a CAN address on a device to wither the first empty and return that value or a address dictated over serial, since all devices will have the same CAN address after production programming.

Would i be preferred to have a more advanced setup with a GUI to allow configuration of uploading hex files from directories after a single command?

Thank you for your feedback!

[JohanHoltby]

Research and understand CCP (Can Calibration protocol), as a good starter for data transmission over CAN.   Using an already defined protocol could be an advantage, but also comes with a lot of baggage, and is not that useful for in-vehicle use where pretty much all modules are locked and need a handshake seed/key exchange before they can be reprogrammed etc

Will do. Thank you for the pointer since I have not investigate the data layer yet! It's always nice to not have to invent the wheel from scratch even if I don't think I will use the default CCP(or XCP).

[magetoo]

I would be interested in an Arduino with CAN style board, it's on my "to play with" list.

But maybe that is putting the cart before the horse?  Do you have a specific application in mind?  Might be useful to think about a does X thing board, that just happens to use CAN.  Sensor networks, say, or lighting control.

Some thoughts below.  Sorry about the wall of text, I tried to edit it down as best I could.  Probably still dumb though.

I intend to have a serial command you can run to tell the USB to CAN controller (avr chip with code) to forward the ISP programming commands over can to a set address.

I was going to suggest doing exactly this!

You say "USB to CAN controller", and I guess that is a different way of naming the interface board you mention in [6]?  Do you see that board being similar to the others, or just a programmer?

I was thinking the interface board could have a jumper / switch to flip it between forwarding the command stream for programming, and programming itself.  (Or a command, but then the interface board can't simply be a dumb pipe that just forwards everything byte-for-byte.)

A separate interface/master board could also be larger in size and accept shields, or whatever else is useful.  "Slave" boards would be small, say like the DIP style Arduinos (Nano?), which I'm thinking is what you might want for sensor nodes and such.

I guess that's number 2 and 6.

3 and 7.

Yes, keep the price down, and keep it simple.  Anything that is non-trivial is going to be eaten by Ethernet/Wifi and IP anyway; where CAN comes in is simplicity (and real-time control, don't know if there is a hobbyist market for that though).

That said, I would pay for a full-featured master board with all the bells and whistles.

4. For what I want to do, a DC-DC converter would be a useful thing to have, but it might just waste space for others.  Would it be possible to have space/footprints for the components, while also have it be part of the prototyping area?  Might give you some flexibility.

I also intend to have a serial command to change a CAN address on a device to wither the first empty and return that value or a address dictated over serial, since all devices will have the same CAN address after production programming.

"CAN address"?  Are you thinking of putting a higher level, addressed, protocol on top of CAN as standard?  One of the neat features of CAN, for me, is that it doesn't have addresses.

Anyway, I can see how it might be useful to have a command to set a unique ID (or even a shared ID) that is stored somewhere.  The bootloader could then (optionally?) start up in a mode where it first needs to see a specific activation sequence with its own ID as the data payload before accepting programming commands over CAN.  (And then you'd only need to reserve one message ID for all programming too.  Or two, with the second one for broadcast.)

Not sure how that fits in with the Arduino ecosystem, but it should work from a command line at least.

Would i be preferred to have a more advanced setup with a GUI to allow configuration of uploading hex files from directories after a single command?

Just provide the basics, like a command line tool, and let someone else make the GUI.  Otherwise you will get flamed by people like me for not making it cross-platform.

[JohanHoltby]

But maybe that is putting the cart before the horse?  Do you have a specific application in mind?  Might be useful to think about a does X thing board, that just happens to use CAN.  Sensor networks, say, or lighting control.

The idea did come from when I was developing a IR fens and it was a bugger to have a programming solution which was easy to start with so that I could program them all in one go. But also other projects have come in to mind like quadrocopter with engine speed controls using CAN instead of PWM control for more control and stability.

You say "USB to CAN controller", and I guess that is a different way of naming the interface board you mention in [6]?  Do you see that board being similar to the others, or just a programmer?

It's a special board which is a USB programmer and have the power supply from the USB or an external source and outputs 5 volt on the bus (I intend to have GND, +5V, V_external (unregulated) and  RESET together with the CAN_H and CAN_L).

I was thinking the interface board could have a jumper / switch to flip it between forwarding the command stream for programming, and programming itself.  (Or a command, but then the interface board can't simply be a dumb pipe that just forwards everything byte-for-byte.)

A separate interface/master board could also be larger in size and accept shields, or whatever else is useful.  "Slave" boards would be small, say like the DIP style Arduinos (Nano?), which I'm thinking is what you might want for sensor nodes and such.

....

4. For what I want to do, a DC-DC converter would be a useful thing to have, but it might just waste space for others.  Would it be possible to have space/footprints for the components, while also have it be part of the prototyping area?  Might give you some flexibility.

I have been struggling with this question and when I see you say it I totally agree. Especially to keep the price low as you state below. There will be two types of boards (one advanced with the programmer and one simple). When I will use it my self I want to keep the cost down and will only have some small components like a total of like 7 through-hole for the small nodes. So I will add a small prototype area of 2.54 spacing 10*10 or 15 *15 holes. Which size would you suggest?

"CAN address"?  Are you thinking of putting a higher level, addressed, protocol on top of CAN as standard?  One of the neat features of CAN, for me, is that it doesn't have addresses.

Anyway, I can see how it might be useful to have a command to set a unique ID (or even a shared ID) that is stored somewhere.  The bootloader could then (optionally?) start up in a mode where it first needs to see a specific activation sequence with its own ID as the data payload before accepting programming commands over CAN.  (And then you'd only need to reserve one message ID for all programming too.  Or two, with the second one for broadcast.)

Not sure how that fits in with the Arduino ecosystem, but it should work from a command line at least.

I will have a node ID which the programmer will use.
So the flow I'm currently working on is:
1. The programmer is connected to by the serial port and the board is there by toggled to RESET (if the programming jumper is present on the reset signal).
2. The boot-loader receives the node to program or the connection times out after 1 second (the timeout is set by the EEPROM but not less than 0.5 sec to avoid not usable chip).
3. The RESET is toggle is disconnected by the AVR using a mosfet or transistor.
4. All the following commands is responded to as if it where a standard STK500(as Ardruino do it) whit the exception it sends it over the CAN BUS to the right node.
5. Prior to the first transmit the RESET line is toggled low (this have rectifiers so that the debug wire still can be used) RESETING all the devices loading the boot loader and then addressing the node to program so it do not time out and then transfer all the data back and fourth.

Just provide the basics, like a command line tool, and let someone else make the GUI.  Otherwise you will get flamed by people like me for not making it cross-platform.

The better .

Thank you very much for your valuable feedback. It has helped me straight out some of my question marks.

[magetoo]

It's a special board which is a USB programmer and have the power supply from the USB or an external source and outputs 5 volt on the bus (I intend to have GND, +5V, V_external (unregulated) and  RESET together with the CAN_H and CAN_L).

Is having multiple power lines strictly necessary?  If you get rid of +5V in favor of regulating it locally, you could use regular networking cable with consumer PoE injectors.

On the other hand, networking cable might not be the best alternative for something that is a bus rather than point-to-point.

I think there is also an argument to be made for not having power in the same cable at all.  Most of the time, at least indoors, it will be more convenient to look for the nearest wall socket than having power come through low-voltage wiring.  (And when it's not, one can run two separate cables.)

Would it be possible to have space/footprints for the components, while also have it be part of the prototyping area?  Might give you some flexibility.

I have been struggling with this question and when I see you say it I totally agree. Especially to keep the price low as you state below. There will be two types of boards (one advanced with the programmer and one simple). When I will use it my self I want to keep the cost down and will only have some small components like a total of like 7 through-hole for the small nodes. So I will add a small prototype area of 2.54 spacing 10*10 or 15 *15 holes. Which size would you suggest?

I have no idea, but I'm guessing that if you want more than just a few components you would want to make a PCB anyway.

A couple of common SMT footprints, plus space for the DC-DC maybe?  A 2.54mm grid through hole area is easy to add yourself (stripboard), but if you need somewhere to put that one chip that only comes in surface mount...

Take a look at what others have done for inspiration.  (First one that came to mind.)

I will have a node ID which the programmer will use.
So the flow I'm currently working on is:
[...]

Ok, I think I get it.  So the reset line is for "in system debugging" when you screw up and need to start over, without having to go around visiting every node and pressing a button.  :-)

I'm guessing you want to disable resets later, when things are up and running?  Could reset be shared with some other signal somehow?  Seems like a waste to have an unused wire.

Thank you very much for your valuable feedback. It has helped me straight out some of my question marks.

That's very kind.  Don't take anything I say too seriously.

[JohanHoltby]

Is having multiple power lines strictly necessary?  If you get rid of +5V in favor of regulating it locally, you could use regular networking cable with consumer PoE injectors.

On the other hand, networking cable might not be the best alternative for something that is a bus rather than point-to-point.

I think there is also an argument to be made for not having power in the same cable at all.  Most of the time, at least indoors, it will be more convenient to look for the nearest wall socket than having power come through low-voltage wiring.  (And when it's not, one can run two separate cables.)

I intend to make space for two 6p IDC (e.g. http://www.digikey.se/product-detail/en/3030-06-0103-00/3030-06-0103-00-ND/3883456) but not mount them only send them with the board so the user can connect the connector they want. I like IDC since they are cheap and reliable and so fast o make the right length.

I have no idea, but I'm guessing that if you want more than just a few components you would want to make a PCB anyway.

A couple of common SMT footprints, plus space for the DC-DC maybe?  A 2.54mm grid through hole area is easy to add yourself (stripboard), but if you need somewhere to put that one chip that only comes in surface mount...

Take a look at what others have done for inspiration.  (First one that came to mind.)

I did think kind in that direction but that would add space since the pins need to be exposed to make it useful. (You stated previously I should try to have the nodes as small as posible) The DC to DC footprint I can agree on but the rest would add space. Most of the time I have break-outboards or I just dead bug the components. The 16x16 (might be better than 15*15 when i think about) hole area is just a small area for prototyping without the need to have some other board wiggling around or be attached on top. The idea is so that it's easy to connect some small components. If it's not needed it should be easy to just saw off. I intend to have the Atmega pins exposed at one side. However did you mean that the bigger nodes(with the USB interface). That is something I agree on could greatly benefit having more bells and whistles like the QFN and TFQP footprints. I will look in to that.

Ok, I think I get it.  So the reset line is for "in system debugging" when you screw up and need to start over, without having to go around visiting every node and pressing a button.  :-)

I'm guessing you want to disable resets later, when things are up and running?  Could reset be shared with some other signal somehow?  Seems like a waste to have an unused wire.

The reset wire is used to RESET all devices so that the boot loader is loaded. This makes programming of the the device separately from the application code and any CAN protocol can be used since all units will be in the bootloader code until all programming is done. I will have a 0 ohm resistor which can be soldered away if you wish to disable the risk of resting the device during application. The Debug wire part is that I just stated I will not make debug wire useless since the the RESET line will not be connected directly (if it where it would make debug wire use not possible).

Of course i will have tutorials and example code for application CAN protocol to boost start up time.

So the way I will use the nodes is debugging one using debug wire and once I find the problem I will update all units with the fixed hex with the execution of a batch script. I'm not an Ardruino user but understand the need for Arduriono as a stepping stone in to new technology.

Once again, thank you

[magetoo]

I think there is also an argument to be made for not having power in the same cable at all.

I intend to make space for two 6p IDC (e.g. http://www.digikey.se/product-detail/en/3030-06-0103-00/3030-06-0103-00-ND/3883456) but not mount them only send them with the board so the user can connect the connector they want. I like IDC since they are cheap and reliable and so fast o make the right length.

I'm not sure I understand, does that mean using ribbon cable between nodes?  If you just mean putting a pin header on the node and let people attach what they need then that makes total sense.  (But then why bother sending out IDC connectors?)

A couple of common SMT footprints, plus space for the DC-DC maybe?  A 2.54mm grid through hole area is easy to add yourself (stripboard), but if you need somewhere to put that one chip that only comes in surface mount...

I did think kind in that direction but that would add space since the pins need to be exposed to make it useful. (You stated previously I should try to have the nodes as small as posible) The DC to DC footprint I can agree on but the rest would add space. Most of the time I have break-outboards or I just dead bug the components. The 16x16 (might be better than 15*15 when i think about) hole area is just a small area for prototyping without the need to have some other board wiggling around or be attached on top.

If you worry about space, then definitively leave out the through-hole area.  A 16 by 16 grid is huge!  If I want that kind of space, I can just go down to Kjell and get a through-hole proto board.  Room for one IC and a few passives is what I would aim for, if you need anything more then make a separate PCB.

I still think having a SOP/SOIC footprint would be more useful.  SMT breakout boards is something many hobbyists don't necessarily have around, and they take up even more space.  Also, with SMT you can even use both sides for two different footprints..

However did you mean that the bigger nodes(with the USB interface). That is something I agree on could greatly benefit having more bells and whistles like the QFN and TFQP footprints. I will look in to that.

No, I meant the small ones, that's probably where you'd want something custom like sensors or LED drivers.  For the big boards, there's always shields.

Ok, I think I get it.  So the reset line is for "in system debugging" when you screw up and need to start over, without having to go around visiting every node and pressing a button.  :-)

The reset wire is used to RESET all devices so that the boot loader is loaded.
...
The Debug wire part is that I just stated I will not make debug wire useless since the the RESET line will not be connected directly (if it where it would make debug wire use not possible).

I have no idea what "debug wire" is.  Debugging for me the hobbyist just means "put lots of printf()s or LED blinks in", but it seems you have something else in mind.

(You don't have to explain it, you know better what is needed here.)

[JohanHoltby]

I'm not sure I understand, does that mean using ribbon cable between nodes?  If you just mean putting a pin header on the node and let people attach what they need then that makes total sense.  (But then why bother sending out IDC connectors?)

I did only intend to send the IDC pin header with the plastic around to ensure right orientation every time. Not the connectors which are inserted or maybe doing a "pack" with some cables and connectors with some reward level.

If you worry about space, then definitively leave out the through-hole area.  A 16 by 16 grid is huge!  If I want that kind of space, I can just go down to Kjell and get a through-hole proto board.  Room for one IC and a few passives is what I would aim for, if you need anything more then make a separate PCB.

I still think having a SOP/SOIC footprint would be more useful.  SMT breakout boards is something many hobbyists don't necessarily have around, and they take up even more space.  Also, with SMT you can even use both sides for two different footprints..

I will think back and fourth on that one some more. I understand your concern but there are so many standard formats so I'm not sure how to do. Maybe doing a smaller 11x11 area and having the outer U (leaving the outer side not populated) as the pins of the Atmega and the 6p CAN header (+5V, Vin, GND, RESET, CAN_H, CAN_L).

Will fix this in the schematics and do a order soon for the first prototypes.