Going back to electronic after a 20 years break

  lnBMP : Lots of little issues tackled : - Preliminary FreeRTOS awareness through "mon fos M0|M3|M33' - Uart <->USB through DMA, that one was a pain - Configuration change to map the supported boards depending on the amount of RAM we have. But finally, here it is : lnBMP running on a RP2040 in a itsy bitsy case, and it works !

 In the eternal goal of having the smaller debugger possible, i ended up porting the strict minimum of lnBMP on top of the RP2040 chip. Tinyusb is available so that part was not problem. Clang + Rust, no problem either. The pico sdk is providing the basics , already CMake based. Using DMA+Uart was a bit more complicated but not that much at the end of the day. And ...It works !, expect nice pics of a lnBMP + RP2040 zero in a 3D printed case soon.

  This morning i realized the screen of my soldering iron was broken. I like that soldering iron, it is similar to that  one  with a STC chip and the main power supply included. I looked on the net and found this   post My T12 control board is slightly different;  it is not just connecting the VCC/VDD/SCL/SDA but the whole 30 pins ribbon. I removed the whole lcd+ribbon  from one of those cheap  LCD screen s i had in the spare box and solder it in place of the original one.  The screen is smaller than the original one but it's not really a problem. It works fine.

Lately, i updated lnDSO150 to v2.3, in particular its build system to be in sync with how i do things nowadays. The main goal is to easily switch between GCC and CLANG-17 (   arm or riscv ) The lnDSO150 has one variant (the FNIRSI one) with less flash ( only 64 kB), so i could use every flash gain possible Using clang + lto DID provide a nice size reduction (final size was ~ 50 kB for the fnirsi build) and at first it seemed to work alright. At first. Then, i realized that it made some underlying problem appear due its aggressive optimization. In other words, the bugs were there since day one, but hidden because the software was losing the race against the hardware every time. A couple of examples : - On the DSO150, some of the screen GPIO are reprogrammed as input to scan if  buttons have been pressed. If you flip the gpio too quickly, the button MAY keep the last state it was when used as output, causing random fake key pressed. Adding a couple of nops fixed the issue. - Sim...

 Finally got the PCB (that was my first one) As expected a couple of mistakes (selected footprints too small etc..) but it works! Since the CH32V303 is running at 140 Mhz, it is faster than the bluepill based one. For reference, i did the same PCB for a GD32F303, and it was more complicated. The ch32v303 version is much simpler, no need for extra glue. The chip, a 8mhz crystal, couple of resistors and caps and that's it. I've also ran into a false problem. The normal BMP  just reboots when it asserts, so you dont see that happening. The lnBMP halts when it asserts, took me a bit of time to realize that was not due to a problem i introduced.

 It is taking a bit of time, but getting there. What has changed since the last time : A tinyUSB based DFU bootloader  for the CH32V3x, a bit quirky but good enough for now and a small PCB (basically my first one) to host the CH32V303 and provides the pin out i usually use. Also, i fixed the hosted mode of lnBMP so it behaves like a genuine black magic, i.e. you can have the code running on your PC and use the BMP/lnBMP just as a hardware interface to your board.

The lnBMP is a project using the blackmagic probe core + a gdb remote protocol parser written in rust, on top of the lnArduino framework. As it is running on lnArduino, i'm making sure it works also on the CH32v3x chips You can see from left to right  : 1- The bluepill board under debug 2-  lnBlackmagic running on a homeboard based on  CH32v303 3- The WCH debugger to debug the CH32V303 I ported a basic tinyusb driver for the ch32v3x so now it works to some extent! That WCH chip is pretty good, plenty of flash, plenty of ram, 144 Mhz, FPU, plenty of IO and compatible largely with the good ol' STM32F103.