Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

Yet another question (PIC18 MPLAB port)

Posted by Lukasz Sokol on August 14, 2008
Starting a new thread, because this is generally about the PIC18F MPLAB port.

I admit, my assembly language understanding (of PIC assembler that is) is less than satisfactory - but here is what I spotted :

in FreeRTOS\Source\portable\MPLAB\PIC18F\port.c

in portRESTORE_CONTEXT() macro :

----- line 273
/* How many return addresses are there on the hardware stack? Discard\
the first byte as we are pointing to the next free space. */\
MOVFFPOSTDEC1, FSR0L\
MOVFFPOSTDEC1, FSR0L\
_endasm\
\
/* Fill the hardware stack from our software stack. */\
STKPTR = 0;\
\
while( STKPTR < FSR0L )<<<<< this\
{\
_asm
------- line 284

I understand that the STKPTR is just a counter that can be 0..31.
Whereas the FSR0{L,H} are the lower and higher byte of the pointer.

I suppose the line marked <<<<< this

should rather read

while(STKPTR < INDF0)

to have the STKPTR compared with the count of addresses that were saved on stack, and NOT the address it is saved at ?

Am I right or should I learn more PIC18 assembler ? :)



RE: Yet another question (PIC18 MPLAB port)

Posted by Richard on August 15, 2008
I think - again from memory - that FSR0L contains the number of items that need pushing onto the hardware stack.

portSAVE_CONTEXT() moves the hardware stack onto the task stack - the number of items that were on the hardware stack is variable so portSAVE_CONTEXT() also pushes the number of items that the hardware stack contained onto the task stack. When portRESTORE_CONTEXT is called it loads this number from the task stack into FSR0L - then uses this number as a loop counter as it moves the items back from the task stack into the hardware stack - ensuring that the right number of items are restored.

A bit ugly, but this is constrained by how the PIC18 and the C18 compiler both work.

Regards.

RE: Yet another question (PIC18 MPLAB port)

Posted by Lukasz Sokol on August 15, 2008
(Yay, The Author Himself spoke to me :) )

So it actually does, you're right - it is even written in the commentary :)

I'm just concerned about the point of using FSR0L to hold the simple counter value.
Any rationale behind this ? Why not simply use the WREG here ? Or some other memory field (not to search too far - the code that pops the task context back:

--- line 273
/* How many return addresses are there on the hardware stack? Discard\
the first byte as we are pointing to the next free space. */\
+/* Use WREG to hold this value */
- MOVFFPOSTDEC1, FSR0L
+ MOVF POSTDEC1 /* this is one cycle less and one program word less also */
\
-MOVFFPOSTDEC1, FSR0L
+ MOVF POSTDEC1 /* we have the stack level in the WREG now */


\
_endasm\
\
/* Fill the hardware stack from our software stack. */\
STKPTR = 0;\
\
-while( STKPTR < FSR0L )
+ while(STKPTR < WREG) /* no idea how would this compile ?*/
+/* might actually need to be asm-coded - but could it have a point being shorter->faster? */
\
{
--- line 283


RE: Yet another question (PIC18 MPLAB port)

Posted by Richard on August 15, 2008
Provided the value of that register is restored from that task stack after it is used as the counter (if it were before then its value would get clobbered) then I don't see why not :o)

Regards.

RE: Yet another question (PIC18 MPLAB port)

Posted by Lukasz Sokol on August 15, 2008
Yes,

--- port.c, line 353
_asm \
MOVFFPOSTDEC1, STATUS\
MOVFFPOSTDEC1, WREG\
/* Return without effecting interrupts. The context may have\
been saved from a critical region. */\
RETURN0\
_endasm
--- port.c, line 359

this is the very last register restored in context restore.

So this actually could work :) provided, that C18 doesn't f* up the WREG compiling the while() loop...

(I'm just analyzing the code till now - didn't try to compile&see yet - if somebody verified that works I'd be glad)

If it does, bad luck then... we'll need to code the stack restoration in asm fully.
(but hey, this is port code anyway, and port*CONTEXT are macros)

RE: Yet another question (PIC18 MPLAB port)

Posted by Paul_Piak on October 2, 2008
The thing is that the restore code inside the while loop is:
MOVFPOSTDEC1, 0, 0\
MOVWFTOSU, 0\
MOVFPOSTDEC1, 0, 0\
MOVWFTOSH, 0\
MOVFPOSTDEC1, 0, 0\
MOVWFTOSL, 0\
thus WREG is compromised by the restore instructions themselves. Therefore "while(STKPTR < WREG)"
will not work.

You might want to suggest to use the following code instead (just like the stack-save code, not using WREG)
MOVFFPOSTDEC1,TOSU\
MOVFFPOSTDEC1,TOSH\
MOVFFPOSTDEC1,TOSL\
but this is illegal:
Error - file './SERIAL.o', section '.code_SERIAL.o', TOSU cannot be used as the destination of a MOVFF or MOVSF instruction.

Paul


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




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

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

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

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

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists