Searching \ for '[PIC:] duplicate device IDs in the 18F series' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=18F
Search entire site for: 'duplicate device IDs in the 18F series'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] duplicate device IDs in the 18F series'
2004\01\25@165146 by Wouter van Ooijen

face picon face
What the heck is Microchip doing with the device ID's? I just checked
the 18FXX39 ICSP specs. These four chips have device IDs that are
identical to 4 of the 18FXX2/18FXX8 chips in the bits that Microchip
indicates as identifying the device. Maybe these devices should be
identified from their revision numbers only? For instance, I have an
18F252 that reads 0404, and an 18F2539 that reads 0407 (note: the lower
5 bits are the revision).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

2004\01\25@181848 by Rob Hamerling

flavicon
face
Hi Wouter,

Wouter van Ooijen wrote:
> What the heck is Microchip doing with the device ID's? I just checked
> the 18FXX39 ICSP specs. These four chips have device IDs that are
> identical to 4 of the 18FXX2/18FXX8 chips in the bits that Microchip
> indicates as identifying the device. Maybe these devices should be
> identified from their revision numbers only? For instance, I have an
> 18F252 that reads 0404, and an 18F2539 that reads 0407 (note: the lower
> 5 bits are the revision).

I did the same discovery a couple of months ago and I asked MicroChip.
Their answer:

> The brothers of parts which share device id's are where one of the parts
> has the motor control kernel, where the last 1000h of program memory is
> dedicated to the motor control kernel, which is accessed through the API
> calls.
>
> The motor control parts are modified variants of existing parts, with the
> addition of the motor control kernel. As a result they share device id's
> with other parts and have similar programming specifications.

Regards, Rob.

--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

2004\01\25@184830 by Roy J. Gromlich

picon face
Question - does this also relate to NON-Microchip parts?

I am planning to use the Maxim 3100 SPI UART and I would
like to know if I need be on the lookout for this behavior
between the PIC 18F452 and the Max3100?

Fromn the discussion it appears this should NOT be an
issue, but no harm in asking. (I hope)

Roy J. Gromlich

{Original Message removed}

2004\01\26@040007 by Wouter van Ooijen

face picon face
> The motor control parts are modified variants of existing parts, with
the addition of the motor control kernel. As a result they share device
id's with other parts and have similar programming specifications.

The stupid bastards! These parts have less flash memory, so for instance
duplicating a chip has to be done differently, just like the difference
between a 16F628A and a 16F648A and various other twins and triples in
the PIC family. This must be a clever idea of the same guy who invented
the PIC numbering scheme (12 is for 12/14-bit core 8-pin chips, 16 is
for >8 pin 12-bit and 14-bit cores, makes perfect sense, doesn't it? I
bet they never released an 8-pin 16-bit core chip because they could not
decide whether it should be a 12F or an 18F chip) and the 12-bit core
call address format (you want to call a subroutine anywhere in memory?
why on earth would you want that?).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu

2004\01\26@165231 by Andrew Warren

flavicon
face
Wouter van Ooijen <.....PICLISTKILLspamspam.....mitvma.mit.edu> wrote:

> > The motor control parts are modified variants of existing parts,
> > with the addition of the motor control kernel. As a result they
> > share device id's with other parts and have similar programming
> > specifications.
>
> The stupid bastards! These parts have less flash memory, so for
> instance duplicating a chip has to be done differently, just like
> the difference between a 16F628A and a 16F648A and various other
> twins and triples in the PIC family.

   Presumably, the motor-control PICs don't REALLY have less flash
   memory; they're just regular 18Fs with 4K of the flash
   pre-programmed by Microchip instead of by your user.  Perhaps
   there's a signature in the flash that you can use to identify
   the device.

> This must be a clever idea of the same guy who invented .... the
> 12-bit core call address format (you want to call a subroutine
> anywhere in memory? why on earth would you want that?).

   Give that guy a break... The 12-bit parts were designed in the
   late 1970s, when transistors were expensive.  Besides, it's
   trivially easy, in most cases, to overcome the restrictions on
   CALL destination addresses in the 12-bit parts.

   -Andy

=== Andrew Warren -- EraseMEaiwspam_OUTspamTakeThisOuTcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspam_OUTmitvma.mit.edu

2004\01\27@024731 by Wouter van Ooijen

face picon face
>     Presumably, the motor-control PICs don't REALLY have less flash
>     memory; they're just regular 18Fs with 4K of the flash
>     pre-programmed by Microchip instead of by your user.  Perhaps
>     there's a signature in the flash that you can use to identify
>     the device.

No. As far as I can make out from the datasheet they realy have less
FLASH, the remaining is ROM.

>     Give that guy a break... The 12-bit parts were designed in the
>     late 1970s, when transistors were expensive.  Besides, it's
>     trivially easy, in most cases, to overcome the restrictions on
>     CALL destination addresses in the 12-bit parts.

It is just the place of that one fixed bit I was complaining about. IMHO
it should be either the LSB or the MSB, not somewhere inbetween.

And how do you overcome that limitation easily, without using call
vesctors or re-arraging your code? Note that I am looking at it from the
compiler writers perspective.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\27@043537 by Wouter van Ooijen

face picon face
> I did the same discovery a couple of months ago and I asked MicroChip.
> Their answer:

You seem to be a few steps ahead of me Rob (now who was arguing that
using more-or-less open software is a bad idea when you want to make
money?). Maybe you also noticed (and asked Mircochip): the 18FXX39 ICSP
guide p7 mentions a full-chip-erase, but table 3-1 shows only partial
erase codes. And code 80h (which is the bulk erase on for instance the
18Fxx2 chips) is suspiciously missing. Just an omission?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\27@052802 by Rob Hamerling

flavicon
face
Wouter van Ooijen wrote:

> You seem to be a few steps ahead of me Rob (now who was arguing that
> using more-or-less open software is a bad idea when you want to make
> money?). Maybe you also noticed (and asked Mircochip): the 18FXX39 ICSP
> guide p7 mentions a full-chip-erase, but table 3-1 shows only partial
> erase codes. And code 80h (which is the bulk erase on for instance the
> 18Fxx2 chips) is suspiciously missing. Just an omission?

Me a few steps ahead of you???? Maybe I took a shortcut ;-).

I discovered the duplicate device-IDs when I wanted to added the 18Fxx39
 series to the list of supported PICs by my own variant of your XWisp
for the Wisp628 programmer. Only after I got some sample chips I was
sure it was not a mistake in the datasheets (would not have been the
first mistake of that kind!)
Before I realised what I was doing I programmed an 18F2539 (as if it
were an 18F252) with a 'blink a led' program incl. a bulk-erase!    The
whole 32 KB of memory can be read normally, but the motor kernel (0x6000
and up) was erased! Apparently the bulk-erase code that is currently in
Wisp628 (1.09) seems to work (too) well for the 18Fxx39's!

I didn't ask MicroChip more questions.

Regards, Rob.


--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\27@053424 by Wouter van Ooijen

face picon face
> The
> whole 32 KB of memory can be read normally, but the motor
> kernel (0x6000
> and up) was erased!

Are you sure about that? As far as I can see the motor kernel is not
readable, so there would be no way to verify that it can was erased?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\27@054252 by Rob Hamerling

flavicon
face
Wouter van Ooijen wrote:
>>The
>>whole 32 KB of memory can be read normally, but the motor
>>kernel (0x6000
>>and up) was erased!
>
>
> Are you sure about that? As far as I can see the motor kernel is not
> readable, so there would be no way to verify that it can was erased?

I'll send you the hex file of a 'virgin' 18F2539, as I read it with a
Wisp628.

Regards, Rob.



--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\27@110400 by Rob Hamerling

flavicon
face
Hi Wouter,

