gnupic: Thread: gpasm-0.18.1

18.1 is now in CVS and on the web page:
http://www.dattalo.com/gnupic/gpsim.html
http://www.dattalo.com/gnupic/gpsim-0.18.1.tar.gz
(I did not create any rpms)

This version is probably less stable than what I'd normally release. But,
it is a development release. 19.0 will most probably be a week away.



There have been three major changes since 18.0:

1) Ralf has merged in the pinout window. 
It's really cool! Now you can click on the I/O pins of a graphical image
of the pic and change the state or the direction. There's a screen shot on
the web page:

http://www.dattalo.com/gnupic/gpsim.html

or go straight to it:
http://www.dattalo.com/gnupic/bb.gif

2) I re-designed the whole processor instantiation logic.
This should be transparent to you, but this is a significant change. I had
to do this because there was a design error in the way processors were
instantiated. I had previously neglected the way virtual functions were
being invoked while a class is constructed. In the process, I've cleaned
up the declaration of processors somewhat. I expect to make this a little
more clean in the coming days. (By clean up, I mean that before you had to
specify information in two separate places when ever you created a new
processor and added to the list of simulated processors. Now you only have
to do it once.)

3) Fixed scripting.
I don't how or when this broke, but it was horribly broken. The script
files in the examples subdirectory will dump core if you try to invoke
them. This has been fixed, but I still need to check out everything.

Minor changes:

a) Port D and Port E are now implemented on the 40 pin devices. The
peripherals tied to these I/O ports are not implemented (e.g. psp).

b) The 16C8xx devices (and in particularly the 16c877) are now supported.
This is an over statement somewhat, because all I've done is allowed the
instantiation of the devices, but have not provided the unique features
they offer (the 10-bit A/D , flash , and extended ram sizes are not
supported)


I'll be beating on gpsim in the coming days and trying to flush out a few
more bugs. I'll also begin adding more to the 16C8xx. I'm not sure if I'll
add the 14000 or not.

Scott

> 
> b) The 16C8xx devices (and in particularly the 16c877) are now supported.
> This is an over statement somewhat, because all I've done is allowed the
> instantiation of the devices, but have not provided the unique features
> they offer (the 10-bit A/D , flash , and extended ram sizes are not
> supported)
> 

Scott,
	up until now, whenever you said 16C877 I just assumed there was a
different product I hadn't heard of, but now i am convinced that all the
time you were meaning the 16F877. You threw me for a while.. so
basically, there's no 16c877. but thanks for adding features for the
16F877, or at least up and coming features.

matt

On Mon, 28 Feb 2000, Matthew Bowles wrote:

> 
> > 
> > b) The 16C8xx devices (and in particularly the 16c877) are now supported.
> > This is an over statement somewhat, because all I've done is allowed the
> > instantiation of the devices, but have not provided the unique features
> > they offer (the 10-bit A/D , flash , and extended ram sizes are not
> > supported)
> > 
> 
> Scott,
> 	up until now, whenever you said 16C877 I just assumed there was a
> different product I hadn't heard of, but now i am convinced that all the
> time you were meaning the 16F877. You threw me for a while.. so
> basically, there's no 16c877. but thanks for adding features for the
> 16F877, or at least up and coming features.

oops. At least it's an F877 in gpsim.

I just added EEPROM support to the 16F874/16F877. It's in CVS, but I
didn't make a tarball...

I'll be adding the program memory flash read/write next.

Ralf - Are you up to writing a program memory object viewer? I was
thinking of something based on gtksheet again, just program memory would
be displayed instead of register memory. 

Modifying program memory is going to have impact on the other windows.
Perhaps we should add xrefs to he object browser and source browser that
get invoked when program memory is changed. In the object browser, we
could update the window to reflect the new changes - perhaps highlighting
the modified locations with a unique color. For the source browser, I'm
not sure what we should do...

Does anyone have any suggestions on how 1) to present the contents of
program memory 2) to convey changes in the program memory?


Scott

