I want to design my code space as two halves, one part is 48KB which is resident in RAM and the other part 16KB is dynamically swappable based on the operations 8051 is required to perform. How should I organize and build my code?
1.) I am guessing I will need to design my own dynamic code page loader. I have an indirect ability to write to code space RAM structure using an external h/w piece.
2.) The problem for me is how should I organize my code and build it in this case since, I can have several pages of swappable code? Should I build each of these swappable 16KB code as absolute-segment libraries and assign them the upper 16KB address space? How about the data segments for these swappable code? Do I need to limit the range there as well?
Any insight will be helpful. Thanks.
erik,
You can use RAM instead of ROM/PROM/etc if you wire it up that way. But it will take some intervention to execute out of this RAM. You would have to load up the RAM wired into code-space either through some external means or a boot-loader in ROM/PROM/etc.
I am aware of that, have used battery-backed-RAM as "bootable flash" before flash was available, the question was intended to "flush out" what the OP was REALLY doing.
Now that it is (from posts above/below) obvious that the OP is stuck with some 'inventive' memory scheme, his solution, most likely, will be serial eeproms. but, regardless, this mix of permanent and replaceable code will be a nightmare unless it was VERY well thought out before first implementation.
Erik
Somehow, I think not...
I must say that when I saw your statement, I was taken aback. I figured you were a lot smarter than that question. Especially since many development kits use "Code RAM" (odd name: CRAM... kind of fits though)
You've always (99.9%) had been on the right side of any 'debate' and it is clear to me (and all land walking forum contributors), that you would know such information.
I felt weird 'correcting' your post because I have respect for you and a few others like Per, Andy, Tamir, and many others too. [I'm sure there are some really smart cookies out there who never post too].
In general I try not to post much, but when I do it is a bit rambling. I found this guy's dilemma rather interesting since I have done some weird things with memory and boot-loaders.
My latest project has me running four 8051s, one ARM Cortex-M3 processor and three FPGAs (Actel of course) all in concert. I'm trying to fit the micros into the FPGAs and reduce the cost and footprint. All the while I have a few megabytes of SRAM that must be shared through bus arbitrators.
In doing so, the shared memory is getting rather tricky---and I hate 'tricky' non-traditional methods as it can reduce reliability... I'm ensuring this doesn't happen.
Yet my project is a *new* design but this OP has to deal with an established ('old') system and 'cram' the solution into what exists. YOU/WE HAVE HAD TO DO THE SAME THING AT ONE POINT OR ANOTHER: us veteran embedded guys have always dealt with band-aid fixes fully knowing the pitfalls. But when the boss says Jump you either Jump or find another job.
Given the lack of full disclosure on his exact system, I still recommend that the OP check out the Huge Memory Model's capabilities, and modify it to suit his needs.
EOR {end-of-ramble}
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
{excuse me, but i had to fix my dual redundant MIL-STD-1553 name}
Cpt. Vince, I am assuming you mean "Large" memory model. http://www.keil.com/support/man/docs/c51/c51_le_memmodels.htm
That is exactly what we (have been and) will be using with banking. Need to work on some modifications for fast swapping or, software assisted prefetching if we go down this route.
Thanks all for your feedback!
"I felt weird 'correcting' your post because I have respect for you and a few others like Per, Andy, Tamir, and many others too."
My vote goes to Jack Sprat.
"'Large' memory model ... is exactly what we (have been and) will be using"
In that case, you mave definitely not optimised the code as much as possible!
Switching to the Small model, and being careful to put your most-used variabls into DATA space, can save a considerable amount of code!
If you've missed this obvious one, there are probably other areas in which you can optimise your coude at the Source level.
See: http://www.keil.com/support/man/docs/c51/c51_xc.htm
And: user.it.uu.se/.../engblom-esc-sf-2001.pdf
Thanks for those links Andy.
Thats a good suggestion. We are indeed aware of differences between DATA space and XDATA space and how the resulting code is different for those accesses. However, our system requires lots (many KBs) of data memory and many many KBs of program memory. We do use some of the DATA memory, though, not all, as we reserve some for future perf. sensitive operations. Even if I use all of the currently unused DATA space, I doubt if it can reduce so much of code space that we do not need banking at all for our system.
I will go over the optimized code doc to see what we have missed. Even if we cannot get rid of the banking requirement, it would be good to further lower the footprint. Doing more with less... thats the motto!
The thing here is that arrays and other large structures are better moved to XDATA, while you try to make optimum use of bits, chars and int variables in DATA. The important thing is to get as many code lines as possibly that perform memory accesses to use as small addressing modes as possible.
By moving a few carefully-chosen, much-used variables from XDATA to DATA I once saved several KBytes of code from 16K or so program - so there can be quite significant savings to be had.
You say you're on v3 - so you must, surely, have seen this coming?
No, one fine day, we suddenly realised we were out of code space. :-)
Of course, we knew. We went through several rounds of code crunching using efficient memory types/memory specific pointers among other things. When we thought there were no further gains to be had, we started obsoleting features. Then, we started getting good-sized code requests for new features and that is when we had to switch to banked code space. We have been in production with that for one generation.
The issue NOW is we want to see if we can keep the banking design but, get rid of some physical RAM storage. Sounds crazy... I know. Hence, I am here to see if anybody has attempted that.
I don't want to rub it in, but the upcoming generation of Cortex processors is going to have to up 1 MB internal flash space...! Our LPC2478 has 512KB, and even so, I had to increase the size of the application on my flavor of the product on the expense of a low level firmware layer (we have 3 components in each controller - bootloader, a firmware layer and an application) to accommodate extra functionality. I have seen at least one project so far that failed due to internal flash running out at a too advanced stage.
The issue NOW is we want to see if we can keep the banking design but, get rid of some physical RAM storage. why not get rid of it all CODE banking (all in ROM) allow you more codespace then any '51 project should ever be needing.