While researching about the embedded systems I found libmraa library for Linux. But I can't make sure that it is the right tool for me.
What I would like to do is to implement an embedded system that contains stepper motors, heaters and fans etc. It would be good If I can do it with Linux, but I thought that it is not practical and possible.
Does libmraa provide scheduling guarantees to ensure deterministic behaviour and timely response events and interrupts? Because I always make sure that steppers always work without any interruption.
Is libmraa just a tool for hobbyists or a good to for a real embedded system?
Warning: I have no experience with mraa. What I did though, beyond looking at what it's about, is clone the repo and grep the sources for 'sched', 'nice' etc.
The only thing I found is this mraa_set_priority() API:
https://github.com/intel-iot-devkit/mraa/blob/master/api/mraa/common.h#L153
Note that it's for SCHED_RR, but there's no API for the more aggressive and deterministic SCHED_FIFO nor the modern refinement SCHED_DEADLINE.
So:
Does libmraa provide scheduling guarantees to ensure deterministic behaviour and timely response events and interrupts?
No (with the relatively minor exception of this SCHED_RR API).
And it does so rightfully, since "Libmraa is a C/C++ library [...] to interface with the IO on Galileo, Edison & other platforms", and scheduling policy has nothing to do with that: scheduling policy is an application specific and/or system integration wide (considering other processes) design decision and setup. It is most of the time (some exceptions exist) not a wise choice to hard-code a specific sched scheme into an application without considereng other running processes, nor the sched policy mechanisms built into the kernel or not (kernel configuration choice).
It is the job of:
benchmark the system (kernel + app + other processes),
make use of standard tools (or the API they use into the app via build or runtime configuration option) and/or configure the kernel to make new sched options available,
benchmark again, rinse, repeat.
The standard tools for this are:
...and the standard API they use, such as sched_set/getaffinity, sched_set/getscheduler etc (look at the shchedutils/ source dir in the util-linux package).
As for the kernel scheduling options, look at the doc in the scheduler/ subdir. You may also look at the CPU cgroup controller, look at cgroup-v2.txt or the cgroup-v1/ subdir depending on your kernel version.
I did myself some benchmarks/tests for an embedded product using these alternatives, and finally decided to go with CPU shares from the CPU cgroup controller, because they were the "smartest self-adapting" and flexible load balancing mechanism for my case (mix of realtime vs non-realtime yet important for the product functionality vs low prio tasks such as logging). I did not considered/tested the cgroups cpuset, making not much sense for a dual-core embedded system, nor the period/quota setups.
Of course, one may use a mix of above mentioned techniques.
Is libmraa just a tool for hobbyists or a good to for a real embedded system?
Again, no experience with it. Though, some experience with Intel open source (from their e10000 Ethernet drivers), and as for me Intel is serious and does not throw away some sources in the wild and then forget about it. Even for a very "prototypesque" project.
For mraa, looking at github, there's minimal wiki, and a issue tracking showing some issues are indeed fixed.
So I would be inclined to trust it "for a real embedded system". The community may be small though, which is not a negligible factor.
PS:
The most important thing in all that is: benchmark, benchmark, benchmark...
EDIT:
And as for the "real RTOS" vs Linux:
I have some experience with that too, and though yes, technically this would be the rational choice for the application you describe, it only is if you have time (= money) and/or missing a deadline may led to catastrophic event such as hurting/killing someone or destroy something (including your own hardware, ex drone falling) or plain failing at doing its mission-critical job. Think defense, aerospace, health/medical equipment.
The development cycle of Linux (code -> build -> flash/install -> debug, repeat) vs a real-time OS will be faster with Linux (you can prototype a lot of things on your PC without any hardware yet), the ecosystem of libs/apps will be richer, the community will be wider, lesser special technical training required, tons of doc for everything etc = faster time to market and rich functionalities.
If the case of "no catastrophic event" considered, going to a real embedded RT OS is more a question of BOM (Bill Of Material: less flash/RAM/CPU power) or sometime legal liability regarding the product reliability.
And hard real-time with Linux is possible (not necessarily in the userland), as @LPs answer point out.