I was wondering if it was possible to disable simulation of the ports? I am not using them for serial communication and I want to use these bit addressable registers another way. I am simulating a M8051EW and everytime that I reset the micro-controller the ports all reset to 0xFF. I don't want the micro-controler to reset these registers. I want them to keep the same value that they had before the reset occured. How do I turn off simulation of different device features?
I am simulating a M8051EW and everytime that I reset the micro-controller the ports all reset to 0xFF. I don't want the micro-controler to reset these registers. I want them to keep the same value that they had before the reset occured. That is exactly the way the hardware works. if you want the simulator to function different from the hardware, what is the purpose? Erik
If I understand it correctly, you can choose not to have serial port capability if you aren't going to use them when you compile the 8051 in order to have more SFR space available for other data. From the page about the M8051EW (http://www.keil.com/dd/docs/datashts/mentor%20graphics/m8051ewarp_pd.pdf) it says: If, however, either the serial port or any of the timer/counters are not required for a particular application, these items can readily be omitted at compile time. I am not going to be using the registers for a serial port but I do want them for other data, but I don't know how to stop the simulator from simulating a serial port reset (which resets all ports to 0xFF) when I reset the micro-controller in the simulator.
"That is exactly the way the hardware works." Erik, Are you sure it's the way this hardware works? This is an IP softcore: http://www.keil.com/dd/chip/3227.htm So it's possible that its ports don't behave in the standard way... In fact, it's possible that the "ports" on the core don't actually meet the outside world at all!
"a serial port reset (which resets all ports to 0xFF)" Eh? What do you mean by that?? Does the M8051EW core have a special "serial port reset" that is distinct from any other sort of reset? The beauty of a soft core is that you can effectively design your own chip; the downside, of course, is that it's your chip, so you have to provide the support for it...! There is an application note that describes AGSI - Keil's simulation "API".
When I said the serial port reset I meant just a general simulator reset. For example, using Keil's simulation "API"(AGSI), it calls TriggerReset() or if you click on "reset CPU" while in debug mode of the uVision simulator. When you do any of these, the simulator automatically resets the port SFR's to 0xFF and any other normal 8051 defined registers to 0x00, their default values. I am not using the Serial ports. When I compile the soft core I will choose not to add them. So when I simulate my soft core right now, I don't want them to reset to 0xFF. I want them to act like any other undefined register and keep the value that was in the register before the reset. So I am looking for a way to disable the reset of pre-defined SFR's.
"That is exactly the way the hardware works." Erik, Are you sure it's the way this hardware works? However, the OP ask that the ports keep their current state after a reset (not that they do not get reset to '1' ot '0'). There is a 0,0001% possibility that some stupid developer of a deviate would leave the port pins random after a reset. Visualize a medical device with random outputs after a power glitch OUCH. No, I can not be sure, however, if, for every answer one should analyze whether the OP is using a deviate, rather than a derivative, it would be very difficult to answer 87% of the posta. Now, say that my answer is wrong, there would be nothing wrong with the OP going through this very exxcruciating process of a 30 second look at the datasheet to find out and post that for this (it would then be a ) deviate, the ports are not reset to a known state. Erik
"There is a 0,0001% possibility that some stupid developer of a deviate would leave the port pins random after a reset. Visualize a medical device with random outputs after a power glitch OUCH." But, again, this is an IP core - so he's probably also developing the rest of the system, and can design it accordingly. "if, for every answer one should analyze whether the OP is using a deviate, rather than a derivative" You could always just say, "I don't recognise that part - I'll just ignore it..."