Miosix 1.54 released

After a lot of time spent coding, here’s the new release of Miosix, my OS kernel for microcontrollers.

New features include:

  • Porting for ST’s Cortex M3 microcontrollers
  • Preliminary implementation of the POSIX thread API (pthreads)
  • Improved statistics on memory usage and debugging messages
  • Bug fixes and other enhancements

If you’re interested, download the new release here: http://www.webalice.it/fede.tft/miosix/index.html


Tags: , , ,

11 Responses to “Miosix 1.54 released”

  1. kuchura Says:

    Hi Federico,

    Very interesting project. Way to go!
    I’m successfully running Miosix 1.54 with Strive Mini board on STM32VET6. Unfortunately, I cannot use newer Miosix versions because as far as I remember the JTAG that I have (ST-Link v2) is not properly supported on Linux, and there’s no arm-miosix-eabi toolchain ported to Windows. I’ll try to build the toolchain in virtual machine with Ubuntu, build with it and then debug on Windows :).

    Several notes.

    1. There is a build problem on high optimization levels (at least for STM32 target). If the compiler inlines a function that contains inline assembly, and this function is used at least twice, a build fails because of duplicate labels. Therefore, local labels should be used in inline assembly, like, in delay.cpp:
    asm volatile(” mov r1, #0 \n”
    “0: cmp r1, %0 \n”
    ” itt lo \n”
    ” addlo r1, r1, #1 \n”
    ” blo 0b \n”::”r”(count):”r1″);
    Local labels begin with number. And a suffix should be used to jump: “0b” means “label 0 before”, “3f” means “label 3 forward”.

    2. Some MicroSD card connectors don’t have card presence switch, so the code that checks it should be moved to board specific bsp.cpp. Or a define in miosix_settings.h should be used.

    3. UsageFault_Handler is called on my board with default testing code (as of ver. 1.54), with “Unaligned access” as the reason. The board could not start until I disabled unaligned access fault checks. I did not investigate a reason yet.

  2. fedetft Says:

    Thanks for using the kernel 😉
    I have good news for you, I’m in the process of updating the Miosix website, and among other information, I’ll post a guide on making the ST-Link work on Linux, because that’s an issue I faced when porting Miosix to the stm32vldiscovery. In a couple of days the new information will be published on the website.

    Regarding the fixes:
    1) Actually, the compiler shouldn’t try to inline functions in .cpp files, if you can provide me a simple test case to trigger the bug I’ll certainly fix it.

    2) Never thought of that. But without a card detect, I guess I should assume that the card is present, try to initialize it and if initialization doesn’t fail it means it was really present. I’ll try this.

    3) Yes, the cortex-m3 port enables unaligned access fault. That’s because unaligned access is a nonportable processor specific feature. Some other CPUs, such as the ARM7 simply can’t cope with unaligned access, so to make sure I write portable code all the time, I thought enabling unaligned access was a good idea.
    I’ll make a configuration switch for that as well.
    Anyway, I don’t know if you’re aware of this feature, but the fault handlers print the address of the instruction that caused the fault, making it easy to narrow down the problem. Documentation for this feature is here: http://gitorious.org/miosix-kernel/miosix-kernel/blobs/master/miosix/doc/textdoc/Error%20debug.txt

  3. kuchura Says:

    Very good news. I hope I will be able to use ST-Link in Ubuntu.

    Will try to make a refined asm inlininig test case tonight.

    It was late in the night when I found that unaligned access fault happened, I simply disabled it and enjoyed the tests passing. So I’ll try to reenable it and use addr2line to find the source of fault.

  4. fedetft Says:

    I’ve updated the Miosix website, that’s the guide to make the stm32vldiscovery run on Linux: http://www.webalice.it/fede.tft/miosix/boards/stm32vldiscovery-linux-support.html

  5. kuchura Says:

    Hi Federico,
    I’ve found some free time for experiments. I’ve successfully built arm-miosix-eabi toolchain in Ubuntu (running in VirtualBox), installed vsprog and openocd there, as you described. Thank you for useful guide!
    Then I decided to “brick” my good old STM32VLDISCOVERY by converting it to Versaloon. I have standalone ST-Link, so I think I don’t loose anything. But if I succeed, I’ll replace the F100RBT chip with pin-to-pin compatible F103RET6 (I have one spare) and the Discovery can become a really useful tool.
    Unfortunately, the binaries that I’ve built both with arm-miosix-eabi (in Ubuntu) and with IAR (in Windows) from provided Versaloon sources did not work. I think only two things should be modified in order to let it build for VL Discovery, but maybe I’ve missed something. Never mind, I’ve found the latest prebuilt binaries (both with and without bootloader offset) and successfully flashed it to VL Discovery. Now it’s Versaloon. Great!
    Finally, I’ve passed the Versaloon through USB gate to the Ubuntu in VirtualBox, built Miosix and a simple app with two threads that blink LEDs on Discovery, flashed with “make program” – and everything works fine, from the first touch.
    Now, since I have all the tools, I think I am ready to continue with experiments.
    The goal is to run GUI on STM32VET6 with TFT LCD attached, to attach RF/ADC frontend and to make standalone SDR receiver controlled by STM32. I hope I’ll succeed 🙂

  6. fedetft Says:

    Good news!
    I’m glad you found the new documentation useful.

  7. kuchura Says:

    Succeeded to build arm-miosix-eabi toolchain for Windows, under MinGW. It took almost 5 hours and some voodoo, but now I can build projects and use IDE for development and debugging (I used slightly tweaked CooCox IDE based on Eclipse) and ST-Link JTAG adapter in an environment familiar to me.

    I’ve been stuck for a while when I saw that UART is running much slower than configured. Finally I’ve found that SystemInit() call was commented out in the program_start() due to bootloader conflict. It should have been wrapped with some if or #ifdef. Never mind.

    All tests pass. Here are the benchmark results with Strive Mini STM32 board on STM32F103VET6 at 72 MHz, SanDisk 4G class 4 SD card:

    Time required to print 165888 char is 86398ms
    Effective baud rate =19200
    111296 context switch per second (max priority)
    97990 context switch per second (min priority)
    Filesystem write benchmark
    Total write time = 78513ms (13KB/s)
    Max filesystem latency = 842ms
    Filesystem read test
    Total read time = 1758ms (582KB/s)
    Max filesystem latency = 4ms
    32831 Mutex lock/unlock pairs per second
    134704 pthread_mutex lock/unlock pairs per second
    257253 pause/restart kernel pairs per second
    371100 disable/enable interrupts pairs per second
    583673 fast disable/enable interrupts pairs per second

    SD write speed is slow, but I understand that it’s hardly possible to improve it on such a device. More discouraging is the filesystem latency on write operations. But pthread_mutex is something special – I like the performance!

  8. kuchura Says:

    On no, it was with -O0 optimization. -O2 is much better:

    219526 context switch per second (max priority)
    195228 context switch per second (min priority)
    Filesystem write benchmark
    Total write time = 76292ms (13KB/s)
    Max filesystem latency = 673ms
    Filesystem read test
    Total read time = 1408ms (727KB/s)
    Max filesystem latency = 3ms
    188889 Mutex lock/unlock pairs per second
    645090 pthread_mutex lock/unlock pairs per second
    785819 pause/restart kernel pairs per second
    906749 disable/enable interrupts pairs per second
    6508494 fast disable/enable interrupts pairs per second

  9. fedetft Says:

    Ok, the -O2 results match what I was expecting.
    By the way, to improve write speed on the SD you may want to comment out SYNC_AFTER_WRITE in miosix_settings.h (http://gitorious.org/miosix-kernel/miosix-kernel/blobs/master/miosix/config/miosix_settings.h). The filesystem implementation is by default configured to minimize the risk of filesystem inconsistency if power is removed unexpectedly. Because of that, it syncs after each write, even if this is painfully slow.
    I’m interested in the way you succeeded in compiling arm-miosix-eabi-gcc on Windows, it’s been on my todo list for quite a while, but given I seldom use Windows, I’ve never actually tried.

  10. kuchura Says:

    It’s a good hint to disable SYNC_AFTER_WRITE. How could I forget? 🙂

    MinGW / MSYS has almost everything needed to build gcc 4.5.2 cross-compiler. Missing stuff can be installed from packages available online, right from MSYS command line with command like “mingw-get install unzip mpfr mpc gmp”. (Probably something else was needed, I don’t remember).

    The only thing I had to download manually is libelf-0.8.13. I’ve built it from sources (with native MinGW) and placed the libelf.a somewhere among linker libraries. (“make install” could not do this properly, so I did it manually instead of finding the reason). And three headers were moved too. As I understand this library is needed only to provide link-time optimizations, and with gcc 4.6 this step can be omitted.

  11. fedetft Says:

    Well didn’t even know of the existence of mingw-get 😉
    I’ll have a look when I find some spare time (not easy) and try to write down a guide for windows.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: