I am interested in embedded programming with rust.
As one knows so-called real-time property is one of the main concerns for product-grade programming.
"hard real-time" could not be achieved without dedicated HW. (Even if one manages to preclude context switching by manipulating the scheduler of OS, branch prediction and cache memory will produce uncertainty regarding processing time at the HW level).
Although these relatively small jitters from HW could not be eliminated, It. is quite clear that system calls are one of the major sources of uncertainty.
So, I figured out marker traits for functions indicating no system call or memory allocation. It would help to accept certain kinds of functions in a time-critical context like Fn, FnMut, FnOnce.
I would like to know if there is any apparent reason which makes the approach infeasible before I conduct a further study regarding this concept.
Thank you for the recommendation. Indeed the FP is the way I am trying to solve the side-effect issue for logic level(I would say). #![no_std] is interesting for OS level approach.
Please let me know if anyone knows any other prior arts or discussions or keywords related with OS level approach regarding the real-time uncertainty issue.
One thing I'd like to point out is that C doesn't have any sort of marker for functions that don't allocate or make system calls, yet we've been writing hard real-time applications in C for 40+ years.
Yes, you are right. C would be sufficient for real-time programming, if handled by experienced SW engineer. However, wouldn't you think it relies heavily on programmer rather than systemic support?. As Rust solve memory management issue of C++, wouldn't it be helpful for less experienced SW engineers and large scale projects?