F103RB vs F105RB

As mentioned before I am a big fan of STM32F105RB as the smallest MCU that I use unless package size is an issue. I have other preferences for LQFP48 and TSSOP20. What puzle me is a comparison between STM32F103RB and STM32F105RB on functionality and prices from AliExpress. I suspect that the reason for the low price on F105RB is because they are ditching old 32Kb Versions since the New Versions have 64Kb (Just guessing)? But, the price difference is only 0.1 USD on ST’s own sites as well. You have a similar game between STM32F103CB and STM32F303CB.

MCU 32 bit ARM M3 32 bit ARM M3
Frequency 72 Mhz 72 Mhz
FLASH 128Kb Flash 128Kb
SRAM 20Kb SRAM 32/64Kb (1)
Package LFPQ64 LFPQ64
PSU 2 – 3.6V 2 – 3.6V
PVD Yes Yes
x-tal 4 – 16 Mhz 3-25Mhz
Internal x-tal 8 Mhz 8 Mhz
Power Sleep, Stop, Standby Sleep, Stop, Standby
ADC 2 x 12 bit, 16 channels 2 x 12 bit, 16 channels
DAC 2 x 12 bit
DMA 7 channels 12 channels
5V Tolerant IO Yes Yes
SWD Yes Yes
Timers 7 10
I2C 2 2
UART 3 5
SPI 2 3
I2S 2 (On SPI)
CAN 1 2
USB 1 1
CRC Yes Yes
Unique ID Yes Yes
Price Ca 2.5 USD Ca 1.6 USD

(1) Current datasheet state 64Kb SRAM, while older datasheet state 32Kb SRAM.


RS-X is easyIPC over RS485 using a special 4-wire cable and a timing protocol. Several modules are designed to be connected to a RS-X network as well as a series of infrastructure components needed to build an automation/robotic network based on easyIPC.

easyIPC is about providing a plug & play network with open, secure communication to enable more complex robotic/automation systems. The network focus on using Raspberry PI as intelligent nodes.

CAN-X and RS-X technologies are very similar from a functional perspective, and also from a wire perspective. The main difference is that RS-X is based on RS485 using UART/USART that is available on all devices, while CAN-X is based on CAN ports that are a more limited resource.

CAN uses an arbitration principle that makes it easy to implement multi-master communication, but it limited by a small 8 byte payload. Arbitration will however secure close to 100% utilization of a network.

RS485 in classic mode is more flexible and available than CAN, also more easy to get working as the arbitration timing can be a bit tricky. The drawback is that the wiring have no support for multi-master networks.

The RS-X protocol uses a chain reaction scheme where each device send an EOT (End of Transmission) allowing the next device to start. This enables a timed multi-master where each device can communicate within a small time-frame that is adapted to standard UART/USART features.

Both Technologies have their ups and downs, but availability of RS-X and the fact that RS485 is easier to get working account for a lot on the smaller micro devices. Both RS-X and CAN-X are available and can be used together as part of a easyIPC network. In fact, it will be fully possible to have a wire that starts as RS-X and ends as CAN-X or wise versa.

Micro Dual Stepper Driver


This board uses a LQFP48 because I needed more pins and it extended the size to 50 x 15 mm to get everything in. It contains 2 x Stepper Motor Drivers and 2 x end point connections. This can operate 2 x 5-wire or 4-wire stepper motors. I have not decided on MCU yet. I used STM32F103CB on the schematics, but I know that STM32F303Cx can be used and I will check if the same is the case for the M0 series in LQFP48 package. All of these MCU’s are an overkill for what we do here.

I target 28BYJ-48 or similar stepper motors that can operate on < 0.5A current. Having two steppers rather than one is because it often is required to operate two steppers in parallel. I use two ULN2003 drivers mounted back to back on each side, meaning I have 6 spare PWM signals and plenty of spare pins on the MCU. I only need to expand the PCB Space for Connectors to have a full 3-axis driver. This is just an early draft where I focused on size only, so will see where I go next.


 The beauty with the RS-X based micro modules is that you can just add on modules by connecting them to the network and locate them as an extension of cabling on the robot or in your house etc. We still need a more intelligent unit like a Raspberry PI in centre, but it expands our scalability to easily build more complex systems.



