Get mbf-freertos running on Wio Terminal

[LongDirtyAnimAlf]

Hi Michael, I have forked this repo. Going to try to get it running on Wio Terminal. My plan is to have as many standard tasks as possible running in FreeRTOS itself. This inludes WiFi, USB, Bluetooth, more. And to allow FPC consumers to use these tasks. Will keep you updated.

[LongDirtyAnimAlf]

Blinky task on Wio Terminal is working with your implementation of FreeRTOS ! Thanks.

[MichaelRing]

I have ordered one of those Wio Terminal boards locally, should arrive before Christmas.

Which import units do you use? I have generated Modules for samd51 based on the atdf files provided in Microchips' packs, perhaps you can send me your version via pm so that I can verify that my bindings are complete.

[LongDirtyAnimAlf]

My FreeRTOS fork here: https://github.com/LongDirtyAnimAlf/mbf-freertos My FPC fork here: https://github.com/LongDirtyAnimAlf/freepascal

Both repo's hold the changes and files needed to get things working. The FPC fork is in sync with trunk.

If you need more, please let me know.

I will add more files the next few days. Especially to get easy hardware access for the Wio.

[michael-ring]

I think you need to be carefull with those bindings, I quickly checked ac_registers and what you have does not seem to match with the Header files from microchip's site.

Here's what I see in the ac Header file:

if !(defined(ASSEMBLER) || defined(IAR_SYSTEMS_ASM))

/ \brief AC register API structure / typedef struct { / Analog Comparators */ IO uint8_t AC_CTRLA; /*< Offset: 0x00 (R/W 8) Control A / O uint8_t AC_CTRLB; /< Offset: 0x01 ( /W 8) Control B */ IO uint16_t AC_EVCTRL; /*< Offset: 0x02 (R/W 16) Event Control / IO uint8_t AC_INTENCLR; /< Offset: 0x04 (R/W 8) Interrupt Enable Clear */ IO uint8_t AC_INTENSET; /*< Offset: 0x05 (R/W 8) Interrupt Enable Set / IO uint8_t AC_INTFLAG; /< Offset: 0x06 (R/W 8) Interrupt Flag Status and Clear */ I uint8_t AC_STATUSA; /*< Offset: 0x07 (R/ 8) Status A / I uint8_t AC_STATUSB; /< Offset: 0x08 (R/ 8) Status B */ IO uint8_t AC_DBGCTRL; /*< Offset: 0x09 (R/W 8) Debug Control / IO uint8_t AC_WINCTRL; /< Offset: 0x0A (R/W 8) Window Control */ I uint8_t Reserved1[0x01]; IO uint8_t AC_SCALER[2]; /*< Offset: 0x0C (R/W 8) Scaler n / I uint8_t Reserved2[0x02]; IO uint32_t AC_COMPCTRL[2]; /< Offset: 0x10 (R/W 32) Comparator Control n */ __I uint8_t Reserved3[0x08]; I uint32_t AC_SYNCBUSY; /*< Offset: 0x20 (R/ 32) Synchronization Busy / IO uint16_t AC_CALIB; /< Offset: 0x24 (R/W 16) Calibration */ } ac_registers_t;

and this I see in your fpc fork:

TAc_Registers = record CTRLA : byte; // Control A CTRLB : byte; // Control B EVCTRL : word; // Event Control INTENCLR : byte; // Interrupt Enable Clear INTENSET : byte; // Interrupt Enable Set INTFLAG : byte; // Interrupt Flag Status and Clear Reserved1 : array[0..0] of byte; STATUSA : byte; // Status A STATUSB : byte; // Status B STATUSC : byte; // Status C Reserved2 : array[0..0] of byte; WINCTRL : byte; // Window Control Reserved3 : array[0..2] of byte; COMPCTRL : array[0..1] of longword; // Comparator Control n Reserved4 : array[0..7] of byte; SCALER : array[0..1] of byte; // Scaler n end;

