STM32 Blue pill IoT expansion boards

Expansion boards are designed to be easy to use in DIY IoT projects, low cost, reliable, saves the pain of cabling bread boards

Similar projects worth following
The focus is a low cost and popular IoT ecosystem. Expansion boards are designed to use modules only, no tiny components impossible to solder at home, and the PCB have relaxed rule checks so that they can be ordered from the cheapest PCB suppliers. Target is to have smart boards, connected with RF in a mesh network, and linking the network to the environment : sensors (pressure, humidity, temperature, light, gesture,...) and actions (high power IOs, servo control,...)
Any links to already existing expansions are welcome, same for any reviews, suggestions or recommendations.

If you would like to get support, give feedback or discuss new ideas related to this stm32 project ? It's possible to directly discuss on the forum

STM32 RF Node - One HW Many appications

This STM32 RF Node is the main IoT hero of the #Home Smart Mesh project.

  • Application Firmware on : IoT_Frameworks
    • rf_bridge : Mesh repeater Node with sensors (BME280 + APDS9960)
    • rf_uart_interface : RF mesh to serial, to be used with the Raspberry pi c++ app.
    • host_controller_interface : Open API to control and diagnose the RF mesh with the Raspberry pi Python commands
    • action : Fun and game application, RF distributed state machine managing group speach sessions.

PCBs repository

The PCBs design files are shared as open source, free to use without any restriction at github

IoT Boards details

STM32 RF sensors Node Concept

  • Always connected to a power supply (no low power worries)
  • usage as RF dongle for a Raspberry pi
  • RF repeater with color status
  • Fixed sensors node (wireless nodes are more efficient but this one is simpler)
  • Control node (hopefully when the gesture gets working with the APDS9960)

STM32 RF sensors Node PCB v2

also on github

  • Added USB connector for power supply, although not connected to the uC USB, this connector is very handy to make a space efficient node housing, similar to a smart USB dongle.

STM32 RF sensors Node v1 Board

  • It is possible to connect either a MAX44009 module or an APDS9960 in the middle I²C slot.
  • Note v2 has USB connector in addition (not depicted here)

Sensors Node used here as dongle for the Raspberry pi

STM32 RF PIO Concept

  • Smart RF controlled PIOs
  • extensive PIO number x24 PIO s from which x12 PWM
  • power outputs x500 mA 50V compared to uC pio of 25mA 3V
  • RF Smart light control
  • RF Servo motors control

STM32 RF PIO Schematics

also on github

STM32 RF PIO Board

github linksize : 80 mm x 39.37 mm

  • It is possible either to connect servo controllers cables or solder an ULN2804A in each of the 3 slots.


RFPIO Board Options

See this RFPIO bloard in action in this project

                                                                       #STM32 BluePill x8 Edison Bulbs with nRF and MQTT 

Existing STM32 Boards

Well this section is out of topic regarding the Bluepill, but given the fact that some boards are using the STM32, I'd like to keep them close here as a reminder for potential use cases and resources sharing:

  • 1 × STM32 BluePill STM32F103C8T6 bread board
  • 1 × nRF24L01+ module
  • 1 × WS2812B RGB LED
  • 1 × BME280 Temperature, humidity, pressure sensor
  • 1 × MAX44009 Ambient light sensor

