BasicPI

Just a picture showing what I am working on. I also think this is the first picture with Ethernet mounted. Both these boards will soon come in new versions.

I need to experiment a bit with picture resolution since my screens now are 4K – I used to reduce pic resolution by copying pictures through a 2K screen to make them more user friendly – that don’t work anymore.

The main board at right was made 2cm short of full length to enable 5 x DSUB9 in front panel with 1:1 cable to the ports. What you see here is a test cable used to communicate port to port. Firstly I detected that port 2 on the cable was not properly connected and secondly I detected that the 3rd port had crossed tx/rx – but, I got the CANFD ports working. Using CAN ot RS485 I usually either use DSUB9 or simply screw terminals. M12-5 and NEMA2000 (left) add a different perspective. I am quite eager to test both NEMA2000 and an increased speed version to see what speed/distances that can be used.

But, that’s work for another day. I lost power in my house yesterday and realized the reason was that a plug-board in the basement had short-cutted. The reason it shorted had something to do with 20cm rainwater on the floor. It has been raining so much that water now comes in through the floor rather than leaving out – so water pumps was installed this morning. Only minimal damage done, but this scare me a bit – I did not thing this was possible and have even bragged about my basement beeing dry – I never considered the water to come in from the drains in the floor. Oh easter fun!

The block diagram below reprecent a single ECU Node – which in reality is a baby with many names. It is also called a VCU (Vehicle Control Unit) or Mini PLC if you like, I prefer the terminology “ECU” – Electronic Control Unit since it is assembled in a waterproof, small box and general purpose.

We have several main board versions, but the latest dual ethernet version will become standard because it is more flexible than the previous versions. I started with a main board with 3 add-on modules and 3 CAN ports, but moved on to a pure M12 based, waterproof version with 8 add-on modules and have now extended that to include a dual Ethernet design. The key here is that the same board can be assembled with or without Ethernet if you want the IO slots for other purposes, but it made a lot of sence to have the capability to daisy chain Ethernet and avoid an external switch. Below is a picture of the M12 PCB’s and modules mounted in the lid to form 6 x M12 ports and one MX23 in this example. The advantage with M12 and MX23 is that they are water-/air-tight.

The new version with RJ45’s will not be directly waterproof, but it can be configured to use only MX23 or M12 connectors if we drop the dual Ethernet RJ45’s. I also have single port Ethernet for M12-4. but that target sensors that need Ethernet and not a daisy chain between nodes. I will do a few mechanical tricks to keep RJ45 waterproof – or more important airtight. As you close a box you will have a minimum of air that contain humidity inside. What you cannot afford is that this air is renewed bringing more humidity into the box + as this is to be used on vehickes and boats it must tolerate a dash of water as well.

Back to the block diagram you see 8 sub-modules – in reality the main board support ten, but as one position is needed for Power we max have 7 free positions (5 if we use dual Ethernet). The idea is that you use a distributed design with either CAN or Ethernet as network between nodes. And from any node you will see the system as a big tree of IO and logic. The sub modules use a 8Mhz full duplex serial port and the MCU frequencies 500 and 250Mhz is selected for optimal baudrate settings. I will return to the easyIPC protocol in use. A trick is that the sub-modules are booted and powered from the main board and can be switched on/off separately.

Configuration is mainly done with a CLI that can access the entire system from a script. Putty can be used, but we will create a specialized tool to support fw download and scripting.

Wifi/Lora/LTE modules will be added for wireless solutions, but these needs to be handed specially due to the antenna. I am in general not found of radio involved in control systems so the core design is wired and closed. IoT Cloud and Web technology can easely be supported, but outside the core control system. Web based systems are so slow and unreliable that they don’t notice a few ms extra through a GW dedicated for that purpose.

Support for screens are coming. I started with 7″ or 10″ screens and go up to 24″. I will get back to the details here, but in gereral we connect either CAN or Ethernet to a HMI controller so we can add as many screens or HMI nodes as we need.

At precent things are a bit in “SW mode” – meaning SW is beeing created and as this takes time it is not that often I have news to update here. It is easier to share pictures of HW than of SW 🙂

Work in Progress – managed to finish schematics and place components – a bit more than I expected, but extended board on right side with 2cm so it goes wall-to wall in the box and SD-Card comes out as awell. Using KSZ8863RLL to achieve dual Ethernet on this. The MCU will see this as a RMII interface and it will act as a switch. This is a first draft as I have to go through the schematics again and document each component and optimize the layout a bit. But, it looks good. I use 2 x single RJ45’s so I can decide to populate with either none, one or two Ethernet on the same board. RJ45’s, SD Card and USB is not really waterproof “as is”, so might need to do something on the lid side on these.

