As an instructional task to understand a fairly complex C control-software tree, I’m modifying a flight simulator (autonomous underwater glider) to run on an ubuntu 20.04 laptop. The current simulator that I’m starting from is configured to run on a stm32L4xx board, and has the commercially licensed OpenRTOS running along with a Wittenstein CONNECT FAT-16/FAT-32 filesystem. The build I’m working on will remove any linking to stm32 and Wittenstein fs source or drivers. The build is executed via recursion make; I’ve modified a litany of makefiles and helper *.mk files, and have the following steps mapped to construct the build:
Customize drivers to work with FreeRTOS-linux architecture, modify gpio and uarts to accept real and simulated inputs.
Client-side simulation with a pty terminal such as posix-openpt, pts, etc. Use the drivers to replace the Hardware Abstaction Layer (HAL) with linux read/write calls.
Having done some embedded work on a beaglebone black, I understand much of the pieces-parts; I’m interested in any tips or guidance from a relative beginner-level understanding of how to bring together this kind of build. The simulator source is significantly more complex than what I’ve previously worked with.
Are you using the FreeRTOS Linux port? If so, note it may not be possible to run IO functions that make Linux system calls as that can cause Linux to suspend threads that FreeRTOS thinks are still executing.
Thanks Richard, that is correct; I am starting with the Linux port; I’ve read up a bit about the potential for issues with underlying Linux functions. I’ll attempt to work around this.
One way to solve this issue is by disabling signal on a thread and make linux system calls.
please check the bottom of the linux port guide.
The thread making the Linux system calls should not be part of FreeRTOS and not be scheduled by it.
Thanks, are you referring to the “port layer design description” and other content at the bottom of the simulator for Linux doc page? Embedded C for microcontroller programming is a new domain for me.
to be more specific, any thread created to simulate a hardware device (network, uart, linux read/write calls…) that sends interrupts to your own normal implementation, needs to be in a new thread (pthread_create), and everything created with calling pthread_create directly needs its signals blocked, from those threads, you can call any Linux calls (libC or system directly).
@gedeonag ,
I was able to progress significantly with your advice; however, I’ve run into compiling issues for linux kernel header files. I am building with kernel headers for 5.11.0-27. I’ve run into a number of unknown type name errors in the system-level header files for stdio.h, and others. There are many versions of stdio.h in the kernel headers, and the source tree for the simulator. Other than ascertaining whether I have the correct dependencies included, I’m not sure how to resolve errors at the kernel development level; there isn’t much content to provide guidance on the typical channels (stackexchange, etc). Do you have any suggestions for further troubleshooting on this. An example of the errors is pasted below.
/usr/include/sys/cdefs.h:174:46: note: in definition of macro ‘__REDIRECT’
define __REDIRECT(name, proto, alias) name proto asm (__ASMNAME (#alias))
^~~~~
/usr/include/stdio.h:462:8: error: unknown type name ‘__gnuc_va_list’; did you mean ‘__isoc_va_list’?
__gnuc_va_list __arg), __isoc99_vsscanf)
^~~~~~~~~~~~~~
/usr/include/sys/cdefs.h:182:11: note: in definition of macro ‘__REDIRECT_NTH’
name proto asm (__ASMNAME (#alias)) __THROW
^~~~~
In file included from …/src/IRQ-handlers.c:18:
/usr/include/stdio.h:831:8: error: unknown type name ‘__gnuc_va_list’; did you mean ‘__isoc_va_list’?
__gnuc_va_list __args)
^~~~~~~~~~~~~~
__isoc_va_list
In file included from /usr/include/stdio.h:864,
from …/src/IRQ-handlers.c:18:
/usr/include/bits/stdio.h:39:40: error: unknown type name ‘__gnuc_va_list’; did you mean ‘__isoc_va_list’?
vprintf (const char *__restrict __fmt, __gnuc_va_list __arg)
^~~~~~~~~~~~~~
__isoc_va_list
NP!, I am not sure about the exact error you are having.
but it looks like you are trying to include the C standard library headers in kernel build, which is not a good idea.
add the following to your gcc command and see what happens
You are correct, I had set an #include <stdlib.h> in my threading script, because the compiler was throwing errors for size_t, and apparently not finding the correct version of stddef.h. The -nostdlib option was already set.