This is an early draft with only the main components mounted. The schematics are not even close to done yet. I like to place main components straight away to get a look & feel and in many cases I adapt schematics to physical layout. I know some prefer to complete schematics before they start PCB layout, but with modern tools I find it easier to just get the packages and dump them on a PCB. The larger chips often need to be rotated for optimal routing and sometimes you can change components or select a different SPI/UART etc based on what is most optimal.
I have several issues already. The areas at left with the yellow marked isolation space is fine. I have plenty of routing space in that area. The area around W5500 is however tight. An obvious solution would be to swap Wifi and Wired Ethernet. I don’t want to move the led’s up because they will end up under the SWD adapter, but moving W5500 up should work.
I have used ESP-03 simply because I had a pre-made package, but I am thinking of replacing it with ESP-12E. The later is a little larger, but have the same form with legs on the side that will hold the breakout board in place. The NRF breakout have an issue as all legs are on one side. This will make it weak as the other end will tilt up and down and vibration might break it loose. I have seen different solutions for NRF24L01+ so will look into that. The USB is placed in the middle away from the edges because it is held with those 4 large pad’s. These are GND and need extra support to provide mechanical strength to hold the USB as we plug in and out. As mentioned in an earlier post I had issues with this on a different board.
I hope to have the first draft of this ready to order PCB’s tomorrow.
Connecting things to a Windows PC is sometimes a bit of a challenge. I am in urgent need of a CAN-X adapter. These things cost and if I add my request for a Wired Ethernet, Wireless Ethernet as well as USB prices start to have several digits. The amount of software needed and the component cost is however not that big a job, so I can as well make one myself for the fun of it.
I will use STM32F405RG as MCU this time. This is an overkill, but I fancy doing something with this small M4 and it only cost 5.- USD.
- – 32bit ARM M4 168Mhz, 1Mb Flash, 192+4Kb SRAM
- – BasicPI SWD connector
- – Issolated RS485
- – Issolated CAN HS
- – NRF24L01+
- – 10/100Mbps Ethernet
- – Wifi
- – USB
This is my first Ethernet design and I am cheating big time. The F405 don’t have a Ethernet connector so I am adding a Wiznet W5500 chip. This provide a hardwired TCP/IP stack that we interface to through SPI. The smaller version of this W5100 should be well known for hobby makers.
As for Wireless we use ESP8266. Either ESP-3, ESP-12 or similar. This is a cheap solution that will work well in this case.
I am doing the same trick on USB. This MCU actually have a USB connection, but I am cheating and using a CH340 to get a serial over USB connection. I have used this for years and I never have any fuzz with this one. Programming a serial port is also much easier than programming USB drivers.
The rest of the code is a small router. I will not be doing any clever code on the CAN. I simply want to provide a dumb remote I/O and let software on the PC do the rest.
It’s not been much activity lately. You can blame the summer and the mess in my garden for that. I want to wire up a few experiments. One is a motor controller based on F405 and the other is a Ethernet controller based on F107. The Rx breakout board is excellent for this as it is vero-board friendly. Looking at my earlier draft I realize that I need to add a few more leds. I want the breakout to be as generic as possible, so using pin’s for leds is a challenge because it means those pins already are used. But, I notice that PC13 and PC14 are located quite handy so I will add a led on those.
The first batch will be only 10 PCB’s, but this board will be available in several options. I will make a few assembled boards available for ca 10.- USD + P&P later, but I will also be looking into options to manufacture the boards in higher volumes.
Writing a blog it is always Nice to know that someone (except bots) are reading it. Readers from 90 countries have visited the site so far, Thanks to you all.
Due to the commercial marketing bot’s that spam any log please use a proper email if you subscribe or comment. I am the only one that will see the email, but I tend to reject anything that I suspect is a bot.
I earlier talked about replacing the legs on this robot, but the fact is that I want to rebuild the entire robot from scratch. I need stronger legs that can carry some weight. I also need a control system that includes a battery charger and PSU. As mentioned earlier 12 servo’s will draw 10+A in peaks. Getting that out of a LIPO is not a problem, but I need to regulate it to 5V and still deliver 10A.
The picture above show two different LIPO batteries. The one at bottom is 5.2AH while the smaller at top is 1.5AH. Both at 11.1V. Both have a discharge rate at 40A max. The smaller one did take me by surprise because the large one weight 400g while the smaller 100g meaning I get more power by using 4 x 1,5AH at the same weight. This will complicate the charger thought, but I will get back at that. One of the smaller ones will probably provide 2-3 hours of continuous operation.
I did buy a 24/12V 5V/10A Car Converter module that is ok, but the hard fact is that 4 off those DC/DC step down regulators cost 2.- USD and weight very little. Their size is an issue, but that’s not really a problem on this robot. This gives the makers the choice to use any 6-30V LIPO at hand.
The picture abobe shows my veroboard PSU using 4 x DC/DC converters in parallel to support 9-12A in peaks. I need to work on this a bit, but I like the idea because the entire PSU will cost something like 4.- USD.
On STM32 (or ARM) I have always used CooCox IDE. This is free and even recommended by ST these days. It is based on Eclipse and quite OK as it integrate properly with full debugger to ST-Link etc.
This is a screenshot of WhiteStarUML that I use for simple UML drawings. I actually used to create my own CASE tools in earlier days to achieve a higher level of automation, but those tools are build on MFC and I don’t want to continue using MFC as GUI base since Microsoft is not supporting it seriously.
WhiteStareUML is free, open source and written in Delphi. It is quite ok for high level class diagrams. Code generation on these tools tend to be Limited.
One important part of easyIPC is it’s “repository”, a real-time database that hold all information needed. The repository on devices are very simple and is only a map of objects made available through the interface. Raspberry PI on the other hand will need a repository of all devices as well as a log of data that has been collected. A node hold its own data only and depend on interconnection to other nodes their data. The exception is the dictionary part that need to be on each node so we know what resources we have in our network.
The UML diagram above illustrate the 4 main tables in the repository on Node level. At device level only the Local Object Map is implemented.
Node is a list of main nodes accessible in the system. One of the entries will be “this” node.
Local Object Map is a list of local resources, objects and variables that are available through the interface.
Remote Object Map is the Node’s local info storage about objects. This contain full name, description, PID and other information uploaded from the device at start-up. The Remote Object map can also be loaded/saved locally on the RPI for fast start-up.
Data is a log of data for a selected object/resource.
This is a very early draft so expect some changes as we dig into more details.
Our High Level protocol include a 1 byte message code. The reality is that we can also add PID’s as messages with an object containing several parameters. In fact we talked about reserving ranges of PID’s for special needs. With a 2 byte integer we have 65536 possibilities so if we reserve 0 – 0x7FFF for parameters we can use the ranges above for special needs.
I am thinking about something like this:
- Bottom PID range for variables/Objects.
- A range for common, mandatory objects like firmware information etc.
- A range for special purpose PID’s like envelope etc.
- A range for standard commands (restart etc) or should this be in the main message code?
- A range for device specific commands.
As for the main message code we need:
- – Support for the start-up sequence.
- – Link maintenance messages (ack, nack, repeat etc).
- – A generic message to act as a container for PID commands that is neither read or write.
- – A generic read message.
- – A generic write message.
- – A subscription/unsubscribe message.
- – A range dedicated for device specific messages.
- – A heartbeat/Status message.
- – Error messages.
What else? Let’s leave this for now. This is an early draft and we will definitely be adding stuff here as we dig into the details. With both a 1 byte main message code and the possibility to use PID ranges as sub-messages I think we should be well covered. We can even let the PID ranges be message specific if we need to.
One of the challenges dealing with a parameterized system is error handling if only some of the parameters are successfully sent. This is a classic issue for systems using Modbus and CAN that we have solved in easyIPC.
We earlier described techniques using CAN-X/SPI to transfer larger messages using “envelopes”. As an envelope contain it’s own CRC we also have a method to guarantee that a set of parameters arrive complete or not at all. SPI, RS485 and Ethernet will not need the envelope as messages can be rather large and have their own CRC’s.
This means the transaction system is embedded into the communication system as we will either process a complete message or nothing at all.