Author: andre

Playing with some radio modules (part 4)

In previous post of this series I have been comparing the specs of various Sub-GHz transceiver ICs. In this part, the goal is to let different transceiver ICs of different brands communicate. In this part, I will let a HopeRF RFM69 module, which appears a rebranded SemTech part, close to the SX1231H, communicate with a…


MH32F103 I²C issues

As discussed in previous posts comparing the 32F103 microcontrollers, there are several I²C issues on the MegaHunt MH32F103. Disclaimer: The parts are assumed to be MegaHunt MH32F103. I have been told the “STM32F103 China” Blue Pills from AliExpress contain a MegaHunt MH32F103. As these parts have been relabelled as STM parts, I cannot tell for…


32F103 Comparison (part 7)

A while ago, I wrote a post about discovering performance difference between the STM32F103 and the CS32F103. With this in mind, I decided to run the Dhrystone benchmark on all of them. A benchmark as old as I am. I have compiled a firmware such that it contains the benchmark with O0, O1, O2, O3…


The Cortex M Series

Once upon a time, I wrote some code to identify a Cortex M core: cpuid_t *cpuid = (cpuid_t*) (&SCB->CPUID); if ((cpuid->PartNo & (0b11 Revision; where cpuid_t is defined as typedef union { uint32_t cpuid; struct { unsigned int Revision : 4; // p value in r_p_ unsigned int PartNo : 12; unsigned int Architecture :…


32F103 Comparison (part 6)

After the I²C test, showing problems with GigaDevice running at 400 kHz, and MegaHunt at either speed, this time I am running an SPI test. In this test, I have hooked up an MFRC522 and a CLRC663 PDC (RFID/NFC reader). Using this reader I will scan an ISO 14443 A tag (PICC), specifically an NTAG213….


32F103 Comparison (part 5)

It has been a while since I compared some 32F103 chips. Most recent posts has been about identifying them, but let’s now have a look at how they perform. In this post I will have a look at the I²C peripheral. The test is simple: A number of I²C peripherals is connected to the chip…


It’s a compiler bug!!!!

It’s a compiler bug!!! Yes!! It is!! Seriously, it is!!! Well… is it? Let’s have a look. What is going on with my RISCV debugging issue. So, last time, I mentioned, a binary built with GCC 8 could be debugged fine with GDB, however, building the same code with GCC 12 gave issues with GDB…


On RISCV bare metal toolchains (part 2)

I’m going to look into some more details regarding the debugging issues I am experiencing with a GCC12 toolchain that do not appear in a GCC8 toolchain on RISCV microcontrollers. I’m loading the binary, set a breakpoint, run the code until the breakpoint hits, and request a backtrace. Compiled with the MounRiver GCC8 toolchain I…


On RISCV bare metal toolchains

Some notes on RISCV bare metal toolchains, regarding building and debugging code on GigaDevice GD32VF103 and WinChipHead CH32V103 microcontrollers. In the past I’ve made some start-up code and linker files that allow building firmwares abstracting the differences between these two chips, allowing one unified firmware image for both of the MCUs. I’ll look at three…


I²C issues on GigaDevice microcontrollers

When I was looking into microcontrollers with 32F103 peripherals, but with a RISCV-core, I ran the stm32f1xx HAL on them. The assumption was, their peripherals were the same. (Except USB). Using this on a GD32VF103, I was able to communicate with most I²C sensors I connected to the bus, but I ran into issues with…