Final 3D with horizontal connectors. I might add a jumper to allow separation of 5V and Stepper V+. This can in theory drive 28 PWM channels up to 50V @ 500mA each, but the ULN2003’s overheat if we tried that.
I will add a proper PWM Hat later as this is dedicated for 5-wire stepper motors.
This board is a bit misleading because I am using the wrong connectors to mock up an early 3D. The actual connectors are right angle and a bit wider, but testing on a paper print it seems that I have just about the size I need. Below is a picture of the Stepper Motor this targets.
These Steppers cost ca 1.- USD and they took me completely by surprise. As I started one of them it was moving slow, smooth and absolutely soundless far more powerfully than I expected. You get a lot for 1.- USD on these to be honest.
Revision 1.1 of my 8x DC Motor Hat. Basically this is 8 x DC Motors and 16 x IO/Servo, but the IO ports are 5V only. Differences from revision 1.0 are;
This module was basically created because I wanted to control a robot arm I have around. This is a toy with 5 x DC motors, but using the IO I was hoping to create some position or end-stops so I could control it better. Just fun.
Revision 1.3 of my 32xIO/Servo Hat. This export 32 of the GPIO pins using a Signal, V+, GND header common for Servo ports. V+ can be separate or use 5V from USB.
This version uses the 3 edges to get all 32 IO’s available on the edge of the board. It does in addition add the CAN port (top left) and address pins are removed.
STM32F105RB is also replaced with STM32F405RG and I added the USB port. USB is handy for many reasons, but it makes it convenient to download MicroPython and then use USB as programming port for Python scripts.
I need to return to MicroPython because porting that down will be a large task. I am confident I can get it compiled and ported fast, but I also need to extend the libraries to support firmware available on the Boards.
Small units to communicate over radio is not exactly new. We are well used to 2.4Ghz modules that cover both 100m and even 1km ranges. LoRa stand for Long Range and some of the units have very impressive parameters.
This little fellow is 20x14mm and can communicate over 6,5km using 850-930Mhz. It’s brother E22-400M22S cover 410-493Mhz and it’s bigger brothers M30S cover 12km with 300Kbps data speed. The M22S uses ca 100mA transmitting while the more powerfully M30S uses 650mA for 12km.
These are LoRa (Long Range RF Tranceivers) for the global LoRaWAN standard and cost ca 8.- USD.
Ra02 is smaller, cover up to 10km and uses 433Mhz. This is also an older unit costing <4.-USD.
Usageand interfacing to these are rather straight forward with UART or SPI, and the radio range versus cost and power usage makes the excellent for various sensors and low bandwidt data-links where distance is of importance. Do however check regulations in your country before using these because some countries have license regulations and restrictions on usage.
I moved CAN to the same place as the X Hub and will be using this from now. Added jumpers for RS485 vs UART out. The rest is as before:
The X Hub is a better match for Raspberry PI, but this can replace Raspberry PI to get Wifi and with the CAN port you can stack up IO as much as you want.
Routing a PCB is actually a bit of work, but I enjoy doing it a few hours early morning and late evening. It is easy to pick up and then just leave, and over 1-2 weeks I usually get a design done like this. It is always a special feeling to suddenly find that you have no more green lines and can start the checks. I am actually not fully finished here as I need to modify the Micro SD package + I would also like to replace the 1.27 pitch headers with connectors 3D because I need to adjust their distance to the edge. I also need to check my alternatives on footprint for the Super capacitor and battery. I ditched the GPIO header because I have only 3 pins left and will see if I can route them out as leds. But, this looks good!
This is the PCB the way I usually see it in the EDA without the ground plane.
This is the PCB the way I usually see it in the EDA without the ground plane.
I use ground pane for connections to ground to avoid ground loops, but the EDA have an error that it does not warn me about isolated icelands. So I remove components and top layer and copy it to MS Pain using fill. That will indicate what icelands that are left. In this case it was several that I managed to change so they got connected. The small ones left in the middle has no connections so they can just be left.
I will do the last check later today and off we go – next time you see this will be the actual PCB in 6-8 weeks. I had a bit of challenge finding a name on this, but decided to call it “X Hub”.
This is the 3D of a new 1.1 that I never ordered. The only difference from 1.0 is the TVS diods and a few mechanical adjustments. I will remove the address logic at top right, replace the SWD, replace the power connector and move the inner 16 IO ports to the edges while I also add CAN and USB.
These block diagrams are simple, but they are part of how I like to document the modules, so I like maintaining them because they illustrate the Inventory of the Boards.
One remaining decision is where to put the CAN port because they should be at the same position on all boards since this is the main control bus. At present top left corner is a candidate, but I need to make that the same on all Hat’s. The RPI Header is not a pri 1 on these Hat’s. I will leave the RPI header on if possible. It also make sense having one side with no connectors out.
As for the 32 x IO board I think I have covered that before. These are GPIO signals exposed “as is” with a TVS diode to give the MCU some protection. They uses a 5V design, but I will allow a separate 5V so that we can feed Servo’s from a different PSU source. That alone provide a huge protection from misbehaving Servo’s and it allows Servo Power to be 12 V if needed.
I probably need a weeks time re-routing this board. At present I plan to do a lot of these boards before x-mas, but let’s see.
This board have extra mounting holes for Raspberry PI Zero W. I am not bothered about these because ESP32 privide a low cost Wifi alternative. I don’t want a Linux board for the sake of having a Linux board. But, Raspberry PI 3 A/B+ with it’s 4 x 64 bit MCU, Camera and HMI capabilities makes a lot of sense if you need to dig into some of it’s capabilities.
I also have a ESP32 version of this board that in many ways are superior because you get ports and Wifi on the same board. I have to upgrade that as well and I wonder if I should follow the same RPI format – the board is about the same size, just a bit different. As great as ESP32 is it can however not really compete with a F405 on IO capabilities. One Word about ESP32 is that I need to check out it’s CAN capabilities before I do this.
Stay tuned!
This rather boring drawing represent my new base for a Hat. Notice that I have removed the addressing scheme from the old ones, added USB and CAN as standard as well as Raspberry PI Hat form and SPI to communicate with the PI.
F405 is so fast that we can use higher SPI speed (ca 45Mbps) and I think we can achieve ca 30Mbps full duplex data, which basically is 60Mbps comparable to other standards. I can soft-switch on a SPI bus sending to one device and receiving from another creating a true device to device data stream. Removing the address scheme means that any device can become “Network Master” controlling this. I will return to the Software design tricks here in a different article.
I have one challenge here – how to identify a device? F405 have a Random Number Generator allowing me a safe way to guarantee that two devices behave different. Each of the F405’s also have a unique 96 bit ID. Using this in combination I can manage to tell the network master that we have a new device and get it allocated a time slot. I know F405 is up for the job, but I am more concerned about Raspberry PI due to the Linux core. The SPI on the Broadcom do not have the same support as you have on a F405, but lets see what we can achieve.
CAN is the actual control bus here. Can is excellent as it also allow up to 1km cable between devices. It does not cover the same speed as a SPI, but it is a classic in control systems. I am as many of you know a big fan of RS485, but CAN have it’s advantages as well. It is a bit more difficult to wire, but used here as a backbone net on short distances it is excellent.
USB is a bit new to me, but this is basically a high speed 1:1 serial port. It allows me to connect and power the device stand-alone from a PC. 5V from USB is connected to 5V on Raspberry PI, so this will power RPI and the rest of the stack as well.
I use a new 6 pin SWD connector here. I have described this earlier. I am very happy with my old 2×5 pin, but I mostly only used 3 pins and it added a lot of complexity. I tried a JST Micro connector, but will return to a simpler 1.27 pitch header and an external adapter card to convert to ST.Link/V2 with a Boot and Reset button on the adapter. I also had an UART on the old one, but that is expensive (in terms of pins) and I never used it.
This will be my base for a series of board that I plan.
The next ones are an upgrade of earlier Hat’s.
Most of this is consolidation of work I have done on this blog before, so it is not as much work as first impression might suggest. I am in general not scared of Electronics because I find it very easy and relaxing to do an hour now and then, and over time I achieve a lot. Writing SW for all of this is a larger challenge, but I only intend to make the basis so others can start programming this time.
I sadly need to make one assumption – the state of Norway plan to put MVA and handling fee on all import. This means that a small package that now cost me 10.- USD suddenly will cost ca 30.- USD extra in tax and bullshit fee’s. It will become a limiter on what I can afford to do in here. My only alternative is to start selling board so I can afford to continue. Without this I fear the electronics part of this blog will come to an end.
Thanks for reading my Saturday morning ranting 🙂
A bit different picture this time. This show the component layout and the green lines are the PCB lanes I need to make. I have added the package for the Micro SD Card holder, but I still only use 1.27 pitch headers for the Micro JST connectors. GPIO Header is not wired in schematics yet. The exercise here is to have as little crossing green lines as possible to make PCB layout smoother, but this starts to look promissing.
I added a 10 pin 1.27 connector for SD card. It gives me the option to use this as a 9 pin IO connector + the header make signals available on both sides.
I will start to upgrade my other RPI hat’s once this is done. I have a 32 port Servo controller + 8 port DC-motor controller, but I also want to move on with a 7 port stepper/PWM controller. Have them all as RPI-Hat’s, stand-alone USB or CANbus plug-in’s.
I want to use STM32F405RG, but as you know this can also use STM32F105RB by just replacing 2 capacitors with 0R. F405 and USB means this becomes very available for Python programmers etc.
I am not sure about the SWD connector. I have replaced the 2×5 pin with a 1×6 pin. The 6th pin is 3.3V. I tried using JST Micro connector as SWD and it worked, but I must admit that is much easier to plug in a adapter board on a header. The JST connectors are hard to mount and remove again + wiring on a SWD is a bit critical.