realtime timer simulation

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.

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