• 1 x STM32H723Vx – 512Kb Flash, 560Kb SRAM ticking at 500Mhz.
• SWD Connector
• 1 x USB
• 1 x CANFD
• 2 x 10/100Mbps Ethernet
• 10 x Module connectors
• 1 x SPI Flash
• 4 leds

This board is still a bit work.

RTOS with a Dictionary is standard in any system I build.

Most people will think FreeRTOS or a similar thread shifter then we say “RTOS” on embedded, but the hard reality is that most embedded systems are “barebone” and run some version of a round robin scheduler. Myself I do the same – I install FreeRTOS if I need to, but I still run a Linear Scheduler on top of FreeRTOS, Linux or Windows because they scale better than needing a stack for every thread.

Another major issue is that a linear scheduler can switch tasks with ca 10us in between, while any task shifter struggle with the same since they are depending in interrupts. You are welcome to try interrupts 10,000 times a sec (100us) and see what happens. You will be using a lot of CPU power on that interrupt alone – depending on MCU.

But, what about the OS part of any RTOS? An OS is more that just multi-tasking – it is your eco-system with library functions you can safely access in any module and expect to exist on any system you use.

• Clock – RTC and ETC is a must
• Signals and Timers
• Message Queues
• Standard API functions/framework.

Myself I also include a mechanism called a Dictionary that is an index over variables and tables that I use as API between modules. In a well designed system my dictionary will be the only module that can access all parts of a system and it consist of a generic part that is extended with an index table containing pointers to variables and tables I want to access.

One of the standard functions are Persistent Memory that is handled by the Dictionary.

Another critical function is entity integrity then dealing with protocols like CAN and Modbus. These protocols are capable of sending you a single parameter in a message, meaning that your system can start operating on incomplete data unless you have a mechanism ensuring integrity over a set of variables. The most used technique is a low cost CRC.

But mentioning CAN, Modbus and other protocols they all access the same variables making it very convenient to build these protocols on top of a dictionary.

Or to make it simple – a well designed dictionary will simplify your system dramatically and reduce the total usage of flash/ram if you have a complex system.

CLI and Configuration is another feature. Will all API variables accessible through a central dictionary it becomes ease to implement a CLI with set/get functions, and since CLI is USB/TCP or serial ports they can be scripted as well.

The last trick I often use is the HMI that mirror the dictionary on a PC that again is linked 1:1 with components or entities on the screen. This allows me to focus on gadgets and with a few lines of code I have fancy UI that can visualize or edit variables/tables on multiple embedded devices.

FreeRTOS or any thread shifter can be added with a few lines of code if I need them, most often I don’t.

As for modules I have a strict requirement that any module – collection of embedded C++ code – can be dropped into any project with only 2-3 lines of code since they use a standard API and OS definition that I can duplicate on any system embedded, Linux or Windows.

Added functionality like Redundancy or distributed systems is basically added dictionary functionality.

One advice is to use #ifdef to exclude/include entire modules. GCC is very good at excluding code that is not used, but this is the only time I recommend #ifdef and a custom config.h that manage this.

I am using KSZ8863RLL to achieve dual Ethernet, This is a 3 port switch and it basically just replace the LAN8742. The MCU will just see an ordinary Ethernet not realizing that it is a switch. My initial idea was to re-use the ECU main board with minimal changes, but I underestimated the amout of extra components needed + many of the pins need a strap since they have one purpose during boot and another during operation. The result is that with 0603 components I run out of space, I can start pushing trancient caps to the back side, but I also have 2 cm space left on the right side so I can push the MCU to right and re-route the entire board. What I can’t move is the M connectors because they are aligned with the sub-boards, but I can move MCU w/components and route more to the right to free space for dual Ethernet.

The schematics on this is not 100% yet – I have found 2 good references that I am using, but it is a fiddle then you want to reduce components. I am using a trick to strap Ethernet to RESET as it power up so that it don’t boot before the MCU wants it to. I will also use a 2nd 3.3V PSU that can be switched on/off for this. I preffer to leave all components on top layer, but I will consider putting straps and trancient caps on the bottom. It is an interesting routing experimen, so will be interesting to see if I get this working. TBH the complexity on this is at the level where I expect I will need two PCB runs – actually I always do.

As mentioned in my previous entry I started with 100Mbit, considered 1000Mbit and reversed to 100Mbit. The reasons to stick to a more conservative 100Mbit are many:

• Cost for 100Mbit is ca 1/4th of cost for 1000Mbit.
• Very few PLC type systems support 1000Mbit on daisy chain designs.
• And the hard fact is that a 10Mbit system is sufficient for the signaling used in most configurations.
• Complexity on routing increased dramatically.

All in all I concluded that the benefits of having 1000Mbit was to small to justify the extra cost and risk.