I was just looking at putting together an Arduino UNO shield that has a a high-power h-bridge for the main and a low-power h-bridge for the programming track, with no jumpers required. I finished the motor drivers and was starting to look at what it would take to put an expansion header on the board when I realized a few things: LCC - needs CAN support. CAN is commonly either baked into the microcontroller (as in some of the ATCAN line and the SAM line of ex-Atmel controllers), or it is provided from a SPI controller like the MCP2515 plus an extra transceiver chip. The current motor shield configuration uses the SPI pins on the Arduino UNO (ATMEGA328P), but they are still accessible on the Arduino mega along the double-row header. This would limit LCC support to the mega. Loconet - needs an ICP pin on the Rx line S88 - can someone comment on what S88 requires? I can't find much reliable info from a quick google search. CMRI - needs RS485, which needs another serial port. So and Arduino Mega is needed, again. This leads me to begin to define the expansion header - it needs three (or maybe four?) wires for SPI, another two or three for the serial port that the RS485 chip could be driven off, and perhaps another couple pins for general purpose expansion. I would also include the signal and enable pins for the main and programming track so that we can drive local boosters. I2C could be helpful for driving displays and other peripherals. What am I missing?
Hardware and software. I've designed several S88 boards for my own use (and a few friends), and I took early retirement last year from a job where I was doing both, mainly Java programing. I also do some PIC programming in assembly language. I had been an electronics hobbyist and technician from 10 years of age until becoming a software engineer at HP-Agilent-Avago-Broadcom. I'm also a ham radio operator and trolley mechanic. My least favorite thing is documentation, but I muddle my way through.
S88 - can someone comment on what S88 requires? I can't find much reliable info from a quick google search. I built an S88 shield that uses some I/O pins on the Arduino Mega and provides 3 S88 busses. https://github.com/chuckbade/S88forDCCpp_3port
I think the rational was to stay away from either end because I didn't know if someone would choose to use those pins. Pretty much arbitrary without knowing who would use any of the other pins.
I know some of you are going to hate me for this... but what does everyone think about porting DCC++ EX to a SAMD21G? Here's my rationale: The ATMEGA328P doesn't have enough pins available to make everyone happy - the interrupt pins we need are also used by the communications buses we need to make the LCC bus work. The ATMEGA2560 is a $10 component, and most of that functionality is thrown away by using it as a DCC controller. The SAMD21G is a very well-supported microcontroller in the Arduino IDE. It's much cheaper than the 2560 ($2.50) and it has lot's of clocks and timers on it. You can turn most of its pins into timers or communications buses of some sort. It's the modern version of the ATMEGA328P. IMHO, porting to a new microcontroller family will take some work, but if we do this it will allow for much greater flexibility and adoption. I'm willing to take the software lead, but I will probably need some support. Thoughts? We could start prototyping with boards like this: https://www.sparkfun.com/products/13672 There's also lower cost boards that should work just as well: https://www.seeedstudio.com/Seeeduino-Cortex-M0-p-4070.html
I am not against the EX being more modern chip. What are the advantages/disadvantages compared with ESP32. I think esp32 is slightly more expensive maybe $10 to $15 but can do a lot with it and @Atani has done a time of work on it already that we could pick up/help with but again I will yield to the group on this one. I am a big LCC believer so that's where my vote will go. I know can be done in ESP32 but not sure about others. The high power ops chip and low power programming chip with accurate current sense ( this is important) is the way to go if you are going to build custom hardware. It will require a bit of a rewrite I believe as currently I believe basically all parameters are shared except a few. Even as written they dont power seperately so should just need to make sure current monitoring and therefore short protection etc is properly implemented in the code but yes one with no jumpers and traces to cut that is a hat for the mega would be really nice. The good news is that both esp32 and the board you link look like uno footprints are available so you could build a shield based on same footprint.
David: The boards with the SAMD21G (*) look very good and are even available here where I live. But of course not as available as the original Aruino. One of the big plus of using such a common animal as the Uno is that many have one lying around so tio have a broad user base we should support these very common boards for the basic functionality which I see is to program CV and run trains from JMRI. But yes we should see to that we can use a board which costs half and can do at least double so much as the Uno. I see the value of custom HW for the I/O (motor drivers to busses) but I don't think we need it for the CPU side. Regards, Harald.
Welcome, I always love to hear from another DCC++ user and if you want to contribute the better. In the future I see not only the need to develop DCC++ itself but as well it's connection to other software like JMRI because I think all parts should do what they do best and DCC++ should stay small and simple. That said I should have a look at JMRI again how if function refresh could be handled better but that's a mighty big amount of code to understand in Java and if I can choose between writing/understanding stuff in C(++) and Java I'd rather do C(++). Then if you are running your trains with DCC++ you might want to test my fork at https://github.com/habazut/dcc-ardu/ Now that Keith has gotten some live into DCC++ here the goal is to have one code base in the end and for that I want to shake out as many bugs as possible. More tests help. Regards, Harald.
David: What I wanted to write as a footnote (*) in the post above: (*) The timer code - the key part to get out a DCC formed wave - will need to be reworked as the SAMD21G can much more and is much more flexible in that respect than ATMEGA328P. So it needs more setup and the control registers are named different. I guess that all the functionality is there to do the variable length PWM with direction change in the middle but it would be nice to check that first on a prototype. Regards, Harald.
LCC can be run on the AVR platform *BUT* it has a lot of overhead that won't mesh well with DCC++EX code so I'm not certain it is worth the effort to integrate the two. Though, a dedicated node that could translate LCC <-> DCC++ protocol would be interesting. Something of the same could be done for other protocols (LocoNet as example). I've sourced them for around $5 USD each and have seen it cheaper for other variants. It comes down to finding a reliable source though, DigiKey/Mouser/etc all will sell them for around $10 USD though for the Espressif branded ones (which are nice, I have a few!) Are the SPI pins not available on Uno/Nano? You would need the SPI pins plus one extra for interrupt pin. But as mentioned above, integration would be a bit of a headache on the AVR platform and I wouldn't advise it to be directly integrated with DCC++EX unless it is a standalone translation like node. The biggest piece that LCC provides that DCC++EX does today is the Traction protocol. DCC++EX doesn't need to know or care about other LCC components as that can (and should!) be managed by JMRI or by the nodes themselves. http://www.s88-n.eu/ It requires at minimum 3-4 pins (arduino S88 node implementations do not use the reset pin but commercial ones do).
If we use something like the ESP32-WROOM-32U or ESP32-WROOM-32D modules we can get the cost down to about $4 per module. So cost isn't really an issue for the ESP units. So BOM costs being equal, we need to decide whether we want to invest the development effort in the SAMD21 chip. I'm still for it. I take back my earlier comment. The current UNO programming track enable pin is on MOSI, but that can be moved. The main track signal pin is on the chip select pin, but that's not a big deal. So on both the UNO and the mega we do have a SPI bus open. Have you made DCC++ to work with LCC on the ESP32?
I would opt for the PICO D4 at this point instead of investing in the WROOM line of chips, or at least consider the WROVER model instead. But, opting for the bare SoC will require a lot of additional work due to the FCC certification requirements since it is a WiFi device. This is one reason I've so far opted for using modules that are already certified. I would opt for the SAMD21, the ESP32 while quite powerful has a lot of odd quirks that will trip up a lot of developers. The SAMD21 is a lot closer to the AVR chips so it should be a lot easier to migrate to, but are there sufficient boards available for the end user to simply plug-n-play like there are for the Mega? I maintain the ESP32 port of OpenMRN which provides the full LCC stack. I do not support DCC++ on the ESP32 *BUT* I do have ESP32 CS which supports the DCC++ text based protocol and supports LCC today, including the TCS UWT-100 out-of-box. I'll be posting an update on this in my own thread soon as I'm working on the final bits of stabilization for the next release, as well as a custom PCB that supports LCC and RailCom using the ESP32.
There are boards out there, including the RobotDyn (https://robotdyn.com/samd21-m0.html) and the Seeed studio board (https://www.seeedstudio.com/Seeeduino-Cortex-M0-p-4070.html). The sparkfun board (https://www.sparkfun.com/products/13672) is a good deal more expensive. There's also the official Arduino MKR Zero and the Arduino Zero, the latter of which is rather expensive but comes with an embedded debugger which is a very nice feature... until you blow up your board
embedded debugger is a nice feature to have for development but not necessary in the field really. Been there, done that... I have a dead ESP32 board with OLED on it that I can't use now since the USB connector broke off. I'll eventually replace it but not likely for a while since I have plenty of other options available with more pins available. I would opt for any of those as long as they all support the same basic features. The cost is comparable and I'm certain you could find more options online from AliExpress or similar. They also appear to follow the Uno footprint which is good since that means most shields should be plug-n-play ready. I guess the question will come down to, can you support the Mega *AND* SAMD21 with ifdef blocks similar to the way Mega/Uno/Nano are done today?
What is the benefit from doing the more high level protocols like LCC on the same board that is used to generare the track signal? In contrast to take another board and connect to where you run JMRI. Or in other words: Can I do something standalone with DCC++ and LCC in the same box? I admit I don't have the overview of how LCC ties into this so my question might be stupid ;-) Regards, Harald.
The CS has one job, generate a DCC signal, and it needs to be able to focus solely on that job. On the AVR platform there is one LCC library available and it will consume precious cycles for the LCC processing (SPI or otherwise) that could cause a degraded DCC signal to be generated. On the ESP32 there are two 240Mhz cores to work with as well as dedicated hardware for CAN, WiFi and for generating a consistent DCC signal. Looking at other MCUs like the Tiva or STM32 you also have more CPU cycles to spread across various tasks and there is an LCC stack available for these and code that can provide for generating a stable DCC signal. LCC provides a parallel "bus" to the DCC "bus" which can be used for various purposes such as accessories, block detection, signals, throttles, etc. Think of it as similar to LocoNet in that regard, but designed for future usages using an open source like model for documentation. You could, but it likely won't work well on the AVR. I also don't see the need for it considering what the majority of usecases for LCC have been so far (block detection and signals that operate autonomously without JMRI or the CS).
Hi All, After being away from the hobby for a while I recently decided to begin plans for integrateing a layout into my new home's interior. After some googling I found DCC++ to be a cheap and fun way to easily get things going. I've already managed to get a small layout working with DCC++ and JMRI. I've purchased two lokpilot 5 decoders and these support Railcom. I found the "Handmade Railcom" topic on RMweb, but after building this circuit, I discovered my DCC++ basestation (Mega + motor shield) lacks the cutout ability.. i'd prefer railcom block sensors over current-sensor-based detection, simply because it offers more options, but having to buy a cutout-enabled base station seems like a bit of an investment.. Since Railcom is an addition to NMRA's DCC, it might be a nice time to also integrate it in to the DCC++ codebase. I've recreated the schematic from RMWeb's topic in KiCad and put it on my github, you can also find links to the railcom specification and the RMWeb topic there. https://github.com/dikkedimi/RailcomDetector. The schematic is originally in the topic, but has a bit of a confusing way of labeling nets. What I've built seems to work, but I don't have cutout functionality so I can only guess. I am receiving bits on the second arduino that's configured to read when the cutout window is open, when I switch on track power, but not when the loco enters the block. I'd be happy to help with testing, but since I'm not an experienced programmer I'm afraid integrating it myself is a few levels above my knowledge and insight. If there's better alternatives I'd be happy to hear what you guys have to say about it, I find there's been a lot of change over the years in DCC world, but mainly for the better
