Don't take this as a definitive answer as I just and found it (HERE ) ....... 'Can you use ESP8266 with Arduino? The ESP8266 is a low-cost WiFi module built by Espressif Systems. Its popularity has been growing among the hardware community thanks to it's nice features and stability, to the point that it can be easily programmed using your Arduino IDE.' So with that in mind might be possible but I'd check with them on Discord. I used something similar in building the $50 DCC WiTcontroller throttle above, a LOLIN32 ESP32 Lite. I just followed Peter Akers of EngineDriver fame instructions that I've got posted on my site here... https://1fatgmc.com/RailRoad/DCC/WiTcontroller-Index.html Sumner
No, but we already ported it to the ESP32. The ESP8266 does not have the hardware to generate the DCC signal correctly. It is also discontinued. It will probably be around for a while since they made so many, but better to use it. You can make a great command station out of an ESPDuino32 board ($3-$8) and a motor shield like our EX-MotorShield8874. We are working on something new, but to use that board, you have to add a resistor and make another change. Start here and read through to the instructions for the ESPDuino if that interests you. We will have this available soon in our store for those wanting it already modded and flashed. https://dcc-ex.com/reference/hardware/microcontrollers/microcontrollers.html#espressif-esp32-series
And what might those hardware issues be? I am interested to know since a simple AVR can do the job of generating DCC signals correctly? If I understand this article correctly then a UNO-formfactor board with an ESP32 onboard can be used to compile and download DCC-EX?
The DCC-EX team has a pretty frustrating relationship with Expressif. Apparently AI-Thinker, one of their biggest clients, and who writes their own firmware based on the Expressif code (you often see their name in a bootup log or on the chips), feels the same way and have abandoned them to use Bouffalo Labs BL616/618 hardware instead. And no plans for us to look at that yet with the ESP32-WROOM and STM32 Nucleo hardware we already use. Among other things, the ESP8266 cannot generate a DCC signal because of the way it handles interrupts. They use soft interrupts which means that when anything they think is a higher priority like handling a WiFi interrupt or doing garbage collection, it completely stops everything else. Even on the ESP32, some of which have 2 cores, both processors are interrupted! So the only way to generate DCC is a trick to use another piece of hardware on some ESP32s called "RMT". It is a remote control transceiver circuit with hardware and firmware designed to be used for infrared transmitters and receivers in remote controlled devices (TVs, remotes, LED lighting, etc.). We can send instructions to that hardware to generate DCC from main processor. ESP8266 boards do not have RMT, ergo, can't generate DCC. A "simple AVR" has hardware timers and interrupts, and even though they are a hodge-podge of bit depth and pins they are attached to, we luck out that they are connected to the right pins on a standard motorshield. Additionally, since the processor is so fast relative to the DCC signal frequency, and the AVRs do not block timer interrupts, we can also generate DCC on most of the other pins (there is a bit of jitter so we call using the recommended pins "High Accuracy" mode). Newer processors like the STM32 pretty much let you configure any pin for any function which if freeing! Important to note, there are many confusing iterations of ESP32s, all with different hardware features. We only support the ESP32-WROOM. For whatever reason we can't fathom, most of the other versions of the ESP32, like the ESP32-C3, cripple the RMT hardware by reducing the number and configuration of RMT "channels" (memory buffers). Since DCC packets have to be sent as data, rather than just generating pulses as we can do on other processors, the memory of most of the ESP32 RMT devices are too small to handle the larger DCC packets. So yes, the ESPDuino32 board with some minor modifications work great. We are working more and more on our own hardware due to the issues with a lot of the cheap hardware from China. Many of you may already know about the "Wangtongze" board that was cloned by someone in China and made with misspelled words and the wrong level shifting transistors. It works, but not without modifications. The same holds for the ESPDuino32 boards. The people who made them incorrectly connected the IORef pin to 5V rather than IORef which would be used by other boards to tell if they are connected to a 5V or 3.3V device. They also have an issue with the voltage on IO0 and you can't use the A0 and A1 pins we normally use because they are taken up by WiFi functions. So there are 3 small, and simple, changes to make to use them with a Motor Shield and make a command station. Those are listed on the website link in the previous post. You can't see the ESPDuino32 on the bottom, but this is a 3D printed mount, ESPDuino32, and the EX-MotorShield8874 (in purple since it is the one sold in Australia), along with a small I2C OLED display. You need to bend out a pin if using the Arduino MotorShield or modify a solder pad jumper on the bottom of the EX-MotorShield8874:
Somehow I had not been notified of your aswer here so it is with great delay (after manually searching for this topic) that I found your excellent reply for which many thanks! A few questions Fred: 1. The Wangtonze" boards shows an ESP8266. So why mentioning this board if the ESP8266 cannot generate proper DCC signals? 2. what type of mosfet's are J1Y and J3Y? When ordering mosfets it is usefull to know what the actual devices are, or at least if thes are N- or P- channel? 3. what is the difference between your alias "Flightrisk" and another I have seen "Frightrisk"? Grts, Erik
Hello Erik, 1. There are 2 separate issues to consider, the first is simply providing a WiFi option for the command station. The second is on which processors we can run a command station. Initially, we only ran on an Arduino Uno and Arduino Mega. Unos and Megas do not have WiFi (though there is a Mega+WiFi, that does, but sometimes the WiFi on them works and sometimes it doesn't). We needed a way to run WiFi and the ESP-01s boards cost only $1 and worked out of the box, though you have to connect them with several wires. We also found the Makerfabs WiFi shield that worked. We tested many other boards and found ways to make some of them work as a WiFi add-on board, like the Wangtongze board. So you can use the Wangtongze board (with a small amount of work) to add WiFi to an EX-CommandStation, but you can't used it AS a command station. Recently, the ESP8266 chips started to have many that were shipping with an incorrect firmware version. This can be upgraded (or downgraded), but is not something we wanted our users to have to do. So we partnered with Makerfabs to design a new board that they and the DCC-EX dealer network will sell. That will be available in the next 2 weeks or so. But people can still go online to learn how to flash any of the ESP8266 chips with the correct firmware if they want to themselves. The easiest way is to buy a little USB dongle that converts USB to TTL serial and then use some flashing software. Makerfabs sells one of those and is what they use to program their/our boards. 2. This is a standard logic shifter circuit, which is always an N-Channel MOSFET. You can see tutorial circuits online. A J1Y is a BSS138. The people who made the cloned Wangtongze board used a J3Y, which is a bipolar NPN S8050 transistor. The circuit requires a voltage controlled switching device and someone just substituted a current controlled audio amplifier device. Hey, one type of transistor is just as good as any other, right? Either just bypass the transistors and connect directly to the debug port pins on the board, or use a hot air station or good soldering skills to install 2 J1Y (BSS138) MOSFETS. 3. FlightRisk and FrightRisk are a double joke. A "flight risk", which you may already know, is a term applied to someone accused of a crime. If they go to a bail hearing, the prosecution may try to prevent the person from being let out of jail until the trial by saying they are a "flight risk", they will pay the money and go into hiding and not face justice. So I might just "run away" at any moment I am also a Halloween "Haunter" and do a big display every year. I participate in some of the Halloween based forums like this one. Using a play on words, I changed "flight risk" to "FRIGHT risk" on those forums. And whenever "FlightRisk" is already used on something I join, I use "FrightRisk" instead. See here: https://www.youtube.com/@frightrisk7407 PS: We now support the Arduino Mega and clones, the ESPDuino32 (with some easy modifications), and the STM32 Nucleo boards for a command station. The ESPDuino32 board is Uno sized and has WiFi built in. The Nucleo type boards are what we are focusing on for the future.
Good, now I understand, thanks. Why would firmware be required (I assume you are not referring to the bootloader?). Maybe I overestimated the "general public's" hardware skills but all that is needed to program an ESP8266 is being able to set the chip in "flash" or "programming" modus and connect TX, RX and GND in the right way, using an UART module. Yet if I understand your previous explanation correctly the ESP8266 is not an option because of the way interrupts are handled? Yet even there, with all its background wifi-stack handling, a simple "yield();" command (allowing the background wifi processing to be handled) will not work in this case due to DCC output signals being corrupted? From what I experienced with the ESP8266, is that, when not giving it the time to execute the background wifi jobs, the controller may go in WDT (watchdog timer) crash. But even so, I am surprised that consistent DCC signal generation is made impossible by the way the ESP8266 seems to give its own priorities to interrupt handling. In principle any N-ch mosfet will do the job but the BSS138 has one of the lowest Von(G-S) voltages and fast response times. I always use those for this type of "job". Soldering of course is not everyone's piece of cake . Funny, thanks for that explanation. The ESPDuino32 is something like this, right? If the ESPDuino32, or whatever module is equipped with an ESP32, can be used as a DCC-EX command station than so can a bare ESP32 be used, of course again on the condition that knowledge how to program it correctly is present. Right?
Yep, if you think all of that is easy, you are overestimating the general public's hardware (and software) skills . I'm fairly handy with both and tried the Mega that also has WiFi and had to do that to get it working and struggled with all of the steps. Remember some of us do this with things to get them to work and then if might be a year or two later that we have to do it again and go through all of the learning process again. As Fred mentioned after doing all of that I also had intermittent problems with the Mega that has WiFi. I put on one of the Maker-fab $8 WiFi shields and it worked right off. I usually use JMRI since I have it running all the time. With my WiFi throttles and JMRI the throttles see the roster saved on JMRI and I can call the locos up via the roster and the commands for that loco (sound or non-sound) show up on the throttle screen with their corresponding function keys assigned to them. Really handy with as sound decoder that has over 20 sound options. You can do that a different way also with DCC-EX and the WiFi shield on the command station. Sumner
Again, I am not talking about having a CS flashed on the board, I am talking about a board that was designed for embedded systems. It is supposed to come with firmware that just allows it to be a WiFi add-on inside some other hardware. A lot of these are inside infrared decoders and infrared and wireless Christmas lights. They come out of the box with the ability to send them commands (in our case AT commands) to configure its built-in network capabilities, like a web server, web client, or access point. They were not initially designed to be flashed with actual applications in addition to their WiFi application, another microcontroller was supposed to do that. At first, the AT firmware that came with these boards just worked. But then there were updates that had bugs, changed the command set, then changed some of those changes back, removed the AT command portion, etc., etc. And mDNS has never worked properly. So now instead of a plug and play solution, we had TWO devices a user had to upload firmware to. And flashing an ESP device is absolutely not trivial, not even for a computer expert, until they have learned how to do it. We still have issues and have to use a different version of a hardware or software flashing tool to get some chips to flash with no way to know why one path worked and one did not. Expressif was in the right place at the right time at the right price for the maker community, but they are abysmal as designers, especially regarding firmware. All my contacts in China tell me that finding and keeping firmware developers over there is difficult. Many just design the hardware and then rely on third parties (like AI-Thinker) to take their proprietary "blobs" and write the firmware we use from that. Not ideal. Those companies come and go like ocean waves. People have different talents, which is why you need a good team. As you may have seen, at the risk of generalizing, a lot of brilliant engineers, don't also have excellent people skills, or know how to market a product to users. Those skills use different parts of the brain. And people who are immersed in something almost always underestimate its complexity to others. We have many Conductor level folks (non-technical) along with the Tinkerers and Engineers. People want to save money, or they underestimate their own abilities or time, or they want to solve a particular problem, or they want to learn, etc. But it has to be simple and as painless as possible for them if they can't buy it already configured. Even engineers aren't masters of every kind of engineering. All electrical engineers aren't expert coders and visa versa. You just want to run your trains and the WiFi won't work, now what? I'm an engineer and I think it is too difficult. I can still put myself in the place of the user, but I am also lazy. I don't want anything to take more than 3 steps or I'm out. After days of reading, downloading things, getting help on line, and trying different settings, we get it to work. And then we go online to help someone else and say, "once you do it the first time, it's easy!" I think if you actually tried to document this for someone you would find that it is much more complicated than that, especially for a first time user. Some questions might be which tool to use? the GUI Flash Tool or the python script esptool.py, or the Arduino IDE? What binaries work on that board? What are the starting addresses for each of those files? Do Tx and Rx need to be crossed? I am using 5V, do I need a voltage divider? PS, What's a voltage divider? Imagine having to open the hood of your car, use jumper wires to connect some buttons you take out of the glove box, hold down one button and then press the other, then let both go, then use your phone connected with an OTG cable to upload firmware, before you could drive to work. That's what is is like for a lot of folks. Even Engineers often want an already configured option so they can spend more time on other things. More like this ESPDuino32 Without understanding Expressif's marketing strategy, I can only be frustrated by what seems like an ever expanding and convoluted mess of ESP32 versions. Because you can't use either of the cores (if you even have a dual core unit) to generate a solid, uninterrupted DCC signal, you have to rely on the RMT hardware on those devices. That is the separate peripheral on the chip designed to handle the infrared remote control transceiver functions. But it can generate other kinds of square pulses, like DCC. We need multiple "channels" and a certain amount of memory in those channels. Every version of the ESP32 changes how that is configured, and many versions are not capable of generating DCC packets. Therefore, the only version we support is the "WROOM" version. That version is on the ESPDuino32 board, and on the smaller ESP32-WROOM development boards. Using other boards also means knowing what GPIO pin functions they have changed, since they mess with that too. Yes, that's right. See the web page here for a list of supported boards and instructions. DCC-EX Boards in Beta Test. Take a look at the Nucleo higher up on the page also, because they can do a bit more for us as we expand, but any of the boards you see below (documented in the link above) will work. For those not familiar, these are not scaled to each other since the righthand 3 boards are much smaller than the Uno sized ESPDuino-32 at the left:
Hi Fred, thanks a lot for that explanation. Do you participate in the DDC-EX team and in what position? Grts, Erik
Maybe consider purchasing from makerfabs direct at $15 US including shipping. The current wifi shield version on the site appears to be pre-loaded with 1.74 and is in stock. https://www.makerfabs.com/esp8266-wifi-shield.html "This new version v1.1 is co-designed with DCC-EX, with ESP8266 firmware v1.7.4. customers can free to update the ESP8266 firmware with ESP32 programmer CH340K, for detaield step,please check this as reference." Buying an ESP8266 Shield or ESP01S+Adpater if purchased from anywhere else will most likely require upgrading or downgrading to 1.74 thus adding another $10 (USB adapter)with shipping excluding the hassle of performing the upgrade, replacing MOSFETs, possibility for failure and, TIME. Unsure if the $5-$10 savings (incl shipping) justifies any other product than the Makerfabs 8266 Wifi shield if one wants to avoid issues.
Why buying preprogrammed hardware? This is contrary to what open source projects like DCCpp or DCC-EX should promote. Encourage self development of people in this hobby. I resent this pushing for "off-the-shelf" solutions, especially when coming from DCC-EX crowd. If you had been reading my topic and my comments carefully you would have understood I am not being helped by your answer.
Unfortunately, you may have misunderstood my reply. All devices that have firmware must already some version of firmware or what you define as "pre-programmed". There is difference between DCC EX software or any other software, and hardware based firmware such as the ESP8266s firmware. Apples and Oranges here. The 8266 firmware issue is not specific to DCC EX. Other Mega, UNO microcontroller open source projects that incorporate it also recommend or require upgrading or downgrading to a specific 8266 firmware version. Would you consider any other OS or application the same because a OS or app needed a different driver or a SSD required a hardware BIOS update. I was not pushing nor am I a team member, but have been using EX for over 3 years and have seen a number of people get frustrated and discouraged. It was my attempt to minimize and suggest another option to get wifi with less hassle. It was not a discouragement to pursue self development and apologize if you feel that way especially since I'm a tinkerer at heart.
Hi Mark, thanks for that clarification. However now it is up to me to offer clarifications: 1. there is no need at all for any firmware to be present on any microcontroller whatsoever. The myth distributed even in this topic and by no less then Flightrisk, that Espressif or any maker (be it AI-Thinker, Wroom, or whoever, should or would ship their hardware (ESPxx) with whatever kind of "firmware" is completely obsolete information. It is total hogwash to believe any kind of "firmware" would be required to load whatever software (or "sketches" as the Arduino crowd likes to say). Above all, assuming AT commands should be used to do anything sensible with microcontrollers is good for people living in the Middle Ages of soft- and hardware development. 2. If integrated hard- and software solutions are made available to the unintiated, good for them. But if or when I am asking questions requiring at least the minimum of understanding of microcontrollers, or of the ESPxx family to be specific, then at least I expect to receive sensible answers to my questions on this forum, by people involved, far or close, form the DCC-EX project. 3. Stating that is impossible to explain to "the uninitiated" how to program an ESPxx without (totally obsolete) AT commands is, please excuse the term, stupid. No engineering degree is needed to know how to download and install the Arduino IDE, to install the ESPxx boards and libraries, to connect an ESPxx via TX/RX and to get it into flash modus. Simple video instructions and/or proper written and documented instructions,.. will do the job. And there I blame the DCC-EX crowd for not providing this framework, for those "uninitiated" to do what they like to do most: the nuts-and-bolts job of creating their own command station.
Curious... Wouldn't you consider the Arduino Bootstrapper firmware? The BIOS in any general purpose Computer is considered to be its firmware and without it, how can different operating systems talk to the respective hardware devices. You would be unable to install an OS without BIOS (Firmware). With the exception of the ESP8266 Makefabs or equivalent or ESP01S, are standalone devices so there is a distinction whereas the Mega+Wifi or the ESP32 with built in wifi boards. With the combos, really 2 firmware exists (the bootstrapper and the esp8266 wifi). It is the devices firmware that acts as the communications bridge from apps and OS to the raw hardware.
I think you misunderstand the purpose of "bootstrapper", and the difference with "firmware". A bootstrapper is required to load code into the flash memory of a controller, if programmed from, for example the Arduino IDE set for the ESP8266, or ESP32 board. "Firmware" is the actual program (code, sketch,..) in a controller. This has nothing to do and is not comparable to regular computers. These are distinct worlds, and associating them with my subject topic obfuscates my original questions above. Your comments here above show a (sorry for the term used) lack of understanding of the workings of microcontrollers. It is the devices firmware that acts as the communications bridge from apps and OS to the raw hardware. This is a meaningless statement. The DCC-EX software (or "sketch") is loaded on one controller. If this is an ESPxx family then all work (DCC signals, WiFi, etc..) is done on that one single module (integrating the actual controller, the WiFi stack controller etc..). And using for example the Arduino IDE, or any other IDE that supports the ESPxx family of controller boards, this "program", or "code", or "sketch" can be downloaded to that controller. Without "firmware, needed to understand AT commands". Anyway, I am still awaiting answers to my questions to Fred (Flightrisk). And I suggest for any further discussion other than related to my previous questions should be conducted in another topic, I do not like my topic to be hijacked.
Ah, and here lies the very thing that I have tried to avoid in this hobby, and prevent from infecting the DCC-EX team. Everyone has an opinion, and an ego, and some level of knowledge. When we manage those things, and consider the other people we interact with to express ourselves, it can be a great experience for everyone. When we want to use a little knowledge to try and prove our superiority over others, get angry and/or defensive, insult others' choices/opinions, communication becomes futile. When I read some of the above things like, "The myth distributed", "is completely obsolete information", "total hogwash", "is good for people living in the Middle Ages", "stupid", "And there I blame the DCC-EX crowd", it raises my blood pressure, which I don't need, and shuts down productive communication. Assuming we can move past that, I'll continue. The EX team is not in the business of making WiFi or Ethernet shields, but we wanted connectivity beyond a USB connection. The simplest way to do that until we wrote our own stack and offered something else better, was to just point people to the 8266's the same way we did to Megas and Motor Shields. And it was a great solution. Thousands use it every day to do exactly what they need it to do. It was an add-on to the CS, to provide WiFi, literally overnight. If anyone wanted something else different and sooner than we could get around to it, they were free to do so. Also, if the age of something was the only criterion to consider in business, we would not have L298 based motor shields, or maybe guys like me, still in use either. It is just a price, availability, user request, time to market, business decision. For the entire DCC-EX team, the support nightmare is flashing. It just is. The day the ESP-01s and the even easier Makerfabs board could not just be plugged in and work, life changed. We had to change focus, elevate the next WiFi solution in our priority list, and even partner with Makerfabs to get a new board to market, fast. Even with detailed instructions, using the Arduino IDE is a bit much for a lot of people. That is why we created the installer. I normally use PlatformIO to do everything, but because as I mentioned, I am lazy, I use the installer for a lot of my uploading. It's just easier and saves me time if I am not needing to debug code in the IDE. I love the devices with virtual drive drag and drop upgrading or OTA. Users, IMHO, shouldn't have to compile their own software in an IDE just to upgrade to the latest version. We encourage open-source development and for people to join the team so that we CAN come up with different solutions. We have a saying when people have a request and expect us to do all the work, "you have an itch? come scratch it", and try to get them to help We are in the process of addressing the next stage of networking when it comes to the Command Station. Our goal is to always have an open source DIY option with off-the-shelf parts, alongside other more "works out of the box" solutions. People will be able to build a command station, or just buy one board to replace 2 or 3. We consult our mission statement often on difficult decisions because our goal is always providing "free and open source" solutions and making model railroading simple, and more accessible. We try to provide solutions for the Conductors, Tinkerers, and Engineers. It is a huge, but rewarding, challenge. I could go into detail about each decision along the way, sometimes the "why" can clarify things, like I did talking about why we didn't just use one of the cores on an ESP32 to generate the DCC signal. But some of that is on the website (along with all those steps on how to plug things in and even flash firmware), and on Discord where all the history of our conversations is online for anyone to see (we are "open" there too). If it helps anyone, I am always happy to explain particular things or point them to a specific team member who can explain it better. I know I also get my terms mixed up and it may make me sound uninitiated. We want engineering to be precise, but sometimes close, if both parties understand each other is good enough Is the DCC command set our "API" or "Protocol"? Is it the EX-CS "firmware" or "software"? I'll switch terms sometimes. And here is a good one to troll a forum just to see how many posts you can get in the thread, "Is DCC DC or AC?" Not sure if I answered all the questions, but I think this was the last one I haven't taken a stab at yet, the team is listed here and deserve a lot of kudos for all the time and talent they provide. My name may be at the top of the list, but the true stars shine below it, and I would love for people to know their names: https://dcc-ex.com/about/about.html#gsc.tab=0
Find the right branch on github and finish the port if you fancy the ESP8266 so much. I however did not find it worth to do the ESP8266 port as the ESP32 is the better replacement for the task so I decided to port the DCC-EX CS to the ESP32 instead. I know of 3 more open source DCC CS based on the ESP32 which are not DCC-EX and as far as I know ours is the only one that produces a continious DCC signal without gaps. Some of these other projetcs may have supported the ESP8266 instead of the ESP32 at some point in time. (One in the US, one in France and one in Japan) Then when discussing: * Do not confuse the usage of an ESP device as TCP/IP adapter/coprocessor (connected via AT or WifiNINA) compared to running the whole CS on it. * All devices from Espressif require "closed" code to access their undocumented HW parts. Unless you reverse engineer everyting, there is not much you can do about that. Well, you could use another micropricessor, but you asked about an ESP. I think you would need to replace pieces like `tools/sdk/lib/libhal.a` and find or write a matchting TCP/IP stack. Harald.
