Bare-Metal vs RTOS for advanced control systems - Cyclone V SX

Hi Claudia,

I have similar project, according to functionality and demands you described.

We choose Threadx as RTOS. It is simple enought and has realtime scheduling. The bare-metal library is actually core part of Threadx drivers for Cyclone V SOC.

My answer to the question is yes, the RTOS (like Threadx, vxworks, etc) are more suitable. The reason is multitasking support and scheduling.

Gery

If use 1 thread in any RTOS, come in Baremetal application ! :)

If only that RTOS may will start from any flash ! :)

Wait 1-2 year, and Baremetal learn to work on SoC FPGAs ! :)

It depends on the how 'hard' the real-time requirements are.

If you have very strict real-time requirements you can't afford the randomness that an RTOS will generate.

IMHO I'd avoid vxworks ...

Hi Gery,

--- Quote Start ---

I have similar project, according to functionality and demands you described.

We choose Threadx as RTOS. It is simple enought and has realtime scheduling. The bare-metal library is actually core part of Threadx drivers for Cyclone V SOC.

My answer to the question is yes, the RTOS (like Threadx, vxworks, etc) are more suitable. The reason is multitasking support and scheduling.

--- Quote End ---

I’m sorry for having to ask – but what is realtime scheduling?

I would have thought the most important reason is the ability to use multiple cores.

Have you tried other RTOSes as well?

Because Threadx is fairly expensive and I would have to explain the benefits for choosing Threadx over a free solution to my boss.

Hi Witfed,

--- Quote Start ---

Wait 1-2 year, and Baremetal learn to work on SoC FPGAs ! :)

--- Quote End ---

My appologies, but what exactly do you mean by bare-metal learning to work on SoC FPGAs? Is bare-metal not properly supported by the SoC FPGAs yet?

Hi dsl,

--- Quote Start ---

IMHO I'd avoid vxworks ...

--- Quote End ---

Okay, thanks for the tip!

--- Quote Start ---

It depends on the how 'hard' the real-time requirements are.

If you have very strict real-time requirements you can't afford the randomness that an RTOS will generate.

--- Quote End ---

That’s interesting. So an RTOS with the ability to use multiple cores will still not outperform a bare-metal application? I am given to understand that bare-metal applications cannot use both cores of the ARM Cortex-A9 and I would have to run a separate bare-metal application on the second core – or leave it idle.

Thank you guys!

Claudia

Hi Claudia,

I hope below link will help for understanding of real-time

http://en.wikipedia.org/wiki/real-time_computing

You should define what are the real-time demands in your project and it may help to accept the Linux as a solution.

Choosing Linux reduces the bringup time and may provide many already done solutions from open source world.

Gery

Now Baremetal applications may only be debugged in DS-5, and not started independent on power + from flash with regular Altera-s Preloader without semihosting support.

If for task solution is enough only original Altera-s SoC and run your program in debugger, may use current state, else need demand to Altera for revision and upgrade Preloader, about that I scream long time ! :)

For small transparent private application (no Internet, USB, CAN) without threads, semaphores and other "piles" best way is -- in one thread with one stack cycling with polling of all inputs, processing new data with not great portions and deliver results to outputs, then again read inputs and call most-priority handler... If need be urgent reactions to fast events in 10-20 tacts, may be used interrupts -- as exception, usually this urgency is not need.

Try start with one powerful processor core -- it may be sufficient for your tasks, and 2nd may only cause troubles in interaction and divide all works between all cores. Although if your tasks good divides on independent parts -- may run its on independent processors.

RTOSes have big initial costs for application developers, demand many unnecessary code (> 1/2) for supplying interaction and unnatural parallelizm, big times of task switching, volume of memory and unpredictable time of reaction. And many-many all-ready obscure sources and followers ! :)

With weak possibility of debugging -- by order greather even with powerful debugger.

--- Quote Start ---

Now Baremetal applications may only be debugged in DS-5, and not started independent on power + from flash with regular Altera-s Preloader without semihosting support.

If for task solution is enough only original Altera-s SoC and run your program in debugger, may use current state, else need demand to Altera for revision and upgrade Preloader, about that I scream long time ! :)

--- Quote End ---

Hi WitFed,

So bare-metal applications cannot boot on their own from SD-Card or QSPI Flash? I have to have a usb cable attached and configure via JTAG to run bare-metal applications?

But what do OSes or RTOSes have that makes them able to boot on their own?

Are you sure about this? Because the following tutorial tells you how to boot bare-metal applications from SD-card:

(please google "HPS SoC Boot Guide - Cyclone V SoC Development Kit" and click on the first result)

I didn't actually get it to work myself though...

Thanks

Claudia

In booting a bare metal application from qspi flash (http://www.alteraforum.com/forum/showthread.php?t=44985) and more older topics I discuss these theme. Some people says, what they may boot from QSPI, only without concrete recipe, some confirm impossibility.

Standard bsp-editor have checkbox-es for change Preloader functionality in sources, boot not from SD-card with Linux, and from QSPI flash with filled Preloader on address 0 and application on 60000, and in practice this not work, only Linux from SD! RTOSes I not touch.

I entreat Altera in detail describe this processes, because available some allusions and even is not known, where utilite must make binary image for fill application in flash and with what keys.

In debugger by run both Preloader and from it my HWLIB from QSPI is clear, what not handled exception "SVC 12345" in system libraryes with call to supervisor for semihosting: work with host files as stdin, stdout and from disk. In debugger this exception is wonderful handled (if semihocting enabled), and program interact with consoles and filesystem, and in "bare" boot first ASM command "SVC 12345" right away hang.

For my research I write semi-simulating handler in Preloader and may start with rbf downloading and LED blinking, and all wait Altera with officially promulgate sources of compatible with any flash-device non-semihosting starting Preloader ! May will be this in 14.1, may in 15.0 version...

In OSes or RTOSes, probably, is a similar handler, or they not using HWLIB with SVC interface. For Linux really used other compiler.

...All Boot Guides I read 2 month from april and battle with obscure problems, scream on forums, while perceive truth... :)