My new code is pretty close... although some bugs included: TAC_Registers = record CTRLA : byte; //0000 Control A CTRLB : byte; //0001 Control B EVCTRL : word; //0002 Event Control INTENCLR : byte; //0004 Interrupt Enable Clear INTENSET : byte; //0005 Interrupt Enable Set INTFLAG : byte; //0006 Interrupt Flag Status and Clear STATUSA : byte; //0007 Status A STATUSB : byte; //0008 Status B DBGCTRL : byte; //0009 Debug Control WINCTRL : byte; //000A Window Control RESERVED0 : byte; //000B SCALER : byte; //000C Scaler n RESERVED1 : array[1..3] of byte; //000D COMPCTRL : longWord; //0010 Comparator Control n RESERVED2 : array[1..12] of byte; //0014 SYNCBUSY : longWord; //0020 Synchronization Busy CALIB : word; //0024 Calibration end;

[LongDirtyAnimAlf]

Thanks for this. I guess you will find more of these. Its not that important for me anymore. I am planning (and already succeeded) to compile a big and fat freertos library, incuding all hardware support. And just add functions to use this.

See GPIO: procedure freertos_pinMode(ulPin:DWORD;ulMode:DWORD); external name 'pinMode'; procedure freertos_digitalWrite(ulPin:DWORD;ulVal:DWORD); external name 'digitalWrite';

I want to do the same for USB and LCD. I am a lazy guy ... ;-)

Buts its better to have a correct header. I do not have tools to generate them. I will welcome your efforts !

[michael-ring]

My Wio Terminal arrived today, I already pimped it to work with Segger JLink and installed Circuitpython, I am a really lazy guy ... ;-) Display is supported out of the box:

[LongDirtyAnimAlf]

Wow, that is quick ! Wow, you are good !! Its a very nice device. Do you have FreeRTOS running with FPC ?

[michael-ring]

What you see is CircuitPython, not yet fpc+freertos. I am currently playing with the uf2 bootloader.

[LongDirtyAnimAlf]

I have the USB CDC and MSC tasks running with FPC and FreeRTOS ! Next target : LCD.

[michael-ring]

Great! I have uploaded atdftopas project to github, allows you to create units for atsamd51 based on atdf files provided by MicroChip and have also updated my fork of freepascal with new low-level code for freertos target, mainly cleaning up the old cortexm*.pp files which were (for me) a pain in the ass and were incorrect in some cases. There is likely still more lowlevel work needed for virtual interrupt tables to properly support uploading code with a bootloader.

[LongDirtyAnimAlf]

That looks good !!

About the vector table. We need to have exactly the same interrupt names as used in the standard libraries, as they might be referenced from C-code ! For SAMD51 I saw some different names in your files.

[michael-ring]

vtor setting is done now, freetos tasks now also work for me on boards that use bootloaders. The interrupt names were generated from atdf files, I am not changing them, what definitions give you troubles?

[LongDirtyAnimAlf]

Look at this file. https://github.com/Seeed-Studio/ArduinoCore-samd/blob/master/cores/arduino/TinyUSB/Adafruit_TinyUSB_SAMD.cpp As you can see, it redirects the USB interrupts on SAMD51. When using other names these redirects will fail.

Look at this file. https://github.com/Seeed-Studio/ArduinoCore-samd/blob/master/cores/arduino/cortex_handlers.c These are the names as needed by the other libraries.

vtor setting is done now, freetos tasks now also work for me on boards that use bootloaders.

Would you mind making a Lazarus project example available somewhere ? I would be very interested to test this and see how you get this working !

Thanks again very much for all your work.

[michael-ring]

Fixed, definition is a little different in the atdf files (Hate it..) the normal interrupts look OK now, there are still a few issues with the cmsis innterrupts which I have seen before on other platforms, (SVCall vs SVC and others), will need to check if I can alias those entries.

Lazarus project examples are generated by the genalllpi.sh script, I have uploaded a completely prebuilt (with freertos-libs) version here:

http://temp.michael-ring.org/mbf-freertos-20201227.zip

You will likely need to tweak the lpi files a little bit.

Current buildresults are like this:

