Hello, For those of you working with the 8051 – have you tried using PDATA pages to store the tasks stack/context?  This seems to be a viable approach for devices like the C8051F120 – and obviates having to do the XRAM copy/restore step. Regards, John W.

Is PDATA not limited to 256 bytes?

Each PDATA page is limited to 256 bytes – but you can have multiple pages. Regards, John

PDATA is a method to use eight bit addressing to access external memory.  The lower eight bits of the 16-bit address are encoded in the instruction while the upper eight bits are set by some other register outside of the instruction. I don’t see how this obviates an XRAM copy/restore step as the hardware stack must always reside in internal memory.  What am I missing?

Hello David, I think I should have worded, "and obviates" – to "could obviate". I was a little unclear on this myself – evidently IAR limits you to one PDATA page at link-time – but you can switch PDATA pages using: (according to a reliable source:) "The C8051F120 has 16 pages of PDATA space.  The datasheet refers to this space as XRAM.  Switching between pages is accomplished by setting the PGSELx bits in the EMI0CN SFR.  In assembly, this can be accomplished by a “mov” instruction, which will take 3 clock cycles." Someone mentioned to me this could obviate the XRAM copy step – in reality, as you point out – I don’t think it does. I think the person that mentioned this to me thought everything could be declared __pdata_reentrant with the IAR compiler – but didn’t think about the hardware stack in IDATA.  Since the IAR compiler has it’s own routines to copy stacks for the reentrant functions – I think the thinking was/is if a task can be assigned a PDATA page – that the task contexts could be paged effectively. I suppose this could be done – but you still have the to/from copy step to the PDATA page that has to be done.  This is also not a good use of XRAM if your app. becomes somewhat XRAM limited. Regards, John W.