The TP Link outdoor camera comes already equipped with a flexible mounting solution: can be screwed in if a flat wood surface is provided, can be placed directly and attached with the magnet or can be installed with a mounting screw. Sometimes it needs to be mounted on a round bar.... for this some kind of adapter is needed.

Using FreeCAD such adapter is very easily designed and 3d printed. There are two parts with a hinge and a tightening screw. This solution seems to be a very practical way of mounting the TP Link camera.

The most relevant dimensions are defined by the mounting bar diameter and by the mounting plate provided by TP Link.

Once the bracket is printed in two parts it can be fastened with the screws and for the hinge ideally a brass insert can be used.

Design files can be found on Thingiverse.

Most of the times a converter is provided to reduce the number of pins required for the interaction with the display. In my case, I have a simple model that is directly driven using 8 bit data bus.

For this display I created my own low level driver where I use the GPIO pins to drive implement the commands specification. The ST7066U is used for the control of the display so the commands are according to the datasheet of this lcd driver.

The only drawback that I see is the need to power the thing with 5V (3V3 won't work).

A library for this can be found in my github repo: https://github.com/bdmihai/stm32-st7066u

I had the chance to get some parts from a damaged board to use the for a new project - the "fancy clock".

The main parts of the clock are the four 7-segment display that are driven, in a sequence, in order to give the 4 digit clock display. Tease are driven by the the microcontroller one at a time. The phosphorescent coating of the display helps to give the illusion that the segment is permanently lit.

As a the main uC I decided to go with the ATmega328P as I had a few available and seemed ok from the programming point of view. As extra HW components I also opted for a light sensing resistor and a NTC Thermistor.

The user interaction is made using 3 buttons - SW1, SW2 and the RESET. A LED is always useful and for the ALARM functionality a simple active buzzer.

The time keeping chip is the DS1302 plus a extra battery to keep the clock running when not powered. In the same chip the alarm settings are also stored at it provides a set of RAM locations.

I have design a simple 2 layer PCB in kicad and decided to have-it produced at Aisler as I really like the quality and delivery speed of their service for small prototypes.

I have chosen to program the clock from scratch by using the actual uC registers and datasheet definition. In this way the program is very simple and efficient.

The program is executed in 2 threads:

• the main loop that handles the display
• a timer triggered task where the events are processed and the loop transition

The loop transition is defined in a small array and has basically 4 parts: the start state, the end state, trigger and callback.

typedef struct {
    loop_state_t        from;    // the state from which we need to transition
    loop_state_t        to;      // what state we shall transition to
    loop_transition_t  *pfn_go;  // transition trigger function
    loop_action_t      *pfn_do;  // transition callback funtion
} loop_state_transition_t;
......
static const loop_state_transition_t loop_state_transitions[] = {
    { loop_time,          loop_date,          button_1_released,        0                 },
    { loop_date,          loop_year,          button_1_released,        0                 },
    { loop_year,          loop_thermistor,    button_1_released,        0                 },
    { loop_thermistor,    loop_time,          button_1_released,        0                 },
    { loop_time,          loop_set_alarm,     button_2_hold_released,   alarm_init        },
    { loop_set_alarm,     loop_time,          button_2_hold_released,   alarm_set         },
    { loop_set_alarm,     loop_set_alarm,     button_2_released,        alarm_inc_digit   },
.....................

The full content of the project is available in github: https://github.com/bdmihai/fancy-clock

The basics of the operation for the rotary encoder is the delay actuation of a set of contacts that when tracked can indicate the direction of the movement: clockwise or counterclockwise.

Usually the contacts are pulled up and for a brief moment they are pulled down. Depending which one gets pulled to ground first the direction can be established. The best way to monitor this is by the means of interrupts - when the interrupt is triggered the state of the gpio pins can be read and the state calculated. A third option is normally build into the encoders and this is the ability to press on the knob in order to get a button functionality. This is also handles in the library.

The small module uses 2 queues as interface: one as input that gets events normally from  interrupts and one that provides the output events (position change or key pressed).

typedef struct rencoder_input_event_t {
    rencoder_input_type_t type;
    uint8_t gpio;
} rencoder_input_event_t;

typedef struct rencoder_output_event_t {
    rencoder_output_type_t type;
    union {
        struct {
            uint8_t direction;
            uint8_t position;
        };
        uint8_t key;
    };
} rencoder_output_event_t;

extern QueueHandle_t rencoder_input_queue;
extern QueueHandle_t rencoder_output_queue;

The main module task will listen for any input events and according to its state will trigger the output events.

state = (state << 2) + input_event.gpio;
if (state == 0b01001011) {
    if (position > min) {
        position--;
        output_event.type = rencoder_output_rotation;
        output_event.direction = RENCODER_DIR_CCW;
        output_event.position = position;
        xQueueSendToBack(rencoder_output_queue, &output_event, (TickType_t) 1);
    }
} else if (state == 0b10000111) {
    if (position < max) {
        position++;
        output_event.type = rencoder_output_rotation;
        output_event.direction = RENCODER_DIR_CW;
        output_event.position = position;
        xQueueSendToBack(rencoder_output_queue, &output_event, (TickType_t) 1);
    }
}

The source code for my demo can be found in my github repository: stm32f411ce-rotary-encoder. It uses the encoder to scroll through the contents of a serial i2c eeprom.

I've been around here for about 8 years and this was my first time up with the bicycle although I was many times hiking or with the car. I used to go there regularly to find wild berries and enjoy the view but since 2 years I haven't went there any more. Now with the summer and the quarantine regulations more relaxed I managed to do a road trip with my bicycle. This time I set myself to make this trip with my bicycle.

It was a little hard at first... but the road up is quite beautiful and I managed to find my pace and take a few pictures from time to time. The trip I did it in the morning when is still cool. At the top, where the road splits, taking a left there is another road to take downhill.

There one can find a farm on the right that sells Yogurt (quite good one!). Going down is very fast and is good to thrust your brakes :)

I thing this is a very pleasant experience that needs to be repeated and I can only recommend to anyone desiring to give-it a try and enjoy the view!

I have made some updates to my 3d printer and from the parts that remained I though I could make a very simple project. Browsing through the internet I did stumble upon AxiDraw and its cheaper home made clones. I really wanted to get into designing things with FreeCAD and testing grbl so this was a perfect project.

The first ideas

I googled all the plotter projects I could find in order to understand the basic concepts of the design and i put up a list of the mandatory features:

• grbl firmware - open source, robust and proven by other projects
• arduino uno based, using the CNC shield and DRV8825 drivers. I would like to create a port to stm32 and eventually design my own pcb.
• end stops
• the linear rods/bearings that I salvaged from the 3d printer
• 12V, 5V, 3V3 available from my power supply
• printed 3d parts, corexy (both motors stationary in operation)

A great starting point is the awesome plotters on github. Here one can find a lot of concepts, ideas and available SW.

The pen holder

I think the simplest part is the pen holder so is ideal to start designing this in the first place. The design is straight forward and makes use of a small servo motor powered by 5V. This is also a weakness of the plotter as I think is the first part to fail (already at the second motor). The entire pen holder slides on two 3mm rods (old CD parts) and is pressed using a pen spring - 3 brass bushings are used for a smooth movement.

XY center block

The goal for this is to be printed in one go without the need of screws or anything else. I chose to use the same 3mm rods to catch 4 smooth idlers in the middle. The end stops are also mounted here.

The steppers

I have 2 stepper motors with a peak current of 1.5A. These I have bought extra for this project as they might be also useful in the future. The cables I have trimmed to the right length and depending on the driver used the polarity of one of the coil needs to be inverted (can be also achieved by configuring grbl). The first motor support brackets that I have design failed due to the wrong material that I have used for the print - ABS. Since the top part is ment to be squized with the two bolts in order to catch the rods in place the material needs to have a certain elasticity. for this purpose PETG is perfect. The pulley is mounted quite high... this could be improved by lowering the rods a bit.

DRV8825 vs TMC2208

I have originally started with the DRV8825 drivers. I think they do work and provide quite a good performance. The annoying part is of course the stepper noise. By replacing them with the Trinamic drivers this problem is not noticeable anymore. There is a light downgrade as high feederates cannot be achieved. A maximum of 10000 mm/min was all that I could reliable and silently obtain. Maybe further tuning of the Vref could improve the performance.

The drv8825 classical stepper sound:

Final notes

For each part that I have design it takes 2-3 iteration to get-it right. I think right now everything matches but if I would have the time I would really touch every part in order to bring an overall optimization.

Project github link: https://github.com/bdmihai/plotter

I got to revisit my AMD Threadripper CPU in order to clean up the cooler and refresh the thermal paste. Even today I'm impressed of the amazing achievement that AMD has pooled in 2017 with the Zen Architecture comeback. I was always a ""readteam" fan and I can clearly say that I'm very happy with the chosen CPU brand and type.

I also appreciate the Noctua brand - and so I did decided to try out the NH2 thermal paste. It was advertised as 2-3 degrees thermal performance increase. After using-it and performing the testing before and after I can say the 3 degrees are spot on!

The fan mounting and the NH-U14S TR4-SP3 CPU cooler is perfect. Desing to avoid any kind of vibration or noise but flexible enough to be mounted and unmounted within second.

Another improvement is the new addition of a USB type C header on my front panel. Originally the Corsair 750D did not come with one but the connection was available on the motherboard. I finally decided to buy the new front panel from corsair and changed the old one.

I also upgraded from the 256 MB to a newer 1TB V-NAND SSD from Samsung.

I'm really exited to see what will be the aftermath of the entire silicon crisis driven by Corona, miners and co. I think this could bring an exponential growth once more in the evolution of computing technology.

The ADC allows a the application to read analog voltages using a single ADC from a maximum of 16 external sources with maximum 12 bit resolution.

Clock (digital part)

Getting the ADC to work on the STM32f411CE requires first a clock. The microcontroller datasheet contains a very intuitive diagram showing the clock tree. The ADC is connected to the APB2 with a maximum 100 MHz. The actual frequency that is uses it depends on the APB prescaler. This will enable the peripheral. The actual GPIO also needs also a clock to be able to function.

    /* confgure the APB clocks */
    MODIFY_REG(RCC->CFGR, RCC_CFGR_PPRE1_Msk, RCC_CFGR_PPRE1_DIV2);
    MODIFY_REG(RCC->CFGR, RCC_CFGR_PPRE2_Msk, RCC_CFGR_PPRE2_DIV2);

    /* enable AHB1 ports clock */
    SET_BIT(RCC->AHB1ENR, RCC_AHB1ENR_GPIOAEN);
    SET_BIT(RCC->AHB1ENR, RCC_AHB1ENR_GPIOBEN);
    SET_BIT(RCC->AHB1ENR, RCC_AHB1ENR_GPIOCEN);
    SET_BIT(RCC->AHB1ENR, RCC_AHB1ENR_GPIOHEN);

    /* enable APB2 devices */
    SET_BIT(RCC->APB2ENR, RCC_APB2ENR_ADC1EN);

Channel

The pin connection is actually defined in the datasheet. There are 16 pins each corresponding to one ADC channel. The decision of what channels are used and in which order the conversion is made is programmable.

    /* set the pis B0 as input ADC */
    MODIFY_REG(GPIOB->MODER, GPIO_MODER_MODER0_Msk, 11);      /* set the pin as analog */
    MODIFY_REG(GPIOB->PUPDR, GPIO_PUPDR_PUPD0_Msk,  0);       /* no pull up, no pull down */
    
    /* select B0 channel for conversion */
    MODIFY_REG(ADC1->SQR1, ADC_SQR1_L_Msk, 0);
    MODIFY_REG(ADC1->SQR3, ADC_SQR3_SQ1_Msk, 8);

Conversion clock (analog part)

This clock defines the speed of the actual conversion. There is a prescaler that  can be configured in order to have a faster/lower conversion speed. This needs to be properly because the actual maximum specified clock lies in the uC datasheet. For example the maximum specified clock for Vdda=3.3V is 36 MHz. By dividing the APB2 Clock (48 MHz) in half (minimum prescaler possible) we get 24 MHz, a value that fulfills the specified maximum.

    /* ADC prescalar 2*/
    MODIFY_REG(ADC1_COMMON->CCR, ADC_CCR_ADCPRE_Msk, 0);

If accuracy/stability is more important, then the clock can be further divided:

    /* ADC prescalar 8 */
    MODIFY_REG(ADC1_COMMON->CCR, ADC_CCR_ADCPRE_Msk, ADC_CCR_ADCPRE_0 | ADC_CCR_ADCPRE_1);

This will give 6 MHz analog clock for the ADC conversion. Another thing is that a normal conversion takes usually 12 clock cycles + channel sampling time.

This is on one side dependent on the ADC resolution as the rate can be increased by decreasing the number of bits. With 12 bit resolution a minimum of 15 (12+3) clock cycles are necessary. If the resolution is reduced to 8 bit then only 11 (8+3) clock cycles are necessary, considering an individual sampling time of 3 cycles.

The channel specific sampling time is individually configurable for each channel and varies from 3 up to 480 cycles. This is programmable and should be defined based on application. More documentation on this can be found in the ST application note AN2834.

    /* select 480 ADC cycles */
    MODIFY_REG(ADC1->SMPR2, ADC_SMPR2_SMP8_Msk, ADC_SMPR2_SMP8_0 | ADC_SMPR2_SMP8_1 | ADC_SMPR2_SMP8_2);

Data read

The data can be pooled or a interrupt can be enabled. Pooling the data is a very fast way to doit but it will block completely the uC.

  /* wait for start of conversion */
  do {
  } while (!(ADC1->SR & ADC_SR_STRT));

  /* wait for end of conversion */
  do {
  } while (!(ADC1->SR & ADC_SR_EOC));

A better option is to enable the end of conversion interrupt and handle each conversion in there. The disadvantage is that the execution of the normal tasks is fragmented by the interrupt triggering quite often (context switch, etc).

    /* 12 bit ADC with interupt enable */
    MODIFY_REG(ADC1->CR1, ADC_CR1_RES_Msk, 0);
    MODIFY_REG(ADC1->CR1, ADC_CR1_EOCIE_Msk, ADC_CR1_EOCIE);
    
....
    
void adc_handle_conversion(void)
{
  adc_event_t event;
  event.digital_value = ADC1->DR;
  xQueueSendFromISR(adc_queue, &event, (TickType_t) 0);
}

DMA

The data gathered by the ADC can be stored via DMA directly into memory and processed in a single step. The initialization process is in this case more cumbersome but afterwards there is no more interrupt after each and every conversion. Using double buffering in the DMA makes sense and the entire thing can be send further for processing via the queue events.

    /* configure the pointers/data amount for DMA */
    DMA2_Stream0->PAR  = (uint32_t)&(ADC1->DR);
    DMA2_Stream0->M0AR = (uint32_t)dma_buffer0;
    DMA2_Stream0->M1AR = (uint32_t)dma_buffer1;
    DMA2_Stream0->NDTR = 1000;
    
    ...
    
    dma_event_t dma_event;
    dma_event.length = 1000;
    if (DMA2_Stream0->CR & DMA_SxCR_CT_Msk) {
        dma_event.buffer = dma_buffer0;
    } else {
        dma_event.buffer = dma_buffer1;
    }
    xQueueSendFromISR(dma_queue, &dma_event, (TickType_t) 0);

The examples can be found on my github page:

• Simple ADC readout: https://github.com/bdmihai/stm32f411ce-adc
• Read the data in interrupts: https://github.com/bdmihai/stm32f411ce-interrupts
• Scan mode: https://github.com/bdmihai/stm32f411ce-adc-scan
• DMA: https://github.com/bdmihai/stm32f411ce-adc-dma

Since some time now I have a couple of very old OLED displays - 128x128 pixels. These are driven by the ssd1339 chip for which I found the datasheet online. Based on this I created my own driver and demo application.

Adapter board

The first challenge was to find an appropriate way to connect to the display. It uses an FCC connector that is quite narrow pitched. My first try was actually to solder a couple of jumper wires on to this but it quickly failed. I decided to make my own adapter and produce an adequate pcb.

I also made a custom cable to be avoid messing up the wiring if I disconnect and then reconnect the oled to the breadbord. The  oled board itself has a FCC connector and is powered by 3.3V.

Holder

The flat cable is also quite sensitive. A holder proved to be very good as it avoided shorts and bad contacts. The holder is designed in OpenSCAD and it will hold the the adapter and display together.

Driver examples are quite seldom, but I did manage to find something that could be analysed. I found the serdisplib but I could not use it directly... it wort mentioning nevertheless.

Source code

For the OLED display I have created a new library in my project. This gets linked into the project as a git submodule andneeds to be included into the qbs files of the project and app. The init function requires function pointers to the GPIO interface for setting various pins to high/low (basically bit-banging). The 8 data lines are directly written to port A in my case.

All ssd1339 commands are implemented including the graphic accelerator ones. From the concept this interface is quite interesting but I'm disappointed of the low brightness and color accuracy of this display.

The repository for this project can be fount in github: stm32f411ce-oled

Since the Cortex M4 offers some clear advantages and improvements over the M3 I started working on this as a side project. The goal is to make this a feasible platform for highly optimized, low level C code projects and use the uC for standard communication as infrastructure microcontroller.

The uC that I have chosen is the STM32F411CE included in the MiniF4-STM32F4x1 development board. This is a very simple and cheap board the necessary HW for the development setup. Main features of the uC are: ARM Cortex M4 with FPU running up to 100 MHz freq, 512 KB Flash, 128 KB Ram. Peripherals are the usual stuff: I2C, SPI, USB.

Development Board

As mentioned before, I have bought my Mini's F4 from a reputable Chinese store and receive them quite fast. The quality and overall design of the boards is quite good and I can only recommend them.

I will power the board separately and use a ST-Link V3 to flash the sw and debug the  programs. There are cheaper options than the V3 but I do like the board extension that includes a Bridge feature and 2 virtual COM ports. I think is also reasonably fast @24000 KHz but this needs to be configured in the OpenOCD config files. Speaking of OpenOCD this is one of the mandatory tools that needs to be installed (locally compiled in my case) and eventually updated to fit the target board/debugger. This can be cloned from the official OpenOCD repository clone and compiled. The configuration files can be then locally altered to take advantage of the V3 higher speed.

# Boost JTAG frequency
adapter speed 24000

Build environment (Qbs)

There are quite a few options available (including STM32CubeIDE) that offers a good starting point. I did want to use the Qbs build system as I found-it to be very intuitive and powerful. Taking into account that I want to have full control over the compilation process I build up my own stm32.qbs module instead of using the already existing cpp one. The modules in Qbs can be inherited so I wanted to use this strategy for my setup. There is a base stm32 module that get inherited by the stm32f4 and finally by the actual uC specific module stm32f411ce. At each level properties defined in the stm32 base are overwritten with specific values like compiler flags and memory specifications. The tools (compiler, linker, etc) will use the information from all 3 levels in the compilation process.

Only one module can be instantiated and this is selected by the qbs.targetPlatform that is specified in the command line call.

CONFIG_MCU = STM32F411CE
...

build: 
	/usr/bin/qbs build -d build -f source/project.qbs --jobs 16 config:$(CONFIG_MCU) qbs.installRoot:bin qbs.targetPlatform:$(CONFIG_MCU)

I included a project separation concept into the build process that allows the split-up of projects into smaller components. This is similar to the Arduino build where each library gets compiled into a lib and at the end everything is linked together. For this Qbs provides the Product and Project build-in items.

Setting up this kind of build environment offers a lot of control and insight on the uC and the tool chain used. A lot of information comes from understanding and experimenting with different compiler flags and options. I have analysed and reused two build systems before getting to this stage that I would like to mention here: the make based build system of esp-idf and the stm32-base.

Documentation

The most important document required for starting with any stm32 uC is the Reference Manual. Here every feature and peripheral is explained and the registers are described. Secondly the datasheet is necessary as some information and electrical characteristics are detailed here. The STM32CubeIDE will provide tease and also a very intuitive GUI to setup the pin assignment and clocks. This will use the HAL but one can dig a little deeper and find out exactly what registers are changed (the target is to handle the low level myself).

Interacting with the target

OpenOCD provides the necessary commands to interact with the target microcontroller. It provides basic commands like reset and flash but also allows to connect with gdb for debugging.

The most simple command is the reset command. The commands can be issued using the -c command line argument

openocd -s $(CONFIG_OPENOCDCONFIGDIR) -f $(CONFIG_OPENOCD_INTERFACE) -f $(CONFIG_OPENOCD_BOARD) -c "init; reset; exit"

or via telnet on the port 4444

telnet 127.0.0.1 4444
> reset

More details can be found online in the OpenOCD documentation:

• general commands
• flash commands

A Makefile is available hier to execute the necessary tools with the right parameters.

Source code

The source code for this article can be found in github: stm32f411ce-blink. The project is splitt-up so that the common source code is located into independent submodules that can be separately updated and shared (the qbs module, freertos, linker, etc).

Linker

The linker file is what defines the memory layout of the program, where every function shall be places, where the variables should reside. For each uC there is a little bit of difference as each one has different amount of flash and ram, this is why there is a common.ld and a specific uC .ld script. Only the specific one is included into the .qbs project for compilation.

MEMORY {
    FLASH   (rx) : ORIGIN = 0x08000000, LENGTH = 512K
    RAM    (rwx) : ORIGIN = 0x20000000, LENGTH = 128K

    CCMRAM (rwx) : ORIGIN = 0x10000000, LENGTH = 0K
}

INCLUDE common.ld

The example above shows how the memory is defined. Further the Flash is split into sections that have a dedicated purpose and needs to be placed at various addresses. The first thing in needs to be the ISR vector that is located at the first address in flash, then code and constants.

Ram is constituted from variables (initialized and uninitialized), heap and stack. The heap section is somehow artificial and used by the FreeRTOS for dynamic memory allocation. The .data section will have a flash section equal with the allocated ram amount. The actual copying of the values in ram happens in the startup phase.

https://github.com/bdmihai/stm32-linker

Startup

This small part defines the first steps executed by the controller and it defines the isr vector. This, like the linker, is build to be portable to more uC types and it also has a common and a specific part. Is written in assembly but is quite straight forward.

https://github.com/bdmihai/stm32-startup

Cmsis and HAL

Tease are the two libraries that come normally with the STM32CubeIDE and are directly provided by ST. They contain all necessary definitions and also the hardware abstraction layer if this is required by the application.

https://github.com/bdmihai/stm32-cmsis

https://github.com/bdmihai/stm32-hal

FreeRTOS

Is a must in all modern application to have a underlying OS that manages your task. It basically allows to take full advantage of the processing power of the microcontroller and do a lot of things in parallel.

https://github.com/bdmihai/stm32-freertos

App

Hier the user code starting with the main function is written. The very simple blink sketch is the uC "Hello World" program so this is why I have this as my first example.

STM32 is a uC family developed by STMicroelectronics based on the 32-bit ARM architecture. Overall a very interesting platform for embedded development with multiple choices regarding features and power. The community support is very good I would say and tools for development are widely available. Free and open source is always in scope for hobby and prototyping!

This is still a work in progress... so there are just pieces of information and not a complete article. I do plan to write more as I progress with my project. First of all I bought 2 STM32 boards from Aliexpress:

The STM32F103RCT6-Generic-Board - due to some of the nice features that the STM32 chip offers (2 DAC's).

The Blue Pill because is cheap and I got a good deal for both ST Link and the board (about 3.5 euro).

The first challenge is always to test that everything works as expected and to set up a comfortable development environment. There are 2 variants that I would like to cover in this article. The first one is based on Arduino IDE with no support for debugging and the second one base on VS Code where one can take advantage of the debugging features and extensive intelisense.  The second one is where I would go for bigger projects, where actually teams can work and do more thing together.

Officially the STCubeIDE is provided and is in any case a must as it comes with a few tools that make life a hole lot easier. Coding experience in the IDE is not perfect but it does work well. Debugging is also quite good. The fact is that STCubeIDE will hide a lot of the low level stuff by having the HAL as a middle layer.

Another topic that I would like to cover is the base that is used. Here are the libraries on which the user application is based. From the Arduino framework to a fully featured Realtime OS there are a lot of options to choose. I would like to cover here the 2 that I think have the most community support and are, of course, Open Source: Arduino and FreeRTOS.

For interfacing with the two STM32 boards I have two solutions at my disposal: the FTDI and the ST-Link v2.

Arduino IDE

After downloading the IDE one needs to install the toolchain and adaptation for the STM32. This can be installed from here: https://github.com/stm32duino/Arduino_Core_STM32

After this is done there are a couple of changes needed in order to be able to use the ST Link or the FTDI chip for flashing:

1. OpenOCD: usually the default version that comes is a little out of date or missing scripts. The best way is to get one from github and compile-it yourself. A couple of scripts are necessary (basically copy paste some of the existing ones and change the FTDI vendor id, etc).
2. Change the boards/platforms definition from the Arduino STM32 core.

With tease changes a new program compiled with Arduino IDE can be flashed on the chip.

Debugging  connections can be made in 2 ways: SWJ or JTAG. Here I use my ft4232h adapter.

           RS232  JTAG       SWJ
---------------------------------------------------------          
ADBUS0  |  TXD    TCK        SWDCLK
ADBUS1  |  RXD    TDO/DI     SWDIO
ADBUS2  |  RTS    TDI/DO     SWDIO (470 Ohm)
ADBUS3  |  CTS    TMS        N/A
ADBUS4  |  DTR    (GPIOL0)   /nSRST  optional module reset
ADBUS5  |  DSR    (GPIOL1)   /nTRST  optional target reset

Another way to flash a program using the FTDI is to use the serial communication features. The STM32 comes with a prebuild serial bootloader:

Visual Studio Code

Visual studio code is my preferred development environment: light but still packet with features and extensible. A few extensions will be required: C/C++, Cortex Debug, ARM and QML.

To get the full control of the compilation process I chosen to use qbs and I have created my own rules for compiling the code. As the compilation process I used a similar one as the Arduino where every project is compiles as a lib and in the final step everything is linked into the application. The compiler of choice is gcc as provided by my package manager. Using qbs proves to be very intuitive and easy and I was able to create full build framework vor various ST uC in a couple of lines of code.

A very helpful starting point is the STM32-Base web site. From here I used the project layout (startup + linker) as it looked very easy to understand and integrate. basically they provide the linker + startup files in a very structured way. I only used the F3 and F4 uC for the moment but in theory it can be extended to the other STM32 families as well.

My project example can be found in github: https://github.com/bdmihai/blink-stm32f103rb

Tips and Tricks

Reseting the FTDI kernel module. It hapens when you remove the FTDI but the driver still remains. After pluging again the ttyUSB ports cannot be opened anymore. The reset command is the following:

sudo modprobe -r ftdi_sio && sleep 5 && sudo modprobe ftdi_sio