Rob Hamerling wrote:
> I discovered the duplicate device-IDs when I wanted to added the 18Fxx39
> series to the list of supported PICs by my own variant of your XWisp
> for the Wisp628 programmer. Only after I got some sample chips I was
> sure it was not a mistake in the datasheets (would not have been the
> first mistake of that kind!)

Coincidence or not, only an hour after I wrote this today I received a
sample 16F767. Its deviceID reads as 0x0EA1. According to the
programming specifications (ds30492a.pdf) and the errata (ds80177a.pdf)
this is an 16F777!! But it really is 28 pins DIP....

Regards, Rob.

--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\27@135322 by Wouter van Ooijen

face picon face
> Coincidence or not, only an hour after I wrote this today I received a
> sample 16F767. Its deviceID reads as 0x0EA1. According to the
> programming specifications (ds30492a.pdf) and the errata
> (ds80177a.pdf)
> this is an 16F777!! But it really is 28 pins DIP....

I just hope this is an engineering sample? Or is there another way to
distinguish this new chip?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\27@144800 by

picon face
> Coincidence or not, only an hour after I wrote this today I
> received a sample 16F767. Its deviceID reads as 0x0EA1.
> According to the programming specifications (ds30492a.pdf)
> and the errata (ds80177a.pdf) this is an 16F777!!
> But it really is 28 pins DIP....


Hi I'm not "into" programmers, I'd just like to understand...

What is the difference, from the programmers point of view,
between programming a 28pin device and a 40pin device ?
If everything else is the same.

As far as I can see from the line card the 16F767 and 777 have
the same amount of flash, no eeprom and so on.

Jan-Erik.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\27@145918 by Wouter van Ooijen

face picon face
> What is the difference, from the programmers point of view,
> between programming a 28pin device and a 40pin device ?
> If everything else is the same.

Did you also check the programming specifications and fuses bits?

And besides that, I often use scripts that check which chip I am
programming - this has occasionally saved me from blunders.

> As far as I can see from the line card the 16F767 and 777 have
> the same amount of flash, no eeprom and so on.

Even if this were completely true it would still be a bad sign of
screw-up (lack of quality control) from uChip. AFAIK there used to be no
chip types were indistinguishable for a programmer.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\27@152652 by Rob Hamerling

flavicon
face
Hi Jan-Erik,

Jan-Erik Soderholm XA (TN/PAC) wrote:
>>Coincidence or not, only an hour after I wrote this today I
>>received a sample 16F767. Its deviceID reads as 0x0EA1.
>>According to the programming specifications (ds30492a.pdf)
>>and the errata (ds80177a.pdf) this is an 16F777!!
>>But it really is 28 pins DIP....
>
>
>
> Hi I'm not "into" programmers, I'd just like to understand...
> What is the difference, from the programmers point of view,
> between programming a 28pin device and a 40pin device ?
> If everything else is the same.

Doesn't make a difference for a PIC programmer (at least not for mine,
the Wisp628).

> As far as I can see from the line card the 16F767 and 777 have
> the same amount of flash, no eeprom and so on.

True.

So for a PIC programmer it may not be a problem if a 16F767 and 16F777
would use the same ID. The reason that I mentioned the 28-pins DIP
package was to say that I'm sure it is _not_ a 16F777 (I didn't mention
it, but it has also 16F767 printed on the body!).

I reported a documentation error to MicroChip.

Regards, Rob.


--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\27@155547 by

picon face
Rob Hamerling wrote :

> So for a PIC programmer it may not be a problem if a 16F767 and 16F777
> would use the same ID. The reason that I mentioned the 28-pins DIP
> package was to say that I'm sure it is _not_ a 16F777 (I didn't
> mention it, but it has also 16F767 printed on the body!).


You say that the fact that the 16F767 and the 777 are sharing the
same ID isn't a (major) problem (if they, from the programmers point
of view, are the "same"). Fine.

