Going back to electronic after a 20 years break

Spi not good enough for  you?  The easy way to use WS2812B programmable RGB leds is using the SPI MOSI pin. That works fine most of the times with a couple of gotchas : The SPI divider is not very flexible on the GD32/STM32 chips, you can only divide by a power of 2. So if your APB clock is not "near"  enought the WS2812B 400 us tick you are in trouble or must use complicated schemes. Using a SPI "locks" the alternate functions of ~ 4 pins. So you can't use them for PMW or any other alternate functions, even if you dont actually use them. The SPI pin is the one getting killed most often on my boards. I have a few MCUs that are working fine except the spi is fried.  Also the 2nd /3rd SPI are using APB1, so not ok in terms of clock. In short, Spi0 @ 72 Mhz is ok, other setup is to be looked closely at. What's the other option ? The other option is to use PWM + DMA. We program a 1.2 us PWM mode 0 on a pin. We change the duty at every cycle to create 0s and 1s. ...

  I'm porting the spotwelder control board from stm32duino to lnArduino, so that i can use indifferently a STM32F1/GD32F1/F3/VF3 and to have a smaller and better codebase. It had a couple of tiny bugs but it is working sort of ok. Then  i reached the last missing piece : Non volatile memory. The Stm32duino version is using the eeprom emulation code from STM that can only store couple (id,value) with value on 16 bits.  It works  but it's a bit awkard to use if you want to store 32 bits stuff or floats. Additionally, the license is a bit restrictive it seems. On the other end of the spectrum, you can switch to tinyFS. But this is way overkill to store some basic settings. I looked on github without finding something suitable. What do we want ? Sort of robust if interrupted during a write ( ~ atomic) Variable size writes (with a small maximum) Not erasing the flash at every write Since i couldn't find something suitable,  i wrote a quick & dirty non volatile me...

 Sometimes it really helps to have a nice GUI for GDB Finding an IDE that supports *correctly* remote gdb debugging as used with Arm or RiscV boards is difficult. There is one option that seems to work ok :  gdbgui The principle is that the UI is actually your favorite browser How to start it easily with the backmagic ? 1- create a blackmagic gdb init script target extended-remote /dev/ttyBmpGdb monitor connect_srst enable monitor swdp_scan attach 1 load compare-sections set mem inaccessible-by-default off set confirm off 2- start gdbgui through a small shell script #!/bin/bash export F=$PWD/$@ echo "Loading $F" gdbgui -g "/home/fx/Arduino_stm32/arm-gcc-2020q4/bin/arm-none-eabi-gdb-py3 -x /home/fx/blackmagic.gdb ${F}" (you'll need to adapt those 2 scripts for your configuration : path to gdb, path to blackmagic.gdb, device to use etc...) then bash ~/gdbgui.sh myelf.elf and it starts.  A small warning, i have to go to the output panel and press enter or else it...

It's not secret, i rather like the GD32xx chips. They work fine, the doc is ok (not great but ok) and they have a riscv based one that works very well. So i started writing lnArduino, i.e. running an Arduino style API on the riscv GD32VF103 chip as found on the Longan Nano. And then i wondered : Why should i care if it is an arm core or a riscv core ? The peripherals are mostly the same between the GD32F1/F3 and the GD32VF1 So i started adding support for Arm core (only GD32F1, GD32F3, and to some extend STM32F1) It is surprisingly simple to do, once you get through the base ones (boot, interrupts, freeRTOS) that are nasty. So for the features that are done, i can build the *same* code on a longan nano and on bluepill with a GD32F1 chip.  Only one line to change to select the MCU/Architecture in the CMakelist and that's it. "But i can do that with the Arduino API" you might think Sure thing, but you dont have the code & drivers written with FreeRTOS available out ...

It's just a toy but it works : sine, triangle, square from 10 hz to 100 khz The aim is mainly to use the lnArduino framework and makes sure it works (it does!) Youtube demo   Source code : https://github.com/mean00/longan_nano_signal_generator

  The Goal here is to make a simple signal generator with the longan nano. We'll just add a rotary encoder and that's it. It must be able to output sine, square and triangle sine up to ~ 100 kHz. So first thing first : How ? Using the internal DAC(s) to generate the signal. Let's have a look at it. DAC The  dual DAC is a 8Bits/12 bits digital to analog converter connected to PA4/PA5.  It seems the pins used are hardwired and cannot be changed. That could be a problem as they are shared with 2 SPI0 signals, connected to the screen. The DAC will do a conversion each time a trigger event happens. That event can either be software (i.e. you write a register) or a timer. A DMA can be scheduled using said timer too. What does it mean for us ? It means we prepare the data to send, a sine wave for example in a buffer, setup a DMA transfer and program the timer so that a new sample is sent to the DAC at the proper time. Each time the timer rolls over, the DMA will send the next sa...

  This is a known quirk of recent compiler.  It began with Arm, then appeared in apple llvm and now everywhere. Can you see the error in the following code ? (answer at the end [1]) bool        myMcp23017::dumpRegisters() { uint8_t reg=0; for(int i=0;i<27;i++)    Logger("Reg 0x%x : 0x%x\n  ",i,reg); } The usual bug is there is a crash at returns because the return address is mixed-up. On riscV, the generated code is as follows : Dump of assembler code for function _ZN10myMcp2301713dumpRegistersEv: 0x08007f3e <+0>:     addi    sp,sp,-16 0x08007f40 <+2>:     sw      ra,12(sp) 0x08007f42 <+4>:     sw      s0,8(sp) 0x08007f44 <+6>:     sw      s1,4(sp) 0x08007f46 <+8>:     sw      s2,0(sp) 0x08007f48 <+10>:    li      s2,0 0x08007f4a <+12...