gnupic: GPAL loops bug?
Subject:
Re: GPAL loops bug?
From:
####@####.####
Date:
27 Oct 2004 11:04:36 +0100
Message-Id:
####@####.#### wrote:
> > How do you know "no looping happens" ?
David McNab wrote;
> By single-stepping with gpsim
WOW !! GPAL does single-stepping ?
> > Use sucessive refinement:
> > 1. start with the simplest possible code-piece,
> > 2. be able to bebug/analyse right down to hex instructions level.
>
> There's a time when it's more appropriate to hand the issue over to the
> author, especially when the author is active and sincerely responsive.
Yes the response in this group is fantastic.
But if you 'ride the horse too hard' it might get burn out.
It's always good to feedback:
* I did abc,
* got xyz..
both to reduce the work load on the developer, and spread knowledge
to other users.
We'd like to see the GPAL 'hex-generated' compared with that of
picforth, which we know you are using.
I can't remember if picforth wrote hex or if I just used a hex editor
to cutNpaste the 'obj-file'.
== Chris Glur.
> > PS. does any one know if Miniature cards [flash] are accessed
> >parallel random like normal RAM or serial.
John Sheahan wrote;
> my SD cards have 9 pins - I'd take a punt that its fairly serialized .
> john
Yes, I got an Olympus D1000 digital voice recorder [discontinued
model for a good price], and the local agents don't want to talk to
me. Inet ambigious reports refer to bigger size memory cards being
usable.
So I did a pin count to calculate if a 4 times bigger flash-mem was
drivable. Thinking that perhaps 2 [or more] adr. lines were un-used.
The reported adaptor to PC: either via PCMIA or a par-port, may not
be easily available, so I may want to hack my own.
If the interfacing of the various flash-mem models is secret, then its
a problem ?
BTW I think pic is becoming absurd with it's 'expansion'.
Like trying to evolve a wheel barrow to a truck.
An approprate application would be the uProc which interfaces
the flash in a smart-card ?