Then you say that the fact that the 767 reads an ID that is
documented to be a 777 is an error, right ?

Isn't that a contradiction in a way ?
If they *do* share ID, how could you use the ID to separate them ?

Just trying to learn here... :-)

Jan-Erik.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\27@155801 by

picon face
Wouter van Ooijen wrote :

> > What is the difference, from the programmers point of view,
> > between programming a 28pin device and a 40pin device ?
> > If everything else is the same.
>
> Did you also check the programming specifications and fuses bits?

It doesn't matter if I did and it wasn't my point anyway.

*If*, and I say *if*, the *only* difference is the number of
pins on chip (that is, no differences from a programming
point of view), does it matter if they have the same ID
(still strictly from a *programming* point of view) ?

(Yes, it might matter for your scripts, but that wasn't
my point either. You can't blame uChip if a specific use
of the ID (for which it *might* not have been intended),
breaks, can you ?)

I'm just trying to understand what the ID realy was intended
for.

Regards
Jan-Erik.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\27@161041 by Wouter van Ooijen

face picon face
> I'm just trying to understand what the ID realy was intended
> for.

To distinguish PIC types in an electronic way.

If it was meant to distinguish only chips that differ
programming-relevant aspects uChip could have shared IDs for many more
chips, so I assume this is an error.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\27@161045 by Wouter van Ooijen

face picon face
> If they *do* share ID, how could you use the ID to separate them ?

Rob did not. He used his eyes to separate them :)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\27@161829 by Matt Pobursky

flavicon
face
On Tue, 27 Jan 2004 20:58:28 +0100, Wouter van Ooijen wrote:
> > What is the difference, from the programmers point of view,
> > between programming a 28pin device and a 40pin device ?
> > If everything else is the same.
>
> Did you also check the programming specifications and fuses bits?
>
> And besides that, I often use scripts that check which chip I am
> programming - this has occasionally saved me from blunders.
>
> > As far as I can see from the line card the 16F767 and 777 have
> > the same amount of flash, no eeprom and so on.
>
> Even if this were completely true it would still be a bad sign of
> screw-up (lack of quality control) from uChip. AFAIK there used to be
> no
> chip types were indistinguishable for a programmer.

I was thinking that these chips just might be the *exact same die*,
just a different number of the pins bonded out. It kind of makes sense
and lots of other chip makers do this. They could actually be the exact
same chip, just a different package and part number.

Otherwise I agree with you Wouter -- they should have different device
ID's if they truly are different chip types.

Matt Pobursky
Maximum Performance Systems

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\27@162036 by Rob Hamerling

flavicon
face
Jan-Erik Soderholm XA (TN/PAC) wrote:

> Rob Hamerling wrote :
>
>>So for a PIC programmer it may not be a problem if a 16F767 and 16F777
>>would use the same ID. The reason that I mentioned the 28-pins DIP
>>package was to say that I'm sure it is _not_ a 16F777 (I didn't
>>mention it, but it has also 16F767 printed on the body!).
>
>
> You say that the fact that the 16F767 and the 777 are sharing the
> same ID isn't a (major) problem (if they, from the programmers point
> of view, are the "same"). Fine.

I didn't say these PICs *are* sharing the same ID! I said *would* use
the same ID.  As far as my knowledge of English goes this means
something like 'suppose' they use the same ID.
I don't have a 16F777 to check *if* the IDs are the same. Stronger I
expect 'm to be _not_ the same, because the datasheets specify different
IDs.

> Then you say that the fact that the 767 reads an ID that is
> documented to be a 777 is an error, right ?

Right, most likely a documentation error.

> Isn't that a contradiction in a way ?

No. Because I think the IDs should be different.

> If they *do* share ID, how could you use the ID to separate them?

I don't think you can.

> Just trying to learn here... :-)

I'm afraid I'm not a good teacher, but I'll try (to be patient) ;-)

Regards, Rob.


