gnupic: Thread: Re: [gnupic] Error in default link script for pic16f676

On Fri, 8 Jun 2007 16:59:31 -0700
"R. Timothy Edwards" ####@####.#### wrote:

> I found an error in the default link script for the PIC
> 16F676 chip.  The line:
> 
> 	SHAREBANK  NAME=gpr0     START=0xA0     END=0xDF
> 
> should be:
> 
> 	SHAREBANK  NAME=gpr1     START=0xA0     END=0xDF
> 
<snip>
> Several other link scripts
> duplicate the name "gprnobnk", but I'm not sure if this
> is intentional or not.
Actually, I think those lines are correct as-is. The SHAREBANK
directive defines sections of RAM that are shadowed across multiple
banks of a particular MCU.

David Barnett

Dear David,

>> I found an error in the default link script for the PIC
>> 16F676 chip.  The line:
>>
>> 	SHAREBANK  NAME=gpr0     START=0xA0     END=0xDF
>>
>> should be:
>>
>> 	SHAREBANK  NAME=gpr1     START=0xA0     END=0xDF
>>
> <snip>
>> Several other link scripts
>> duplicate the name "gprnobnk", but I'm not sure if this
>> is intentional or not.

> Actually, I think those lines are correct as-is. The SHAREBANK
> directive defines sections of RAM that are shadowed across multiple
> banks of a particular MCU.

I assume you mean that the "gprnobnk" statements are correct as-is,
although I think I have not quite grasped the whole concept of
shared banks (please forgive my ignorance;  I'm just now looking at
compiling C code for PICs, where in the past I have written all my
PIC programs in assembler.  I'm just getting my brain to adjust to
the statements like BANKSEL that the assembler sticks in that aren't
part of the PIC instruction set).  Certainly the duplicate "gpr0"
was a problem in that without it, the linker ran of of data space
on a very simple program, whereas once I changed it, the program
linked, and I was able to download it to the PIC, plug it into the
circuit board, and it ran like a charm.

Admittedly, the 16F676 has a meager amount of memory and is probably
not the best thing to be compiling code for (we're switching to the
more spacious 16F636, but the 676 is what I have on the bench today).

Off-topic:

By the way, is there any plan to write a driver for the USB-based
ICD2 programmer?  It's a wonderful little device, and I'd love to
start building boards with the 6-pin modular plug and have in-system
programming capability.  But I'm not going to switch to the ICD2
unless I can access it from a Linux box.

					Regards,
					Tim

+--------------------------------+-------------------------------------+
| Dr. R. Timothy Edwards (Tim)   | email: ####@####.####     |
| MultiGiG, Inc.                 | web:   http://www.multigig.com      |
| 100 Enterprise Way, Suite A-3  | phone: (831) 621-3283               |
| Scotts Valley, CA 95066        | cell:  (240) 401-0616               |
+--------------------------------+-------------------------------------+

On Fri, 08 Jun 2007 21:26:40 -0700
"R. Timothy Edwards" ####@####.#### wrote:

> Dear David,
> 
> >> I found an error in the default link script for the PIC
> >> 16F676 chip.  The line:
> >>
> >> 	SHAREBANK  NAME=gpr0     START=0xA0     END=0xDF
> >>
> >> should be:
> >>
> >> 	SHAREBANK  NAME=gpr1     START=0xA0     END=0xDF
> >>
> > <snip>
> >> Several other link scripts
> >> duplicate the name "gprnobnk", but I'm not sure if this
> >> is intentional or not.
> 
> > Actually, I think those lines are correct as-is.
<snip>
> 
> Certainly the duplicate "gpr0" was a problem in that without it, the
> linker ran of of data space on a very simple program, whereas once I
> changed it, the program linked, and I was able to download it to the
> PIC, plug it into the circuit board, and it ran like a charm.
The key to all this is the concept of shadowed RAM. The 16f676 actually
has half the gpr's you think it has, with two ways to access each
address. Address 0x20 refers to the same RAM cell as address 0xA0, 0x21
as 0xA1, etc. You can verify that on the 16f676 datasheet: over the
address range 0xA0-0xDF, it says "accesses 20h-5Fh". The SHAREBANK
sections just describe the layout of the chip, so if you change it as
you describe, you'll be randomly overlaying each cell on another,
and you'll eventually have data collisions.

> Admittedly, the 16F676 has a meager amount of memory and is probably
> not the best thing to be compiling code for
Yep. You probably already know this, but when you compile code from C,
there's a little bit of fixed overhead along with a little bit of
variable overhead. On your chip, the fixed overhead probably eats up
most of your RAM. Plus in C it's easy to make much bigger programs
RAM-wise without realizing it.

> Off-topic:
> 
> By the way, is there any plan to write a driver for the USB-based
> ICD2 programmer?
Not that I'm aware of. I program my chips with the ICD2 as well, but I
think the logic is that if we have a good simulator, we can build
cheaper programmers that don't need expensive USB and drivers. gpsim
has a few flaws and missing features that are hard to work around if
they affect you, but in a lot of ways it's better than the hardware
itself or MPSIM (MPLAB's built-in simulator). Anyway, it's really
pretty easy copying the HEX and cod files onto a windows box to debug
with the ICD2.

Hope that all gave you some perspective.

David Barnett

On 6/9/07, R. Timothy Edwards ####@####.#### wrote:
> Off-topic:
>
> By the way, is there any plan to write a driver for the USB-based
> ICD2 programmer?  It's a wonderful little device, and I'd love to
> start building boards with the 6-pin modular plug and have in-system
> programming capability.  But I'm not going to switch to the ICD2
> unless I can access it from a Linux box.
>

Try Piklab.
http://piklab.sourceforge.net/

If you only need a USB programmer, PICkit 2 is a better bet under Linux.
It is supported by pk2 and Piklab as well as pyk.

Dear Xiaofan,

>> By the way, is there any plan to write a driver for the USB-based
>> ICD2 programmer?  It's a wonderful little device, and I'd love to
>> start building boards with the 6-pin modular plug and have in-system
>> programming capability.  But I'm not going to switch to the ICD2
>> unless I can access it from a Linux box.

> Try Piklab.
> http://piklab.sourceforge.net/

I looked at this, and may go ahead and install all the KDE and Qt
libs needed to compile it.  Normally I'm not a big fan of GUIs when
all I'm looking for is a simple application.  However, the source for
Piklab has all the code needed to build a simple usb driver for the
ICD2.  I could write a Linux driver for it such that it looks like
a serial device.  Once installed, it could be accessed through "picp"
simply by calling, e.g., "picp /dev/icd2 ...".  How much interest
would there be for such a driver?

						---Tim

+--------------------------------+-------------------------------------+
| Dr. R. Timothy Edwards (Tim)   | email: ####@####.####     |
| MultiGiG, Inc.                 | web:   http://www.multigig.com      |
| 100 Enterprise Way, Suite A-3  | phone: (831) 621-3283               |
| Scotts Valley, CA 95066        | cell:  (240) 401-0616               |
+--------------------------------+-------------------------------------+

On Sat June 9 2007 07:18, R. Timothy Edwards wrote:
>
> However, the source for
> Piklab has all the code needed to build a simple usb driver for the
> ICD2.  I could write a Linux driver for it such that it looks like
> a serial device.  Once installed, it could be accessed through "picp"
> simply by calling, e.g., "picp /dev/icd2 ...".  How much interest
> would there be for such a driver?
>
There's more to it than the driver. Picp uses the PicStart Plus protocol. I 
don't have an ICD2 so I don't know what protocol it uses. You may have to 
write a completely different application on top of the driver.

Jeff