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

Port to PIC18F8722 (extended mode)

Posted by Nobody/Anonymous on July 13, 2005
Having issues porting the FreeRTOS (v3.2.0) to run on a 128k device -- ie. a pic running in extended mode. Has anyone done this and can pass on any tips? (running latest MPLAB and mcc18)

I've sucessfully ported to a PIC18F8680 with no problems.

Thanks!

Ron.

RE: Port to PIC18F8722 (extended mode)

Posted by Marcel van Lieshout on July 13, 2005
What do you mean by "extended mode"?
What problems do you have?

RE: Port to PIC18F8722 (extended mode)

Posted by Nobody/Anonymous on July 13, 2005
The idea is to get FreeRTOS to run on a PIC with more than 64k of flash. I seem to have it running in non-extened mode, but this means I can't use the extra 64k of flash for code.

The build option for the C18 compiler:
Set to "Large code model (>64k bytes)
Extended mode flag set

MPASM compiler:
extended mode flag set

The linker file (with RTOS mods):
18f87221_e.lkr

Configuration bits:
Extended CPU enable: Enabled
Address Bus Width: 20 bit

if it's worth anything when debugging it repeatedly executes the portSAVE_CONTEXT call.

void vPortYield( void )
{
/* This can get called with interrupts either enabled or disabled. We
will save the INTCON register with the interrupt enable bits unmodified. */
portSAVE_CONTEXT( portINTERRUPTS_UNCHANGED );



RE: Port to PIC18F8722 (extended mode)

Posted by Marcel van Lieshout on July 13, 2005
For a moment, you got me doubting myself here :-)

I believe the word "extended" is misinterpreted here:

A device with more than 64kB flash is not a extended device in Microchip jargon. It's just a device with more than 64 kB flash :-) . Because pointers need to extend beyond the default 16bits, the compiler needs to know this. I have briefly looked at port.c for MPLAB and it seems to be ok for these larger pointers. You should set the large memory model to use this additional flash (as you already did).

The word "extended" applies to the instruction set. By setting the "extended instruction set" fuse (XINST), a few new instructions become available. More important is that a new addressing mode is enabled, too. Because of this new addressing mode, a lot of standard instructions function in a different way, so the compiler should know this (extended mode flag). The current FreeRTOS MPLAB port will definitely not run with this changed behaviour. The best way (I think) to look at this changed behaviour is to think of the pic in extended mode as an entirely new processor. When you look at the runtime routines that are delivered with the compiler in source, you'll find two sets of them: one for the normal pic18 and one for the extended pic18. To adapt FreeRTOS to the extended mode pic18, a new port is needed.

Conclusion:
- Set "large memory model" to use the flash above 64kB.
- Do NOT set extended mode and do NOT set the XINST fuse. The current port does not support the changed instruction set behaviour.

hth

Marcel

ps. I did not write the MPLAB port. I did, however, write the wizC/PIC18 port.

RE: Port to PIC18F8722 (extended mode)

Posted by Richard on July 13, 2005
Thanks Marcel for your very informative reply. I have definitely learned something today!

Regards.

RE: Port to PIC18F8722 (extended mode)

Posted by Marcel van Lieshout on July 13, 2005
Let's hope this helps the TS :-)

RE: Port to PIC18F8722 (extended mode)

Posted by Nobody/Anonymous on July 13, 2005
Marcel,

Thanks for the info -- made the changes and it works fine!

Ron.


RE: Port to PIC18F8722 (extended mode)

Posted by Marcel van Lieshout on July 13, 2005
According to Microchip, using the extended mode results in tighter and faster code. Perhaps someone can do a new port for this mode. It cannot be me as I don't have the time and have never used MPLAB or C18...

Glad things work now! Thanks for the feedback!


[ 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