--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\27@162628 by Wouter van Ooijen

face picon face
> I was thinking that these chips just might be the *exact same die*,
> just a different number of the pins bonded out. It kind of makes sense
> and lots of other chip makers do this. They could actually be
> the exact
> same chip, just a different package and part number.

Could be, but the sudden introduction of this alarms me. Why not use the
same 'silicon sharing' for 16F877/16F876 etc?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\27@162630 by

picon face
> I didn't say these PICs *are* sharing the same ID!

OK, and there was the point where I messed up !! :-)
Kind of mixed up things with Wouters other chips with
the same ID...

Oh well...


> I'm afraid I'm not a good teacher,

Oh yes !

> but I'll try (to be patient) ;-)

And I've learned my lesson and will keep silent now...

Jan-Erik.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\27@163107 by

picon face
Wouter van Ooijen wrote :

> Could be, but the sudden introduction of this alarms me. Why
> not use the same 'silicon sharing' for 16F877/16F876 etc?Hm, seems as my misreading of Rob's post has got this
thing a bit off-road... :-)

We actualy don't know if the 767/777 parts share ID,
as I understand it now.

Sorry for the mess up !!

Jan-Erik.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\27@192822 by Andrew Warren

flavicon
face
Wouter van Ooijen <@spam@PICLISTKILLspamspammitvma.mit.edu> wrote:

> As far as I can make out from the datasheet they realy have less
> FLASH, the remaining is ROM.

   That seems unlikely, especially since they have the same device
   ID as an all-flash PIC.

> > it's trivially easy, in most cases, to overcome the restrictions
> > on CALL destination addresses in the 12-bit parts.
>
> It is just the place of that one fixed bit I was complaining about.
> IMHO it should be either the LSB or the MSB, not somewhere inbetween.

   On the 16C54, that bit IS the MSB... And if you don't count the
   page-select bits as part of the address, it's the MSB on the
   other 12-bit PICs, too.

> And how do you overcome that limitation easily, without using call
> vesctors or re-arraging your code? Note that I am looking at it
> from the compiler writers perspective.

   Although the destination of every CALL must be in the lower half
   of a 512-word page (i.e., in the 0xnn00-0xnnFF area), there's no
   similar restriction on the destination of GOTOs... So you just
   put your subroutine entry-points at the low end of a page and
   have them GOTO the body of the subroutine which can be anywhere
   in memory.

   For an example "from a compiler writer's perspective", see the
   output of Bytecraft's C compiler; Walter Banks uses what I
   believe he calls "CALL islands" to solve this problem and the
   related problem of cross-page GOTOs.  Presumably, the other C
   compilers deal with the problem in a similar way.

   I'm not familiar with JAL; is there something inherent in its
   design that makes this approach unworkable?

   -Andy

=== Andrew Warren -- KILLspamaiwKILLspamspamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\27@192822 by Andrew Warren

flavicon
face
Wouter van Ooijen <RemoveMEPICLISTTakeThisOuTspammitvma.mit.edu> wrote:

> As far as I can make out from the datasheet they realy have less
> FLASH, the remaining is ROM.

   That seems unlikely, especially since they have the same device
   ID as an all-flash PIC.

> > it's trivially easy, in most cases, to overcome the restrictions
> > on CALL destination addresses in the 12-bit parts.
>
> It is just the place of that one fixed bit I was complaining about.
> IMHO it should be either the LSB or the MSB, not somewhere inbetween.

   On the 16C54, that bit IS the MSB... And if you don't count the
   page-select bits as part of the address, it's the MSB on the
   other 12-bit PICs, too.

