« Return to Thread: Status on enhanced 14-bit instruction set
Re: Status on enhanced 14-bit instruction set
by Marko Kohtala
::
Rate this Message:
Hi.
I'm not really a maintainer, but I have been slowly working on
changing the tools to work on bytes rather than instructions. This is
necessary for 100% compatibility with MPASM especially in PIC18
code_pack sections.
While at it I changed considerably how you add a new device class.
The changes I've done almost pass all tests (or almost all those tests
that passed before, and some tests that did not pass before as well as
some new tests). There is only some gplink problems remaining. If
someone wants to start work on this new device class, or otherwise
wants to see what I have, I wish he tells me. I'll then take the
effort to either fix the most severe problems and commit to trunk or
commit it into a branch.
Marko
On Sat, Apr 3, 2010 at 12:12 AM, Byron Jeff <byronjeff@...> wrote:
> On Fri, Feb 12, 2010 at 08:18:26PM -0500, David wrote:
>> If you do go that route and have any questions about what specific commands to run, feel free to email me directly.
>>
>
>> I doubt anyone's working on implementing it right now, but I'm not sure.
>> I haven't been a gputils *user* for some time (haven't used PICs lately),
>> so I don't develop on it anymore.
>
> So that begs the question who is the maintainer of gputils at this point in
> time?
>
> This thread did not parse with me the first go round. But just earlier this
> week I got a hit on an 16F1826 while poking around for the cheapest PIC
> that had both a USART and I2C. In short:
>
> it was a jaw dropping experience.
>
> I just bought 10 16F1936s, 3 16F1937, and 5 16F1826s. I'm waiting with
> baited breath for the 12F1223s to come out in the next month or so. The
> price point and features makes this enhanced family the goto chip for
> virtually any new 16F application. No more worrying about banks, full stack
> access, movable peripheral pins, linear RAM access (and 512 bytes of it
> too).
>
> jaw dropping.
>
> I spent my spring break building up an integrated FORTH interpreter for the
> 16F family. I then started to port to the 18F. The multiple FSRs with auto
> increment/decrement and eliminating banks shrank and sped up the code
> significantly.
>
> The enhanced 16F chips have both these features.
>
> So in short enhanced 16F features need to be implemented in the main line
> of gputils ASAP. I'm willing to pitch in. I just need to know who to
> coordinate with.
>
> Let me say it again: jaw dropping.
>
> I have a 16F88 makes the 16F84 obsolete. That page is now going to be taken
> down.
>
> It may be heresy, but there's another very slender PIC assembler out there
> called SMALPIC. You can find it here:
>
> http://www.cs.uiowa.edu/~jones/cross/pic
>
> Trivial parsing because it breaks ranks with MPASM. I'm wondering as a
> quick fix if it could be updated with the enhanced instructions.
>
> Any help would be appreciated.
>
> BAJ
>
>>
>> David
>>
>> ----- Original message -----
>> >??
>> > David
>> >
>> > Thanks.?? This sounds complicated - beyond my experience level.
>> >
>> > If nothing else materializes I might give it a try.?? The 16f1xxx parts
>> > seem to be accepted and becoming mainstream so presumably
>> > gpasm will need to support them.?? Do you know if anyone is
>> > working on it.
>> >
>> > Thanks
>> >
>> > Roger
>> >
>> > David wrote:
>> > > gpasm doesn't support the enhanced 14-bit instructions at all. Joseph did send
>> > > a patch to this list some time ago to support it, but the parser/lexer gave
>> > > compile warnings and it looked like it might mess up other things, so I didn't
>> > > pull it into the mainline. Incidentally, the parser/lexer are horrible to work
>> > > with, so it's no small task to get rid of the warnings, and I'm not doing any
>> > > work on gputils anymore.
>> > >
>> > > You should be able to patch and compile to get it running. If you need new
>> > > features from gputils and the patch won't apply anymore, try getting it from
>> > > SVN, svn update to an older version, apply the patch, and SVN update back to
>> > > the latest. I know it's a pain, but hopefully it'll get you through.
>> > >
>> > > David
>> > >
>> > > ----- Original message -----
>> > >?? ??
>> > > > Thanks Joseph
>> > > >
>> > > > So, the 16f1933 has the enhanced instruction set but the current
>> > > > version of gpasm does not seem to recognize it (I only tried
>> > > > the BRA instruction for a quick test). In the absence of an option
>> > > > to to pull in the extra instructions (I tried the -y option) I suppose
>> > > > I need the old version. I see a thread back in June 2008 that
>> > > > mentions the PIC 16 architecture but it doesn't seem to give
>> > > > instructions on how to use it.
>> > > >
>> > > > If I use an old version of gpasm, presumably it wont recognize the
>> > > > 16f1933. So, what is the procedure for getting it to emit the
>> > > > enhanced code?
>> > > >
>> > > > I'm using Debian.
>> > > >
>> > > > Thanks again
>> > > >
>> > > > Roger
>> > > >
>> > > > Joseph.Julicher@... wrote:
>> > > >?? ?? ?? ??
>> > > > > I added the enhanced instruction set to GPASM 2 years ago when we were
>> > > > > defining the instruction set.?? I passed the modifications on to the
>> > > > > list.
>> > > > >
>> > > > > I can provide the version (old) of GPASM that we used to generate code
>> > > > > for the chip simulations.
>> > > > >
>> > > > > Joseph Julicher
>> > > > > Applications Manager
>> > > > > Microchip Technology, Inc.
>> > > > >
>> > > > > -----Original Message-----
>> > > > > From: Roger Dellor [mailto:roger@...]
>> > > > > Sent: Friday, February 12, 2010 2:23 PM
>> > > > > To: gnupic@...
>> > > > > Subject: Status on enhanced 14-bit instruction set
>> > > > >
>> > > > >
>> > > > >??
>> > > > >
>> > > > > I'm beginning to write assembler code for the p16f1827 (and new to this
>> > > > > list).?? I have version 0.13.7, which I believe is the latest, and it
>> > > > > does not
>> > > > > support this part.?? So, to get started, I'm pretending that I have a
>> > > > > 16f1933, and modifying the 16f1933.inc file to reflect the 1827.?? If I
>> > > > > can't
>> > > > > get a 16f1827.inc file from Microchip - the request is pending - I can
>> > > > > write
>> > > > > my own, but gpasm does not appear to recognize the enhanced
>> > > > > instruction set which I would like to use.
>> > > > >
>> > > > > So, if I'm not doing something wrong, does anyone know when gpasm
>> > > > > will support the extra instructions in the enhanced instruction set.
>> > > > >
>> > > > > Thanks
>> > > > >
>> > > > > Roger
>> > > > >
>> > > > >?? ?? ??
>> > > > >?? ?? ?? ?? ?? ??
>> > > > --
>> > > >
>> > > >
>> > > > cell?? ?? ?? 650 823-5307
>> > > > home?? ?? ?? 650 969-8227
>> > > > e-mail roger@...
>> > > >
>> > > >
>> > > > ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: gnupic-unsubscribe@...
>> > > > For additional commands, e-mail: gnupic-help@...
>> > > >
>> > > >?? ?? ?? ??
>> > >
>> > >
>> > >?? ??
>> >
>> > --
>> >
>> >
>> > cell?? ?? 650 823-5307
>> > home?? ?? 650 969-8227
>> > e-mail roger@...
>> >
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...
I'm not really a maintainer, but I have been slowly working on
changing the tools to work on bytes rather than instructions. This is
necessary for 100% compatibility with MPASM especially in PIC18
code_pack sections.
While at it I changed considerably how you add a new device class.
The changes I've done almost pass all tests (or almost all those tests
that passed before, and some tests that did not pass before as well as
some new tests). There is only some gplink problems remaining. If
someone wants to start work on this new device class, or otherwise
wants to see what I have, I wish he tells me. I'll then take the
effort to either fix the most severe problems and commit to trunk or
commit it into a branch.
Marko
On Sat, Apr 3, 2010 at 12:12 AM, Byron Jeff <byronjeff@...> wrote:
> On Fri, Feb 12, 2010 at 08:18:26PM -0500, David wrote:
>> If you do go that route and have any questions about what specific commands to run, feel free to email me directly.
>>
>
>> I doubt anyone's working on implementing it right now, but I'm not sure.
>> I haven't been a gputils *user* for some time (haven't used PICs lately),
>> so I don't develop on it anymore.
>
> So that begs the question who is the maintainer of gputils at this point in
> time?
>
> This thread did not parse with me the first go round. But just earlier this
> week I got a hit on an 16F1826 while poking around for the cheapest PIC
> that had both a USART and I2C. In short:
>
> it was a jaw dropping experience.
>
> I just bought 10 16F1936s, 3 16F1937, and 5 16F1826s. I'm waiting with
> baited breath for the 12F1223s to come out in the next month or so. The
> price point and features makes this enhanced family the goto chip for
> virtually any new 16F application. No more worrying about banks, full stack
> access, movable peripheral pins, linear RAM access (and 512 bytes of it
> too).
>
> jaw dropping.
>
> I spent my spring break building up an integrated FORTH interpreter for the
> 16F family. I then started to port to the 18F. The multiple FSRs with auto
> increment/decrement and eliminating banks shrank and sped up the code
> significantly.
>
> The enhanced 16F chips have both these features.
>
> So in short enhanced 16F features need to be implemented in the main line
> of gputils ASAP. I'm willing to pitch in. I just need to know who to
> coordinate with.
>
> Let me say it again: jaw dropping.
>
> I have a 16F88 makes the 16F84 obsolete. That page is now going to be taken
> down.
>
> It may be heresy, but there's another very slender PIC assembler out there
> called SMALPIC. You can find it here:
>
> http://www.cs.uiowa.edu/~jones/cross/pic
>
> Trivial parsing because it breaks ranks with MPASM. I'm wondering as a
> quick fix if it could be updated with the enhanced instructions.
>
> Any help would be appreciated.
>
> BAJ
>
>>
>> David
>>
>> ----- Original message -----
>> >??
>> > David
>> >
>> > Thanks.?? This sounds complicated - beyond my experience level.
>> >
>> > If nothing else materializes I might give it a try.?? The 16f1xxx parts
>> > seem to be accepted and becoming mainstream so presumably
>> > gpasm will need to support them.?? Do you know if anyone is
>> > working on it.
>> >
>> > Thanks
>> >
>> > Roger
>> >
>> > David wrote:
>> > > gpasm doesn't support the enhanced 14-bit instructions at all. Joseph did send
>> > > a patch to this list some time ago to support it, but the parser/lexer gave
>> > > compile warnings and it looked like it might mess up other things, so I didn't
>> > > pull it into the mainline. Incidentally, the parser/lexer are horrible to work
>> > > with, so it's no small task to get rid of the warnings, and I'm not doing any
>> > > work on gputils anymore.
>> > >
>> > > You should be able to patch and compile to get it running. If you need new
>> > > features from gputils and the patch won't apply anymore, try getting it from
>> > > SVN, svn update to an older version, apply the patch, and SVN update back to
>> > > the latest. I know it's a pain, but hopefully it'll get you through.
>> > >
>> > > David
>> > >
>> > > ----- Original message -----
>> > >?? ??
>> > > > Thanks Joseph
>> > > >
>> > > > So, the 16f1933 has the enhanced instruction set but the current
>> > > > version of gpasm does not seem to recognize it (I only tried
>> > > > the BRA instruction for a quick test). In the absence of an option
>> > > > to to pull in the extra instructions (I tried the -y option) I suppose
>> > > > I need the old version. I see a thread back in June 2008 that
>> > > > mentions the PIC 16 architecture but it doesn't seem to give
>> > > > instructions on how to use it.
>> > > >
>> > > > If I use an old version of gpasm, presumably it wont recognize the
>> > > > 16f1933. So, what is the procedure for getting it to emit the
>> > > > enhanced code?
>> > > >
>> > > > I'm using Debian.
>> > > >
>> > > > Thanks again
>> > > >
>> > > > Roger
>> > > >
>> > > > Joseph.Julicher@... wrote:
>> > > >?? ?? ?? ??
>> > > > > I added the enhanced instruction set to GPASM 2 years ago when we were
>> > > > > defining the instruction set.?? I passed the modifications on to the
>> > > > > list.
>> > > > >
>> > > > > I can provide the version (old) of GPASM that we used to generate code
>> > > > > for the chip simulations.
>> > > > >
>> > > > > Joseph Julicher
>> > > > > Applications Manager
>> > > > > Microchip Technology, Inc.
>> > > > >
>> > > > > -----Original Message-----
>> > > > > From: Roger Dellor [mailto:roger@...]
>> > > > > Sent: Friday, February 12, 2010 2:23 PM
>> > > > > To: gnupic@...
>> > > > > Subject: Status on enhanced 14-bit instruction set
>> > > > >
>> > > > >
>> > > > >??
>> > > > >
>> > > > > I'm beginning to write assembler code for the p16f1827 (and new to this
>> > > > > list).?? I have version 0.13.7, which I believe is the latest, and it
>> > > > > does not
>> > > > > support this part.?? So, to get started, I'm pretending that I have a
>> > > > > 16f1933, and modifying the 16f1933.inc file to reflect the 1827.?? If I
>> > > > > can't
>> > > > > get a 16f1827.inc file from Microchip - the request is pending - I can
>> > > > > write
>> > > > > my own, but gpasm does not appear to recognize the enhanced
>> > > > > instruction set which I would like to use.
>> > > > >
>> > > > > So, if I'm not doing something wrong, does anyone know when gpasm
>> > > > > will support the extra instructions in the enhanced instruction set.
>> > > > >
>> > > > > Thanks
>> > > > >
>> > > > > Roger
>> > > > >
>> > > > >?? ?? ??
>> > > > >?? ?? ?? ?? ?? ??
>> > > > --
>> > > >
>> > > >
>> > > > cell?? ?? ?? 650 823-5307
>> > > > home?? ?? ?? 650 969-8227
>> > > > e-mail roger@...
>> > > >
>> > > >
>> > > > ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: gnupic-unsubscribe@...
>> > > > For additional commands, e-mail: gnupic-help@...
>> > > >
>> > > >?? ?? ?? ??
>> > >
>> > >
>> > >?? ??
>> >
>> > --
>> >
>> >
>> > cell?? ?? 650 823-5307
>> > home?? ?? 650 969-8227
>> > e-mail roger@...
>> >
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...
« Return to Thread: Status on enhanced 14-bit instruction set
| Free embeddable forum powered by Nabble | Forum Help |
