DCC++ HAT (Raspberry Pi)

[Ngineer]

Well said - I plan to offer a pre-flashed SD card and a case with the power supply too so that it becomes a truly plug-and-play system - all you would then need is a keyboard, mouse, and monitor.

And the Arduino mentioned above?

Sorry for asking, but I've never had one.

I am only using a Raspberry Pi2 with OpenELEC, but that's it. I have no further experience with those small and "geeky" computers.

   Javier

[reinhardtjh]

And the Arduino mentioned above?

No, the DCC++ HAT replaces the Arduino since it has the same ATmega328P processor on board.  So all you need is the Pi and the DCC++ HAT.

At least that's my understanding.

[dcutting]

And the Arduino mentioned above?

Sorry for asking, but I've never had one.

I am only using a Raspberry Pi2 with OpenELEC, but that's it. I have no further experience with those small and "geeky" computers.

   Javier

As reinhardtjh mentioned, this board replaces the arduino, motor shield, and raspberry pi.

Update - I'm working on a new version of the HAT that also includes hardware for an OpenLCC system. There will be one or two RJ45 jacks, and I will also be adding a 5V power supply so that you can simply plug the power supply, HDMI, mouse, and keyboard and start running the device. No micro USB needed. There's also some other improvements coming... stay tuned.

[kiwi64ajs]

Update - I'm working on a new version of the HAT that also includes hardware for an OpenLCC system. There will be one or two RJ45 jacks, and I will also be adding a 5V power supply so that you can simply plug the power supply, HDMI, mouse, and keyboard and start running the device. No micro USB needed. There's also some other improvements coming... stay tuned.

Hi David,

Very interesting - you've been busy...

I took a look at the "BoosterHC HAT V0_2" schematic https://github.com/cescalemodels/BaseStationHAT/blob/master/Hardware/BoosterHC%20HAT%20V0_2.pdf and it looks good. Be great to have an OpenLCB DCC Command Station we can customise.

A few questions and comments:

1) What is the purpose of the TL7660D and the EXP0 connector?

2) If you switch the MCP2551 to a MCP2562 you can eliminate the 3.3V to 5V voltage level converter components as the MCP2562 has separate VIO and VDD pins to handle interfacing to 3.3V controllers and still drive the CAN Bus at 5V.

3) Have you been able to validate the performance of the MCP2515 CAN Controller connected to the RaspBerryPi as I've seen mixed feedback. From an OpenLCB/LCC perspective it's critical to send and receive CAN frames in order.

The MCP2515 is a common chip and there is wide support for it in the Linux kernel and lots of application notes, but it does have issues with buffering and maintaining frame receive ordering. We've used the MCP2515 with the Arduino in early OpenLCB prototypes and battled with it for a while. We eventually gave up and went to using the AVR AT90CAN128 chip with on-chip CAN controller and had a lot more success.

However, recently some other people are wanting to try the MCP2515 again but this time using interrupts, so hopefully that might improve things.
I've got one of the MCP2515 interface board from eBay to try it again on the Raspberry Pi and the Arduino, also someone else has mentioned some work-around for problems in the silicon so that may help too.

4) Would you consider bringing out the PB0(ICP) pin12 + PB1(OC1A) pin 13 on the ATMega328 to a 1x4 header along with GND and +5V as that would let me experiment with adding a LocoNet interface which might be interesting. I don't know how busy the Mega328 is running the DCC++ firmware already but could be useful.

Regards

Alex Shepherd

[dcutting]

Hi David,

Very interesting - you've been busy...

I took a look at the "BoosterHC HAT V0_2" schematic https://github.com/cescalemodels/BaseStationHAT/blob/master/Hardware/BoosterHC%20HAT%20V0_2.pdf and it looks good. Be great to have an OpenLCB DCC Command Station we can customise.

A few questions and comments:

1) What is the purpose of the TL7660D and the EXP0 connector?

2) If you switch the MCP2551 to a MCP2562 you can eliminate the 3.3V to 5V voltage level converter components as the MCP2562 has separate VIO and VDD pins to handle interfacing to 3.3V controllers and still drive the CAN Bus at 5V.