> And how do you overcome that limitation easily, without using call
> vesctors or re-arraging your code? Note that I am looking at it
> from the compiler writers perspective.

   Although the destination of every CALL must be in the lower half
   of a 512-word page (i.e., in the 0xnn00-0xnnFF area), there's no
   similar restriction on the destination of GOTOs... So you just
   put your subroutine entry-points at the low end of a page and
   have them GOTO the body of the subroutine which can be anywhere
   in memory.

   For an example "from a compiler writer's perspective", see the
   output of Bytecraft's C compiler; Walter Banks uses what I
   believe he calls "CALL islands" to solve this problem and the
   related problem of cross-page GOTOs.  Presumably, the other C
   compilers deal with the problem in a similar way.

   I'm not familiar with JAL; is there something inherent in its
   design that makes this approach unworkable?

   -Andy

=== Andrew Warren -- spamBeGoneaiwspamBeGonespamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts29-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <TakeThisOuT20040127233641.OTS19788.tomts29-srv.bellnexxia.netEraseMEspamspam_OUTmitvma.mit.edu>>          for <RemoveMEpiclist_errorsspamTakeThisOuTSYMPATICO.CA>;
         Tue, 27 Jan 2004 18:36:41 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 6049 ; Tue, 27 Jan 2004 18:36:37 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 0258; Tue, 27 Jan 2004 18:36:37 -0500
Date:         Tue, 27 Jan 2004 18:36:37 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <LISTSERVEraseMEspam.....MITVMA.MIT.EDU>
Subject: PICLIST: error report from YAHOO.COM
To:           EraseMElistsjoshspam3MTMP.COM,
             RemoveMEpiclist_errorsEraseMEspamEraseMESYMPATICO.CA
Message-ID:   <LISTSERV%RemoveME2004012718363727spam_OUTspamKILLspamMITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'RemoveMEowner-piclistTakeThisOuTspamspamMITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 0256; Tue, 27 Jan 2004 18:36:37 -0500
Received: from mta138.mail.dcn.yahoo.com [216.155.197.38] by mitvma.mit.edu
         (IBM VM SMTP Level 430) via TCP with SMTP ; Tue, 27 Jan 2004 18:36:37
         EST
X-Comment: mitvma.mit.edu: Mail was sent by mta138.mail.dcn.yahoo.com
From: EraseMEMAILER-DAEMONspamspamspamBeGoneyahoo.com
To: RemoveMEowner-piclistKILLspamspammitvma.mit.edu
X-Loop: MAILER-DAEMONSTOPspamspamspam_OUTyahoo.com
Subject: Delivery failure

Message from yahoo.com.
Unable to deliver message to the following address(es).

<spamBeGonehbarregrdSTOPspamspamEraseMEyahoo.com>:
Sorry, your message to KILLspamhbarregrdspamBeGonespamyahoo.com cannot be delivered.  This account is over quota.

--- Original message follows.

Return-Path: <EraseMEowner-piclistspamEraseMEmitvma.mit.edu>
Received: from 209.119.0.109  (EHLO cherry.ease.lsoft.com) (209.119.0.109)
 by mta138.mail.dcn.yahoo.com with SMTP; Tue, 27 Jan 2004 14:53:20 -0800
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <@spam@21.00CBFA52@spam@spamspam_OUTcherry.ease.lsoft.com>; Tue, 27 Jan 2004 16:10:50 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 3269 for spamBeGonePICLISTspamKILLspamMITVMA.MIT.EDU; Tue, 27 Jan 2004
         16:10:42 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 5863; Tue, 27 Jan 2004 16:09:08 -0500
Received: from smtp-out2.xs4all.nl [194.109.24.12] by mitvma.mit.edu (IBM VM
         SMTP Level 430) via TCP with ESMTP ; Tue, 27 Jan 2004 16:09:07 EST
X-Comment: mitvma.mit.edu: Mail was sent by smtp-out2.xs4all.nl
Received: from PAARD (a213-84-20-53.adsl.xs4all.nl [213.84.20.53]) by
         smtp-out2.xs4all.nl (8.12.10/8.12.10) with ESMTP id i0RL99Ml035244
         for <.....PICLISTspam_OUTspamMITVMA.MIT.EDU>; Tue, 27 Jan 2004 22:09:09 +0100 (CET)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID:  <000a01c3e519$cedda080$0b00a8c0@PAARD>