I have a bunch of these that has been laying around for ages with the DIP version drivers of ULN2003, but I have never tested them. So I connected a STM32F030F4 dev board to the ULN2003 driver and tested a 4 step and 8 step algorithm.

I have used quite a lot of steppers and servo’s before, so I was a bit surprised. It uses about 4ich second on one turn, so it’s not the fastest, but it is incredible strong. The 8 step algorithm draws 130mA on the motor + driver and is absolutely soundless using 4096 steps on a 360 degree trip. At the cost of ca 1.- GBP on ebay I am actually impressed and I fully understand why these are so popular.

I can drive one of these using the micro PWM driver, but I will return with a few more specialised driver boards that support 1-2 motors and 1-2 endstops or position encoders.

8 x DC or 4 x Stepper Motor Hat


As mentioned in a previous post I could extend this to 8x DC motors. I realized that the screw terminals I used had a smaller 2.54 pitch version. Connecting 8xL9110 to drive 8 DC motors or 4 Stepper motors are easy and straight forward. This is a draft as I was keen on looking at terminators, but we will add some protection logic and order the Hat.

I have a personal preference to keep motor controllers away from Raspberry PI, but it is quite handy to have a multi motor driver for small motors. I have a robot arm with 5 DC motors that this board is perfect for.

Mini PWM Driver


I am quite found of these small boards so I reuse the MCU and RS485 interface on various designs. This one uses a ULN2003 to provide 7 PWM ports with up to 16V and 0,5A each. I use a 8 pin 1.27pitch connector. the 8th pin is V+, while the second row is all GND. This allows the board to be used for driving steppers, LED’s or small solenoid style actuators.

ULN2003 can actually handle 50V, but the regulator on the back is LM1117 that only handle 16V. I am actually only planning a 12V system so it will do.

 These boards all have a 120 Ohm terminating resistor mounted. In real life this resistor will not be mounted as I expect to deploy a lot of these boards in the same RS-X network. This one is tagged for Christmas lights, but with two months to go I will need a bit of luck to get the PCB’s in time.

RS-X Cable


As you deploy RS485 (or CAN) on larger distances you will need to increase cable quality and lower baudrate. For 15 meter I don’t fuzz, I just twist a pair of cables and hook them up. A good advice is to have standard colours for A+ and B-. For better cable quality you can use a shielded solution like illustrated above.

Twisted pair Shielded cable is quite common and don’t cost to much. Just remember that the shield should be connected to ground only on one side of a cable to avoid creating a ground loop.

RS-X Network


This is a simple, passive switch anyone can wire on a vero-board. It just connect 8 ports in parrallell.  “GBA+” is easy to remember and means Ground, B(-), A(+) and Power. You use one port as input and 7 as output in a classic star network.

 The only thing you need in addition are 120 Ohm terminators at the optional place. I introduced 120 Ohm terminators on every module, but I either need to not mount them or add a jumper. The same goes for this circuit as it need a 120Ohm resistor with a jumper.


The illustration above shows a classic star wiring using these switches. In reality you can cover quite some distance with only passive switches like this. I am not worried about short distances like 10-15 meters, but as the network gets longer we need to take more care.

 Needless to say, this is 50 x 12mm in size and you can use the switch as a cable extender or T point as well. The mounting holes are M2.

Mini SW Draft


The Software on the Mini Sensor Module is outlined above. I need to wrap up a tight RS-X protocol as illustrated earlier. I also need a RTOS ported as well as sensor Logic for each sensor.

DHL11 (or 22) uses a bit-bang protocol. We will use an interrupt on this pin with some timing for decoding. It will send us Humidity and Temperature once per second.

The IR module is connected to an ADC and will measure distance. The Light sensor is also connected to an ADC measuring light.  The last sensor is the temperature sensor on STM32F030F4 itself.

The Data Map tionary is a small module that will map variables in the interface with actual variables in the modules. This is set up as a pre-configured table.

I am a bit concerned about 16Kb Flash, so I have the STM32F042F6 as a fall-back.