What's the trick to make the C51 simulator increment timers in realtime? Ive tried setting the xtal value appropriately, on the target panel. (I just need the simulation's blink led freq to have the same period as the real target) Peter
What's the trick to make the C51 simulator increment timers in realtime? There is none, and there shouldn't be. The simulator has its own simulated time --- synchronizing that to wall-clock time would be impossible on slow machines, and wasteful on fast ones. (I just need the simulation's blink led freq to have the same period as the real target) And what good is that supposed to do you?
I'm (politely) amazed at the two responses. If I paraphase the responses: the original requirement was non sensical. Use a real board, and jtag debugger, Peter. Let me be more precise about my working scenario, which I simplified and recast in the original post to use only a few words. I have (borrowed) an IP stack on an 8051. It has a 24hz signal derived from a timer, which acts as a timeout for a polling loop on the serial port. The same signal is a timebase for other exception handlers in the TCP stack. In the simulator, I have succesfully redirected the IP listeners's abstract serial port to the PC COM1. Another instance of the simulator is acting as IP client, initiating a TCP connection, connected to COM2. A null modem anbd suitable handshake is emulated between the two COM ports, using some fancy windows driver software. At some point, later on, a real client board will talk unto a simulated server Things work fine, except that the 24Hz timebase is not in realtime. I cannot test so far (in the simulator) the reality, which seemed a really obvious thing to want to do! Now to my incredulity. If the simulator handles core timing so that the peripherals are accurate in realtime (e.g. the baud rates, the smartcard barrel shifter in ETU, etc), why not the core 8051 timers!? If its expense and waste issue, Dont worry! My machine is idle 12 hours a day as it is. I can happily waste a pentimum's ghz of core bandwidth emulating an 8Mhz/12 8051 timer.
I can happily waste a pentimum's ghz of core bandwidth emulating an 8Mhz/12 8051 timer a couplew of comments: 1) it may be possible to real time simulate ann 8MHz/12 '51 chip, but would you not want tghe same for a 100MHz/1 2) the simulator simulate it does not emulate if you need to emulate, buy an ICE or switch to "chips with built in ICE" (SILabs, some late derivatives from Philips and ST, maybe more). Erik
Peter, At least some of those peripherals aren't really handled by Keil's simulator at all. For instance, the PC is responsible for handling the timing on the serial ports, etc. Keil doesn't have to provide a timer to do this. I'm not familiar with a barrel shifter, but that may be a similar scenario. Also, trying to get good timing resolution within Windows generally means straying into the realm of API calls that will work differently (or sometimes not at all) on different machines, so I'm not surprised they don't support it. That being said, the comments about getting an ICE might not be a bad idea. There are some EXTREMELY inexpensive ICEs out there that will do this sort of thing. Of course, if your target board doesn't even exist yet, that could be a bit of a wrinkle. :)
That being said, the comments about getting an ICE might not be a bad idea. There are some EXTREMELY inexpensive ICEs out there that will do this sort of thing. Of course, if your target board doesn't even exist yet, that could be a bit of a wrinkle. Not necessarily, My Ceibo ICEs for the XA, the standard '51 and the x2 '51 (but not for the LPC) work beautifully without a "target board". Erik
erik, True enough... I think most ICEs will work in a targetless mode of some sort. Visualizing a blinking LED with them as Peter had originally asked, however, might be somewhat difficult. :)
the original requirement was non sensical. As posted, yes, it was. You didn't mention any connection between the simulator and the real world other than your visual comparison of the simulated LED blink speed an a wall clock. And requiring those to be in synch is nonsense. Use a real board, and jtag debugger Nobody mentioned JTAG up to that point in the debugger --- only emulators. In the 8051 world, even though some JTAG-enabled variants now exist, "emulator" usually still refers to the old-fashioned "unwieldy drop-in replacement for the real CPU" kind of device. If the simulator handles core timing so that the peripherals are accurate in realtime [...]why not the core 8051 timers!? Because it doesn't do the former, there's no reason it should attempt the latter. You're mixing two possible meanings of "realtime" here. The simulator internally is realtime-correct, i.e. everything that happens within the simulated CPU has exactly correct timing behaviour relative to everything else in that category. What the simulator does not even try to do, while you insist it should, is establish any kind of relation between the simulated time (as displayed in the "Regs" pane) and real-world time (as displayed on your wristwatch), or any other time base you might think of. If you want to lock the simulated times of two instances of uV2 running in parallel, you'll at least have to write your own simulator extension DLLs to do it. I wouldn't bet on it being possible at all. The builting simulator is a very powerful tool for some jobs --- but it's not a panacea.
not really, the Ceibo's have a connector for each port and a row of led's with an identivcal connector, you plug in a little cable and a port has LEDs on all pins Erik
Nobody mentioned JTAG up to that point in the debugger --- only emulators. In the 8051 world, even though some JTAG-enabled variants now exist, "emulator" usually still refers to the old-fashioned "unwieldy drop-in replacement for the real CPU" kind of device. While you are 100% correct in this statement, it has been common to refer to the JUAG etc debuggers as "built in ICE" since the PC screen basically is the same Erik
View all questions in Keil forum