ESP32 Ethernet Hat Challenges

I am a bit stunned by the memory usage on ESP32. This is a 178 line test script that uses wired Ethernet and it only send an UDP message out – the program uses 645606 bytes – which is 49% of available space. Luckily it does not increase that much, so I assume this is the core libraries. I would also like to understand why a 4Mb Flash is reduced to 1310720 bytes… The answers are probably online somewhere.

A more annoying issue with ESP32 is it’s SPI support. I wrote sometimes earlier that I lack info about SPI, but I finally found some doc that states it can support up to 80Mhz on selected pins, and 40Mhz if you select your own pins – but only in Master mode and only in Full Duplex. In Half Duplex and Slave it might be reduced to something like 8Mhz due to lack of DMA support etc – bummer. This is not a showstopper, but it will force me to use reduced speed on SPI with ESP32 modules in the stack – which is a bit annoying since this is an Wifi/Ethernet adapter.

Coding on an Olimex GW board works fine – I am not able to test SPI here, so I will use a different board for that, but Ethernet works just fine so far. I must admit that ESP32 is a good match for Arduino libraries. The libraries are not as flexible as the full SDK, but it requires very few lines to get something up working. The main limitation that the libs are blocking can also be overcome by putting both CPU’s to usage.

Wifi/Ethernet Rev 1.2

Minor upgrade of the Wifi/Ethernet Hat as I remove the 5V Power connector from all Hat’s. It just occupy space and I really needed to add a shortcut protection if I was to keep it. 5V for MCU will now only be available from RPI backbone or USB only. I already have a separate PSU board + it is easy to add a connector on RPI between pin 4 and 6 for 5V if I want to use a board stand-alone and not use USB. I will do this change on all my boards + add PSU protection on those who need motor power. The objective is to avoid that an entire stack is destroyed by a single mistake mixing up 5V/Motor or PSU polarity.

I just receive an Olimex Gateway Development Board with the main components, it lack CAN and SPI1 but Ethernet is identical and based on LAN8710. I might swap for LAN8720 later, but that is for later. The Olimex have some demo software so I can get Ethernet up running and experimenting.

The 2nd change I needed was that I use an AMS1117 for 3.3V on ESP32 and a SPX3819 for LAN8710 and by mistake the 3.3V outputs was connected. The intention is that Ethernet should be switchable on/off. I am however also a bit unsure about SPX3819 as this feeds 0.5A. I need to verify that this is sufficient.

The 3rd change is that I by mistake added ground plane below over the build in antenna on ESP32. I plan using the external antenna on this, but we should still avoid ground plane over the antenna part. The new PCB is displayed below.

And just to repeat – this board basically replace Raspberry PI for Wifi, Bluetooth and Ethernet allowing an ESP32 to be used in the stack. SPI is connected on RPI bus and can support both Master/Slave and the Half Duplex mode. I have never tested ESP32 on SPI, so it will be interesting. I also have the CAN port. The main difference from RPI is however that I can add several of these boards in the same stack if needed.

I will regardless get the Olimex board working before I order this + I just also receiver PCB for Thunderstick, 12PWM and Sensor Hat, so I got plenty to play with – as if my backlog was not already filled 🙂

LoRa & GPS

Rev 1.3 of my LoRa/GPS Hat. It will be a Rev 1.4 before I order this PCB because I want some changes. I want to remove (11) the UART port and (7) the separate Power port. The 5V power port will be removed on all Hat’s as I want to force 5V through USB or a separate PSU board. Having a separate MCU Power connector on each board is just occupying space and I need to be more consistent to separate MCU power and Motor power on those boards that need both.

  1. CAN Tranceiver
  2. LoRa 125mW Tranceiver. Covers between 3-6km of range.
  3. LoRa 1W Tranceiver covers up to 12Km of range.
  4. LoRa Antenna port
  5. Leds
  6. Standard USB
  7. MCU Power
  8. GPS Module
  9. GPS Antenna port
  10. GPS USB Connector
  11. UART
  12. SWD
  13. RPI Connector

I have the modules, I also have the Rev 1.0 boards, but I did a schematic error on 1.0 and I have so much to do so I will make Rev 1.4 and order new boards before I assemble this. A last change I am considering is to remove the E22-900M30S which is the 1W version. But, I will leave it on for now since I have a few modules anyway.

This board is quite flexible as I can switch on LoRa and GPS separately. The main reason I am holding back on assembling these units is coding – it requires a bit of coding for testing and the framework is in the pipeline, but I focus on XPortHub to build basic libraries/infrastructure.

 

Unable to start USB from STCubeIDE

Adding the USB console with a buffer so I can perform printf before the console is open was very usefully as I instantly detect that it’s huge differences between starting the device from the IDE on debug mode or on its own.

