Hi guys. I'm trying to simulate a code for MSC1210 (Texas Instruments). The problem is that I have serious doubts about the results of the simulation since I've detected the following situation:
I make an external memory access, which, as you all know, uses the Port 0 as both Address and data bus (the address will be latched to preserve its value for the address lines of the memory). The fact is that it succeeds, in spite of I forced several Port0 pins to LOW, simulating that there is a ground connected to them.
The simulation of this "forcing" is done by cliking the corresponding checkbox of that pins in the "Port0" simulated peripheral window.
I hope you help me. If you need any clarifying note tell me.
Thanks, and excuse my wrong english.
Thank you Andy. Anyway what I was trying to do, when I noticed this issue, is to make use of Port0 for both External Data memory access (by means of WR RD and ALE signals) and 8 Data bits of LCD. This was a doubt that I couldn't solve.
MSC1210 specs (TI circuit based on 8052 enhanced core) says sometimes that once you programmed the flash memory and, hence, Hardware configuration register, you wont be able to change this Hardware configuration register in which a bit in low or high decide if PORT0 is to be used as either Memory access port or general I/O port. This is not totally right defined in specs, and as I aspire to use port 0 for Memory in some cases, and for LCD data in other cases (by ENABLING DISABLING circuits as needed, of course), I hope that someone expert here told me if it's possible or not.
The code I tried is the following, but after you told me that uVision is not a total hardware simulator, the success of this code in my uVision doesn't offer to me any reliability.
void main (void) //programa principal { char xdata pruebamem;//defined in external memory space char estadolcd; char tecla; char bdata banderas; P2=45; P0=23; pruebamem=35; estadolcd=pruebamem; tecla=estadolcd; estadolcd=P0; estadolcd=P2; while (1); }
In this code after write (by command line of uVision) the Hardware Configuration Memory in the flash, commanding MSC1210 the usage of Port0 as Memory access port only, I do many assignments to test if it is true that I can not use Port0 as both Memory and general I/O manager. My surprise is that it can do everything I demand to... So I don't know what to believe. Please help
Thank you.
as I aspire to use port 0 for Memory in some cases, and for LCD data in other cases
what is the problem? just set up the LCD as memory mapped I/O instead of I/O mapped I/O
Erik
Let's see. I've a short life in microcontrolers programming. I'll try to explain where the problem is:
MSC1210, and I suppose all 8052 uC, permits me to manage an external RAM since it has WR RD specialized pins. In the mode Port0 managing memory, I supposed it wasn't possible to treat port 0 as general I/O port, so that the only instruction this port is affected by, would be MOVX, that rises signal WR or RD during the time necessary to make a good transfer toward/from the RAM memory.
Signals and timing of LCD are quite different, so that the instruction MOVX is not going to work well unless I think of anything to solve this tradeoff.
What I desired, but don't know if it's possible, is to enable memory and make transfers with MOVX whereas I can use simple assignments to write by means of toggling control bits of LCD "by hand" (not as it do the MSC1210 with MOVX and its automated RD WR commuting).
Thank you again Erik
Sorry. Last sentece was:
What I desired, but don't know if it's possible, is to enable memory and make transfers with MOVX whereas, to manage LCD, I can use simple assignments to write by means of toggling control bits of LCD "by hand" (not as it do the MSC1210 with MOVX and its automated RD WR commuting). If I (actually it's the compiler the one who writes the program) used MOVX instruction when writing LCD, WR signal would activate, so that I'd have to disable RAM memory in order to not provoke a conflict in data bus, but... besides Port0 shows not only DATA but also, during several oscilator clock cicles, ADDRESS commanded by MOVX instruction. Therefore it seems not to be a good idea.
... has always been fraught with problems.
one day you make a change and the bits on P0 from a movx match something the LCD 'understands" an KABOOM.
Then you make some LCD access in main and some external memory access in an ISR and the LCD is enabled to 'see' the memory access bits.
Just make it memory mapped I/O
Signals and timing of LCD are quite different, so that the instruction MOVX is not going to work well unless I think of anything to solve this tradeoff. that is ludicrous, unless you have an extermely fast RAM or an extremely slow LCD, as you - in any sensible design - do not access external RAM for anything critical, you may have to slow RAM access down just a tad without any serious problems.
If that is not possible add a couple of latches.
Rafa; I think that you need to look more closely at Erik's link at http://www.keil.com/forum/docs/thread14553.asp.
Look at the method of storing the address in a transparent latch such as a 74HC573. Also look at a simple decoder such as a 74HC138 to get the proper memory selection and finally, you do not mention the LCD controller type but you might need to add simple logic to make Read/Not Write and E terms for your LCD controller. But after all is said and done, YOU NEED TO USE MEMORY MAPPING. Sorry about the yelling but it's very important that you get off to good start on the proper path instead of attempting to by-pass the features of the 8051. Bradford
Thank you. You've been really helpful. I'll put it mapping the LCD by means of decoder.