Scott Dattalo wrote:
> 
> On Mon, 28 Feb 2000, Matthew Bowles wrote:
> 
> >
> > >
> > > b) The 16C8xx devices (and in particularly the 16c877) are now supported.
> > > This is an over statement somewhat, because all I've done is allowed the
> > > instantiation of the devices, but have not provided the unique features
> > > they offer (the 10-bit A/D , flash , and extended ram sizes are not
> > > supported)
> > >
> >
> > Scott,
> >       up until now, whenever you said 16C877 I just assumed there was a
> > different product I hadn't heard of, but now i am convinced that all the
> > time you were meaning the 16F877. You threw me for a while.. so
> > basically, there's no 16c877. but thanks for adding features for the
> > 16F877, or at least up and coming features.
> 
> oops. At least it's an F877 in gpsim.
> 
> I just added EEPROM support to the 16F874/16F877. It's in CVS, but I
> didn't make a tarball...
> 
> I'll be adding the program memory flash read/write next.
> 
> Ralf - Are you up to writing a program memory object viewer? I was
> thinking of something based on gtksheet again, just program memory would
> be displayed instead of register memory.
> 
> Modifying program memory is going to have impact on the other windows.
> Perhaps we should add xrefs to he object browser and source browser that
> get invoked when program memory is changed. In the object browser, we
> could update the window to reflect the new changes - perhaps highlighting
> the modified locations with a unique color. For the source browser, I'm
> not sure what we should do...
> 
> Does anyone have any suggestions on how 1) to present the contents of
> program memory 2) to convey changes in the program memory?
> 
> Scott
> 

Show adjusted program memory values in a new colour, and perhaps have an
option available to auto-scroll the window to show the memory block
containing the recently adjusted memory location. obivously you can't
display all at once ,but can we select multiple and not neccessarily
adjacent blocks of memory to display.. that would be useful, for
instance, when picc locates some code around the reset vector and some
near 7FFh and some more at the end of the memory bank (1FFFh for the
16F877)....

don't know if this is hard... but suggestions are suggestions as my late
uncle used to say.

kidding.
matt

On Mon, 28 Feb 2000, you wrote:
>Scott Dattalo wrote:
>> 
>> I'll be adding the program memory flash read/write next.
>> 
>> Ralf - Are you up to writing a program memory object viewer? I was
>> thinking of something based on gtksheet again, just program memory would
>> be displayed instead of register memory.

<off topic>
I just got one of these 'ergonomic' keyboard, and I have BIG problems
finding the keys. :-) I'll have to relearn typing, but we'll see how
it goes.
</off topic>

>> Does anyone have any suggestions on how 1) to present the contents of
>> program memory 2) to convey changes in the program memory?
>> 
>
>Show adjusted program memory values in a new colour, and perhaps have an
>option available to auto-scroll the window to show the memory block
>containing the recently adjusted memory location. obivously you can't
>display all at once ,but can we select multiple and not neccessarily
>adjacent blocks of memory to display.. that would be useful, for
>instance, when picc locates some code around the reset vector and some
>near 7FFh and some more at the end of the memory bank (1FFFh for the
>16F877)....

How would you want to define memory areas to display?

My first thought was to select memory in the object browser and have
a menu item to add it?

 / Ralf

On Mon, 28 Feb 2000, Ralf Forsberg wrote:

> <off topic>
> I just got one of these 'ergonomic' keyboard, and I have BIG problems
> finding the keys. :-) I'll have to relearn typing, but we'll see how
> it goes.
> </off topic>
> 
> >> Does anyone have any suggestions on how 1) to present the contents of
> >> program memory 2) to convey changes in the program memory?
> >> 
> >
> >Show adjusted program memory values in a new colour, and perhaps have an
> >option available to auto-scroll the window to show the memory block
> >containing the recently adjusted memory location. obivously you can't
> >display all at once ,but can we select multiple and not neccessarily
> >adjacent blocks of memory to display.. that would be useful, for
> >instance, when picc locates some code around the reset vector and some
> >near 7FFh and some more at the end of the memory bank (1FFFh for the
> >16F877)....
> 
> How would you want to define memory areas to display?