3) Have you been able to validate the performance of the MCP2515 CAN Controller connected to the RaspBerryPi as I've seen mixed feedback. From an OpenLCB/LCC perspective it's critical to send and receive CAN frames in order.

The MCP2515 is a common chip and there is wide support for it in the Linux kernel and lots of application notes, but it does have issues with buffering and maintaining frame receive ordering. We've used the MCP2515 with the Arduino in early OpenLCB prototypes and battled with it for a while. We eventually gave up and went to using the AVR AT90CAN128 chip with on-chip CAN controller and had a lot more success.

However, recently some other people are wanting to try the MCP2515 again but this time using interrupts, so hopefully that might improve things.
I've got one of the MCP2515 interface board from eBay to try it again on the Raspberry Pi and the Arduino, also someone else has mentioned some work-around for problems in the silicon so that may help too.

4) Would you consider bringing out the PB0(ICP) pin12 + PB1(OC1A) pin 13 on the ATMega328 to a 1x4 header along with GND and +5V as that would let me experiment with adding a LocoNet interface which might be interesting. I don't know how busy the Mega328 is running the DCC++ firmware already but could be useful.

Regards

Alex Shepherd

Thanks for taking a look at the schematic. I actually have already switched to an AT90CAN128 (that happened two weeks ago). I really liked the fact that it had all the same timers as a regular ATmega328P, so I decided to start switching over. I will be working on this more in the coming weeks.

I think the loconet interface is also a great idea, just so that this shield can be used as a booster for existing systems as well.

The EXP0 header was put on there so that the device is future proof, as I saw in the draft OpenLCB docs that the Alt_L and Alt_H pins on the RJ45 connector will have some sort of cool function related to boosters, but the specs aren't perfect yet so it's there to use if needed.

I wasn't really sure about the TL7660D... do I have to have a +12V and a -12V signal on the power bus, or a +12V and GND? The TL7660D is there to invert the +12V to -12V.

David

[sizemore]

This is awesome. 

The S.

[Ed Kapuscinski]

I kinda want one just because it IS so cool.

[dcutting]

So... I have a preliminary setup that would all fit onto the hat, giving you the following connections/interfaces:

• 5A DCC Main Line
• 5A DCC Programming Track
• OpenLCB interface (2x RJ45 connectors) including the option to connect the brand-new ALT_L and ALT_H lines to the DCC signal.
• Loconet Interface that allows connection of an existing loconet system. I copied the schematics off the MRRWA page, so whatever capability that has, this will.
• Serial line to the raspberry pi for DCC++ operations using the mini-UART port on the pi.
• 12V Input for a standard ATX 6-pin PCI express connector so that you can either connect a computer PSU directly to the board, or a converter/adapter cable can be fashioned.
• ICSP connections made directly to the raspberry pi and broken out on the board so you can program the board using either the pi (avrdude) or a separate programmer.
• I2C EEPROM Chip that can be read by the Pi. This can store info about the setup of the HAT

A schematic is available here: https://github.com/cescalemodels/BaseStationHAT/blob/master/Hardware/BoosterHC%20HAT%20V0_3.pdf

Before I go any further, I'd like to get a feeling for how much execution time that all of these peripherals require. Can anyone familiar with the code side confirm that the DCC++ interface, the OpenLCB interface, and the Loconet interface can all happen at the same time on a 16MHz microcontroller?

David

[kiwi64ajs]

So... I have a preliminary setup that would all fit onto the hat, giving you the following connections/interfaces:

A schematic is available here: https://github.com/cescalemodels/BaseStationHAT/blob/master/Hardware/BoosterHC%20HAT%20V0_3.pdf

Before I go any further, I'd like to get a feeling for how much execution time that all of these peripherals require. Can anyone familiar with the code side confirm that the DCC++ interface, the OpenLCB interface, and the Loconet interface can all happen at the same time on a 16MHz microcontroller?

