Using mBed OS 2 single thread

I am using mBed OS 2 online and just now tried to switchover to offline using PlatformIO. I don’t use multiple threads at all. I tried to compile the initial project of Blinky with wait_ms() but it couldn’t recognise wait_ms(). It seems as though it is exclusively using OS. Can I use mBed 2 without OS on PlatformIO? How? Can I use all the library functions like wait_ms() which are not allowed in the multi-thread environment?

We have a baremetal blinky example at platform-ststm32/examples/mbed-rtos-blink-baremetal at develop · platformio/platform-ststm32 · GitHub and there the used API is

maybe that’s what you’re looking for?

(Also note that the project folder contains mbed_app.json to configure the baremetal config)

Thank you for the prompt reply. This is not what I am looking at. I want to use my existing code written for mBed 2 and compile on PlatformIO. Is there any way by which I can set the platform to mBed 2?

Also I found another problem, a single line program for toggling IO line takes 40 minutes to compile. My laptop is new, core i7 with 16 GB RAM and SSD.

Per Porting a target from Mbed OS 2 to Mbed OS 6 bare metal - Mbed OS bare metal profile | Mbed OS 6 Documentation

The Mbed OS bare metal profile offers the same functionality as Mbed OS 2 and allows targets to access features that we have added to more recent versions of Mbed OS. At the same time, it removes the RTOS and provides fewer features than Mbed OS 6, so it’s smaller and therefore suitable for ultraconstrained devices.

So it’s basically a compatible but better version of mbed 2. Same said here.

Anyways, the documentation states that if a project is using mbed-os 5 at a base package but doesn’t have the RTOS enabled via PIO_FRAMEWORK_MBED_RTOS_PRESENT, it is mbed-os 5.

There is an example at https://github.com/platformio/platform-ststm32/tree/develop/examples/mbed-legacy-examples/mbed-rtos that is mbed-os 5 (via a package selection in the platformio.ini) and enables the RTOS via the mentioned build_flags. So, if you remove that (and remove any RTOS reliant code in main.cpp, you should have mbed-os 2.

If you have further problems with it, we’d need to know which platformio.ini and code you’re using.

The entire mbed-os framework is compiled and then 99% is discarded at link-time. See PIO compiles everything in MBED framework when RTOS is enabled · Issue #288 · platformio/platform-ststm32 · GitHub and Mbed for STM32 compiles toooooo long. But it shouldn’t take 40 minutes… I think some antivirus by Windows or external is interfering. (See Hang creating new projects. Hang using pio install - #2 by maxgerhardt)

The way to genereally combat this in mbed-os is with .mbedignore files. There are also helper scripts for that to make it more comfortable.

There are some ways to handle wait functions with 6.7, normally they use literals from the chrono library for ms or s, (us doesn’t work!):
ThisThread::sleep_for(2s)
ThisThread::sleep_for(2ms)
thread_sleep_for(5ms) this should used for bare metal I think
for pass a variable you need do this:
int delay = 500; ThisThread::sleep_for(chrono::milliseconds(delay));
following should also work
wait_us(delay); wait_ms is deprecated

Many thanks. All understood about the OS version.

Now on the slowing down issue, I am personally not comfortable with deleting the folders directly as any mistake would make the Windows system unstable. I have only Windows Defender installed and no other antivirus. Do you think by setting up exclusions for the folders C:\Users<user>.platformio\pacakges and C:\Users<user>.platformio\platforms will work? Besides slowing down I also experienced hang-up twice.

If absolutely necessary I shall delete those folders. Will the app automatically download the required files again?

Any update on the slowing down issue? I am personally not comfortable with deleting the folders directly as any mistake would make the Windows system unstable. I have only Windows Defender installed and no other antivirus. Do you think by setting up exclusions for the folders C:\Users.platformio\pacakges and C:\Users.platformio\platforms will work? Besides slowing down I also experienced hang-up twice.

If absolutely necessary I shall delete those folders. Will the app automatically download the required files again?

Yes, PlatformIO is self-healing. It is intended that when you have a problem with a corrupted package, that you can delete it (and C:\Users\<user>\.platformio\.cache, too) and it will simply be redownloaded.

