DSP libraries, interrupts, and a RTOS

Author
kas219
New Member
  • Total Posts : 3
  • Reward points : 0
  • Joined: 2010/02/09 09:01:56
  • Location: 0
  • Status: offline
2010/02/15 11:52:00 (permalink)
0

DSP libraries, interrupts, and a RTOS

I am currently using FreeRTOS on my dsPic33 but I am having problems running the DSP libraries. Roughly once a second I am am computing an FFT using the FFTComplexIP function as well as using the BitReverseComplex, and SquareMagnitudeCplx functions. Periodically the code would crash with the program counter going to 0. If I disable the interrupts before calling the FFT code and then re-enable them after, the code works perfectly. I assumed that the problem was being caused by the compiler not saving all the registers and they were being trampled. I set all of my interrupts up as follows to save the SR and CORCON register but it still didn't help:

void __attribute__((__interrupt__(__save__(SR,CORCON)), auto_psv)) _SI2C1Interrupt(void)

I have also tried to manually PUSH and POP all of the registers at the beginning and end of each ISR but still no luck. I can't even tell which ISR is causing the problems. I have added traps.c but none of them are ever hitting.

Has anyone ever used the DSP libraries in code where they will be interrupted and if so what am I missing? Unfortunately I cannot always disable the interrupts before running my FFT code.

Thanks for your help.
Keith
#1

10 Replies Related Threads

    getout
    Starting Member
    • Total Posts : 88
    • Reward points : 0
    • Joined: 2008/10/31 11:08:48
    • Location: 0
    • Status: offline
    RE: DSP libraries, interrupts, and a RTOS 2010/02/15 12:35:46 (permalink)
    0
    I have also used FreeRTOS in the past but without DSP functionality.

    So I had a look at their code and as far as I can tell, FreeRTOS does nowhere use the dsPIC MODCON register. I think this implies that FreeRTOS just is not DSP capable.

    dsPIC offers specific DSP addressing modes like Module and bit-reversed addressing. When these addressing modes are active and an interrupt occurs it can happen that the regular addressing modes used by the interrupt routine will use these DSP addressing modes since the interrupted thread has activated them. This will lead to an error.

    The only correct solution is to in the ISR save the current value of the MODCON register and change its content to disable the DSP specific addressing modes.

    In principle you can solve this yourself but you have to do this in every ISR. The problem here probably is that FreeRTOS itself also uses ISR internally and these also have to be modified.

    The problem can however be larger and beyond the scope of easily being solved. Threads get preempted by other threads. Suppose now that a thread is using DSP functionality and it is preempted. In that case the new thread also will be activated with these DSP addressing modes being active and this will lead to disaster. Solving this will however require deep kernel modifications.

    Since I can find no reference to the MODCON register in their code I assume this is the case and can conclude no different than that FreeRTOS is not DSP capable.
    #2
    QKernel
    Super Member
    • Total Posts : 220
    • Reward points : 0
    • Joined: 2008/09/23 17:09:44
    • Location: Alberta Canada
    • Status: offline
    RE: DSP libraries, interrupts, and a RTOS 2010/02/15 13:00:16 (permalink)
    0
    Our RTOS supports DSP functionality. All interrupts push/set and pop the MODCON register if you indicate that you are using the DSP. I don't think this would be difficult to implement this in FreeRTOS, you just have to find all internal ISR's and push/set and pop the MODCON register.


    Q▪Kernel The new generation RTOS
    ▪ Dual mode RTOS (PIC24, dsPIC and PIC32)
    ▪ Never disables interrupts
    ▪ Fibers, threads and lightweight threads
    Free download at www.quasarsoft.com
    #3
    getout
    Starting Member
    • Total Posts : 88
    • Reward points : 0
    • Joined: 2008/10/31 11:08:48
    • Location: 0
    • Status: offline
    RE: DSP libraries, interrupts, and a RTOS 2010/02/15 13:22:58 (permalink)
    0
    I don't think this would be difficult to implement this in FreeRTOS, you just have to find all internal ISR's and push/set and pop the MODCON register


    I think this is an oversimplification. Without knowing details about the internal structure of FreeRTOS you may not assume this is sufficient. For instance who says the internal scheduler of FreeRTOS is activated using an ISR? If this is not so, making a change like this can be quite risky.

    There are RTOSes that explicitly specify they are DSP aware and can deal with this. Besides QKernel there is AVIX and I think ThreadX is another one.

    But I would say chaning to a different RTOS is quite an undertaking so I would first have a look at the support forum of FreeRTOS to see if my assumption from my first post was correct.
    #4
    QKernel
    Super Member
    • Total Posts : 220
    • Reward points : 0
    • Joined: 2008/09/23 17:09:44
    • Location: Alberta Canada
    • Status: offline
    RE: DSP libraries, interrupts, and a RTOS 2010/02/15 14:09:45 (permalink)
    0
    But I would say chaning to a different RTOS is quite an undertaking so I would first have a look at the support forum of FreeRTOS to see if my assumption from my first post was correct.

    Good point. Maybe Richard can answer this question. My thoughts were as follow. If you do all your DSP work in one task/thread, which I think is a must because you can't save and restore the DSP-State, then you only have to handle the interrupts. But it is a good idea to look at the support forum.

    Q▪Kernel The new generation RTOS
    ▪ Dual mode RTOS (PIC24, dsPIC and PIC32)
    ▪ Never disables interrupts
    ▪ Fibers, threads and lightweight threads
    Free download at www.quasarsoft.com
    #5
    ewalker
    New Member
    • Total Posts : 25
    • Reward points : 0
    • Joined: 2009/06/05 15:39:43
    • Location: 0
    • Status: offline
    RE: DSP libraries, interrupts, and a RTOS 2010/02/22 16:24:46 (permalink)
    0
    Has any resolution been found for this issue?  I searched the FreeRTOS forums but did not find any reference to this problem there.

    I have experimented with FreeRTOS in the past on a dsPIC33 but at the time was not using any DSP libraries.  I am begining a new project that will require using several of the DSP library routines and was about to build it on top of FreeRTOS to make handling the multiple tasks easier.  Now however, I am very concerned that this issue might make FreeRTOS a show stopper. 

    I will try posting on the FreeRTOS forums about this issue as well but, I was hoping the original author, or possibly others here, may have found a solution or a work around.

    -Eric
    #6
    RichardDamon
    New Member
    • Total Posts : 2
    • Reward points : 0
    • Joined: 2009/08/26 09:56:37
    • Location: 0
    • Status: offline
    RE: DSP libraries, interrupts, and a RTOS 2010/02/22 17:54:04 (permalink)
    0
     It shouldn't be too hard to add the saving of that and the related registers (I suspect that you would need to save MODSRT/END registers too. You just need to add the Push/Pop to vPortYield in portasm_dspPic.s, and the matching pop to the portRESTORE_CONTEXT macro in port.c, and add initial values for the registers in the stack frame defined in xInitialStack in port.c

    That should be all the places that know about the stack frame used for task switching (you may need to raise the minimum stack size a bit to compinsate for the additional information on the stack).
    #7
    ewalker
    New Member
    • Total Posts : 25
    • Reward points : 0
    • Joined: 2009/06/05 15:39:43
    • Location: 0
    • Status: offline
    RE: DSP libraries, interrupts, and a RTOS 2010/02/22 18:08:52 (permalink)
    0
    Richard,

    As I said on the FreeRTOS forum, thanks for the quick reply.  I will post any progress I make on the FreeRTOS forum here.  But, as I said there, it has been several months since I played with FreeRTOS and I have not yet used the DSP functionality of the dsPIC so I am a bit hesitant to jump right in and make changes to the kernel code.  However, if nobody else has worked around this issue and can say exactly what they changed -- and that they tested it and it worked -- then I may have to tackle this myself.

    Hopefully someone here can provide some help.

    Thanks again.

    -Eric
    #8
    xiaofan
    Super Member
    • Total Posts : 6247
    • Reward points : 0
    • Joined: 2005/04/14 07:05:25
    • Location: Singapore
    • Status: offline
    RE: DSP libraries, interrupts, and a RTOS 2010/02/22 22:23:23 (permalink)
    0
    Interesting thread. I've added this to the ROTS threads collection.
    http://www.microchip.com/forums/tm.aspx?m=381449


      USB_Links and libusb
    #9
    zardoz1
    Super Member
    • Total Posts : 1852
    • Reward points : 0
    • Joined: 2005/07/09 08:03:28
    • Location: 's-Hertogenbosch, The Netherlands
    • Status: offline
    RE: DSP libraries, interrupts, and a RTOS 2010/02/22 23:45:46 (permalink)
    0
    (I suspect that you would need to save MODSRT/END registers too)


    When using an RTOS, DSP functionality typically is used from a single thread only. The reason is that dsPIC does not allow the DSP status register to be restored since this register contains a number of read only bits. You can find much information on this forum regarding this topic since it has been discussed many times before.

    This is not bad since typically DSP functionality is not spread all over your application and concentrating DSP functionality in a single thread does have its advantages. You can always model this DSP thread as a server which performs its functionality when requested to do so through a message or a similar mechanism.

    So the only register that needs to be saved/restored and manipulated as described before is MODCON.

    Of course an alternative to manipulating the core of an RTOS yourself is using an RTOS specifically developed for this processor family. With AVIX all you need to do is set a single DSP configuration flag to 1 and AVIX takes care of all the rest.



    AVIX
    the PIC32 & dsPIC/PIC24 RTOS with:
    - Zero Latency Interrupts
    - The best performance!
    - Integrated Power Management
    Download here: http://www.avix-rt.com/
    #10
    ewalker
    New Member
    • Total Posts : 25
    • Reward points : 0
    • Joined: 2009/06/05 15:39:43
    • Location: 0
    • Status: offline
    RE: DSP libraries, interrupts, and a RTOS 2010/02/23 09:15:46 (permalink)
    0
    Leon,

    Thank you for your input.  While it looks like AVIX would be a great option, this project is for graduate work (not my day job) so I do not really have a budget to support purchasing AVIX-RT.  Additionally, as this is a project in academia there is benefit to having the full source code of the entire project available and GPL licensing is not a concern since the whole project will get published in my thesis when I am done.

    I do appreciate you comments on the need to save and restore the MODCON register, as well as the point that some of the DSP status bits are read-only and so cannot be restored from a context switch.

    In my application I will probably be doing some convolution and/or filtering of data coming from the ADC at one rate and then running a PID loop at a lower rate.  I am very early in the design of this project so I am speculating a bit on what I will need to do.

    If I am limited to running all the DSP routines from one task that is probably not a significant problem.  However, I anticipate I will have DSP processing running at very different rates, the input filtering, CIC, etc., the I & Q processing, the PID loop, etc.  At this stage I would think it might be easier to separate these in to more than one task if possible.  If what you say about the status bits is correct, this may never be possible.

    Unfortunately I am not up to speed enough right now to add much original input to this discussion. I just started reading through the Programmer’s Reference Manual last night to try to better understand the special addressing modes of the DSP class instructions and how those might be affected by context switches or even interrupts. I will also have to study the FreeRTOS code to understand what it is doing on context switches.

    Again, thanks for your input and suggestions on this issue.

    -Eric

    #11
    Jump to:
    © 2017 APG vNext Commercial Version 4.5