RTuinOS: A Real Time Operating System (RTOS) for Arduino 1.0.1

[ireland94]

Peter,
Reading your last post has saddened me - no current support for 32 bit architecture.
I was happy to see that you added semaphore elements as that is essential for inter-process (think thread) communications.
The Arduino DUE is the processor of my choice mainly due to (1) higher speed, (2) larger available memory, (3) more digital pins.
Having to wait for the Arduino world to catch up to Linux level of threading brings tears to my eyes.
I can get Linux already on the Beagle Bone, but the I/O pins structure is much more restrictive.
Oh for a Linux on the DUE, the the world would happier for me.
Of course the Linux DUE will need to have 2GB of Flash in addition to 512 MB of RAM.  The flash means the OS and your program can boot without need of a kludgy micro SD card.
My candle is rapidly burning down to the point of choosing the product hardware with the compelling need of an multi-threading OS so I can implement waitless read-and-continue and write-and-continue operations.

[PeterV]

What do you think about Raspberry Pi, which seems to be even somewhat cheaper than the Due?

[vp1942]

With avr-gcc 4.7.2 in Mint 16 I get the following results:

make -s APP=tc01 build
(...)
Compiling debug code
Linking project. Ouput is redirected to bin/tc01/DEBUG/RTuinOS_tc01.map
avr-gcc: error: unrecognized command line option ‘--fatal-warnings’
avr-gcc: error: unrecognized command line option ‘--no-undefined’
avr-gcc: error: unrecognized command line option ‘--reduce-memory-overheads’
make: *** [bin/tc01/DEBUG/RTuinOS_tc01.elf] Error 1

echo $?
2

I've searched but found none, anyone knows what is going on?

[Edit] Same problem with Ubuntu 14.04

[PeterV]

Hello,

Unfortunatley I can't reproduce your problem as I have a different system (Windows, avr-gcc 4.3.2), which obviously doesn't have this problem.

A basic, general tip: Run the same build command without the -s; the actually used compiler and linker command lines will become apparent in the console output and if you compare them with the online help of these tools you might get a step ahead. Then copy the critical command line and enter them directly in the shell to see if you can reproduce the same error. If so, you can start manipulating the command line until you get the linker succeesfully run or let it at least print more meaningful messages.

If the printed error messages were literally correct all you'd to do is to remove the three options from the command line; none of them is essential. (Although it could indeed be just a matter of differences in the linker interface of our two versions, I don't really believe so. I'd rather guess that the reported problem is a subsequent fault and that you will have to find the true problem.)

Given, you've found a properly working linker command line it's straight forward to change the makefiles so that they adopt your findings. Open file makefile/compileLinkAndUpload.mk and change the definition of variable lFlags. Look for "Linking project".

And please let us know ...

Thanks,
Peter

P.S. Please note, that this topic refers to the first release of RTuinOS (0.9). Meanwhile, version 1.0 has been released. If you still work with the first release, the first thing you should do is to download, install and try the current revision. Please visit http://forum.arduino.cc/index.php?topic=184593.0 to get more information

[rjain]

The manual is great to start with. Thank you Peter.

[zaferbahar]

We want to run rtos on arduino mega with RTuinOS version -0.9.1 but we can't this.İf your suggest an application sample with a running
file. Could your send a sample to me. For doing this. BEST REGARDS.

[PeterV]

Runnable application samples are already available. The distribution of RTuinOS contains a number of such samples, starting from most simple to becoming more complex. The first thing you should do - prior to writing any line of code yourself - is to make these samples run. Only then you can have the needed confidence in your environment and configuration. The samples are held in the folders tc<nn> and how to compile and make them run is described in the manual.

Why do you want to work with the elder revision 0.9 of RTuinOS? I don't see any reason not to use the 1.0. Besides the functional completion of the system it came along with a strongly improved makefile, which will make initial operation of the samples easier.

[zdaijie]

Hi Peter,

Recently, I am studying the code of RTuinOS1.02, but I have a question of the code.

when I read the "RTuinOS- A Real Time Operating System for Arduino -Version 1.0 User Guide" and code annotation, I know "If mutexes or semaphores are in use suspend list is sorted with decreasing priority"(2057 line of rtos.c). But in the function 'rtos_initRTOS' of RTuinOS1.02, your code is like this :
       "              #if RTOS_USE_MUTEX == RTOS_FEATURE_OFF
                    _pSuspendedTaskAry[idxTask] = pT; // is not sorted
                      #else
                     .........// insert pT into _pSuspendedTaskAry list with decreasing priority
        "
in addition, I found the codes in function "waitforEvent" (1535 line of rtos.c) :
"
  #if RTOS_USE_SEMAPHORE == RTOS_FEATURE_ON  ||  RTOS_USE_MUTEX == RTOS_FEATURE_ON
 
           int8_t idxPos;
          for(idxPos=0; idxPos<_noSuspendedTasks; ++idxPos)
                  if(_pSuspendedTaskAry[idxPos]->prioClass < prio)
                         break;
           for(idxTask=_noSuspendedTasks++ - 1; idxTask>=idxPos; --idxTask)
                   _pSuspendedTaskAry[idxTask+1] = _pSuspendedTaskAry[idxTask];
           _pSuspendedTaskAry[idxPos] = pT;
#else
          _pSuspendedTaskAry[_noSuspendedTasks++] = pT;
#endif

"
 So , I think there is a bug in function 'rtos_initRTOS': the code "#if RTOS_USE_MUTEX == RTOS_FEATURE_OFF" is wrong ,it should be changed as " #if RTOS_USE_SEMAPHORE == RTOS_FEATURE_OFF  &&   RTOS_USE_MUTEX == RTOS_FEATURE_OFF"

Am I right?

Looking forward to your reply!



Best wishes to you!

Daijie

[zdaijie]

Hi,

I have received the letter from Peter.

Peter has confirmed that my analysis about the bug of 'rtos_initRTOS' function is right----" Initial acquisition of a semaphore would disregard the task priority. The earlier initialized task would get it not the one of highest priority. "

For Now, anybody can follow my explanations in #22 and fix your copy of the code.

Finally, I am very happy that I can contribute to the work of RTuinOS1.0.2.

Thanks Peter's answer.

Daijie