These things are a bit annoying, but they can be handled if your aware of them. USB start from IDE if I restart the computer, but after a while it stop working. If I start the device outside the IDE I have no problem. I believe the issue is the PC/IDE and not the device.

STCubeIDE promote usage of Debug, meaning your start in single step mode and I know from other IDE’s that this sometimes can be a bit funny. I only use this to verify init sequences as single-step is very intrusive in a multi-threaded app. So the console is very valuable as it instantly tells you what is going on and give you a capability to log from the device at high speed since this is USB. STCubeIDE have a more hidden support for starting the device differently so I will set this up later. For now it is workable to restart the device by plugging USB cable in/out.

I am not sure USB is of much usage in real use on a control system, but it is very handy for debugging, downloading new firmware (once I get bootloader) and maintenance/config tasks. I am however depending on one feature – I need the MCU main feed to be 5V only and very separate from motor/pwm PSU’s. This enables me to power the MCU through the USB. I realize I need to review my boards on this to ensure this is safe. In fact, I am considering removing external PSU feeds for 5V and only use the RPI bus, meaning you either feed USB power to one device or add a PSU board to the stack.

 

BasicPI OS Started

Kind of cool – using USB as console on XPortHub – notice all the init messages before the USB starts. Just a buffer tricks. The “Terminal” is a simple C# app that open a port, read/write. I will upgrade it to a proper CLI later.

This is maybe the most important part of the infrastructure as it allows me to use USB as 2-way console/HMI for debugging.

Getting USB to work is straight forward, but getting it to work properly with STCubeIDE is a different issue. It’s been a few tweaks to get a working IDE.

The idea is that you can use this console to upload firmware and set configuration as well to do debugging/maintenance.

NB-IoT Hat rev 1.1


Just a minor upgrade of my NB-IoT Hat Cleaned up ground plane, remove one UART, added new SWD and resistors on SPI1. I have still not have time to assemble test the previous one, so will do that as soon as I get a SIM card.

This Hat is cool because NB-IoT means you buy a SIM card with close to no monthly cost and send data from anywhere you can connect. NB-IoT is gaining momentum in Norway, so I am on my way to get a SIM card.

  1. CAN Traceiver
  2. UART for com with SIM7020
  3. SIM card
  4. SIM7020E
  5. USB for SIM7020E
  6. Antenna
  7. Leds
  8. MCU USB
  9. Led
  10. External Power input
  11. PSU
  12. SuperCap to assist on send peaks
  13. SWD
  14. MCU
  15. RPI Bus w/SPI

 

 

Plain

Plain (Programming Language for AI Networks) is very different from Languages like Python, Java and C#. The only similarity is that they all are based on a Virtual Machine and all use C/C++ as native host language.

One difference is that C++ is more openly integrated into Plain than Java and C#, while Python have an easy path to use C libraries as well. Plain is designed to extend C/C++, while the other languages tries to replace C/C++.

The core difference is however that Plain is network centric and capable of handling logic for a system distributed over a network. It implement concepts not covered by any other Language while it still build on the best from many Languages. In languages like C/C++, Python, Java and C# you need to develop the single device and manually implement a communication technique to other devices. Plain has all this build into core and the added “system diagram” concept that allows a developer to interact with a Complete system consisting of a network of nodes as if it was one system.

Plain support state engines at it’s core which provides a more natural way of coding AI Networks – it simply means we process based on events in the system and Focus more on WHAT we do rather than drowning in the details of HOW we do it. Plain can deal With HOW, but more important is that it leaves those details to C/C++ that is far more suitable to interract With Electronics. Close interaction With C/C++ is important and is provided through it’s OS.

Other key features are parallelism, threading, distributed processing and complex concepts implemented at core with mechanisms forcing the developer to use them in a systematic and safe way.

Plain is basically an assembler assembling into a RTL (Real-Time Linker) syntax that the VM need to convert to executable.

BasicPI OS is implemented in C++ and provide easyIPC, a networking technology that is at core in Plain, but other more classing communication protocols like Modbus and CANbus can also be supported.

At the end of the day Plain was developed for one purpose – I wanted to do more with less hours. I wanted to build high quality AI networks capable of handling complex logic with only a minimal number of coding lines.

Plain looks like an advanced 3rd generation, text based language, but it is referred to as an assembler because it is 1:1 between Plain statement and VM instructions. The higher end of Plain is another language not described in details yet called PLD (Plain Logic Diagrams).

Plain has a lot of heritage from various older languages and easy to learn and easy to use has been at core in it’s design.

Status of Plain is that it’s core infrastructure is coming together, so I will start on it’s Assembler, Linker and VM – they exist as proof of concept, but it’s a job to complete them.

