Going back to electronic after a 20 years break

  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 samp

  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>:    li      s0,0 0x08007f4c <+14>:    lui     s1,0x8001 0x08007f50 <+18>:    mv      a2,s2 0x08007f52 <+20>:    mv      a1,s0 0x08007f54 <+22>:    addi    a0,s1,1608 # 0x80016

  This is a common need: Be able to see and navigate among threads from gdb. There are 2 ways to do that : It is built-in at  low level. That means either inside gdb or openOcd or blackmagic probe etc.... Using external scripts One gotcha to make things more difficult : Depending on the FreeRTOS port, the way the registers are pushed on the stack differs and may confuse gdb. As far as option 1 is concerned,  i did not manage to make it work with riscv-openOCD, in addition i'm pretty sure the FreeRTOS port i'm using will cause problem So let's go for option 2. GDB Python support  We'll use some python3 scripts within gdb to deal with thread awareness In order to do that, we'll need a python3 enabled riscv gdb Let's download the vanilla gdb 10.2 from gnu.org  (*not* the riscv version) and configure it that way export PATH=/opt/gd32/toolchain/bin/:$PATH echo /usr/bin/python3-config --includes echo /usr/bin/python3-config --libs export PYVER=3.8 export LIBS=`/usr