Wow switching out the ATMega328 for a AT90CAN128 is a pretty radical change. An interesting idea - need to think about it some more.

Initial comments:

1) I had suggested connecting the LocoNet Rx to ICP because the UART on the Mega328 is already consumed and my existing code uses ICP so it can sense collisions etc. The FREMO guys made a version that uses the UART RX + ICP to be more efficient Receive but still bit-bashed the Tx to have tight control of the collision sensing. As the AT90CAN128 has multiple UARTS we can use RXD1 + ICP1 for LocoNet Rx now. The ICP1 would be used to detect LocoNet Start-Bit activity before the first byte is complete as part of the collision sensing required for LocoNet. We could use TXD1 for LocoNet Tx, but the polarity is wrong so need to have an inverter between TXD1 and Q1 Base. Another NPN to invert the signal might be enough.

2) Having CAN also come into the AVR doing both DCC++ and LocoNet as well as CAN might be too much load - I don't know yet. You'd have to transfer the CAN data and the LocoNet data and the DCC++ data into the RPi via the UART0, which might be a bit of a challenge.

LocoNet runs at 16K and the CAN Bus runs at 125K, so if both are running at max capacity then we need to communicate to the RPi at about 150k, so expand that to 230k if you add some extra protocol overhead bytes to multiplex each of the LocoNet, DCC++ and CAN to the RPi.

I just don't have a good sense for this yet - I guess we will need to prototype it to know.

Alex

[dcutting]

1) I had suggested connecting the LocoNet Rx to ICP because the UART on the Mega328 is already consumed and my existing code uses ICP so it can sense collisions etc. The FREMO guys made a version that uses the UART RX + ICP to be more efficient Receive but still bit-bashed the Tx to have tight control of the collision sensing. As the AT90CAN128 has multiple UARTS we can use RXD1 + ICP1 for LocoNet Rx now. The ICP1 would be used to detect LocoNet Start-Bit activity before the first byte is complete as part of the collision sensing required for LocoNet. We could use TXD1 for LocoNet Tx, but the polarity is wrong so need to have an inverter between TXD1 and Q1 Base. Another NPN to invert the signal might be enough.

2) Having CAN also come into the AVR doing both DCC++ and LocoNet as well as CAN might be too much load - I don't know yet. You'd have to transfer the CAN data and the LocoNet data and the DCC++ data into the RPi via the UART0, which might be a bit of a challenge.

LocoNet runs at 16K and the CAN Bus runs at 125K, so if both are running at max capacity then we need to communicate to the RPi at about 150k, so expand that to 230k if you add some extra protocol overhead bytes to multiplex each of the LocoNet, DCC++ and CAN to the RPi.

While we don't have a good idea of the execution time, I can say that the board layout is going to be VERY tight if I want to still be able to call this a HAT. I had to source and make up my own EAGLE part for the dual stacked 8p8c port, and since I couldn't find any stacked 6p6c ports I have to make those separate, but I will probably use a single side-by-side component because that'll save a tiny bit of space. I will also need to switch the package for the AT90CAN128 chip to a slightly smaller QFN one so I can cram it in a corner:



As for cramming things into the execution time, I will put together a new schematic and hopefully get a board laid out for the prototype.

[kiwi64ajs]

While we don't have a good idea of the execution time, I can say that the board layout is going to be VERY tight if I want to still be able to call this a HAT. I had to source and make up my own EAGLE part for the dual stacked 8p8c port, and since I couldn't find any stacked 6p6c ports I have to make those separate, but I will probably use a single side-by-side component because that'll save a tiny bit of space. I will also need to switch the package for the AT90CAN128 chip to a slightly smaller QFN one so I can cram it in a corner:

As for cramming things into the execution time, I will put together a new schematic and hopefully get a board laid out for the prototype.

I have several of the RailStars RS-Io and RS-Io:duino boards. They have the AT90CAN128 chip and the RS-Io:duino has an Arduino footprint.

http://www.dcctrain.com/shop/item.aspx?itemid=6275
http://www.dcctrain.com/shop/item.aspx?itemid=6273