Even in the case that it goes wrong – the reinstall procedure explicitly says to remove the PlatformIO extension and the whole C:\Users\<user>\.platformio folder to get a clean state before an extension reinstall. Nothing can be permanently destroyed by this.

The .platformio folder is only used by PlatformIO, it will not affect Windows – we’re not deleting C:\Windows\system32 or anything.

As said, I only gained speedups by adding the exclusion to the Windows defender for the .platformio folder and the arm-none-eabi-gcc / g++ executables.

Many thanks. I shall try and report.

Please forgive me for the delayed reply. I deleted all the contents of the C:\Users\<user>\.platformio\pacakges\* and C:\Users\<user>\.platformio\platforms\*, set the exclusion in the Windows Defender and created a new project. It took 1065 seconds to first build. Rebuilding without cleaning takes about 37 seconds. Is this what expected or still there is some problem?

I want to use the Nuvoton board “NuMaker-PFM-NANO130” which is supported by mBed however I didn’t see it in the list. Can I use it?

Awaiting a response to my previous post. Is more than 1000 seconds a normal time for the first or clean-build and about 35 seconds for subsequent builds? If this is not the normal time please let me know the next course of action.

I want to use the Nuvoton board “NuMaker-PFM-NANO130” which is supported by mBed however I didn’t see it in the list. Can I still use it?

Even for mbed-os that’s a bit much (16 minutes). PIO compiles the entirety of the framework there (if not given .mbedignore files). But still, that should be like 5 min max and not 16. For me on Windows, I had problems with Windows Defender interfering and heavily slowing down the process (Hang creating new projects. Hang using pio install - #2 by maxgerhardt), maybe that is also the case here?

Per NuMaker-PFM-NANO130 | Mbed that board has NANO130KE3BN ARM-Cortex M0+ MCU. PlatformIO doesn’t have any support for Nuvoton MCUs at this point, only one feature requets for another Nuvoton board was filed a year ago. So, you should also open an issue there for a feature request for that board.

If you have the time, you can test a self-made integration: Create any new project, e.g. for the Nucleo F103RB and the mbedos framework. Create a new folder boards in that project, and therein the file numaker_pfm_nano130.json. Fill it with the content

{
    "build": {
      "core": "stm32",
      "cpu": "cortex-m0",
      "extra_flags": "-Dnano130ke3bn",
      "f_cpu": "42000000L",
      "mcu": "nano130ke3bn",
      "product_line": "STM32F103xB",
      "variant": "NUMAKER_PFM_NANO130",
      "mbed_variant": "NUMAKER_PFM_NANO130"
    },
    "debug": {
      "default_tools": [
      ],
      "jlink_device": "NANO130KE3BN",
      "onboard_tools": [
      ],
      "openocd_target": "numicro",
      "svd_path": "STM32F103xx.svd"
    },
    "frameworks": [
      "mbed"
    ],
    "name": "NuMaker-PFM-NANO130",
    "upload": {
      "maximum_ram_size": 16384,
      "maximum_size": 131072,
      "protocol": "mbed",
      "protocols": [
        "jlink",
        "cmsis-dap",
        "stlink",
        "blackmagic",
        "mbed"
      ]
    },
    "url": "https://os.mbed.com/platforms/NUMAKER-PFM-NANO130/",
    "vendor": "Nuvoton"
  }

then change the platformio.ini to

[env:numaker_pfm_nano130]
platform = ststm32
board = numaker_pfm_nano130
framework = mbed

And as src\main.cpp

#include <mbed.h>

int main() {

  // available pins see https://github.com/ARMmbed/mbed-os/blob/mbed-os-6.9.0/targets/TARGET_NUVOTON/TARGET_NANO100/PinNames.h
  DigitalOut led(LED_RED);

  while(1) {
      led = 0;
      ThisThread::sleep_for(500);
      led = 1;
      ThisThread::sleep_for(500);
  }
}

compilation should give

RAM:   [=====     ]  45.7% (used 7489 bytes from 16384 bytes)
Flash: [==        ]  21.8% (used 28552 bytes from 131072 bytes)
=================== [SUCCESS] Took 9.68 seconds ===================

and you can try uploading the firmware normally via the upload button, which should use the USB storage device programming method.