Blame us of what exactly? I dare say that DCC-EX has done more for the "uninitated" to get a DIY CS with open source code up and running than any other comparable project. The whole source code with ports to several architectures is on github featuring reasonable readable source code and most of the folks who have written it are available for questions on discord. Add to that the extensive documentation, all produced by enthusiasts in their free time. I am so happy that the real DCC-EX users we meet on Discord do engage their brain before they start to type. Harald.
Fred, I do appreciate your very extensive reply. Yet what still puzzles me is what does an ESP32 have extra and beyond what an ESP8266 can do, in the contect of DCC-EX? And please without reference to "built-in firmware" or AT-commands. Because basicaly a microcontroller only requires (for our purposes) a bootloader for it to be able to be programmed with the DCC-EX code.
Your reply does not answer the core of my OP. EDIT: by which I mean that Fred did partially answer my initial question; but he involved timing and interrupt issues with the ESP8266 in his answer. And my question then was: what exactly differs in the way interrupts are handled in the ESP8266 from the ESP32? Basically: what exactly does prevent, in the DCC-EX context, prevent proper DCC signals from being generated? And this in a purely C++ environment? So, no AT-command nor "firmware" issues please?
We have tried to port the CS onto an ESP8266, ESP32, Teensy, STM32 and more. The challenges as you must already know, of all the differences of how things are handled at the hardware level, make it extremely challenging, especially if we are to have one codebase to maintain. Hardware registers, timers, interrupt handling, port mapping, are different on all of them. For this kind of thing, we usually team up, so several professional engineers get involved and we have code reviews and run things past well-known people in the modelling hobby who are advisors/mentors who are known for their work innovating, being on the NMRA standards committee, etc. So we try to use all the resources available when we work on a project. There are different directions we could go, or could have gone (multiple processors, for example), but when looking at the whole picture we ruled out or decided things based on lots of criterion. We (Harald) actually *was* able to get an passable DCC signal out of an ESP8266 since we also looked at things like the ESP12F for a small CS, but not stable enough to meet NMRA, let alone our, specs. The 8266 has the same issues the ESP32 has, it uses blocking code whenever it has WiFi tasks enabled. Something in their blob halts everything when it is handling WiFi (someone else mentioned when it does garbage collection, but its hidden in the blob so no way to know). We need a stable 58uS pulse and can't miss an interrupt. Could you do it in a timing loop instead, use 2 devices? To some extent. Not worth our time. We want a better, more reliable signal than that. We are talking purely C++ and usually (in the CS code anyway) no 3rd party libraries, because they also often have issues like blocking code, size , or bugs, and this has nothing to do with AT commands. The only thing AT commands were for was to setup the ESP as an access point or to connect to a local network for an external ESP-01. The devices came from China ready to go with their "NonOS SDK" already installed where all we need to do was send 5 or 6 commands over serial to the ESP and we were done other than to send and receive data. If we were going to run an ESP as a CS, as we do with the ESP32-WROOM based boards, everything runs in our C++ code and the WiFi libraries from Expressif/Arduino. Frankly, it doesn't make a difference whether we send an "AT+CWJAP="ssid","password" or "WiFi.begin(SSid, password)" as they both just call the same non-open underlying blob, but when we are connecting over serial to the separate ESP device, we talk to it across the wires with AT commands. When we are running the CS on the same ESP32 hardware running the WiFi, we use WiFi library commands. We pin a task to a core, run the wifi loop code, and look through each connected client and do wifi.reads and when we have something to send, do wifi.writes. We knew, from talking to Expressif and AI-Thinker and Makerfabs that the 8266 line would be going away, and the cost/benefit ratio, and increasing availability and popularity made the ESP32 a smarter choice for us. Expressif has since replaced the NonOS SDK with the ESP8266 RTOS SDK, which by the way, still uses AT commands. To quote Expressif: It is just another tool in the box and has its place like anything else, along with writing it all yourself and replacing what's on the chip. We are moving beyond that anyway and think WiFiNina is where things are going for cross platform support, but Expressif makes a good case for developers to use AT communication to an embedded device as you can see from their graphic. The design is to use an ESP device as a slave to a host controller as we are doing with the ESP8266 or Makerfabs board when connected to an Arduino without built-in WiFi:
Good morning Fred, thank you so much for this exhaustive explanation. This fully answers my OP question. From your explanation I get that an ESP would merely serve as an extension to the original AVR (UNO or Mega) CS. Now one last question: when downloading the code from https://github.com/DCC-EX/CommandStation-EX this code compiles ok for ESP32. Does this mean a CS can be built by adding just a motorboard, no AVR needed? Or are the blocking WiFi background processes (per your explanation) resulting in unstable DCC signals? Erik.