P.S. Link www.altera.com/literature/an/an709.pdf is recently, in July, its glad as Altera work, in a year may be result ! :)

Where I may subscribe to Altera distribution on SoC- and Baremetal-changes on site ? In ug_soc_eds.pdf, my base document, this not described.

In 709 many orthographical, punctuation and meaning errors, idea of Minimal Preloader or Custom Preloader, if BareMetal incorporates to its in 64K of available in HPS hi RAM, very not-good -- very small my code be located and badly debugged on Release. And direct execution of Preloader with big size may be only on FPGA fabric boot. If Preloaders may be max size 1 M (4, 16, ... etc. optional through BSEL pins) and these distantion with copyes, direct execution from flash sources...

Good idea -- boot from FPGA if booting from flash is unsuccessful, as a fallback. Its if FPGA boots without fails :) And I want configure FPGA from HPS: this very safely.

When I found HelloWorld sources contain files "test.c", "io.c" and "Debug-unhosted.ds" (in 13* and 14* SoC EDS used "hello.c"), then try next stages of writed in 709. May be, in application not using HWLIB (base of Altera for work with peripheral), and only with RS-output "Hello!", she start anyway from flash. And .ds-file-extension says me about armcc-compiler in compiling toolchain, licension of these not included in SoC CV kit!.. :)

Hi WitFed!

--- Quote Start ---

In booting a bare metal application from qspi flash (http://www.alteraforum.com/forum/showthread.php?t=44985) and more older topics I discuss these theme. Some people says, what they may boot from QSPI, only without concrete recipe, some confirm impossibility.

Standard bsp-editor have checkbox-es for change Preloader functionality in sources, boot not from SD-card with Linux, and from QSPI flash with filled Preloader on address 0 and application on 60000, and in practice this not work, only Linux from SD! RTOSes I not touch.

--- Quote End ---

But why doesn't it work? And why does it work for Linux?

--- Quote Start ---

I entreat Altera in detail describe this processes, because available some allusions and even is not known, where utilite must make binary image for fill application in flash and with what keys.

In debugger by run both Preloader and from it my HWLIB from QSPI is clear, what not handled exception "SVC 12345" in system libraryes with call to supervisor for semihosting: work with host files as stdin, stdout and from disk. In debugger this exception is wonderful handled (if semihocting enabled), and program interact with consoles and filesystem, and in "bare" boot first ASM command "SVC 12345" right away hang.

--- Quote End ---

But what sort of exception is this? But then the application should work without the error that throws the exception.

--- Quote Start ---

For my research I write semi-simulating handler in Preloader and may start with rbf downloading and LED blinking, and all wait Altera with officially promulgate sources of compatible with any flash-device non-semihosting starting Preloader ! May will be this in 14.1, may in 15.0 version...

--- Quote End ---

What is rbf? I'd love to get a HPS program to work that just boots from the SD-Card an then blinks a couple of LEDs!

--- Quote Start ---

In OSes or RTOSes, probably, is a similar handler, or they not using HWLIB with SVC interface. For Linux really used other compiler.

...All Boot Guides I read 2 month from april and battle with obscure problems, scream on forums, while perceive truth... :)

--- Quote End ---

Yes I can understand your frustration, I find the documentation rather scarce too!

--- Quote Start ---

P.S. Link www.altera.com/literature/an/an709.pdf is recently, in July, its glad as Altera work, in a year may be result ! :)

Where I may subscribe to Altera distribution on SoC- and Baremetal-changes on site ? In ug_soc_eds.pdf, my base document, this not described.

In 709 many orthographical, punctuation and meaning errors, idea of Minimal Preloader or Custom Preloader, if BareMetal incorporates to its in 64K of available in HPS hi RAM, very not-good -- very small my code be located and badly debugged on Release. And direct execution of Preloader with big size may be only on FPGA fabric boot. If Preloaders may be max size 1 M (4, 16, ... etc. optional through BSEL pins) and these distantion with copyes, direct execution from flash sources...

--- Quote End ---

I also don't understand in the an709.pdf (HPS SoC Boot Guide - Cyclone V SoC Development Kit) document, why do they use a linux image at the end? I thought the purpose was to get a bare-metal application up and running

--- Quote Start ---

Good idea -- boot from FPGA if booting from flash is unsuccessful, as a fallback. Its if FPGA boots without fails :) And I want configure FPGA from HPS: this very safely.

When I found HelloWorld sources contain files "test.c", "io.c" and "Debug-unhosted.ds" (in 13* and 14* SoC EDS used "hello.c"), then try next stages of writed in 709. May be, in application not using HWLIB (base of Altera for work with peripheral), and only with RS-output "Hello!", she start anyway from flash. And .ds-file-extension says me about armcc-compiler in compiling toolchain, licension of these not included in SoC CV kit!.. :)

--- Quote End ---

What is RS-output? Yes, I had a lot of licensing problems too, very annoying!

Many thanks,

Claudia

--- Quote Start ---

It depends on the how 'hard' the real-time requirements are.

If you have very strict real-time requirements you can't afford the randomness that an RTOS will generate.

IMHO I'd avoid vxworks ...

--- Quote End ---

Which RTOS would you recommend?

Cheers,

Adam