gnupic: Re: [gnupic] gpsim-0.22.0-RC3 led_test questions
Subject:
Re: [gnupic] gpsim-0.22.0-RC3 led_test questions
From:
"Maxim Wexler" ####@####.####
Date:
10 Nov 2006 18:22:35 +0000
Message-Id: <a0811460611101022v3130f71k5dfe7065ca8cfaa@mail.gmail.com>
On 11/10/06, Scott Dattalo ####@####.#### wrote:
>
> Maxim Wexler wrote:
>
> >> From Simulation mode->Without gui(fastest simulation)
> >
> > ->Realtime without gui
> > ->Realtime with gui
> >
> > All crash the console--the other modes work OK.
>
> What do you mean by "crash the console"? I just tried them out and it
> appears that both the 'Realtime without gui' and 'Realtime with gui'
> behave as 'Realtime without gui'. One idiosyncrasy I did note was that
> the first 'run' broke immediately, but the second one worked as
> expected. Something indeed is fishy, but I see no crash.
Should have said "gui seizes". I start gpsim in the Konsole and when the
gui locks up I have to click on the Konsole and do ctrl-c to get back to
the prompt and start over.
>
> > I hope I don't sound nit-picking here but if you aren't using the gui
> how
> > can you tell what's going on in the simulation since there is no
> > hardware to
> > connect to?
>
> I'm not sure I understand the question. The purpose of inhibiting the
> gui is to speed up the simulation. The more time your PC is repainting
> windows the less time it can spend running the simulation. It may make
> better sense to allow update rates to be specified in terms of real time
> and not in terms of simulation cycles (e.g. update twice a second).
But how can you tell? There's no gui, right? Do you set a break point and
check a log?
Oh, don't feel like you're nitpicking. It doesn't bother me personally
> and in fact I'd encourage criticism and suggestion over silence. If
> something is frustrating, let me know; I'd rather help out than see you
> give up and use other (obviously inferior :) simulators.
BTW did you notice in the source the mask for 6 and B is the same, 0x7b?
This outputs the same thing: 'b'.
Maxim
