realtime timer simulation

there HAS to be a way to do this.

Says who?

allows us to link the 8051 serial port to a real COM port acting in realtime/clocktime/baudtime.

Whether this link is anything like "real time" remains to be seen. The documentation of uV2 is scarily thin in this area --- if there were some reliable timing involved, I would guess Keil would have proudly boasted that in the documentation.

Actually, trying to do pretty much anything in hard real-time under any modern Windows is a lost cause. It's simply not what these platforms are meant for. 24 Hz is a harder requierement than keeping the usual Ms-DOS timer (18 Hz), and Windows is already somewhat flaky in its support of that.

at 9600, the binding of PC COM2 to the second virtual serial port can introduce a timebase with 102uS base period into the simulator

No, it can't. 104 us is the bit time of a 9600 baud line. That's only relevant inside the PC's UART. The time between events leaving that UART is the byte transmission time, which is about 1 ms. And that's without considering the fact that they all have FIFOs these days, which would cut the event rate by another order of magnitude.

I told you several posts upstream: you'll almost certainly have to consider writing a problem-specific debugger/simulator extension DLL go get this done, or forget about doing this in the simulator. The simulator is unfit by design for this kind of work.

there HAS to be a way to do this.

Says who?

allows us to link the 8051 serial port to a real COM port acting in realtime/clocktime/baudtime.

Whether this link is anything like "real time" remains to be seen. The documentation of uV2 is scarily thin in this area --- if there were some reliable timing involved, I would guess Keil would have proudly boasted that in the documentation.

Actually, trying to do pretty much anything in hard real-time under any modern Windows is a lost cause. It's simply not what these platforms are meant for. 24 Hz is a harder requierement than keeping the usual Ms-DOS timer (18 Hz), and Windows is already somewhat flaky in its support of that.

at 9600, the binding of PC COM2 to the second virtual serial port can introduce a timebase with 102uS base period into the simulator

No, it can't. 104 us is the bit time of a 9600 baud line. That's only relevant inside the PC's UART. The time between events leaving that UART is the byte transmission time, which is about 1 ms. And that's without considering the fact that they all have FIFOs these days, which would cut the event rate by another order of magnitude.

I told you several posts upstream: you'll almost certainly have to consider writing a problem-specific debugger/simulator extension DLL go get this done, or forget about doing this in the simulator. The simulator is unfit by design for this kind of work.

One problem here is that there are two distinct time domains:

1. Simulation Time
2. Real Time

I think it comes down to "product concept", not academics.

If you think of the simulator as a showoff for the microcode emulation in the core, then one simulates "performance" of the core, and show that one can nicely emulate the 8051 instruction set... Presumably, professionals in this space compete on the accuracy of the core timing and the instruction decoding, which is no doubt full of theoretical issues to war over, for fun.

If the tool is for software types to build demos, as a rapid developement tool, pre board design/manufacturing, it needs a prototyping emphasis - and concept work for THAT audience.

The fun part of the simulator was always the extension modules: seeing the I2C device, visually, was fun. Seeing the LED visualization was fun. Getting blinky() to work, naturally, could have been fun... acting as a sanity check.

I was almost tempted to write my own extension for fun... now Im not. The product concept is evidently flawed - for my purposes. I have no interest whatsoever in the accuracy of simulation, re core timing. Its irrelevant to making a mockup of a product, that will use a commoidity uP on commodity boards.

So there you have the result:

I cannot show my customer a blinking led on the simualted front panel (or, rather, it blinks at about 20ms rate, clocktime, on my CPU)

I cannot send packets through the redirected COM port to the simulator process, and have the IP stack behave normally re protocol exceptions, based on timers.

This seems a shame, as both features are almost there, and the tool is almost really valuable for rapid application development.

While I could probably now introduce a 50mS period external signal into the simulator as a "trick", I dont think Ill bother. I'd be fighting the product concept, and thats rarely a good idea.

Peter.

May I add a comment just to establish some perspective? I remember writing in asm51 (no C compiler yet), using my own DOS batch files as my make utility, and debugging the code with port pins and an oscilloscope. The first time I used PK51 I was so happy and I couldn't believe how much this tool allowed me to do. It was like being a caveman who discovers fire, the wheel, and refrigeration all at once. When a slick new 51 variant comes out sure I'd like to have the new features supported in simulation right away but that never holds me back, the Keil tools are great.

I had too requirements to run simulator 'nearly' realtime before. Even when I debug my communication stack's and profile my code. I did some work on add-on-own dll to regulate simulation run time. But now I haven't functional dll. I'm ready to cooperate.
Roman

a bit of dictionary definition makes me wonder

how can "simulate" be "real"

I just wonder

Erik

I think the implication/desire is that if simulation speed >= real-time then simulation speed could be constrained or synchronized with real-time.

Unfortunately, simulation speed may be <,=,> real-time. It's still useful, but it isn't real-time.

Presonally, I want the simulator to run as fast as possible (and hopefully, much faster than real-time).

Jon