Re: [Simulavr-devel] RFC: a few feature ideas

[Joel Sherrill]

Michael N. Moran wrote:
> Joel Sherrill wrote:
>   
> > As I have been working on getting a feedback
> > and testing framework built for a real application,
> > I have come across a few things I think would
> > be useful.  I would like to bounce them all off
> > of you.
> >     
>
> Is that going to hurt? ;)
>
>   
:)
> > + A mechanism to load the contents of the eeprom
> > to a file and subsequently save it to that file.
> >     
>
> That sounds useful. I guess there may be cross
> platform issues with file I/O, but ... other than
> that :)
>
>   
Comment on another thread.
> > + exit command from feedback/ui. So it can determine
> > when to terminate a simulation.
> >     
>
> I'm unqualified to comment on that, never having
> used it.
>
>   
Need depends on separate feedback process
driving test cases.  When they are over, you
want to kill AVR to move on to next test case.
> > + optional time "pulse" from simulated avr to
> > feedback/ui so it can stay in time sync with
> > simulation time.  I was thinking of an optional
> > object with a configurable time to pulse.
> >     
>
> Couldn't the ui just "be" another SimulationMember
> and get the same "clock" information that other
> simulated devices receive? Oh ... wait .. the
> UserInterface class is already a SimulationMember.
> I guess I don't understand the issue.
>
>   
There is the ui part of simulavr that is inside
the AVR simulation and the external part
in another process that interacts with it.
It is completely independent from a timing
perspective.
> > + possibly having the simulator stop after the
> > time pulse until the ui/feedback says continue.
> > This would give the ui/feedback time to update
> > the "real world" in sync with the simulated avr.
> > I have done similar things in the past and frame
> > rates of 100 Hz (stop simulated processor every
> > 10 milliseconds of sim time) for updates of
> > real world.
> >     
>
> I don't understand how this would be used.
>
>   
Without seeing the process separation between
"AVR simulator" and "GUI or feedback" I can understand
not seeing the need for this. 

I am not sure yet it is absolutely needed but say
you have a complicated "world simulation" providing
feedback to the simulated AVR program.  It may be
necessary to stop AVR time while the external world
is updated.  So you get "frames" of the external world
in effect.  Robot movement could be updated 1000 times
a simulated second and perfectly match.

Simulated time needs to be kept in sync.
> > Comments appreciated.
> >     
>
> Sorry I couldn't give "useful" comments...
> On the other hand, the bounce didn't hurt either. :-)
>
>
>