0 Members and 1 Guest are viewing this topic.
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 peripherals, 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.
The big advantage is MUCH more horsepower, but the existing code libraries may need work. Alex Sheppard can probably weigh in here.
If you do a RPi HAT with DCC++, then the lower risk option is to stick with the Arduino AVR Uno/Mega as it already works. Is there a good reason to change?Having the DCC++ serial comms to the RPi on a different UART lets you separate the processing logic in the RPI, whereas if you multiplex DCC++, OpenLCB & LocoNet all up the same UART to the RPi then you have to peel that all apart in a single process in the RPi and maybe pass some of it on to other processes. A single RPi process can open multiple serial ports but multiple processes can't easily open the same serial port and help-themselves to only the data they want - something has to peel-it-apart and process it appropriately, so NOT mixing it all up at the source is probably better unless you're trying to reduce BOM costs and your making enough units to justify the increased software complexity. Ignoring exactly how (MCP2515 on SPI or a CAN to USB Adaptor), adding a CAN Bus interface that feeds directly into the RPi would be good in that it gets the OpenLCB/LCC data directly where you can do all the heavy-lifting in the RPi RAM / CPU as it will have lots of packet buffering capacity and ability to have RAM consuming look-up tables for PCER Event processing and Logic Evaluation and mapping/translating/gate-way between OpenLCB on CAN/Ethernet/Wi-Fi and other MRR LCBs like LocoNet, XpressNet, NCE Cab Bus etc.My current thoughts were to develop a small LocoNet interface using the Tiny841 chip as it has 2 x UARTs and pretty much will work now using the ICP Bit-bashed LocoNet Rx/Tx with collision sensing. However, it also has some extra Wake-on-UART-data capabilities that I want to use to sense LocoNet traffic for collision avoidance. That will lets me remove a pile of complicated serial bit-bashing that will reduce CPU load. So we could end up with a LocoNet to UART Adaptor in the Tiny841 and then send that into the RPi. From the RPi perspective it would look like an existing LocoBuffer - problem solved. So this could end up looking like a small LocoBuffer Adaptor PCB with 2 x RJ12 on one side and a 1x6 header on the other side with GND, VCC Tx, Rx, CTS, RTS and look after the tricky LocoNet timing and collision sensing. I also have a few Teensy's as well but AFAICT they lack the Start-detection that Tiny841 has so you'd have to use a hardware interrupt of some kind to detect the LocoNet busy condition. Hmmm... C/MRI uses a unusual "sort-of RS422 but not quite RS485 configuration, which is quite different to LocoNet, so it would not just be a connector change, you'd need different input electronics. If you were just wanting to re-use the PCB realestate then you could probably layout pads for different chips and swap the LM339 for a RS422chip maybe.Alex
I think I am going to be able to keep all of the interfaces on one HAT without any board expansions. All components would probably be populated but the connectors will be unpopulated so that the modeler can solder on what they need for their application.
From that I'm hearing you're talking about bit-banging another couple of UART interfaces on the Raspberry Pi.
If that's the case, I'll get moving on the LocoNet Tiny841 setup, moving back to the mega328p for the DCC+ system, and adding an MCP2515 to the board for the CAN system. I'll also add a converter to the board for C/MRI... does anyone have a schematic that I could use for that? I don't know if normal RS232 to RS485 adapter circuits will operate correctly (I've see the MAX232/MAX485 setups, as well as the BOM for the CMRI one), and there's no schematics on the JRI Electronics page.
So I guess I don't know why you'd want to cram all that stuff on there, when the Raspberry Pi has all those wonderful real USB ports. I think if you focus on just the DCC++ stuff you have an easier to maintain, less expensive product. If folks want LCC or Loconet, then they can hook up a USB CAN adapter or Locobuffer. If you roll your own CAN controller and Loconet interface, you've gotta maintain those and make sure that your micro can keep up and multitask between DCC, LCC, and Loconet.-Dave
This brings up another point. Why should this thing even be a HAT? A USB interface would be better, especially if many modelers will use old laptops. Seems to me that putting the DCC++ controller onto one PCB that has a USB on it would be better. I could imagine that the serial line needed could even be hooked up to a bluetooth expansion module so that you could have remote booster stations or base stations. USB to loconet, USB to OpenLCC, and USB to CMRI all have existing interfaces but I think that redesigning those with a bluetooth module option would be a viable opportunity in the future. If I create a 5A DCC++ booster station all integrate onto a single PCB, I think I will have accomplished what I started. And we don't have to mess with the Rpi mini serial port and the lack of others.
Hmmm... well I've also got a Arduino Due https://www.arduino.cc/en/Main/arduinoBoardDue It has lots of RAM (96k), FLASH (512k), I/O 4 UARTS, 2 I2C, 2 CAN, SPI and lots of PWM and Analog-in etc. The only negative is the absence of any on-board EEPROM. There is the ability to emulate it somewhat with FLASH but it doesn't survive a firmware upload. We could use external I2C/SPI EEPROM and cache the values in RAM.The DCC++ firmware appears to really only rely on EEPROM, 2 Timer/PWM outputs driving the DCC Signals for Main Line and Programming Track and some and Analog Inputs for current sensing. It would take some effort to port it to run on the Due but probably not too much. The result would be a fairly extensible Command Station and lots of CAN and UART interfaces to interface to the different Legacy MRR Systems.
Author
Topic: DCC++ HAT (Raspberry Pi) (Read 10784 times)
