A RTOS (Real-Time Operating System) library consist of several components that most often are compiled or linked into embedded applications as a library. You don’t really need a RTOS in embedded systems as many are happy running things in a loop (also called Round Robin) and timing things themselves. However, as applications get more complex you end up doing more and more of what I would expect from a RTOS library in your code and at the end it can end up a bit messy. I have a strong preference for using a RTOS and I have a library that I have been using for decades. I ported this to Arduino earlier to run 20+ tasks on a 2Kb SRAM computer.
The illustration above show some of the main components in a RTOS package. A bootloader, a kernel, a HAL library, a Watchdog system and CLI (Command Line Interface) is usually included in many packages.
The RTOS I will use is called yX (myx) which stands for micro kernel. The core of yX is as with any other RTOS a kernel that will change from task to task under timed control. yX is however very special in the sense that it is a “linear scheduler” that combines options for actual threading schemes with round robin schemes and offer a very high scalability.
A linear scheduler focus on continuous usage of resources with minimum of interruptions. One part of this is that we avoid thread shifting and run tasks in sequence (an advanced form of round robin). The second part is that once we thread shift we allow multiple tasks to use the same stack either by using the main stack or by sharing a 2nd stack.
The result is scalability without compromising CPU load or memory usage. The effect is so good that yX is also used to extend the capabilities of Windows and Linux applications. The later even allow embedded tasks to be moved and run on a host computer, something we will return back to later.
An embedded Real-Time system have main three concerns:
- Timing of hard real-time tasks
- CPU usage
- Memory usage
Timing requirements are often so hard that they can only be achieved by hardware, an hardware timer or running the task very tight in the main loop. yX can support this directly, but maybe more important is that it can adapt to let the application take over and only focus on support tasks.
One important reason why you actually need a proper RTOS is re-usability of code. The RTSO library with it’s HAL is often the required code needed as infrastructure to make module portable in the first place.
A classic RS485 2-wire network consist of a Master and multiple Slaves. The master query each slave ensuring that only one device communicate at the time. This makes it an easy network to implement, but the bandwidth usage is low due to all the waiting time. The second issue is that a device needing to send an even/alarm simply have to wait.
Some protocols like Profibus offer a solution to this by using a timing scheme. If device #1 has been silent for n ms device #2 will attempt to communicate etc. This type of schemes have usually required better hardware integration and been unreliable with classic UART/USART ports.
Testing on STM32 will however show that we easily can run a Systick at 1000 times per second giving us a response time of 1ms. We can even run it at 10,000 timer per second with 10% MCU load. This offer an opportunity to respond to events with 1ms accuracy. If we in addition create our serial port so we always will read input we can as well verify if what we send is what we received and detect collisions on the bus.
The circuit above shows the modified interface where we control both Read Enable (RE) and Send Enale (DE) from the MCU rather than combining them. The rest of the circuit is rather classic RS485. R4 is the 120 Ohm terminator, R5 and R3 are the bias resistors. R1 and R2 are just shortcut protection and can be replaced with a 0 ohm resistor. D1 and D2 are 12V protection on the line and is optional. L1 and L2 are just leds used to indicate if we are sending/receiving.
The interesting bit about this is that UART/USART interfaces are more commonly available than CAN is and RS485 is easier to wire and get working. If we can overcome the drawbacks of using RS485 we would benefit from a network with the same advantages of CAN, but none of the disadvantages. This will not be doable on all UART’s out there, but I believe STM32 and similar have sufficient juice to manage this without investing into more expensive hardware or compromising MCU availability for other tasks.
The schematics for the main MCU parts. This still uses the ESP-03 for Wifi. I intend to replace that with ESP-12 and ESP-01. The m,ain reason is availability & cost, but also the access to Reset pin that is not available on ESP-03.
At right bottom you have a 6 status leds, one for each communication port. The 7th led is showing 3.3V Power. On top you have my SWD Connector.
I need to do a review of pull-up/down resistors. Usually I don’t add them because the MCU have internal ones that can be added in software. But, you need to consider what happens during the start-up while the pins are floating. I added a pull-down on ch_pd to force ESP-03 to be switched off until software switch it on. I need to add the same on the NRF Circuit to avoid that it og wild transmitting junk during start-up.
The schematics for the NRF24L01+ breakout boards are not the most interesting. It’s a standard SPI with an interrupt pin and two enable pin’s this time. I am using two different footprints that will support 4 different break out boards available. The classic have a range of 100 meters, while the more advanced claim a range of 1.2 km. But, keep in mind that these ranges are outdoors with no obstacles. Indoor going through walls the range will be much Shorter.
Other 2.4Ghz Technologies like Zigbee exists, but I have a preference for NRF. The main reason I am adding these in addition to more classing Wifi is because I want to use this on my next version model train control system + the fact that it’s handy to have around on an adapter that plugs into a Windows PC.
The ShockBurst protocol allows multiple nodes to talk directly on 125 different channels and With 6 pipes simultaneously. A 32 byte payload on packages and a data transfer up to 2Mbps makes it great.
But, keep in mind that this is a non-secure wireless communication method.
Not finished yet, but an early draft of my communiaction adapter.
Isolated RS485. I seldom bother with terminator resistor on RS485 because I never have errors due to this below 10 meters. Bias is a different issue as I experience problems without bias resistors on one side even on very short distances.
The main difference between RS485 and CAN is that CAN uses arbitration and is depending on better timing. RS485 is in contrary much easier to get working even with lousy solutions and cabling.
This is an isolated CAN-HS interface. ADM3053 offer a all-in-one package that cost a bit, but I decided to try it out. As for cost we are talking about 5.- USD rather than 0,5 USD.
A normal transceiver will give some protection while ADM3053 protect against much larger pulses, but it is not unlimited. Your level of protection should be adapted to your usage, and using a galvanic isolated CAN interface is basically an overkill for most hobby projects.
I need to test if I can get away with this simple circuit. The only challenge with CH340 is that it’s documentation in English is limited, so it’s a bit difficult to read up on all the pin options. But, I have seen others attempting this so will give it a try. This is CH340 as minimalist as possible with UART on one side and USB on the other.
The reason I like this is quite simple. We bought RS485 adapters for 1.- USD build on these some time back and now we simply don’t bother with anything else. They simply work to well. They always install correctly on Windows with no fuzz.
Updated the W5500 Ethernet schematics. C9 to C15 present a challenge in PCB routing since I am using 0805 packages. They are supposed to be attached close to each AVDD pin which is a challenge. Also I added the L1 ferrite bead to stop 100Mhz signals from crossing over.
But, I am still thinking that the 8.- USD breakout (below) is a tempting simplification. Particulary since the footprint will be smaller with this. I am also thinking that these breakout boards will even drop in price later.
STM32F303 is a M4 clocking at 72Mhz. It has strong ADC’s and build in op amps as well as 3 motor controllers on the larger chips. It is a very interesting MCU for specialised motor controllers, but have so far been priced in the 10++ USD region. Lately I noticed that CB and CC versions of the MCU are down to 3-4.- USD on AliExpress.
My interest in F303 is limited because I believe MCU’s like F405 and F427 are better choices, but F303 offer the LQFP48 package making it attractive on applications where a LQFP64 is to large. I have so far not considered it because of the cost. I will add veroboard friendly breakout boards for STM32 Cx chips later.
The Rx Version should be able to use my Rx Board. I have mentioned ST’s pin compatibility between MCU’s before. It simply means that if a feature is on both STM32F103CB and STMF303CB they will most likely be available on the same pins though registers and coding might be different. This makes it possible to start With a low end MCU and simply upgrade to get more Flash/SRAM/Speed or extra features.