RTOS for PIC32 in mP

[Dany]

Bad news: things work only well if I keep the delay (in the example delay_us()...) at the end of a task under the 5 millisecs. If I make it bigger in one of the tasks then the other task is not any longer serviced (switched to) every 5 millisecs but as it seems irregurarly at a much longer time interval.
I do expect that "delays" hardcoded like this take 2 times longer than specified because the tasks (including their delays) are run only 50% of the time, but this is not what happens at all.

So, something is completely wrong, and I can not find (or think of) a reason.

Someone any ideas? Thanks in advance.

Example: (Task1 changed with respect to the first post):

Code: Select all

procedure Task1;
var Count: byte;
    Str: string[10];
begin
  Count := 0;
  while true do
  begin

    STAT_LED := not STAT_LED;
    LATE.0 := STAT_LED;

    bytetoStr(Count, Str);
    Uart2_write_text(Str + #13 + #10);
    inc(Count);

    delay_ms(500);
  end;
end;

Procedure Task2;
begin
  while true do
  begin
    DATA_LED := not DATA_LED;
    LATE.1 := DATA_LED;
    delay_us(500);
  end;
end;

Task1 works fine (including the local variable usage), but task2 rarely gets executed...

p.s. In the mean time I do also save the coprocessor's status (12, 0) for each task...

[rmteo]

Exactly what are you trying to achieve? All of this has already been done (with open sources even) as I have shown in the links above. You are far from achieving anything close to resembling an RTOS. I hope you realize that this is a major undertaking (even more so than creating an IDE/compiler, IMO).

[Dany]

Hi, things work as expected when I use a different register for the "delay" in both tasks, e.g. by changing task1 in:

Code: Select all

procedure Task1;
var Count: byte;
    Str: string[10];
begin
  Count := 0;
  while true do
  begin

    STAT_LED := not STAT_LED;
    LATE.0 := STAT_LED;

    bytetoStr(Count, Str);
    Uart2_write_text(Str + #13 + #10);
    inc(Count);

    //delay_ms(500);
    asm
      LUI	R10, 203
      ORI	R10, R10, 29524
      L__Task16_: //
      ADDIU R10, R10, -1
      BNE	R10, R0, L__Task16_
      NOP
    end;
  end;
end;

Now R10 is used for the delay in stead of R24 (which is still used in the delay of task2)...
So, something is wrong in saving/restoring the context of each task...

[Dany]

Problem solved: I used priority 7 for my interrupt, which always uses the shadow register set (no matter what the interrupt header looks like), so the registervalues I saved where those of the shadow registers, not those of the actual ones.

I use now to interrupt level 6, which required a change in the Timer1 init routine, and in the interrupt procedure header.

The new code (in which task1 shows a counter on Uart2):

Interrupt_Context_Saving.zip

(2.31 KiB) Downloaded 150 times

[rmteo]

A pre-emptive RTOS is one where a ready-to-run, higher priority task will pre-empt (switch out - context switch) the currently running task. Compare this to a co-operative RTOS where the currently running task has to voluntarily relinquish control before any other task can run. Huge difference. In both cases, a user interrupt can cause a context switch.

Ha, now I think I understand what pre-emptive means. Earlier I tought it was only "task switching under interrupt" every xx ms and no special things done besides selecting another task.
Thanks!

CRTOS.jpg (54.1 KiB) Viewed 7205 times

PRTOS.jpg (23.42 KiB) Viewed 7205 times

[Dany]

Hi rmteo, thanks for the nice documentation/example of how cooperative and pre-emptive systems differ.

[Dany]

Hi, I got a lot further this time (but still only a basic featured RTOS).
See the attached test project and RTOS library zipfile.

The implemented features are:
- Feature presence is defined in "CRTOS_Defines.pld".
- The sizes used (e.g. max number of tasks or events) are defined in "CRTOS_Sizes.inc".

- Delays in tasks performed by the RTOS (using OS_Delay in stead of delay_ms), giving other tasks the possibility to execute during that waiting time.
- Binary and Counting semaphores, with or without timeout.
- Starting, stopping and replacing (stop current task, start another one) tasks.
- Signalling semaphores both from interrupts and the main thread.
- Task priorities (priority 0 being the highest one)

- Tasks are executed in the main thread, not in an interrupt routine.
- The RTOS timebase is timer 1, using interrupt priority 6 (to prevent the usage of the shadow register set), currently set at 1 millisecs. So, all timed activities have a resolution of 1 ms.
- The max task execution time is 10 ms. This is the longest time a task will be executed, after that another task (or the same) will be chosen for execution. If a task is pre-empted by another one the execution time will be shorter of course.
- Pre-empting (if a task with a higher priority than the current one executed becomes eligible then it gets executed first)
- Tasks with the same priority are executed in a "round Robin" (sequential with wrap around) manner.

Still to do:
- adding the idle task.
- documentation
- perhaps a system stack (now all tasks have their own stack)
- stack overfow detection

Your comments/questions/suggestions will be appreciated! Thanks in advance.

A new version (2015-07-25) has been attached:

https://libstock.mikroe.com/projects/vi ... -for-pic32

[Dany]

Exactly what are you trying to achieve?

An RTOS for mP/mB for PIC32 users.

All of this has already been done (with open sources even) as I have shown in the links above.

Yes, I know, but (last time I checked anyway) there is not yet an RTOS that works together well with the mP/mB for PIC32 compiler (and also not with the mC for PIC32 compiler I think).
Every existing RTOS is written in C, with the usage of macro's etc, so not usable in mP/mB.

You are far from achieving anything close to resembling an RTOS. I hope you realize that this is a major undertaking (even more so than creating an IDE/compiler, IMO).

I know this is a major undertaking, I wanted only to see what possibilities there are for mP for PIC32 users. So far I think I have proven it is feasible (see the previous post).

Thanks for your interest/contributions rmteo!

A new version (2015-07-25) of the library and the testfile have been attached to the post above.
Please feel free to give comments and suggestions. Thanks in advance!

http://www.rosseeld.be/DRO/PIC/RTOS_PIC32.pdf

[Dany]

Hi,

The 'final' version is published on Libstock now: http://www.libstock.com/projects/view/1 ... -for-pic32.

Added are:
- stack creation using the "memory manger" library from mE
- the idle procedure (optional)
- measuring stack usage (optional)
- the documentation (help file)

Comments and suggestions are more than wellcome! Thanks in advance!

https://libstock.mikroe.com/projects/vi ... -for-pic32

[Dany]

No comments? I was under the impression that an RTOS was needed badly...

Of course it is not written in mC, but translation should be not so difficult.

In my personal opinion: an actual pre-emptive RTOS (with respect to a cooperative CRTOS) is a bit/lot overrated.
It has (again in my opinion) little advantages and is much more difficult to use due to the fact that routines called from within threads must be thread-safe, or surrounded with critical section statements.
Since every routine can be interrupted to switch tasks (if not in a critical section), also e.g. routines which drive the SD/MMC card or I2c, debugging and testing can become tedious...

So, my questions/remarks are:
- is there some interest in this library (should I make also as basic version?)?
- could you give comments on my opinion stated above?
- which routines in the mP Pic32 libraries from mE are not thread safe? Does anyone know?
- Some observation: One if the big issues with this type of libraries (RTOS, CRTOS) that give some possibility of multi threading is that fact that the compiler can "spoil" routines that perform task switching and context saving/restoring in the library by e.g. manipulating the taskpointer after saving it, while it was assumed to hold its initial value. At the end of the routine the stackpointer is restored, but it is not pointing to the stack of the newly selected task... I do not know if mP is more difficult than e.g. mC in this respect (or MPLab).

Thanks in advance!

https://libstock.mikroe.com/projects/vi ... -for-pic32

[rmteo]

No comments? I was under the impression that an RTOS was needed badly...

Of course it is not written in mC, but translation should be not so difficult.

In my personal opinion: an actual pre-emptive RTOS (with respect to a cooperative CRTOS) is a bit/lot overrated.

Simple. You are not addressing the correct audience.

1. RTOS needed badly. Professional/commercial developers use an RTOS due to the nature of applications they develop (performing multiple functions concurrently). This site is used almost exclusively by hobbyists and students/learners doing simple (single function) stuff that do not require an RTOS. I doubt if they even understand the concept or need for an RTOS.

2. In the embedded industry, C is the overwhelming language of choice with nearly 90% market share (BASIC, ADA, ASM and others make up the rest). Pascal (and others like Oberon) won't ever make it. Why? Because the validation/test tools (and industry guidelines) required for certification of mission/safety/security critical products all assume software is written in C (eg, look into MISRA-C 2004 for automotive applications, there is no MISRA-Pascal or MISRA-ASM).

3. Regarding co-operative/pre-emptive, many real applications require the deterministic characteristics that only a only pre-emptive RTOS can offer.

4. PIC32. This is an oddball in an industry totally dominated by ARM based MCUs. Every major manufacturer of MCUs (including those who have proprietary core architectures such as ATMEL and the world's largest MCU maker, RENESAS) except MCHP has joined the ARM bandwagon. I would be very surprised if today, PIC32s accounted for 1% of the 32-bit MCU market.

[Dany]

No comments? I was under the impression that an RTOS was needed badly...

Of course it is not written in mC, but translation should be not so difficult.

In my personal opinion: an actual pre-emptive RTOS (with respect to a cooperative CRTOS) is a bit/lot overrated.

Simple. You are not addressing the correct audience.

1. RTOS needed badly. Professional/commercial developers use an RTOS due to the nature of applications they develop (performing multiple functions concurrently). This site is used almost exclusively by hobbyists and students/learners doing simple (single function) stuff that do not require an RTOS. I doubt if they even understand the concept or need for an RTOS.

2. In the embedded industry, C is the overwhelming language of choice with nearly 90% market share (BASIC, ADA, ASM and others make up the rest). Pascal (and others like Oberon) won't ever make it. Why? Because the validation/test tools (and industry guidelines) required for certification of mission/safety/security critical products all assume software is written in C (eg, look into MISRA-C 2004 for automotive applications, there is no MISRA-Pascal or MISRA-ASM).

3. Regarding co-operative/pre-emptive, many real applications require the deterministic characteristics that only a only pre-emptive RTOS can offer.

4. PIC32. This is an oddball in an industry totally dominated by ARM based MCUs. Every major manufacturer of MCUs (including those who have proprietary core architectures such as ATMEL and the world's largest MCU maker, RENESAS) except MCHP has joined the ARM bandwagon. I would be very surprised if today, PIC32s accounted for 1% of the 32-bit MCU market.

Thanks for the elucidation!

https://libstock.mikroe.com/projects/vi ... -for-pic32

[rmteo]

You are welcome. Hopefully others will chime in and add some life to this topic.

[ilferrari]

I hope you realize that this is a major undertaking (even more so than creating an IDE/compiler, IMO).

FreeRTOS compiles to a few KB of ROM. It can't be that complex to switch a few tasks on an MCU.