Need to check the pin-mapping to see if the RS-Io:duino pins line up with the commonly used H-Bridge shield used by the DCC++ projects. If it does then I should be able to try DCC++ and the CAN code.

Another issue I thought of was the AT90CAN128 UART <-> RPi UART comms needs some hardware handshake lines to manage flow control so each end doesn't loose bytes unnecessarily.

I'm nervous about cramming all this into a relatively (by current ARM standards) low powered AVR and having the various bits of data (OpenLCB CAN, LocoNet and DCC) all in the relatively low powered AVR.

While the AVR may be able to receive all the data, its lacking RAM and CPU cycles to be able to do a lot of smart State and Event management as well as acting on that and generating actions based on control logic.

You original design had the MCP2515 CAN interface alongside the DCC++ Mega328. The CAN data was going via SPI to the RPi and the DCC++ was just on the RPi UART and so they had separate data paths back to the RPi.

The RPi has heaps of CPU cycles and RAM to handle all the State and Event management as well as Control Logic etc. It can maintain large lookup tables in RAM etc to gateway LocoNet and DCC to OpenLCB via the various mappings we've discussed over the years.

So to me the previous design made more architectural sense. There is still a ? over the MCP2515 and how it handles CAN frame ordering and not missing frames etc, but that can be verified independently.

[dcutting]

I'm nervous about cramming all this into a relatively (by current ARM standards) low powered AVR and having the various bits of data (OpenLCB CAN, LocoNet and DCC) all in the relatively low powered AVR.

While the AVR may be able to receive all the data, its lacking RAM and CPU cycles to be able to do a lot of smart State and Event management as well as acting on that and generating actions based on control logic.

You original design had the MCP2515 CAN interface alongside the DCC++ Mega328. The CAN data was going via SPI to the RPi and the DCC++ was just on the RPi UART and so they had separate data paths back to the RPi.

The RPi has heaps of CPU cycles and RAM to handle all the State and Event management as well as Control Logic etc. It can maintain large lookup tables in RAM etc to gateway LocoNet and DCC to OpenLCB via the various mappings we've discussed over the years.

So to me the previous design made more architectural sense. There is still a ? over the MCP2515 and how it handles CAN frame ordering and not missing frames etc, but that can be verified independently.

Makes sense. If I were to switch over to a CAN bus coming off the pi, would it be better to switch to a 32-bit AVR that could run at higher clock speeds and has more peripherials, like a SAM3X, or would I better sticking to something like the mega2560? Would you keep the loconet interface on the AVR? There was also a question that came up about sticking a small 4-pin header under each of the RJ11 connectors that would do CMRI. Since CMRI only uses RX and TX, it would be a pretty simple interface.

David

[dcutting]

I did a little more research, the SAM3X8E is a little more spendy but it would have everything we need and more... 2 CAN controllers, plenty (5) of serial ports, lots (3) of 32-bit timers, lots of SPI's... just in general a lot of excess. It does operate at 3.3V but that's not a big deal. The clock speed is a whopping 86MHz. And arduino supports it with their AtHeart program. The question is, would this be helpful or would it just be adding extra cost without too much advantage? The big advantage I could see is all the expansion ports I could include to add extra cool interfaces later.

David

[railnerd]

I did a little more research, the SAM3X8E is a little more spendy but it would have everything we need and more... 2 CAN controllers, plenty (5) of serial ports, lots (3) of 32-bit timers, lots of SPI's... just in general a lot of excess. It does operate at 3.3V but that's not a big deal. The clock speed is a whopping 86MHz. And arduino supports it with their AtHeart program. The question is, would this be helpful or would it just be adding extra cost without too much advantage? The big advantage I could see is all the expansion ports I could include to add extra cool interfaces later.

David

The big advantage is MUCH more horsepower, but the existing code libraries may need work.  Alex Sheppard can probably weigh in here.

[sirenwerks]

It scares me. It's pretty, and I like the cost because I need to enter into the DCC fray, but it presents as if it could become a hobby unto itself. Is there a Dummies manual?