The .cod file has this information encoded in it. But you'd still have
this problem if the memory you wish to view is modified by your program
but not specified in your assembly file (e.g. suppose you want to use the
whole upper half of the program memory to store data acquired from some
measurement. You wouldn't necessarily define this area in your code.)

> 
> My first thought was to select memory in the object browser and have
> a menu item to add it?

I think that would be the way. Essentially have a tab that allows the
object browser select which mode to view the object code: either as
disassembled source or as a 2D spreadsheet.

Some of the features:

1) Highlight the active instruction (the one that the PC points too).
2) Show locations that have changed since the hex code was loaded in a
different background color the original code (like a light gray instead of
white).
3) Right click to bring up a menu that allows:
   a) Set execution break point on the select location(s)
   b) Set read break points
   c) Set write break points
4) Allow the user to edit the program memory within either the sheet or
the edit field at the top of the sheet (like the one that is in the
register viewer)
5) As an alternative to entering raw opcodes also allow mnemonics to be
entered.
6) Show the equivalent ascii in a column to the right of the program
memory (like in the register window). Perhaps allow the ascii column to be
decoded in one of two ways:
  - show the ascii equivalent for just the lower 8 bits (this
    would be useful for decoding retlw encoded strings)
  - show the ascii equivalent of the two 7-bit numbers that
    result when the 14-bit number is split in half. On the 18cxxx
    family, we could make this two 8-bit numbers. It doesn't make
    a whole lot of sense to do this on the 12-bit cores since the
    program memory is not readable.
7) ???


Scott

> 
> The .cod file has this information encoded in it. But you'd still have
> this problem if the memory you wish to view is modified by your program
> but not specified in your assembly file (e.g. suppose you want to use the
> whole upper half of the program memory to store data acquired from some
> measurement. You wouldn't necessarily define this area in your code.)
> 
> >
> > My first thought was to select memory in the object browser and have
> > a menu item to add it?
> 
> I think that would be the way. Essentially have a tab that allows the
> object browser select which mode to view the object code: either as
> disassembled source or as a 2D spreadsheet.
> 
> Some of the features:
> 
> 1) Highlight the active instruction (the one that the PC points too).
> 2) Show locations that have changed since the hex code was loaded in a
> different background color the original code (like a light gray instead of
> white).
> 3) Right click to bring up a menu that allows:
>    a) Set execution break point on the select location(s)
>    b) Set read break points
>    c) Set write break points
> 4) Allow the user to edit the program memory within either the sheet or
> the edit field at the top of the sheet (like the one that is in the
> register viewer)
> 5) As an alternative to entering raw opcodes also allow mnemonics to be
> entered.
> 6) Show the equivalent ascii in a column to the right of the program
> memory (like in the register window). Perhaps allow the ascii column to be
> decoded in one of two ways:
>   - show the ascii equivalent for just the lower 8 bits (this
>     would be useful for decoding retlw encoded strings)
>   - show the ascii equivalent of the two 7-bit numbers that
>     result when the 14-bit number is split in half. On the 18cxxx
>     family, we could make this two 8-bit numbers. It doesn't make
>     a whole lot of sense to do this on the 12-bit cores since the
>     program memory is not readable.
> 7) ???
> 
> Scott
> 


If you can go this far without to much trouble, perhaps it is becoming a
small step for gpsim to accept .asm files. i know there's more to
compiling than converting mnemonics to opcodes, but if you can do that..
well maybe there's a gpsim.0.19 w/ assembler.

as for the idea of entering instructions into program memory, sounds
very good.

Matt

