Post by thread:[PIC:] 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

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_OUTlistservTakeThisOuTmitvma.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-requestKILLspammitvma.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_OUTTakeThisOuTcypress.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-requestspam_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@PICLISTKILLspammitvma.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 -- KILLspamaiwKILLspamcypress.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 <RemoveMEPICLISTTakeThisOuTmitvma.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 -- spamBeGoneaiwspamBeGonecypress.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.netEraseMEspam_OUTmitvma.mit.edu>> for <RemoveMEpiclist_errorsTakeThisOuTSYMPATICO.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: EraseMElistsjosh3MTMP.COM, RemoveMEpiclist_errorsEraseMEEraseMESYMPATICO.CA Message-ID: <LISTSERV%RemoveME2004012718363727spam_OUTKILLspamMITVMA.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-piclistTakeThisOuTspamMITVMA.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-DAEMONspamspamBeGoneyahoo.com To: RemoveMEowner-piclistKILLspammitvma.mit.edu X-Loop: MAILER-DAEMONSTOPspamspam_OUTyahoo.com Subject: Delivery failure Message from yahoo.com. Unable to deliver message to the following address(es). <spamBeGonehbarregrdSTOPspamEraseMEyahoo.com>: Sorry, your message to KILLspamhbarregrdspamBeGoneyahoo.com cannot be delivered. This account is over quota. --- Original message follows. Return-Path: <EraseMEowner-piclistEraseMEmitvma.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 spamBeGonePICLISTKILLspamMITVMA.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_OUTMITVMA.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 <TakeThisOuTPICLISTKILLspamspamMITVMA.MIT.EDU> From: Wouter van Ooijen <.....wouterRemoveMEVOTI.NL> Organization: Van Ooijen Technische Informatica Subject: Re: [PIC:] Picstart plus as an in circuit programmer? (16F627A) To: RemoveMEPICLISTspamBeGoneMITVMA.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

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

2004\01\28@135822 by Andrew Warren

Wouter van Ooijen <TakeThisOuTPICLISTspammitvma.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 -- aiwEraseMEcypress.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 <RemoveMEPICLISTEraseMEspam_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@aiwRemoveMEEraseMEcypress.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...