#2 Suggestion for future implementation of simulator
Notes for some future release of IC:
In my opinion, the simulator should be the selected
option when the port and hardware option "connect
later" is taken. Ideally, with this approach, the
standard interaction window would be the only
interaction window. there would be no option to
actually download software to a real controller while
the simulator is in use, and the IC interfaces for
tools such as; array upload, list files, list globals,
would all act on the simulator instead of the actual
controller. Whenever an actual controller is
configured, the simulator would be unavailable. This
should avoind any redifinition problems between the SIM
library and the controller library. it also would allow
a visual interface to connect some signal generators
(sine, sawtooth, square wave, random, and etc) to
simulator ports to create some test conditions for
program development within the simulator.
In an really ideal world the simulator would support
multithread execution and the current execution source
line would be highlighted by thread.
The simulator pause button should switch to resume when
paused, execute should toggle to reset. All buttons
visible should be valid when enabled.
In a truly completely ideal world the simulator would
be an emulator so that memory addresses used by the
controller (motor bits, ports, interrupt routines, et.
al) would match the actuall controller memory map. I
started to research the HC11 emulators to see if I
could hack one to act like it was on the other side of
a serial port and connect the IC to it. I did not
succeed, but I belive the technique is established for
Windows development of Palm sofware as an example.
Just some thoughts. Feel free to comment or add as desired.
Logged In: YES
user_id=1033039
Ok, let's see here.
On the transparent simulator idea... I think this may have
been what was originally asked for by David and I
misinterpreted it. I don't think it'd be too difficult to
convert to that. However, what about sensor settings? I
understand your idea about signal generators, but I think
this idea would fly right over the heads of most the people
we distribute this to. Combining it with the idea
biolizard89 had about graphical sensor settings might be an
interesting idea.
Code stepping is getting closer to being a reality as I
learn more and more about the internals of the compiler,
which I'm doing by fixing the listed bugs. I can at least
see how to do global/local variable tracking now.
The pause/execute button idea is good, I might bug that
against myself for v5, since it's really a usability issue
more than a feature that needs to be added.
As for the emulator thing.... If we had a larger development
team (i.e. more than just me :) ), maybe, but what we have
to do for one board we have to do for all boards in terms of
IC features, and getting emulators together for all the
processors we use might be difficult. It's an interesting
idea, but yeah, that'd have to be a really, really ideal world.
Logged In: YES
user_id=1176716
Looked around sourceForge a little and found these
"emulators" I haven't actyually researched them to see if
they might actually meet the need, but there might be some
value in thees code sources to the simulator effort:
Game Boy Advance emulator: https://sourceforge.net/projects/vba/
LegoOs emulator:
https://sourceforge.net/projects/emulegos/