Is there a way to have a threaded application running on UEFI? I've only found a few mentions of threading in the UEFI specifications, but they didn't really answer my question.
There is no threads in UEFI right now, but there is a MpService protocol, that can be used for performing tasks on CPU cores other then BSP (BootStrap Processor, the core that runs UEFI itself).
You can read more about the same question here, nearly nothing is changed from that time. This presentation can also be useful, but not all functions mentioned there (sync primitives library, for example) are implemented in any given UEFI firmware.
Related
I want to to write a module that need some RTOS APIs like Mbox and Task creation API !
I'm trying to have structured code and to do that I'm looking at some libraries like "lwip" . In "lwip" there is a file named Sys-arch.c which in my knowledge is an abstraction layer to RTOS APIs ! but in my port it included cmsis_os.h and used that APIs . Why did they do that instead of using cmsis_os directly?
Should I have a new OS layer in order to have portable code or CMSIS_OS is enough ?
This answer is very opinion based.
In my experience it is always a good idea to use function/defines around your OS accesses. If you use CMSIS_OS or your own layer doesn't make a big difference beside you have more work if you use your own and especially porting and testing becomes very cumbersome with more than one OS.
The CMSIS_OS binds you to the Cortex-M systems but since they implement what you would implement in your layer as well and in quite usual way, it is rather simple to port from CMSIS_OS to your own layer later. It is not that simple if you use direct calls to a specific OS in your code directly but it is also possible if you only rely on standard features (take a look at CMSIS_OS what are common features of RTOS are) and don't use special features of your OS.
Why did they do that instead of using cmsis_os directly?
Because:
The idea is to abstract the API from any RTOS. If your target did not use CMSIS RTOS, you'd have to write a porting layer in any case.
the CMSIS RTOS API is ARM Cortex-M specific and lwip is not.
Should I have a new OS layer in order to have portable code or CMSIS_OS is enough ?
CMSIS is only enough if you will only ever target ARM Cortex-M, and there is a CMSIS layer for any RTOS you might be required to use. CMSIS is a portability abstraction, but not perhaps a usability abstraction. You might choose to implement a simpler abstraction of your own over CMSIS that can also be ported to other targets.
lwIP is nicely structured so that as long as your RTOS API supports its semantic requirements, then all you have to do is to adapt sys_arch.c to your OS API and you are done. By making sys_arch.c using the CMSIS_OS API abstraction, that would mean that you can use any CMSIS OS API compliant OS without changing that port of sys_arch.c. It's an extra layer of indirection that only you can decide whether it is worth it or not. If you do not plan to use different RTOS underneath, then there is no reason not to have a sys_arch.c that is specific to a single RTOS.
Anyway, lwIP RTOS requirements are fairly modest. Just about a dozen functions, but really only involve mailbox and semaphores with certain characteristics.
Suppose an embedded system project where I have a multicore ARM processor (to make it simple assume 2 cores with an unshared cache between the 2 cores). Suppose my system contains a critical task and several non-critical tasks.
Therefore, can I assign the critical task to "core 1" exclusively? And all other to "core 2" exclusively?
If so, how to do and what are the best practices from an implementation point of view [assume I use C]? Should I use a library (if so which one)? An RTOS?
Ok, I see that you asked this over in the EE board as well. They gave the same answer I want to give you as well. Use an operating system of some sort to handle thread affinities. If your RTOS or whatever you have does not support this, then look into it and see how it actually handles process/thread scheduling.
Typically, each CPU on a system will be assigned some sort of thread that handles scheduling of tasks. This thread is one of the first things that an OS sets up. Feel free to research some micro kernels out there to see how this is done for your particular processor. You can also find the secret sauce for setting up this thread in the ARM documentation for your particular CPU.
But, I am going out on a limb and assuming this is far, far beyond the scope of any assignment given to you for a project. I would hope that you have some affinity of some sort built into what you were given. Setting up affinity for a known OS is a few seconds task. Setting up affinity on a bare metal system with no OS at all is much more involved.
Original question:
https://electronics.stackexchange.com/questions/356225/multicore-arm-how-to-assign-a-critical-task-to-one-dedicated-core#comment854845_356225
If you don't need real-time functionality, you can do this on a device with a Linux kernel without too much hassle.
See this question here
If we can already execute C programs on cortex-m like micro-controllers, Why do we even need to install RTOS (or other operating systems).?
What benefits it can provide if micro-controller is intended to be multi-purpose.?
No you dont need an RTOS only if you need/want the features of the (particular) RTOS. You can program the microcontroller the way you/we always have without one if you prefer.
Typical things an RTOS might bring,
Memory management (who owns memory)
Interrupt handling support
Scheduling (pre-emptive or co-operative)
Usually several drivers in a BSP for your hardware/SOC
Debug tools
Some sort of shell
File systems
IPC (inter-process communitation)
A tool suite
A build environment
Memory protection
Networking
Your application may or may not need these features depending on your end goal. Some of them may be detrimental to your organizations work flow (like the tool suite and build environment). As a product matures, you may end up needing features you didn't account for.
However, a completely custom solution will probably have a smaller foot print. The race conditions involved in interrupt handling can be quite difficult to get right. Probably most RTOS will give a better implementation than something custom that evolves over time. If you are very dedicated, a state machine with polling of devices can be more optimal (hard real time) but again it is difficult to get right.
If the RTOS is BSD (or other permissive) licensed , it maybe possible to reuse the driver code to your own custom infra-structure. At some point your code may become an 'RTOS' of sorts. There are many to choose from.
POSIX compliance is a common standard. If you confine your code to POSIX, you are portable to many different RTOS/OS. However, most often an API that is more rich than POSIX; it is one way they differentiate each other. You may be able to use more 3rd party libraries if the RTOS is POSIX compliant.
An operating system provides a level of abstraction between the code written by an application programmer and the actual hardware the program runs on.
So you don't have to worry, as an application programmer, about the details of the hardware, as they are handled by drivers.
And thus you can compile the same program for many different hardware platforms, if they run the same (or a compatible) operating system.
I have an existing embedded source code which runs directly on a microcontroller with no operating system. I need to port the code to run on a specific RTOS.
Are there any guidelines in where to start when attempting wuch a thing ?
Resources, best practices, and other insight will be much appriciated.
RTOS preemptive multitasking is all about I/O performance. You need drivers that can make a thread ready when I/O is complete, eg. by signaling a semaphore. Nothing else is remotely as important.
Sadly, this usually means a system redesign to eliminate the performance-crippling polling that existed before :((
First of all, the RTOS has to be ported on your microcontroller.
If the RTOS already supports your microcontroller, then next would be tweaking your code for the RTOS. For that you need to refer the user guide of RTOS.
I am dealing with an existing project (in C) that is currently running on a single thread, and we would like to run on multiple platforms AND have multiple threads. Hopefully, there is a library for this, because, IMHO, the Win32 API is like poking yourself in the eye repeatedly. I know about Boost.Thread for C++, but, this must be C (and compilable on MinGW and gcc). Cygwin is not an option, sorry.
Try OpenMP API, it's multi-platform and you can compile it with GCC.
Brief description from the wikipedia:
OpenMP (Open Multi-Processing) is an application programming interface
(API) that supports multi-platform shared memory multiprocessing
programming in C, C++, and Fortran,[3] on most platforms, processor
architectures and operating systems, including Solaris, AIX, HP-UX,
Linux, macOS, and Windows. It consists of a set of compiler
directives, library routines, and environment variables that influence
run-time behavior.
I would use the POSIX thread API - pthread. This article has some hints for implementing it on Windows, and a header-file-only download (BSD license):
http://locklessinc.com/articles/pthreads_on_windows/
Edit: I used the sourceforge pthreads-win32 project in the past for multi-platform threading and it worked really nicely. Things have moved on since then and the above link seems more up-to-date, though I haven't tried it. This answer assumes of course that pthreads are available on your non-Windows targets (for Mac / Linux I should think they are, probably even embedded)
Windows threading has sufficiently different functionality when compared to that of Linux such that perhaps you should consider two different implementations, at least if application performance could be an issue. On the other hand, simply implementing multi-threading may well make your app slower than it was before. Lets assume that performance is an issue and that multi-threading is the best option.
With Windows threads I'm specifically thinking of I/O Completion Ports (IOCPs) which allow implementing I/O-event driven threads that make the most efficient use of the hardware.
Many "classic" applications are constructed along one thread/one socket (/one user or similar) concept where the number of simultaneous sessions will be limited by the scheduler's ability to handle large numbers of threads (>1000). The IOCP concept allows limiting the number of threads to the number of cores in your system which means that the scheduler will have very little to do. The threads will only execute when the IOCP releases them after an I/O event has occurred. The thread services the IOC, (typically) initiates a new I/O and returns to wait at the IOCP for the next completion. Before releasing a thread the IOCP will also provide the context of the completion such that the thread will "know" what processing context the IOC belongs to.
The IOCP concept completely does away with polling which is a great resource waster although "wait on multiple object" polling is somewhat of an improvement. The last time I looked Linux had nothing remotely like IOCPs so a Linux multi-threaded application would be constructed quite differently compared to a Windows app with IOCPs.
In really efficient IOCP apps there is a risk that so many IOs (or rather Outputs) are queued to the IO resource involved that the system runs out of non-paged memory to store them. Conversely, in really inefficient IOCP apps there is a risk that so many Inputs are queued (waiting to be serviced) that the non-paged memory is exhausted when trying to temporarily buffer them.
If someone needs a portable and lightweight solution for threading in C, take a look at the plibsys library. It provides you thread management and synchronization, as well as other useful features like portable socket implementation. All major operating systems (Windows, Linux, OS X) are supported, various other less popular operating systems are also supported (i.e. AIX, HP-UX, Solaris, QNX, IRIX, etc). On every platform only the native calls are used to minimize the overheads. The library is fully covered with Unit tests which are run on a regular basis.
glib threads can be compiled cross-platforms.
The "best"/"simplest"/... answer here is definitely pthreads. It's the native threading architecture on Unix/POSIX systems and works almost as good on Windows. No need to look any further.
Given that you are constrained with C. I have two suggestions:
1) I have a seen a project (similar to yours) that had to run on Windows and Linux with threads. The way it was written was that it (the same codebase) used pthreads on Linux and win32 threads on Windows. This was achieved by a conditional #ifdef statement wherever threads needed to be created such as
#ifdef WIN32
//use win32 threads
#else
//use pthreads
#endif
2) The second suggestion might be to use OpenMP. Have you considered OpenMP at all?
Please let me know if I missed something or if you want more details. I am happy to help.
Best,
Krishna
From my experience, multi threading in C for windows is heavily tied to Win32 APIs. Other languages like C# and JAVA supported by a framework also tie into these core libraries while offering their thread classes.
However, I did find an openthreads API platform on sourceforge which might help you:
http://openthreads.sourceforge.net/
The API is modeled with respect to the Java and POSIX thread standard,
I have not tried this myself as I currently do not have a need to support multiple platforms on my C/C++ projects.