ring@MacBookAir Samples % ./buildall.sh
Building A02YYUWDemo/A02YYUWDemo-metro_m4.lpi                        [FAILED]
Building A02YYUWDemo/A02YYUWDemo-nucleof401re.lpi                    [OK]     19304 bytes code, 19565 bytes data
Building A02YYUWDemo/A02YYUWDemo-nucleog071rb.lpi                    [FAILED]
Building Blinky/Blinky-metro_m4.lpi                                  [OK]     12280 bytes code, 19393 bytes data
Building Blinky/Blinky-nucleof401re.lpi                              [OK]     15028 bytes code, 19405 bytes data
Building Blinky/Blinky-nucleog071rb.lpi                              [OK]     17196 bytes code, 7357 bytes data
Building BlinkyStatic/BlinkyStatic-metro_m4.lpi                      [OK]     11676 bytes code, 4597 bytes data
Building BlinkyStatic/BlinkyStatic-nucleof401re.lpi                  [OK]     14424 bytes code, 4609 bytes data
Building BlinkyStatic/BlinkyStatic-nucleog071rb.lpi                  [OK]     16648 bytes code, 4849 bytes data
Building MultiBlinky/MultiBlinky-metro_m4.lpi                        [OK]     12020 bytes code, 5813 bytes data
Building MultiBlinky/MultiBlinky-nucleof401re.lpi                    [OK]     14848 bytes code, 5825 bytes data
Building MultiBlinky/MultiBlinky-nucleog071rb.lpi                    [OK]     17120 bytes code, 6065 bytes data
Building SerialPort/SerialPort-metro_m4.lpi                          [FAILED]
Building SerialPort/SerialPort-nucleof401re.lpi                      [OK]     20024 bytes code, 19537 bytes data
Building SerialPort/SerialPort-nucleog071rb.lpi                      [FAILED]

[LongDirtyAnimAlf]

Good ! Will look into all stuff tomorrow. Thanks again. In the meantime: I got the LCD running with FreeRTOS and FPC.

[michael-ring]

Like it! I will see what you did to make USB work, I'd rather use tinyusb directly (wanted to do that for a long time..) because I am not keen on getting the monster dependencies of the arduino libs. I grew quite frustrated reading the SAMD51 reference manual today so I thought I better start a little more simple and added support for a few SAMD21 chips. There I know you already did most of the hard work for creating proper clocks in mdf.

So far Blinky Sample already works for me, time to tackle UART and SPI....

[LongDirtyAnimAlf]

https://drive.google.com/file/d/12CNASV8iPGNA336CGPy9sQCLulawA_DQ/view?usp=sharing

FreeRTOS + TinyUSB + Spi + DMA + SeeedStudioLCD. All running from tasks by FPC with a fat freertos.a static library. :-)

[LongDirtyAnimAlf]

https://wiki.seeedstudio.com/Software-FreeRTOS/

Our version with FPC also working ! https://github.com/LongDirtyAnimAlf/mbf-freertos/tree/master/Samples/Sprites

[LongDirtyAnimAlf]

And the clock in FPC ! https://github.com/LongDirtyAnimAlf/mbf-freertos/tree/master/Samples/Clock

[michael-ring]

Had a brief look at the Clock's code, seems the commit is incomplete, at least I could not see the drawing routine for the clock hands. So far I never used floatingpoint in rtos tasks, so I was not sure if this works out of the box (it should...) or if tweaks are needed for saving floating point registes on task change......

[LongDirtyAnimAlf]

Drawing routines: https://github.com/LongDirtyAnimAlf/mbf-freertos/blob/master/source/MBF.SAMD.LCD.pas

About floating point. Its needs more FreeRTOS stack. And linking with libm. And using functions of libm. And arm hardfloat FPC compiler. And eabihf compiler option.

[LongDirtyAnimAlf]

You were right about missing sources. https://github.com/LongDirtyAnimAlf/mbf-freertos/blob/master/Samples/Clock/ClockTask.lpr

[michael-ring]

I played around with hardware floatingpoint, perhaps you can help me:

