adding dspic porting

[ashrafkamel5]

Hi MR Miro,

We had a discussion on youtube earlier about the ability to port SST to non ARM Cortex-M based MCUs.

here is my contribution to port it successfully on dspic33ep128gs804 MCU

a screenshot of the successful run.

It is based on commit V2.2.1. I just noticed V3 now, so locking is not included yet.

It is the same example blinkybutton. the only difference is the active object pointer isn't const ex: old SST_Task * const AO_Button2b = &Button2b_inst.super; /* opaque AO pointer */ new SST_Task * AO_Button2b = &Button2b_inst.super; /* opaque AO pointer */

for some reason, the XC16 compiler saved the obj itself in Flash not only the pointer. I am sure that can be looked up later.

and I lowered the BSP_TICKS_PER_SEC from 1000 to 20 because this MCU doesn't have an FPU and I ran it on the internal RC oscillator "7.37Mhz -> 3.6 MIPS". I can configure it for a faster clock using PLL.

but a SUCCESSFUL porting is done :]

[quantum-leaps]

Hi Ashraf, Your SST port to dsPIC looks interesting.

I didn't realize that dsPIC has such a powerful interrupt controller that also supports interrupt nesting and prioritization.

I understand that you did your port against an older SST version. To make my life easier in merging your PR, could you perhaps make your PR against the most recent version? This would be very helfpul.

for some reason, the XC16 compiler saved the obj itself in Flash not only the pointer. I am sure that can be looked up later.

This sounds a bit weird and disturbing. (An active object changes its internal data, such as the current state, event queue, etc., so it definitely needs to be in RAM). Could you check what's going on? This needs to be done before merging your PR. I hope this makes sense to you.

--MMS

[ashrafkamel5]

This sounds a bit weird and disturbing. (An active object changes its internal data, such as the current state, event queue, etc., so it definitely needs to be in RAM). Could you check what's going on?

I know that it has to be in RAM that's why I removed the const from the AO pointer. and that solved it till now.

can we post this to its own branch other than the main one for now? till I look up the locking mechanism. "I am not so comfortable with PR and I don't know how to add another commit to the same PR"

I didn't realize that dsPIC has such a powerful interrupt controller that also supports interrupt nesting and prioritization.

I belive that SST is great and is applicable to a much wider range of MCUs than ARM 😄

[quantum-leaps]

Hi Ashraf,

can we post this to its own branch other than the main one for now?

We could do this, but this is unfinished business and your contribution on a side branch will likely get overlooked and possibly lost.

"I am not so comfortable with PR and I don't know how to add another commit to the same PR"

I would just cancel this old PR against the old SST version and create another PR against the latest SST 2.3.0. This would be a great help.

Otherwise, I have to do the merging, which I'm not comfortable doing because I don't have your dsPIC hardware to test the stuff. Also, if I do the merging on the main branch, your name would not be included in the "Contributors" list of the project.

I hope that my comments make sense, --MMS

[ashrafkamel5]

Got it I will get back to it today Insha'Allah.

[ashrafkamel5]

Hi Mr. Mero,

Please give me a brief on the locking mechanism, SRP or the ARM assembly commands at the code. I am trying, but I feel lost in the resources in the readme file.

[quantum-leaps]

Hi Ashraf, The use of the SST task locking mechanism is illustrated in the "blinky_button" example, in the file blinky1.c:

static void Blinky1_dispatch(Blinky1 * const me, SST_Evt const * const e) {
    switch (e->sig) {
        case TIMEOUT_SIG: {
            for (uint16_t i = me->toggles; i > 0U; --i) {
                /* just to exercise SST task scheduler lock... */
                SST_LockKey key = SST_Task_lock(3U);
                BSP_d5on();
                BSP_d5off();
                SST_Task_unlock(key);
            }
            break;
        }
    . . .

For now, you can define the SST_Task_lock()/SST_task_unlock() functions as empty in your dsPIC port. This is just to merge the port with the latest SST.

BTW, the task locking is the biggest part of SRP, if you read the paper.

--MMS

[ashrafkamel5]

For now, you can define the SST_Task_lock()/SST_task_unlock() functions as empty in your dsPIC port. This is just to merge the port with the latest SST.

I would like to try to implement it first! 🤕

BTW, the task locking is the biggest part of SRP, if you read the paper.

To be honest, the size of the paper got the best of me.

so I am trying other resources now -CRECT https://www.youtube.com/watch?v=GMWrw5NkipQ

the code porting for ARM looks simple, but I don't get what is the key returned and what is the value of 3 that is passed in the example, and how would I mimic them.

I will try, if I had difficulty I will make the empty functions.

Many thanks

[quantum-leaps]

Hi Ashraf, The scheduler locking/unlocking is implemented in SST in the very standard way of changing some settings and preserving the original value, which is then restored. The main advantage is the ability to nest such locks. The same algorithm is often used for locking interrupts, etc. For example, you can recognize the same pattern in the way spinlocks are implemented in the Zephyr RTOS.

The SST_LockKey type is defined in the SST port and represents the current setting of the scheduler lock. The SST_Task_lock() function first obtains the current value of the scheduler lock and then locks the scheduler. The original value is returned. The SST_Task_unlock() function simply restores the original scheduler lock settings.

Finally, regarding the crect video, it's probably faster to just read the original SRP paper. The crect project muddies the water by trying to hide the simple concepts behind clever C++ template magic.

[ashrafkamel5]

Success!!

I made the lock on the for loop of blinky1

SST_LockKey key = SST_Task_lock(3U);
            for (uint16_t i = me->toggles; i > 0U; --i) {
                /* just to exercise SST task scheduler lock... */
                BSP_d5on();
                BSP_d5off();
            }
            SST_Task_unlock(key);
            break;

and it worked as expected and delayed the higher-priority task 'blinky3' :D :D

[ashrafkamel5]

I have a question about SST_Task_lock in arm porting file

    uint32_t nvic_prio = ((0xFFU >> nvic_prio_shift) + 1U - ceiling)
                         << nvic_prio_shift;
    SST_LockKey basepri_;
    __asm volatile ("mrs %0,BASEPRI" : "=r" (basepri_) :: );
    if (basepri_ > nvic_prio) { /* current priority lower than the ceiling? */
        __asm volatile ("cpsid i\n msr BASEPRI,%0\n cpsie i"
                        :: "r" (nvic_prio) : );
    }
    else {
        basepri_ = nvic_prio;
    }
    return basepri_;
#endif
}

shouldn't the else here be empty? now the unlock would lower the base priority and it shouldn't.

I don't get this part and I made the elseempty in my porting.

I hope to hear from you.

Many thanks

[quantum-leaps]

Good point about the superfluous else branch in SST_Task_lock() for Cortex-M. The ARM code has been fixed and the dsPIC pull request has been merged in. The new SST 2.3.2 release has been made. Thanks a lot! --MMS