Quality RTOS & Embedded Software

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


PIC18F USB Memory Hole

Posted by Lukasz Sokol on August 14, 2008
Hello all,

so I've started digging into the documentation of PIC18F2455/2550/4455/4550.

The target I wish to code for is the *4550.

Must admit, that the memory map and access modes are a bit weird to me.

But nevertheless, reading through the FreeRTOS PIC18 port code, I see the need to take the USB memory hole into consideration...

Background :
- The PIC uC's mentioned above, sport a USB module.
- The module is communicating with the core via special dual-port RAM area
Now the tricky bit comes :
- The USB memory area is mapped to memory banks 4 to 7 (400h to 7FFH)
- Considering the GPR area (general-purpose, I suppose that means plain RAM) starts at 060h, the area usable for us is 3 banks*256b (Bank1, Bank2, Bank3) = 768b and area 060h -- 0FFh (160b) area of Bank0. Leaving us with 928 bytes available...

- the manual states, that once the USB module is enabled, the bank 4 (used for USB buffer management) (400h-4FFh) should not be used at all by user code, and the other banks, even if not used for buffers, are not safe.

Conclusion :
- the PIC18FF2455/2550/4455/4550 port needs to be considered being sufficiently different from the normal PIC18 port, to be a separate port.

- to save RAM during context switch, would it be considerable to omit saving/restoration of the 22 bytes of tmpdata and MATHDATA at all? It is bad enough to have the sfr's and 'up to' 3*31 bytes for the hardware return stack addresses.

Ridicule :
- maybe this device(s) just needs an I2C(SPI?) RAM chip attached and the context switching data to be put/pulled there, not into main memory...

RE: PIC18F USB Memory Hole

Posted by Richard on August 15, 2008
Yes...the PIC18 is an unusual beast on does not lend itself too well to larger RTOS apps. If you have to leave a hole in the memory then you may not be able to get a nice big array for the heap, which could lead to having to modify the heap_1.c file too.

With regard to the tmp data and maths data - the C18 compiler does not generate reentrant code and uses this data as a scratch area. Unfortunately you need to store the data as part of the task context. You might get away without storing the math data if you don't do any maths, but most embedded apps will do some calculation or other.


RE: PIC18F USB Memory Hole

Posted by Lukasz Sokol on August 15, 2008
I see now.
It is not a 'hole' as such - it is just a 'low attic'... Will search for the setting of MAX_MEMORY ;) I know it is there just didn't have a chance to find it yet ;)

Hopefully, the C18 compiler wouldn't mess with the USB memory area behind my back :J

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

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

Latest News

Version 10.1.0 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.


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


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