After discovering Arduino some time back we found we needed more than the basic nature of the Arduino allowed for. So instead of opting for simplicity, the trademark or the Arduino, we needed to go the other way, the result, LEDuino.
Units all supplied with connectors fitted, this is a complete board, not a kit: no soldering required.
With all of the Arduino Diecimila features, plus a power switch, Vref trimpot and a USB mini-B connector to reduce size and cable drag. With added options:- Separate I2C connector with provision for high current drive
Optional DCC decoder input for model railway types! (Us and many of our users)
Optional CAN bus for industrial and model-railway networking (libraries not available yet)
Application specific connector for LED systems using the TLC594X series of controllers
Design info will be released (schematics and PCB layout in PDF format) we do not use Eagle so we cannot release Eagle files.
After discovering Arduino some time back we found we needed more than the basic nature of the Arduino allowed for. So instead of opting for simplicity, the trademark or the Arduino, we needed to go the other way, the result, LEDuino.
Nice looking board. It's hard to get a feel for the size, but it looks like it's just a bit bigger than the Dieci? I like the idea of custom, more application specific arduino clones such as this. It's a challenge though because it really narrows the audience.
It's good to see another person from Toronto on here.
I've looked into model railroading mainly as an excuse to apply some electronics fun, but I never really got into it besides playing with a friend's immense G-scale system.
I just want to make a coment: when I was developing the Arduino Severino, the ICSP position became an important question of compatibiliyty (for the use with shields) and in your board it seems to be out of the original position.
the ICSP position became an important question of compatibiliyty (for the use with shields)
IMO, it shouldn't be. The ICSP connector is NOT part of the shield interconnection standard, although some of the "protoshield" type shields found it useful to use it to bring "reset" to a reachable position.
That shouldn't be so much an issue with Diecimila and later: RESET is available on the bottom connector "main" pins, AND auto-reset does away with the need to reach the button in the first place...
I can see an argument for it, if you're developing without the bootloader for some reason and need the ICSP to pass up to something physically accessible.
On the other claw, it does waste shield real estate, especially for end-fed connectors.
the ICSP position became an important question of compatibiliyty (for the use with shields)
IMO, it shouldn't be. The ICSP connector is NOT part of the shield interconnection standard, although some of the "protoshield" type shields found it useful to use it to bring "reset" to a reachable position.
That shouldn't be so much an issue with Diecimila and later: RESET is available on the bottom connector "main" pins, AND auto-reset does away with the need to reach the button in the first place...
The simple reality is that the reset signal is available on the power connector and all of the ISP signals (apart from reset) are available on the Arduino-lines 11, 12 & 13. So for us the ISP connector was not an issue.
Our goal was to produce a board that was mechanically compatible with the Diecimila and others. Hence we even stayed with the 1.27mm (.05") offset on the IO pins. My feeling was that the ISP connector didn't form part of the 'standard'. What we needed was to add the various other application specific interfaces to suit our particular needs. Sure this reduces the breadth of market we reach, but it hasn't been a negative so far with sales being quite satisfactory.
Hopefully we will soon have DCC and CAN libraries available.
Sure this reduces the breadth of market we reach, but it hasn't been a negative so far with sales being quite satisfactory.
Just to be clear, I did not mean to imply anything negative about that. It's actually something I meant as positive. Instead of selling 1,000 general arduino clones, you can have 10 groups each selling 100 application specific arduino clones that offer functionality for that group.
Sure this reduces the breadth of market we reach, but it hasn't been a negative so far with sales being quite satisfactory.
Just to be clear, I did not mean to imply anything negative about that. It's actually something I meant as positive. Instead of selling 1,000 general arduino clones, you can have 10 groups each selling 100 application specific arduino clones that offer functionality for that group.
Sorry if I gave the wrong impression, in fact I appreciate your remarks and agree with you 100%.
This product was designed specifically to meet needs which WE have in our organisation. Firstly we do a lot of model railway related stuff so the DCC is common. Secondly, we do a LOT with I2C and we use a variety of speed-up and buffering circuitry, and finally just about everything I seem to touch these days wants CAN in it.
I have CAN in use in PIC's (yuck), AVRs like the AT90CAN128, NXP LPC2378 and similar ARM7 chips, PowerPC's and FPGA based designs. So it made perfect sense to have a CAN enabled 'duino!
The reality is that if I set out to sell a product directly in the Arduino/Freeduino market then the only thing I could compete on would be price. That's pretty pointless, despite the fact that most of my manufacturing is done in China. I would rather offer value added packages that have a smaller user base, but the potential of less competition. That way we also contribute to the entire Arduino pool, rather than polluting it with "yet another 'duino clone".
Can you give any idea of how long the CAN libs will be before release?
I have a CAN based proj coming up very shortly and the libs would be a huge help, even some raw code examples would help if libs not close to completion.
I would appreciate some information on the DCC aspect. I intend to build the various modules needed to run an HO setup and this LEDuino could be just the ticket to get me off and running!
I am working on some CAN code at the moment. I have some basic LEDuino to LEDuino CAN talking happening. I will try to get this into an Arduino lib soon.
Despite a hectic work and development schedule we have finally found enough spare time to get at leas one specialised aspect of the LEDuino working. CAN Bus support was planned in revision A f the LEDuino but never fully implemented. Revision B has been around for over 6 months now and finally we have some reasonable beta quality code working.
Due to the non-availability of the -std=gnu99 option oin the standard Arduino IDE we are using a lightly hacked Arduino-0013 IDE and we have working code for a USB->CAN bus adapter.
We are hoping that this option may be made available in the future, in the meantime should anyone wish to experiment please PM me and I can make the complete code package available to you.
It uses the ATMega168 and the Microchip MCP2515 CAN controller. There is library available for it. Have a look at the website at http://www.siliconrailway.com and the schematic.
Yes it is still available. It is an Arduino with a CAN interface built-in, it is not a shield. RevC is bout to be sent to the board house. If you are interested, send me a private email.
