Hi everyone,
I'm trying to use unistd library in my project, but when compiling it I get the following error:
POSIX\pthread.c(27): error: #5: cannot open source input file "unistd.h": No such file or directory
I'm working with a STM32F103ZE (Cortex-M3) on uVision 4.72.1.0 on Windows 7. I was using microlib but, from my googling results, I found out that some libraries might be missing. Hence, I unmarked this option of my project's configuration.
Thanks for the help!!
But do you feel that MDK-ARM supplies you with a unix system?
Are you sure that your software design is suitable for embedded use?
First Question: I am quite new to embedded systems, but I would guess that no. Threads seems to be a very costly. Second Question: On the other hand, I am not creating an application but evaluating a board. For that reason I don't think it should be a problem to use them.
Is there any way to do that with uVision?
Your MDK-ARM installation comes with a RTOS - an OS specifically intended for software expected with real-time requirements to different events.
But it doesn't behave like any pthreads implementation.
You can use any other RTOS you can find too, if they either supply source code that is possible to compile with the MDK-ARM compiler, or supplies ready-to-use binaries + header files.
But an RTOS written for an embedded platform normally have a quite different architecture than a pthreads-capable platform, because there are normally a need to consume much less resources while responding much quicker.
You may have threads in an RTOS that have maybe 50-100 bytes of stack, while a normal pthreads platform might assume 4MB of virtual memory as default size for each thread. But then you might also have situations where the RTOS can do task switches in response to events on a time scale of a few us or sometimes a fraction of an us.
Another thing is that you normally doesn't have access to multiple processing units - no hyperthreading multi-core processors - which means that something always has to lose the CPU when something else desperately quickly needs access to it. So not just time slice switching and nice "let's wait and donate time until somethings happens", but an individual interrupt handler may signal the need for an instant task switch.
This obviously means that you really have to look at your software design and make sure it is well matched to the limitations of your embedded platform.