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.

Question(s):
- 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...

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.

Regards.

Right.
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