0

FreeRTOS V 7.5.2 port for dsPIC33E (max. 32KB RAM)

Martin Hollenweger

October 15, 2013 08:00

None

Follow

This Port enables the use of the dsPIC33E family with FreeRTOS V 7.5.2.

Please copy the two attached files over the original files in "FreeRTOS\Source\portable\MPLAB\PIC24_dsPIC"

Limits:

- Do not use the assembler instruction <DO> (Microchip has confirmed that the XC16 isn't using this instruction)

- Do not use shadow registers (interrupt functions with attribute "shadow" are not allowed)

- Do not use more the 32 Kbyte of RAM (4K SFR space + 28K RAM)

Compiling FreeRTOS with the XC16 v1.11 Compiler for dsPIC33E devices will generate a bunch of warnings:

warning: Taking the address of 'xxxx' may require an extended pointer for this device

This warnings can be safely ignored if the RAM used is not exceeding the 32KByte limit. (max 28K RAM as the first 4K are used for SFR space)

PIC24_dsPIC.zip

• Facebook
• Twitter
• LinkedIn

7 comments

• 0
  
  Mike October 24, 2013 16:31

  As a minor comment, the dsPIC33E  uses 0x1000 bytes for SFR space, significantly reducing the amount of near data space (the "standard" mplab projects will not link)

  modify the allocation of the heap (in heap_1.c, heap_2.c, or heap_4.c) to be

   

  static unsigned char __attribute__((far)) ucHeap[ configTOTAL_HEAP_SIZE ];

  (actually a good idea for any pic24)

  Also, you can use the <DO> instruction (and it may well be used in come optimized math libraries).

  Unlike the other dsp's the 33E has a hardware DO stack that is 4 deep and may be a problem is used in multiple tasks.

  The other dsp's have a software stack (i.e. the registers are saved in a context switch), but it would appear from the manual that they have a limit of 7 - I have not tried to see what happens after 7 - so the additional restriction of 4 may not be significant.

• 0
  
  Joel January 03, 2014 02:20

  I notice that the port code above saves and restores the DOSTARTL, DOSTARTH, DOENDL, DOENDH registers; however they are listed ad read-only in the data sheet, which means it really only wastes time and memory to save them during a context switch. 

  As a consequence of not being able to restore _any_ DO* registers at all (top of the DO* register stack or otherwise), if any optimized math libraries (or your own code) use the <DO> instruction in more than 1 task you run the risk of corrupting the intended program path for these tasks, unless you protect each <DO> block with a critical section.

  Unless I'm missing something, it seems that the <DO> instruction is use-at-your-own-risk within an RTOS environment.

• 0
  
  Martin Hollenweger January 03, 2014 06:00

  Hello Joel

  Your right about the DOxxx registers, please consider Mike's dsPIC33E port (http://www.freertos.org/Interactive_Frames/Open_Frames.html?http://interactive.freertos.org/forums).

• 0
  
  Mike January 03, 2014 16:29

  Joel,

  You are absolutely right about the dsp registers. I can't remember, but I believe I saved them for the dspic33e's as well (though it should be obvious and simple not to) in case some tool looked at the stack for info.

  Unfortunately as FreeRTOS stands there is no mechanism other than co-operative scheduling (needs newest 7.5.6?) to guarantee tasks are not scheduled until a yield) or as you say all math in a single task or protected by a critical section.

  However, that is not as bad a restriction as it may seem. (and in fact as afar as I can recall no library function uses more than 2 levels, so you can have 2 tasks). I am doing do now.

  More important is that the timer routine needs to be modified, as well as any other interrupt routine, to save and set CORCON.

  I am not at home, so I can't remember details, but there is a thread in the forum about it and in a few days I will update this comment appropriately.

  mike

   

• 0
  
  Mike January 08, 2014 13:03

  Joel,

  To update my previous comment. I do not save the dsp registers for the dsPIC33E's.

  It seems my memory is failing. For the 33E's you do not have to set CORCON (it does need to be set for all other dsPIC's, but MODCON needs to be saved and set. I use

  MODCON = 0xF0;

  disabling the special addressing modes (XMODEN, YMODEN,  and BWM=0xF disabled bit-reversed)

  mike

• 0
  
  johnSmith October 18, 2016 23:07

  In the following port.c fragment there is potential bug:

  const portSTACK_TYPE xInitialStack[] =
  {
  0x1111, /* W1 */
  0x2222, /* W2 */
  0x3333, /* W3 */
  0x4444, /* W4 */
  0x5555, /* W5 */
  0x6666, /* W6 */
  0x7777, /* W7 */
  0x8888, /* W8 */
  0x9999, /* W9 */
  0xaaaa, /* W10 */
  0xbbbb, /* W11 */
  0xcccc, /* W12 */
  0xdddd, /* W13 */
  0xeeee, /* W14 */
  0xcdce, /* RCOUNT */
  0xabac, /* TBLPAG */

  /* dsPIC specific registers. */
  #ifdef MPLAB_DSPIC_PORT
  0x0202, /* ACCAL */
  0x0303, /* ACCAH */
  0x0404, /* ACCAU */
  0x0505, /* ACCBL */
  0x0606, /* ACCBH */
  0x0707, /* ACCBU */
  0x0808, /* DCOUNT */
  0x090a, /* DOSTARTL */
  0x1010, /* DOSTARTH */
  0x1110, /* DOENDL */
  0x1212, /* DOENDH */
  #endif
  };

  The problem is MPLAB_DSPIC_PORT is now deprecated and may be not defined.

  So,

  #ifdef MPLAB_DSPIC_PORT needs to be changed to 

  #if defined( __dsPIC30F__ ) || defined( __dsPIC33F__ ) || defined(__dsPIC33E__)

• 0
  
  Martin Hollenweger October 24, 2016 17:18

  Hi JohnSmith,

  Thanks for the interest in the port, but I do not recommend to use this port anymore, please take a look at Mike's port:

  https://interactive.freertos.org/hc/en-us/community/posts/210026846-FreeRTOS-V8-2-0-port-for-ALL-16-bit-PICs-with-hardware-stack-checking-SPLIM-

  or 

  https://interactive.freertos.org/hc/en-us/community/posts/210026746-FreeRTOS-V7-5-3-port-for-ALL-16-bit-pics-with-hardware-stack-checking-SPLIM-

  Martin