Hi Friends, I have a doubt that the xdata declaration is using the memory of 89c52 chip memory itself,or it needs any external memory .I used an array as xdata in 89c52 based project because i have to store a large data . Is it possible without any external memory ,such chips are not present in my hardware. I need your valuable help.
I used an array as xdata in 89c52 based project because i have to store a large data . Is it possible without any external memory The Arghmel 89c51 does not have any "internal external memory" so how would you even think (sorry that is a bad word) you could use XDATA without any external memory.
Erik
PS do not come back with a question about "internal external memory" your chip does not have any, and if you do not know what it is, hang it up.
Wishing something is there does not make it magically appear and, posting "I need it" does not make it appear either, none of us are magicians. You have only specified "large data", to some 10 is large, to some 1000 is not.
there is one option you might consider which is to replace your chip with a chip with sufficient "internal external memory" e.g the P89C668 has 8k of such. The keil device database will show you what is available with enough internal xram for your purposes.
The Arghmel 89c51 does not have any "internal external memory"
Not true!
Signetics developed WOM (write only memory) technology, and 'Arghmel' and the other processor vendors have incorporated at least 64K of it into almost all micros and controllers. They just don't document it! Erik knows this, but he thinks this knowledge will give him a competative advantage.
You will know which ones didn't license the technology from Signetics: If your processor throws a 'memory access exception' when it writes into this 'undocumented' space, then you know the vendor was too cheap to lay out the WOM in their die.
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
Thank you for that hint. I must confess that I hand't picked up on this feature before.
After a quick check on some of our devices, I can verify that I managed to write quite a lot of data with very good access times (believe it or not, but it actually looks like I can get the same write performance as for the built-in RAM!) in a one of our Arghmel Mega48 chips, which might indicate that we do not need to upgrade them to the pricier Mega88 or possibly Mega168 variants.
This technology should help nicely for a new line of data logger products. Ordinary EEPROM writes tend to be a bit slow (which will limit the possible sample rates), and smaller processors don't always have enough RAM to copy and rewrite full flash pages.
One thing that did surprise me - but you did warn about it - was that one of our 32-bit PPC processors generated a core dump when trying to figure out if the WOM technology was licensed or not. Since the chip is quite high-end - might I just have got the wrong alignment or the wrong memory access timing? Or are Freescale one of the chip vendors who missed out on this technology?
Many chip vendors, like Freescale, have attempted to design their own WOM, but have failed. This is why Signetics practically has a lock on the market.
I think you are seeing the non-licensed attempt at implementing WOM technology. Add a few Miller capacitors on the WOM data bus, and you should be up and running.
I can see that you have also been working with Freescale processors. They designed their own USB controller too, with hardly anyone managing to get it working :(
I'm affraid the Miller caps will affect the write speed, so I think I'll prioritize an overview of the MMU (Memmory Malignment Unit) setup since I still kind of assume this to be an alignment problem - the behaviour is very similar to accessing a 32-bit variable from an odd address (possibly related to the same Signetics licensing issues). As a last resort, I'll take a look at the caps. Thanks for the tip.
Yes, it seems you where right about the Miller caps being involved.
But because of the lead times (we have only RoHS-compliant products), I would have to get a new solder stencil to update the Miller caps. According to the datasheet, only the next generation Freescale processors has the improved DMA (Dynamic Memory Arbitration) with support for software-configurable Miller capacitors. Most probably on license from Signetics.
As a short-term solution, I managed to update the MMU configuration and now have a 4Mword (full 32-bit wide) ordered FINO queue up and running. And the good part with WOM in relation to normal non-volatile memory technologies is that it does not suffer from any wear from multiple write or erase cycles.
Per,
That's great! I'm glad to have helped out with that problem.
"ordered FINO" ?? I just don't think that is the best design.
The 'F' is already intrinsically 'ordered', so a double 'ordered' must either mean you have it wrong---which I doubt---or you have clearly have forgotten about De Morgan's little theorem.
Personally, I would just go ahead and change that 'ordered FINO' into a full blown RINO configuration.
[ Sorry, George B. I credited Augustus D. with your work ]
Personally, I would just go ahead and change that 'ordered FINO' into a full blown RINO configuration. would a GINO not be easier to implememnt?
... GINO not be easier ... ?
True.
After validating data for storage, you have one of two choices; store the data into standard memory or not. The fact that you still have the data does not absolve you from dealing with it. You still must put that data somewhere. And this is what Signetics capitalized upon and is one of the main advantages of their WOM technology. A GINO construct works for that particular situation.
I was discussing the ordered-ordered situation where the double 'ordered' clearly translates into the non-ordered (hence Random).
Per is the only one who could determine if GINO is applicable. But it seems that his Freescale peripherals (MMU & DMA) might be set for Auto-G mode anyway.
I hope he is running his data through Freescale's on-chip CAU (Cryptographic Ambiguity Unit) to ensure it's safety & security.