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.
Is there a reason for you to use an 8051 processor for this? Have you spent any time reviewing other processor architectures?
Why do you need to run code from RAM? To be able to replace the code? In that case - why not use a chip where you may replace the code but store and run the code from flash?
This question keep popping up from people that have no idea what a '51 is intended for.
If you want replaceable code use a (non-Harvard) processsor intended for that.
Erik
Thanks for the responses.
This is a 3rd ver. of the product. The feature set has outgrown the code RAM we have. Also, we cannot choose any other processor because of schedule and cost reasons.
So, one of the solutions we started thinking about was to swap in code pages as they were needed specially for code that did not have real-time requirements. Essentially, we would like to partition code into two parts, one is going to be resident with a code page loader logic and other part can be swapped in from flash using some special h/w when needed. To make that work, we are trying to figure out how to build code for resident part and for the different swappable pages.
But your proposed "solution" sounds like it will be neither cheap nor quck to implement - if it can be made to work at all!
The fact of the matter is that you have long outgrown this processor!
Your immediate effort might be better spent in trying to reduce the size of the existing code - while you make an urgent start working on a re-design that can actually accommodate your requirements!
You might want to take advantage of the Huge memory module and startup code. Within that 'huge' memory model is the ability to bank-switch by setting port I/O to chip-enable (or a higher than the 16-bit address to the RAM) the memory bank in which you need to access. The lower 64K address space and map can stay the same, but the port I/O can swap which chip it needs to read/write from.
The problem then becomes working around the Harvard architecture. But since it is RAM, then you should be able to point to that lower portion of the chip and do a movx instruction.
I might be way off base, but that is what I was thinking as I read this thread.
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
This is a 3rd ver. of the product. The feature set has outgrown the code RAM we have. Also, we cannot choose any other processor because of schedule and cost reasons. what is code RAM, this is a '51
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.
Even though the '51 is not a Von Neumann architecture, you can execute from RAM space (that is wired to be in code-space).
Right. We have h/w hooks to download code from flash into a RAM structure before 8051 execution begins.
One option we are considering is to build code as multiple banks, but, have the h/w alias multiple bank addresses to the same RAM structure. Then, manage the "shared" code RAM from the resident code making sure the intended bank code is physically present in the shared RAM before it is called.
I know we are going over hoops to make it work. But, we are limited due to cost and schedule reasons for the current design. And, we have already optimized the C-code as much as we think is possible.
Why Not stay with Standard Banking The compiler support this directly.
Cannot add more RAM structures for cost reasons/margin.
Or consider an 80C410 from Dallas Semi. Large address space, run code from RAM 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.
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}
{excuse me, but i had to fix my dual redundant MIL-STD-1553 name}