Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Loading

PIC 16-bit port

Posted 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

  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()

  2. 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 port

Posted 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 port

Posted 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 port

Posted 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

https://sourceforge.net/p/freertos/discussion/382005/thread/5bd3a3b3/?limit=25#a8d2

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/freertos/discussion/382005/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

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

Tom Lafleur

Attachments

alternate (3137 bytes)


[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]


Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Meet Richard Barry and learn about running FreeRTOS on RISC-V at FOSDEM 2019

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


Careers

FreeRTOS and other embedded software careers at AWS.



FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Renesas

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner