Exact match. Not showing close matches.
PICList
Thread
'[PIC:] duplicate device IDs in the 18F series'
2004\01\25@165146
by
Wouter van Ooijen
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_OUTlistservTakeThisOuT
mitvma.mit.edu with SET PICList DIGEST in the body
2004\01\25@181848
by
Rob Hamerling
|
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 .....listservKILLspam
@spam@mitvma.mit.edu with SET PICList DIGEST in the body
2004\01\25@184830
by
Roy J. Gromlich
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
> 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-request
KILLspammitvma.mit.edu
2004\01\26@165231
by
Andrew Warren
|
Wouter van Ooijen <.....PICLISTKILLspam
.....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_OUT
TakeThisOuTcypress.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-request
spam_OUTmitvma.mit.edu
2004\01\27@024731
by
Wouter van Ooijen
> 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
> 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
|
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
> 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
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
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
> 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
> 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
> 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
|
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
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
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
> 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
> 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
|
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
|
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
> 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
> 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
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
|
Wouter van Ooijen <@spam@PICLISTKILLspam
mitvma.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 -- KILLspamaiwKILLspam
cypress.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
|
Wouter van Ooijen <RemoveMEPICLISTTakeThisOuT
mitvma.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 -- spamBeGoneaiwspamBeGone
cypress.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.netEraseME
spam_OUTmitvma.mit.edu>
>
for <RemoveMEpiclist_errors
TakeThisOuTSYMPATICO.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)"
<LISTSERVEraseME
.....MITVMA.MIT.EDU>
Subject: PICLIST: error report from YAHOO.COM
To: EraseMElistsjosh
3MTMP.COM,
RemoveMEpiclist_errorsEraseME
EraseMESYMPATICO.CA
Message-ID: <LISTSERV%RemoveME2004012718363727spam_OUT
KILLspamMITVMA.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-piclistTakeThisOuT
spamMITVMA.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-DAEMONspam
spamBeGoneyahoo.com
To: RemoveMEowner-piclistKILLspam
mitvma.mit.edu
X-Loop: MAILER-DAEMONSTOPspam
spam_OUTyahoo.com
Subject: Delivery failure
Message from yahoo.com.
Unable to deliver message to the following address(es).
<spamBeGonehbarregrdSTOPspam
EraseMEyahoo.com>:
Sorry, your message to KILLspamhbarregrdspamBeGone
yahoo.com cannot be delivered. This account is over quota.
--- Original message follows.
Return-Path: <EraseMEowner-piclist
EraseMEmitvma.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@
spam_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 spamBeGonePICLIST
KILLspamMITVMA.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_OUT
MITVMA.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.....
TakeThisOuTMITVMA.MIT.EDU>
Sender: pic microcontroller discussion list <TakeThisOuTPICLISTKILLspam
spamMITVMA.MIT.EDU>
From: Wouter van Ooijen <.....wouter
RemoveMEVOTI.NL>
Organization: Van Ooijen Technische Informatica
Subject: Re: [PIC:] Picstart plus as an in circuit programmer? (16F627A)
To: RemoveMEPICLIST
spamBeGoneMITVMA.MIT.EDU
In-Reply-To: <spamBeGone37FB7AA6F5F9814FB634A7BF4C35A6F5640CDC@spam@
spam_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
> > 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
> > 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
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
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
|
Wouter van Ooijen <TakeThisOuTPICLISTspam
mitvma.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 -- aiwEraseME
cypress.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
> > 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
Wouter van Ooijen <RemoveMEPICLISTEraseME
spam_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@aiwRemoveME
EraseMEcypress.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
> > 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...