Date:         Tue, 27 Jan 2004 22:09:06 +0100
Reply-To:     pic microcontroller discussion list <TakeThisOuTPICLIST.....spamTakeThisOuTMITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <TakeThisOuTPICLISTKILLspamspamspamMITVMA.MIT.EDU>
From:         Wouter van Ooijen <.....wouterspamRemoveMEVOTI.NL>
Organization: Van Ooijen Technische Informatica
Subject: Re: [PIC:] Picstart plus as an in circuit programmer? (16F627A)
To:           RemoveMEPICLISTspamspamBeGoneMITVMA.MIT.EDU
In-Reply-To:  <spamBeGone37FB7AA6F5F9814FB634A7BF4C35A6F5640CDC@spam@spamspam_OUTESEALNT442.al.sw.ericsson.se>> Precedence: list

> Does the PS+ perform verify over the full Vcc range ?
> (As a "production programmer" does ?)

Nope, it's a prototype programmer. But I guess in a pinch you could use
a bench supply to do a multiple-vcc verification. But combined with code
protection this becomes a bit tedious.

IMHO the prototype-production distinction is not so hot any more with
the flash PICs. When you use a (flash) PIC for let's say a Mars rover
you might of course feel different.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica:
http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
*** MESSAGE TRUNCATED ***


..
.

2004\01\28@021905 by Wouter van Ooijen

face picon face
> > As far as I can make out from the datasheet they realy have less
> > FLASH, the remaining is ROM.
>
>     That seems unlikely, especially since they have the same device
>     ID as an all-flash PIC.

