Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

8051 512Kb external linear nonsegmented flash program memory

Status
Not open for further replies.
Re: 8051 512Kb external linear nonsegmented flash program me

As Eric said is not very useful. Well, if not very useful, maybe at least useful.

Why 512K and not 128K or 1024K.
Just easy, because it happens to have three bits available for playing with, inside AJMP and ACALL opcodes.
If four bits would be available (4K range), then definitely 512K from article would become 1024K.
It's what I call a fortune or/and a fact that some peoples (i.e. Martin) has a much deeper observation than others.
As long as Martin didn't claimed any exclusive rights in using this idea I don't understand reader responses.
It's true that MArtin choose a not suitable page banking approach and emphasized shortcoming of bank switching article example (43% memory waste; every serious 8051 user knows that's cannot be true).
However this is not a serious reason to make fun and say "once more we have an article - see how brilliant I am - not here is something useful"
It happens to be a Dallas 390 fun accepting all penalties of using 24-bit PC in contiguous mode.

If Martin takes into account the flows across 64K boundary, conditional relative jump, calling and return from subroutine and ISR, I wonder why didn't mentioned what probably needs to be outlined.
Martin Pawloski said:
Of course, this new hybrid FJMP instruction is an undefined instruction to any real 8051. If it were allowed to pass through to the 8051, the program would malfunction by jumping to an unintended address. So the PME-51 translates the instruction on behalf of the 8051. When the first byte of the FJMP instruction is read from the program memory, the PME-51 detects that it's an AJMP opcode and takes the following three actions:

1. It takes the three bits of embedded address from the AJMP opcode and loads them into a holding register.

2. It blocks the AJMP opcode and instead outputs an LJMP opcode (002) onto the 8051 data bus. The 8051, upon reading and decoding this LJMP opcode, will read the remaining two bytes of the instruction and load them into its 16-bit PC.

3. The PME-51, upon detecting the end of the instruction, will transfer the contents of the holding register to its eXtended Address Register (XAR) and output these three bits as address bits A[18..16]. These address bits form the three most significant bits of the desired 19-bit target address, while the 8051 outputs the 16 least significant bits.

If PME-51 blocks the AJMP opcode and outputs instead an LJMP opcode (0x02) onto the 8051 data bus, then it means AJMP opcode isn't used anymore.
Blocking the AJMP opcode defeats his purpose : a small size memory code for routines that resides in 2K code, as well as faster fetching.
Why using a LJMP followed by 2-bytes of address for a jump inside 2K range ?
wouldn't be more suitable an AJMP opcode followed by 1 single byte ?
You can say what's the big deal 1 byte. I know, I know, you can't use too many AJMP and/or ACALL opcodes in your code.

Only my opinion.

Pont de Pedra said:
Has anybody suggestions about PME-51?

Suggestions ? If you can implement it, use it. Can't be a bad ideea.
 
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top