FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [February 2015 Threads] PIC 16-bit portPosted by dragonflight1 on February 6, 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
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
PIC 16-bit portPosted by rtel on February 6, 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.
PIC 16-bit portPosted by dragonflight1 on February 6, 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
PIC 16-bit portPosted by tlafleur on February 6, 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
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|