What I can find in the datasheet and the reality are not necesarily the
same thing :(


>     On the 16C54, that bit IS the MSB... And if you don't count the
>     page-select bits as part of the address, it's the MSB on the
>     other 12-bit PICs, too.

But of course I do.

>     Although the destination of every CALL must be in the lower half
>     of a 512-word page (i.e., in the 0xnn00-0xnnFF area), there's no
>     similar restriction on the destination of GOTOs... So you just
>     put your subroutine entry-points at the low end of a page and
>     have them GOTO the body of the subroutine which can be anywhere
>     in memory.

OK, but I said 'a solution without the use of a call vector'.

>     I'm not familiar with JAL; is there something inherent in its
>     design that makes this approach unworkable?

No, just less efficient. And it is very difficult to make sure that
there are no unnecesarry call vectors, that is: call routines in the
lower halves directly, and the other ones indirectly.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\01\28@021905 by Wouter van Ooijen

face picon face
> > As far as I can make out from the datasheet they realy have less
> > FLASH, the remaining is ROM.
>
>     That seems unlikely, especially since they have the same device
>     ID as an all-flash PIC.

What I can find in the datasheet and the reality are not necesarily the
same thing :(


>     On the 16C54, that bit IS the MSB... And if you don't count the
>     page-select bits as part of the address, it's the MSB on the
>     other 12-bit PICs, too.

But of course I do.

>     Although the destination of every CALL must be in the lower half
>     of a 512-word page (i.e., in the 0xnn00-0xnnFF area), there's no
>     similar restriction on the destination of GOTOs... So you just
>     put your subroutine entry-points at the low end of a page and
>     have them GOTO the body of the subroutine which can be anywhere
>     in memory.

OK, but I said 'a solution without the use of a call vector'.

>     I'm not familiar with JAL; is there something inherent in its
>     design that makes this approach unworkable?

No, just less efficient. And it is very difficult to make sure that
there are no unnecesarry call vectors, that is: call routines in the
lower halves directly, and the other ones indirectly.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\01\28@073847 by Olin Lathrop

face picon face
Andrew Warren wrote:
>> And how do you overcome that limitation easily, without using call
>> vesctors or re-arraging your code? Note that I am looking at it
>> from the compiler writers perspective.
>
>     Although the destination of every CALL must be in the lower half
>     of a 512-word page (i.e., in the 0xnn00-0xnnFF area), there's no
>     similar restriction on the destination of GOTOs... So you just
>     put your subroutine entry-points at the low end of a page and
>     have them GOTO the body of the subroutine which can be anywhere
>     in memory.

That's what "call vector" means.

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\01\28@073847 by Olin Lathrop

face picon face
Andrew Warren wrote:
>> And how do you overcome that limitation easily, without using call
>> vesctors or re-arraging your code? Note that I am looking at it
>> from the compiler writers perspective.
>
>     Although the destination of every CALL must be in the lower half
>     of a 512-word page (i.e., in the 0xnn00-0xnnFF area), there's no
>     similar restriction on the destination of GOTOs... So you just
>     put your subroutine entry-points at the low end of a page and
>     have them GOTO the body of the subroutine which can be anywhere
>     in memory.

That's what "call vector" means.

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\01\28@135822 by Andrew Warren

flavicon
face
Wouter van Ooijen <TakeThisOuTPICLISTspamspammitvma.mit.edu> wrote:

> OK, but I said 'a solution without the use of a call vector'.

   Yes, but I never promised such a thing.

> No, just less efficient. And it is very difficult to make sure
> that there are no unnecesarry call vectors, that is: call routines
> in the lower halves directly, and the other ones indirectly.

   One GOTO (or long-GOTO) per page, per subroutine that's called
   from that page, doesn't seem like a lot of overhead to me.

   If you just can't stand that "waste", though, it shouldn't be
   hard to rearrange subroutines to minimize the number of call
   vectors.  I'd expect that JAL usually finds itself running on
   a GHz-plus Athlon/Pentium 4... With that sort of power behind it,
   even the clumsiest brute-force algorithm should be able to find
   an optimized solution in milliseconds.

   -Andy

=== Andrew Warren -- aiwEraseMEspamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\01\28@145719 by Wouter van Ooijen

face picon face
> > OK, but I said 'a solution without the use of a call vector'.
>     Yes, but I never promised such a thing.

I a way you did.

>     One GOTO (or long-GOTO) per page, per subroutine that's called
>     from that page, doesn't seem like a lot of overhead to me.

Not necesarrily per page. But for a 1k device: yes, it is still an
overhead, which could have been avoid if that stupid 'sticky0' bit would
have been placed elsewhere (LSB, MSB, but not in the middle!!).

>     If you just can't stand that "waste", though, it shouldn't be
>     hard to rearrange subroutines to minimize the number of call
>     vectors.  I'd expect that JAL usually finds itself running on
>     a GHz-plus Athlon/Pentium 4... With that sort of power behind it,
>     even the clumsiest brute-force algorithm should be able to find
>     an optimized solution in milliseconds.

Feel free to add it to the Jal compiler if you think it is that easy,
the compiler is GPL :) Forgive my sarcasm, but it always pops up when
someone states that something should be easy for someone else to do.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\01\28@180649 by Andrew Warren

flavicon
face
Wouter van Ooijen <RemoveMEPICLISTEraseMEspamspam_OUTmitvma.mit.edu> wrote:

> Forgive my sarcasm, but it always pops up when someone states that
> something should be easy for someone else to do.

   ... Like when someone implies that it should have been easy for
   Microchip to put the fixed "0" bit in the MSB or LSB of the call
   destination?

   -Andy

=== Andrew Warren -- @spam@aiwRemoveMEspamEraseMEcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\01\29@030605 by Wouter van Ooijen

face picon face
> > Forgive my sarcasm, but it always pops up when someone states that
> > something should be easy for someone else to do.
>
>     ... Like when someone implies that it should have been easy for
>     Microchip to put the fixed "0" bit in the MSB or LSB of the call
>     destination?

big big :)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...