View all 8 components

  • STM32 is now Home Smart Mesh Compatible

    Wassim10/21/2017 at 09:02 0 comments

    What is Home Smart Mesh ?

    As described in the Home Smart Mesh Hackaday Project, it is an IoT Mesh Framework using custom RF sensors and repeaters for Raspberry Pi. It is Open Source, and plugs with MQTT and OpenHAB2.

    The mesh protocol has been designed to be simple enough so that you can understand it and debugg it by yourself in your free time, yet with a functionnal level that can be of a practical use. More details about the mesh protocol in this flood mesh project log

    STM32 Hardware Support

    STM32 Applications

    • heater : a pwm control of a Solid State Relay
    • sniffer : not really RF sniffer, but protocol sniffer, as it ignores the format but still has to stick to one channel, helps to see both request and acknowledge for debug.
    • uart interface : 
      • RF dongle collecting messages broadcasted into the mesh
      • Injects messages targeted to a specific node with an acknowledge. Note that the acknowledge is mesh wide from destination back to source and not point to point like the Enhenced Shockburst.

    Now as we can see in the following sections the STM32 bring the possibility to use ARM mbed and all what comes with it.

    Easy to use Mesh functions with ARM mbed and modern c++

    Here we can find code snippets from the RF uart interface acting as an RF dongle. Complete file on github

    //nRF Modules 1:Gnd, 2:3.3v, 3:ce,  4:csn, 5:sck, 6:mosi, 7:miso, 8:irq 
    RfMesh hsm(&rasp,           PC_15, PA_4, PA_5,   PA_7,  PA_6,    PA_0);
    void rf_broadcast_catched(uint8_t *data,uint8_t size)
            case rf_pid_0xF5_alive:
    int main()
    • Provide the Channel to listen and send on. Can be changed later. And yes, currently the mesh is operating on a single channel, channels clusters and channels swapping are features yet to come depending on need.
    • Attach to a mesh event, here a broadcast

    Here we have a code snippet from a Node application that uses acknowledged peer to peer messages. complete file on github 

    void rf_message_to_me(uint8_t *data,uint8_t size)
        if(data[rfi_pid] == rf_pid_heat)
            heat_val = data[4];//heat_val payload : Size Pid  SrcId TrgId  HeatVal CRC
    •  The attachment is to a Message type.
    • As the node id has been provided to the mesh driver, only messages with matching target node id will be provided.
    • The acknowledge transmission is also handled by the mesh driver.

  • Get yourself a j-Link

    Wassim09/30/2017 at 13:10 0 comments

    Debug like a professional

    • I regret all the time I lost being prevented from real debugging to the excuse of low cost flasher and using the ST-Link and co.
    • I had to move to the nRF family for single SoC with ARM-M0 and RF, so I had to have a flasher and debugger
    • Note that updating an ST-Link to J-Link OB and using it with other than ST components is illeagal.
    • So I decided to get a j-Link EDU

    Why a j-Link EDU ?

    • No need to argue too much for reasons such as "It simply works!", it is true, I tried it, also compatibility with all serious and open IDE, so let us focus more on comparison
    • Compared to an ST-Link, you get with the j-Link a VTref input that sense your target voltage so that you can automate scripts using that.
    • Note that the EDU is relatively cheap (60 €) usage for hobbyistes and education only, but there is an even cheaper EDU-mini (16 €) but for cortex M only.
    • The EDU over the mini has a higher download speed, and more CPU variants support.
    • It can control the power up to 300 mA 5V to switch your target completely off, which is important in tests automation as it is not the same as a reset.
    • It has a virtual UART, not the hoisting used from the ARM cortext, but you keep your ARM program unmodified using the external UART and connect it to the external pins of the debugger.
    • So you have all in one : Debugger, Power control, Voltage sensing and UART
    • The segger devices security is improving, so spare yourself the pain of clones that would stop working after SW updates. 

    Where to go on from here

    • I will start updating my scripts and environment to use the j-Link edu, I will break the compatibility with the ST-Link utilities.
    • I'll evaluate debuggers interfaces Ecpilse and segger specific
    • I'll start using python to wrap the debug interface and make it quick and accessible

  • Feelings of a BLDC Speed & Position Control

    Wassim06/10/2017 at 18:26 0 comments

    Experimentation setup

    • The PS4 Joystick is a good way to manipulate multiple variables simultaneously which is suitable for experimentation. The touch pad adds possibilities for position reference.
    • The Raspberry pi here is not needed for the BLDC control but is acting as the Joystick interface plus its development environment is more suitable for programming.
    • Although the RF Node Board has a USB built in, the USB SW is complicated to integrate and uses memory, so the UART has still time to live in experimentation. A USB to UART brings it down to the same.
    • The RFPIO Board was intended for servomotors control not BLDC, but is a good platform for BLDC experimentation as it exposes the PWM outputs and has radio connection.
    • The Radio connection is not of much use here, but it is actually practical and very important isolation medium between the Test PC and the motor test bench. That advantage is not used here but only because the power supply has regulated current.

    Note on Safety:

    Using a normal battery with experimental controller is dangerous and might lead to the test bench catching fire. Use either a fuse, a current limited power supply or a reliable controller.
    • A cheap logic analyzer is being used in the button mode that works with the Saleae Logic SW which is a great and affordable combination for analysis.
    • A commercially ready module is used for the L6234D from eBay, but this one does not offer much options as all enables are joined together and there are no sensing resistances. So this can only control in Open Voltage Loop.


    The interesting part in this demo is not the revolution of turning a bldc for the first time, rather :

    • The integration of such a number of small peaces of SW on different environments
    • The approach how someone could have a feeling of how a BLDC motor works by directly manipulating multiple variable and seeing the pulses on a logic analyzer

    Open Loop Control : BLDC = Stepper motor

    • It is always possible to change the voltage in every coil without regarding the position of the rotor.
    • That definitely would result in missing steps if the voltage is not enough to deal with the torque. As in BLDC steps are big, missing them do hurt and does not go unnoticed.
    • The solution is to increase the voltage, but then you're wasting energy that does not go in torque but in flow to maintain the motor position. The current is much higher when the motor is at rest due the absence of counter electro-force.
    • The used BLDC motor here consumes around 50 mA at a speed of few rotations per second and up to 180 mA at a stopped position with 7.2 volts.

    Control Parameters

    Every new video or diagram about BLDC control allows me to understand something more, that's why, in spite of the number of documents and tutorials in the internet, why not add another simple view on this.

    • The speed acts on the delay before applying the next electric angle position, note that the maximum command update frequency is less then the pwm signal frequency otherwise it is useless (figure not of same scale for both).
    • The voltage is increasing the pulse width. Although only one pwm signal is displayed here, all of the 3 signals proportionally increase and decrease their width pulses.
    • The position is even simpler from software point of view as you just have to increase or decrease the electrical angle proportionally to the movement of the finger on the touch pad. The sinus of every angle is taken to define the pulse width of the corresponding bridge.


    Sorry for placing source code as pictures but the source code plugin is so lame that the code is barely readable, so I keep the VSCode colors.

    All the bldc magic is here. The angle is taken as an int to make it simpler, I'm not even using a proper unit as radions or degrees rather a 256/360° units so that it fits a 256 table where the sinus is porecessed once and stored as lookup.

    • The live calculation of floats with this M3 running at 72MHz took 7.2 us while the lookup function here just around 1 us so it is still worth it...
    Read more »

  • Coming Soon & Ideas

    Wassim06/06/2017 at 21:22 0 comments

    The RF Node with sensors is up and running, the RFPIO is up and running, time to think on what should come next.

    • Ultrasound cartography using multiple low cost HC-SR04 or 05
      • see Hello_Ultrasound sample for experiments.
      • The extension board should provide ready to connect pinout for multiple ultrasound sensors
    • BLDC : After very long hesitation and reflextion time, a serious jump into robotics playground cannot go around motors control
      • Using L6234 PowerSo20 modules or maybe later some lower current L6234 DIP directly on the same board.
    • Servos only : The RFPIO double usage of x24 pins and x12 servos is not of optimal size for servos only usage, maybe another optimal layouting could be more convenient for some crazy many servos projects.

View all 4 project logs

Enjoy this project?



Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates