PIC 16-bit port

dragonflight1 wrote on Friday, February 06, 2015:

In upgrading to V8, in general (7.5.3 has been running quite nicely for me :)) and my own PIC port, I’ve come across/pondered the following issues

  1. The PIC24E series requires 1 instruction after writing to SR before interrupts are actually disabled.
    This probably is not a problem (it wasn’t in 7.5.3) in V8.2, but a nop should be added to portDISABLE_INTERRUPTS()
  • The following all relate to saving/restoring stuff in _T1Interrupt and depend on how “always correct” it should be.
    • The DC flag is not saved/restored in _T1Interrupt.
      This is probably in the technically correct, but who cares category
    • In the non-DSP PICs the PSV flag (in CORCON) is not saved/restored
      I could not find any example of Microchip bothering to save/set this in any examples
    • In the dsPICs the PSV flag (in CORCON) and MODCON are not saved/restored
      If the DSP instructions are actually used MODCON needs to be saved restored and if the functions in libdsp are called then the PSV flag needs to be saved/restored and set to 1 in the interrupt

mike

rtel wrote on Friday, February 06, 2015:

Thank you for your comments:

The PIC24E series requires 1 instruction after writing to SR before interrupts are actually disabled.

To ensure correctness I have added an __asm volatile( “NOP” ) after the write to the SR.

The following all relate to saving/restoring stuff in _T1Interrupt and depend on how “always correct” it should be.
The DC flag is not saved/restored in _T1Interrupt.
This is probably in the technically correct, but who cares category

Let me know if you think it is an issue.

In the non-DSP PICs the PSV flag (in CORCON) is not saved/restored
I could not find any example of Microchip bothering to save/set this in any examples

I think this was discussed some years ago (the PIC24 ports are quite old now) and it was decided to leave it like this. I can’t quite remember the rationale now, but it will be in the archive somewhere.

In the dsPICs the PSV flag (in CORCON) and MODCON are not saved/restored
If the DSP instructions are actually used MODCON needs to be saved restored and if the functions in libdsp are called then the PSV flag needs to be saved/restored and set to 1 in the interrupt

Likewise I think these were discussed at the same time regarding how far to go in making the DSP functionality thread safe. I will need to look up the discussion and re-familiarise myself with the architecture to comment fully.

Regards.

dragonflight1 wrote on Friday, February 06, 2015:

None of the interrupt issues are a question of thread safe, but rather a question of if the user creates code that changes/uses DC, PSV, MODCON then timer1 will either fail or corrupt the program.

In reverse order, for the dsp’s, if PSV and MODCON are not set and the user calls a function in libdsp the code WILL fail in the interrupt (constants won’t be correct and register indexing won’t work) - probably should be added.

In non-dsp’s, if the user modifies PSV (highly unlikely) they should be probably be smart enough to realize that interrupt routines need to be checked, but they might not think of the timer - iffy to add.

As for the DC bit, I think any poor user that tries to use it and has any interrupt routines will spend months trying to figure out why it doesn’t always work even if timer save/restores it! - probably not worth it.

On the other hand even if Microchip doesn’t seem to worry about PSV and DC saving them would cost about .01% to .1% of the cpu.

I’m afraid I don’t have an answer as to what is right - I partially brought it up to see what you thought and if I should bother for my version of the port

mike

tlafleur wrote on Friday, February 06, 2015:

I also would very much like to see a current port for this series of
processors…

For NOW, I’m using Mike’s port.c code, I’m using ATD, I2C, CAN, 2 UART and
4 ch of DMA and it all run well under 8.2.0 with 11 task… I’m using the
dsPIC33EP primarily for it larger RAM… but may consider using the 5.0V
dsPIC33EV for my next project…
I’m not using any of the DSP registers at this time…

Thanks

On Fri, Feb 6, 2015 at 1:28 PM, mike dragonflight1@users.sf.net wrote:

None of the interrupt issues are a question of thread safe, but rather a
question of if the user creates code that changes/uses DC, PSV, MODCON then
timer1 will either fail or corrupt the program.

In reverse order, for the dsp’s, if PSV and MODCON are not set and the
user calls a function in libdsp the code WILL fail in the interrupt
(constants won’t be correct and register indexing won’t work) - probably
should be added.

In non-dsp’s, if the user modifies PSV (highly unlikely) they should be
probably be smart enough to realize that interrupt routines need to be
checked, but they might not think of the timer - iffy to add.

As for the DC bit, I think any poor user that tries to use it and has any
interrupt routines will spend months trying to figure out why it doesn’t
always work even if timer save/restores it! - probably not worth it.

On the other hand even if Microchip doesn’t seem to worry about PSV and DC
saving them would cost about .01% to .1% of the cpu.

I’m afraid I don’t have an answer as to what is right - I partially
brought it up to see what you thought and if I should bother for my version
of the port

mike

PIC 16-bit port
https://sourceforge.net/p/freertos/discussion/382005/thread/5bd3a3b3/?limit=25#a8d2

Sent from sourceforge.net because you indicated interest in
SourceForge.net: Log In to SourceForge.net

To unsubscribe from further messages, please visit
SourceForge.net: Log In to SourceForge.net

~~ _/) _/) _/) ``` _/) ~~

Tom Lafleur