On Mon, 28 Feb 2000, you wrote:
>On Mon, 28 Feb 2000, Ralf Forsberg wrote:
>
>> >> Does anyone have any suggestions on how 1) to present the contents of
>> >> program memory 2) to convey changes in the program memory?
>> >> 
>> >
>> >Show adjusted program memory values in a new colour, and perhaps have an
>> >option available to auto-scroll the window to show the memory block
>> >containing the recently adjusted memory location. obivously you can't
>> >display all at once ,but can we select multiple and not neccessarily
>> >adjacent blocks of memory to display.. that would be useful, for
>> >instance, when picc locates some code around the reset vector and some
>> >near 7FFh and some more at the end of the memory bank (1FFFh for the
>> >16F877)....
>> 
>> How would you want to define memory areas to display?
>
>The .cod file has this information encoded in it. But you'd still have
>this problem if the memory you wish to view is modified by your program
>but not specified in your assembly file (e.g. suppose you want to use the
>whole upper half of the program memory to store data acquired from some
>measurement. You wouldn't necessarily define this area in your code.)

I don't think we can add all of memory (in the case of a large
program), that would make the sheet really slow. We need a way to
select memory.

How much program memory is there in the largest pic?

 / Ralf

On Tue, 29 Feb 2000, Ralf Forsberg wrote:

> 
> On Mon, 28 Feb 2000, you wrote:
> >On Mon, 28 Feb 2000, Ralf Forsberg wrote:
> >
> >> >> Does anyone have any suggestions on how 1) to present the contents of
> >> >> program memory 2) to convey changes in the program memory?
> >> >> 
> >> >
> >> >Show adjusted program memory values in a new colour, and perhaps have an
> >> >option available to auto-scroll the window to show the memory block
> >> >containing the recently adjusted memory location. obivously you can't
> >> >display all at once ,but can we select multiple and not neccessarily
> >> >adjacent blocks of memory to display.. that would be useful, for
> >> >instance, when picc locates some code around the reset vector and some
> >> >near 7FFh and some more at the end of the memory bank (1FFFh for the
> >> >16F877)....
> >> 
> >> How would you want to define memory areas to display?
> >
> >The .cod file has this information encoded in it. But you'd still have
> >this problem if the memory you wish to view is modified by your program
> >but not specified in your assembly file (e.g. suppose you want to use the
> >whole upper half of the program memory to store data acquired from some
> >measurement. You wouldn't necessarily define this area in your code.)
> 
> I don't think we can add all of memory (in the case of a large
> program), that would make the sheet really slow. We need a way to
> select memory.

Have you heard anything from Adrian recently about gtksheet's efficiency
problems?

> 
> How much program memory is there in the largest pic?

Some of the 18cxxx parts have up to 32k internal. The 16f877 has 8k.

I'm not sure if there's a convenient way of getting around the problem of
having to show all of memory. I haven't tried to dynamically vary the
characteristics or attributes of gtk sheet, although I know it's possible
(the demos in gtk sheet let you add and delete rows dynamically). So, one
possibility could be to notify the gui whenever a program memory location
is accessed. Perhaps we can limit it to program memory writes. But at some
point, the user is going to want modify program memory that hasn't yet
been accessed by either the .cod files or by the simulated pic. So we'll
still be stuck with the problem of selecting which portion of memory to
view. Furthermore, eventually someone is going to want to be able to see
*all* of the program memory. I guess we need to convince Adrian to improve
gtksheet's efficiency...


Scott

On Tue, 29 Feb 2000, Matthew Bowles wrote:

> If you can go this far without to much trouble, perhaps it is becoming a
> small step for gpsim to accept .asm files. i know there's more to
> compiling than converting mnemonics to opcodes, but if you can do that..
> well maybe there's a gpsim.0.19 w/ assembler.

I don't think so... It's one thing to decode an instruction, but an
entirely different thing to implement an assembler. I'd spawn gpasm before
writing a gpsim assembler. What I was thinking about instead was to accept
one assembly instruction at a time. I couldn't read a raw assembly file
(unless it was formatted perfectly) because often times there are forward
references. (gpasm is a two-pass assembler - on the first pass, all of the
forward references are resolved and on the second the code is generated).

I doubt that this feature will appear in gpsim-0.19.0. There's a whole lot
of infrastructure that would have to be created to support it. (But
perhaps creating a one-line assembly program and spawning it off to gpasm
wouldn't be a bad idea...) I only mentioned it to throw out some ideas and
stimulate some discussions like these.

Scott