I see that in my small demo code vldr commands are created by the compiler for sin:

  SetNibble(SCB.CPACR,%1111,20);
  y := pi;
  z := y * pi;
  x := sin(y);

# [44] z := y * pi;
    ldr r2,.Lj12+4
.Ll9:
    str r1,[r0, #4]
.Ll10:
    ldr r0,.Lj12
    str r2,[r13, #4]
    ldr r1,.Lj13
    str r0,[r13]
    ldr r0,.Lj11
    ldr r3,[r1]
    ldr r2,[r0]
    sub r0,r11,#56
    bl  float64_mul
    ldr r2,[r11, #-56]
    ldr r0,.Lj15
    ldr r1,[r11, #-52]
    str r2,[r0]
# [45] x := sin(y);
    ldr r2,.Lj11
.Ll12:
    str r1,[r0, #4]
.Ll13:
    vldr    d0,[r2]
    bl  fpc_sin_real
    vstr    d0,[r11, #-56]

but when I debug in (for example float64_mul) it looks that rtl uses software emulation.

As you are the god of cross-compiling, do you have any good tips for me?

The extra Flags I use when compiling the compiler are:

  cleancompiler          arm armv6m  freertos $FREERTOSSRCDIR
  compileinstallcompiler arm armv6m  freertos $FREERTOSSRCDIR "-dFPC_ARMHF"
  compileinstallrtl      arm armv6m  freertos $FREERTOSSRCDIR "-CfSOFT"
  compileinstallrtl      arm armv7m  freertos $FREERTOSSRCDIR "-CfSOFT"
  compileinstallrtl      arm armv7em freertos $FREERTOSSRCDIR "-Sg -CfFPV4_SP_D16 -CaEABIHF -g"

where the last parameter is added to OPT for building the compiler and for RTL the last parameter goes to CROSSOPT

[LongDirtyAnimAlf]

I have used the same settings as used by the Arduino IDE tools to compile the freertos libs. To use this lib with FPC, I use the following settings to build the cross-compiler. OPT: -dFPC_ARMHF CROSSOPT: -CfFPV4_SP_D16 -OoFASTMATH -CaEABIHF SUBARCH: armv7em

Linking uses the same libs as Arduino: thumb armv7em hard E.g. on my Windows machine, I use libc from here C:\fpclazbydeluxe\embedded\cross\bin\arm-freertos\arm-none-eabi\lib\thumb\v7e-m\fpv4-sp\hard\libc_nano.a

And for floating point, link against libm.a from the same directory and call functions from this lib directly.

Is this enough info ?

Ps: I have the sensor demo also running with FPC.

[michael-ring]

Received this super-tiny Seeduino XIAO, it has a SAMD21G18 chip, this demo again is with CircuitPython, but i am close to beeing in the same status with mbf-freertos...

[LongDirtyAnimAlf]

That is a very nice and small device ! Would be very good to have FreeRTOS/FPC-combo running on it !

Question. As you know, I am on the path to use a fat FreeRTOS library to make GPIO,LCD,USB,SPI,DMA-life easier by using the c-sources as a kind of hardware-interface-layer. Less work, less bugs. I am now using a define [{$ifdef freertos_fat}] to use this layer. But this is not the way to go naturally. Do you have a better idea to us/combine both your lean and mean FreeRTOS and my fat FreeRTOS ?

E.g., for GPIO, I only use:

{$ifdef freertos_fat} procedure freertos_pinMode(ulPin:DWORD;ulMode:DWORD); external name 'pinMode'; procedure freertos_digitalWrite(ulPin:DWORD;ulVal:DWORD); external name 'digitalWrite'; {$endif freertos_fat}

So, no registers-calls involved. Only calling these c-functions that are included in the static FreeRTOS library from the available c-sources. The same for ADC and other available hardware.

[michael-ring]

What we have to think about it what goes later to the arm-freertos target and what stays in MBF. My Plans would be to have all things related to freertos-core inside of arm-freertos as a universal target that can easily be used as the building block for riscv-freertos and perhaps esp32s2-freertos. Those versions could use long term support versions of freertos and can have branches for other versions.

So you could check if the arduino code does work with latest LTS Version of FreeRTOS or if you need to provide their special version on a branch.

This of course means that you need to split your dependencies in two parts, one part covering freertos as one lib and then the arduino specific stuff in another lib.

With freertos out of the way the 2nd thing is linking to the arduino part, this we can also achieve (I think) pretty easy by you creating a mbf target that is mbf-samd51-arduino or whatever. I want to keep the samd51 and samd21 targets separate because I believe in the long term it is easier to have native implementations. You can then link to the extra arduino libraries in systemcore or wherever it suits you, you can check what I did to include systemview and rtt, those libs are also included conditionally (or better said, currently excluded because I was to lazy to upgrade them to support LTS Freertos)

[LongDirtyAnimAlf]

If I understand the above correct, than 100% agreed. Indeed best to have FreeRTOS LTS in FPC.

I will check if a FreeRTOS-LTS static lib + Arduino static lib give me all that is needed.

Sidenote. I am very happy with the Wio-Terminal. I guess this device could make many more FPC users happy. We should (must) provide an out-of-the-box experience for the Wio.

[michael-ring]

+1 for the out of the box experience.....

I am now building up the mbf wiki on how to set up a proper fpcupdeluxe environment, perhaps you can lateron check which parts of the instructions can be automated by fpcupdeluxe, likely the same stuff will apply to mbf-freertos

[LongDirtyAnimAlf]

Hi Michael,

New pre-releases of fpcupdeluxe. https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/tag/1.8.2j

Please test by installing in an empty directory. To test the out-of-the-box experience. Many (many many) changes under the hood. Buggers will be there.

Thanks !!

[LongDirtyAnimAlf]

On my Darwin 10.15 VM on Windows. All ok ... Very strange !

[michael-ring]

No surprise to me, this issue started for me with Big Sur, I started a thread on fpc-devel on 15.11.2020

What makes me wonder is that you fixed the issue for compiling fpc + lazarus by checking results of xcrun, please do the exact same thing for compiling embedded controllers, it will work, trust me ..... 8-)

[michael-ring]

What can eventually also help better understand my environment is that I have a 'fpcupdeluxe-only' environment, I have deleted previous installs of fpc because they caused issues rebuilding lazarus and also there is no arm-embedded-as anywhere in my path which means your CROSSBINDIR setting may actually not work (Does it have to be in CROSSOPTS(??)) Please note that I am desribing here my 2nd issue that the crosscompiler cannot be found.

[LongDirtyAnimAlf]

About an 'fpcupdeluxe-only' environment. That should not be necessary. All efforts are there to prevent (nearly) anything in the path being picked up by fpcupdeluxe. It should download and use it's own cross-tools and cross-libs. Unless the user does a manual config. So, even if there are cross-tools in the path, they should not be used by fpcupdeluxe. The whole install must be isolated in a single directory.

About xcrun. I will look into it again !

[LongDirtyAnimAlf]

https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/download/1.8.2j/fpcupdeluxe-x86_64-darwin-cocoa.zip

Added xcrun links as requested. Please test. Thanks very much.

[michael-ring]

Getting closer... Crosscompiler is now successfully built, now buiding package fails with same error:

fpcupdeluxe: Executing: /usr/bin/make --directory=/Users/ring/fpcupdeluxe-embedded/fpcsrc FPCMAKE=/Users/ring/fpcupdeluxe-embedded/fpc/bin/x86_64-darwin/fpcmake PPUMOVE=/Users/ring/fpcupdeluxe-embedded/fpc/bin/x86_64-darwin/ppumove PREFIX=/Users/ring/fpcupdeluxe-embedded/fpc INSTALL_PREFIX=/Users/ring/fpcupdeluxe-embedded/fpc FPCDIR=/Users/ring/fpcupdeluxe-embedded/fpcsrc INSTALL_BINDIR=/Users/ring/fpcupdeluxe-embedded/fpc/bin/x86_64-darwin CROSSBINDIR=/Users/ring/fpcupdeluxe-embedded/cross/bin/arm-embedded FPC=/Users/ring/fpcupdeluxe-embedded/fpc/bin/x86_64-darwin/ppcarm packages CROSSINSTALL=1 CPU_SOURCE=x86_64 OS_SOURCE=darwin OS_TARGET=embedded CPU_TARGET=arm SUBARCH=armv6m NOGDBMI=1 REVSTR=48669 REVINC=force BINUTILSPREFIX=arm-embedded- CROSSOPT=-Cparmv6m -CaEABI -XParm-embedded- OPT=-vw-n-h-l-d-u-t-p-c- -dFPC_ARMHF -ap (working dir: /Users/ring/fpcupdeluxe-embedded/fpcsrc)
/Library/Developer/CommandLineTools/usr/bin/make -C packages all
/Library/Developer/CommandLineTools/usr/bin/make -C ../rtl all FPC=/Users/ring/fpcupdeluxe-embedded/fpcsrc/compiler/ppc
/Library/Developer/CommandLineTools/usr/bin/make -C embedded all
/Library/Developer/CommandLineTools/usr/bin/make -C fpmkunit bootstrap FPC=/Users/ring/fpcupdeluxe-embedded/fpcsrc/compiler/ppc
/Users/ring/fpcupdeluxe-embedded/fpcsrc/compiler/ppc src/fpmkunit.pp -n -Fu/Users/ring/fpcupdeluxe-embedded/fpcsrc/rtl/units/x86_64-darwin -FUunits_bs/x86_64-darwin -Fu../paszlib/src -Fu../hash/src -Fi../paszlib/src   -Fi../fcl-process/src/unix -Fu../fcl-process/src -Fi../fcl-process/src/darwin -Fi../fcl-process/src/dummy -Fu../libtar/src -vw-n-h-l-d-u-t-p-c- -dFPC_ARMHF -ap
/Users/ring/fpcupdeluxe-embedded/fpcsrc/compiler/ppc fpmake.pp -n -Fu/Users/ring/fpcupdeluxe-embedded/fpcsrc/packages/fpmkunit/units_bs/x86_64-darwin -Fu/Users/ring/fpcupdeluxe-embedded/fpcsrc/rtl/units/x86_64-darwin  -vw-n-h-l-d-u-t-p-c- -dFPC_ARMHF -ap
ld: library not found for -lc
An error occurred while linking 
Error: Error while linking
Fatal: There were 1 errors compiling module, stopping
make: *** [packages] Error 2
Fatal: Compilation aborted
fpcupdeluxe: ERROR: FPCCrossInstaller (BuildModuleCustom: FPC): Running cross compiler fpc /usr/bin/make for arm-embedded failed with an error code.

ERROR: Fpcupdeluxe fatal error !
Sequencer (FPCCleanBuildOnly): Failure running fpcupdeluxe: error executing sequence FPCCleanBuildOnly
Sequencer (Only): Failure running fpcupdeluxe: error executing sequence Only

[michael-ring]

Do you think you can build me a version with a fix for the last issue? I have done more testing building avr and esp32 but as those builds never fully finish I think they are good but I do not know because they all break when packages get built.....

Also still seeing the issue with revision.inc on Windows, is it necessary to force creating a new revision.inc when building Crosscompilers? I see revision.inc is updated in build of normal compiler (and there it also works for me) and only there a git pull is done, so I guess no need to force revision.inc again when building crosscompilers.....

What I do not understand is that when I do the echo manually:

echo '12345' I get the needed result '12345'.

So is it possible that a unix-version of echo is sneaked in by the set PATH the build process? It should not because you say you make building independant of the rest of the system......

[michael-ring]

I hit the 'pico' button on my mac and a few minutes later all was built, Yipeee......!!!!! Now trying build for wio and will then go some other archs.... Thank you!

[LongDirtyAnimAlf]

Hi Michael,

I have updated all binaries in this pre-release. You are welcome to test. Some tweaks will be needed perhaps. Lots of changes went in. I hope all for the best. Thanks again for testing !!

[michael-ring]

Can you please review my comments on the pull request? Thank you!