2009/10/11 Alan Grimes <agri...@speakeasy.net>
> Zoltan Padrah wrote:
> >> There is also a bug when closing files directly shown in screen (created
> in
> >> /temp/k.. ) that can be easily fixed (just don't creating a new temp
> file).
> >
> > This is a new one for me. Which mail haven't I read?
> >
> >> For the piccomponent is not very difficult to add a property to choose
> clock
> >> MHz and add a loop in simulator to manage speed.
>
> > This is tricky. Some odd behaviour might occur if we have 2 loops in
> > the simulator.
>
> I'm pretty sure PIC Components already are handled in the simulator.
> There are about 4 lines having to do with them. I haven't done anything
> to them because I'm not into digital. it should be possible to rework
> that so that it can synchronize with the
>
Yes, the loop i'm talking about is just there, that lines you mention is a
"for loop" that call every gpsimprocessor and run 1 step in gpsim.
the only thing the loop does is: depending on the clock speed of each
piccomponent 1,2,3,4 or 5 steps will be executed on gpsim in every logic
update.
But for this to work a new property is needed in piccomponent to choose the
clock speed, and two new functions in gpsimprocessor like: set_clocksteps()
to call from piccomponent and get_clocksteps() to call from simulator. This
is the way i did, but i'm sure there are better ones.
This is just a workaround, not a real solution to run pics at realtime, but
i think this is better than runing the pic a a fixed rate of 1e6 steps/s
(=4MHZ pic clock)
> >> Running the qtimer at 10 ms does the simulation to go at real time for
> me.
>
> > Changeing the simulator's "tick" period should be done one day. There
> > are quite a few issues with the simulator, starting from the total
> > lack of documentation about it.
>
> Have you seen the current SVN head version of the simulator? It's
> considerably simpler than the previous versions and should be easier to
> grok.
>
>
> --
> New president: Here we go again...
> Chemistry.com: A total rip-off.
> Powers are not rights.
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Ktechlab-devel mailing list
> Ktechlab-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
>
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Ktechlab-devel mailing list
Ktechlab-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
