gnupic: Thread: problem in 19.2

Scott,

I am almost certain someone raised this issue about parse errors when
gpsim first loads.

it's like this
***ERROR: parse error, expecting '$'

i checked through the mailing list for the last few weeks, can't find
the comments about this..  anyhow, can't see that it even affects the
running of the program as yet, but it's not a good look... errors for
nothing.

i just did a quick check, no new problems.
And I really hate to say this, pretend I'm whispering. ** TMR1 and TMR2
register updates **   still not working, hard to see if time-outs are
happening.

matt

On Thu, 1 Jun 2000, Matthew Bowles wrote:

> Scott,
> 
> I am almost certain someone raised this issue about parse errors when
> gpsim first loads.
> 
> it's like this
> ***ERROR: parse error, expecting '$'

Despite what it says, it's not an error (this time). What's happening is that I
had to modify the parsing logic (in parser.yy) by adding a YYABORT when I KNOW
that the command entry is completed. Right after making the 0.19.2 release, I
discovered that the 'load' command in particular must have been skipped and
didn't get the necessary YYABORT. So the parser parses the load command
properly, but then has more information (a new line character) in the parser
buffer, but no parser state that maps to that information. It's really simple to
fix, but right now I'm just not going to have time to do it. Sorry.

> 
> i checked through the mailing list for the last few weeks, can't find
> the comments about this..  anyhow, can't see that it even affects the
> running of the program as yet, but it's not a good look... errors for
> nothing.
> 
> i just did a quick check, no new problems.
> And I really hate to say this, pretend I'm whispering. ** TMR1 and TMR2
> register updates **   still not working, hard to see if time-outs are
> happening.

I haven't looked at these in quite a while (in over a year). Like over half of
the bugs in gpsim, this one is yet another manifestation of gpsim out growing
itself. In other words, this was working at one time, but while adding some
other new feature I broke it. Damn, I hate it when that happens!

I'll definitely look at this when I get back from my trip.

Regards,
Scott

On Thu, 1 Jun 2000, Matthew Bowles wrote:

> Scott,
> 
> I am almost certain someone raised this issue about parse errors when
> gpsim first loads.
> 
> it's like this
> ***ERROR: parse error, expecting '$'
> 
> i checked through the mailing list for the last few weeks, can't find
> the comments about this..  anyhow, can't see that it even affects the
> running of the program as yet, but it's not a good look... errors for
> nothing.
> 
> i just did a quick check, no new problems.
> And I really hate to say this, pretend I'm whispering. ** TMR1 and TMR2
> register updates **   still not working, hard to see if time-outs are
> happening.

I'm back home. 

The parse error thing has been fixed, but is not yet in CVS.

I'll review the TMR1 and TMR2 module stuff this week and fix whatever has
broken.

After that, I intend to enhance the square wave stimulus to allow it to preempt
the simulation when there is a change of states. As I said in an earlier
message, the square wave stimulus state can only be ascertained by reading the
I/O port to which the stimulus is attached. The main effect that you'll notice
with this behavior is that the square wave stimulus is unable to initiate a
'interrupt on change' interrupt, or another example is that it's unable to clock
TMR0. If you use an "asynchronous" stimulus, you can get around this problem
(because asynchronous stimuli will preempt the simulation when they change
states).


I expect these tasks to consume about 5 to 8 days time (at the rate I work -
which 1 or 2 hours at most per day).

The next step will be to round out the details that I've already begun on the
module interface. Once this is done, expect version 0.20.0 around the end of
June.

Scott