If you have followed the long path on this blog you will see that I am building electronic components that form part of a modular control system. Each of these will be loaded with a Plain VM + supporting C++ infrastructure to handle the device. Once they plug together the magic will happen as they interconnect and automatically form a system controlled by Plain. Seen from Plain it will look as if it all is on one small super-computer.

Plain is not a magical wand making robots more intelligent. In many way it is a modern PLC making it very easy to control the machinery of a complex, modern AI. The actual intelligence is in the logic applied by the developer. The only difference is that Plain will allow even none-developers to do far more will less effort.

Programming languages have not really changed that much since Grace Hopper implement the first ones, but Plain is a huge step forward into allowing the developer and user to specify what a system should do rather than drowning into the details of how things are done like we do now.

The only part missing from Plain is that I have not described how we do advanced Web applications that will be coming up later.

7x Stepper Revision 1.3

This is Revision 1.3 of the 7x Stepper Driver.

  • Added resistors on SPI1.
  • Changed to new SWD format.
  • Added protection against wrong PSU polarity.
  • Moved leds into board.
  • Major improvement on ground planes.
  • Previous change on 1.2 was that I turned the Connectors around. 

I re-routed the entire module from scratch and created ground planes on both sides. The new technique is to use the top-side as much as possible to leave the bottom side as much as possible. But, I also added the ground plane top side and added extra connections to ensure that all fragments are connected to ground on bottom side.

The reason I abandoned ground plane on top-side was because of the number of short-cuts I experienced. I have since then invested in microscope that makes it possible to actually see if I have a shortcut. This is regardless only a problem on the prototypes where I do manual assembly.

Here you see the top plane (blue) that get very fragmented since it carry a majority of the lanes. The good thing is that I can ground icelands with a single place through.

This is the bottom layer (red) that now is more or less one solid ground plane with minimal fragmentation. This is a major improvement from the previous Version.

16xServo Hat

This is rev 1.3 of 32xIO/Servo Hat. It’s been a few revisions that I never bothered to build because the original is working well. But, I need some changes on this:

  • SWD need to change to new format.
  • Connection to SPI1 need resistors.
  • 2nd Power connector needs to be added.
  • Connection between motor and 5V USB can be moved into board.
  • Leds can be moved into board.
  • Adding protection diodes on wrong polarity.

The main change I want is however new Servo/IO connectors. The right-angle headers used here are great, but they have no mechanical fittings and are candidates for falling off during vibration. How I can achieve this is a puzle. I might have to use JST Micro 3-pin in which case I can achieve 16 IO/Servo ports maximum. I am however thinking that is OK because firstly I can stack board, secondly 16 x IO is a lot + it is much easier to ensure 16 x PWM timers and use hardware for higher pulse accuracy on Servoes.

That said I think the 16x IO/Servo Hat can start at revision 1.0 and we upgrade this to rev 1.4, meaning I maintain both for now. The 32xIO/Servo Hat is after all a cool hobbyist board + it is the closest I have to a generic GPIO Board.

ESP32 based Ethernet/Wifi Adaptor


RC1 of the ESP32 based Ethernet/Wifi Hat can be seen above. The module follow the same standards as the STM32 based modules with SPI backbone CAN and USB. The board can fit straight on a Raspberry PI or be combined with any module described in this series. New to this version is that I removed the IO ports of the previous version and added a wired Ethernet option using LAN8710 Transceiver. This is a 10/100Mbs Ethernet and the lwIP stack is already on the ESP32 module. In Effect this gives Wifi, Bluetooth and Ethernet Acces in addition to CAN, SPI and USB. 

ESP32 have a build in antenna that we still can use, but I added a 2.4Ghz antenna option that can connect to IPEX antenna on some modules. This allows us to use at least 3 different ESP32 modules available on the marked. The 3D model below show the module annotated.

  1. CAN Connector. The actual connector is a right angle 3-point micro connector. Basically the same as used on all boards.
  2. Terminator for CAN. If connected add 120Ohm terminator resistor.
  3. LAN8710
  4. RJ45 Ethernet with magnets.
  5. Ethernet power led. This indicate if Ethernet is powered on or not. I use a separate SPX3819 that is controlled by ESP32 enabling me to switch off Ethernet if I want to.
  6. 2.4Ghz antenna connector for Wifi/Bluetooth.
  7. USB Mini connector. Needed for programming the module.
  8. Leds
  9. CH340G UART to USB. I have used these for a while and I am very happy with their performance.
  10. External 5V power connector.
  11. Internal PSU regulator
  12. ESP32 module.
  13. Reset connector.
  14. Leds
  15. Raspberry PI connector using 5V and SPI.
  16. Boot connector
  17. CAN Transceiver.