0

OK, this might be a very general question but I'm not to familiar with the topic and happy for any hint.

I have a Cross Compiling tool chain from SoucereyCodeBench for ARM ( arm-xilinx-linux-gnueabi-). I cross compiled a library which uses the compiler Options: -DSC_INCLUDE_FX -DSC_USE_PTHREADS -pthreads -fPIC -DPIC

So if I want to use the libary for bare metal program I would need pthreads for the bare metal compiler (arm-xilinx-eabi-) I guess?

Otherwise my program probally wouldn't run or compile in the first place. So could it be done to compile pthreads for bare metal?

Clifford
  • 88,407
  • 13
  • 85
  • 165
eactor
  • 862
  • 3
  • 14
  • 34
  • 3
    Who is going to manage the *threads* on a **bare-metal** project? Basically, you need an OS to do this, and then you don't have **bare-metal** project anymore. – artless noise Jun 13 '13 at 16:06
  • 1
    You may be interested in [Threading using setjmp()/longjmp()](http://stackoverflow.com/questions/2560792/multitasking-using-setjmp-longjmp), but this is **not** *pthreads*. You could do some limited multi-tasking or threading this way; generally known as user-space threading. However, if you expect full blown *pthreads*, then you might as well have an OS. In a bare metal *context*, *user-space threading* is a primitive OS. – artless noise Jun 13 '13 at 22:48
  • I tried an 8MB busy box from ram, but it contains some processes interrupting my applicatin so it hangs ervery 2 secounds. I couln't figure out wich and changed run priority with nice and closed all processes beside the kernel with no luck. – eactor Jun 14 '13 at 09:19
  • If you have busybox (the lightweight shell suite), I'd expect you are running linux and have pthread support. So why are you calling this bare metal development? Or explain what other thing you mean by "BusyBox" – Chris Stratton Jun 14 '13 at 15:24
  • The hanging is the reason why I want to switch to bare metal. – eactor Jun 17 '13 at 18:29

2 Answers2

5

Threads and Bare Metal

Bare metal programming targets only provide what you put on them. The pthread implementation most folks are familiar with is the Linux NPTL version, which works because the Linux kernel and the GNU C library make it work. On bare metal targets, you don't get the benefit of either the Linux kernel or the GNU C library. You'll have to bring your own bare metal thread library and runtime but at that point you may be better off using an RTOS that provides threads.

A Note on Toolchain Prefixes

The gcc toolchain prefix, arm-xilinx-linux-gnueabi-, indicates the target as ARM Linux, not bare-metal. The arm-xilinx-linux-gnueabi- toolchain will build pthread aware code (-lpthread) but it will assume that the Linux target has the pthread library and other necessary software layers already installed.

If instead you switch to the bare-metal version of the gcc ARM xilinx toolchain, your toolchain prefix will be arm-xilinx-eabi-. Everything I said above about bare metal and threads will apply.

Chris Stratton
  • 39,853
  • 6
  • 84
  • 117
Ricardo Anguiano
  • 111
  • 3
4

I think it will be a matetr of porting your code rather than simply cross-compiling it unchanged. As its name suggests POSIX threads (pthreads) assumes a POSIX API.

If you need threads on a bare metal ARM target, the you at least need some sort of thread scheduling libraries of which there are many. Most RTOSs are not full OSs in the sense of Linux, but rather simple schedulers with IPC mechanisms that link as static libraries like any other to your monolithic application - that probably still counts as "bare metal" in the sense that the system boots directly to your main() function where you are responsible for creating tasks/threads and starting the scheduler.

Some RTOSs support POSIX APIs and therefore pthreads, but these tend to be the larger more complete OSs rather than simple schedulers - either way they are generally smaller and more scalable then Linux so may meet yout "bare metal" requirements nonetheless.

Of course nothing stops you from creating a wrapper around any RTOS library to provide a pthread compatible API that might make porting your code simpler.

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • If I would use an RTOS like FreeRTOS for Zynq AMP, would I have to make changes to my programm/libs which right now work fine under a 8MB BusyBox in RAM – eactor Jun 14 '13 at 09:21
  • @eactor: As I pointed out the API will not be the same, but that can largely be dealt with through a porting layer, and the scheduling algorithm is different in an RTOS too which may affect things, but it sounds like scheduling is already an issue - you have much grater control over that with an RTOS. Other than that, without sight of the code how can I tell you what problems you will encounter? – Clifford Jun 14 '13 at 12:43
  • @eactor: You might be better off with an RTOS that already supports POSIX APIs such [NuttX](http://nuttx.org/). There are others, but most are commercially licensed NuttX; is BSD. – Clifford Jun 14 '13 at 12:49