Post by thread:[PIC:] "Flashing" the PIC10F's with the Wisp628 ?

> Before I try to understand everything in the > "Memory Programming Specification" document, > would the Wisp628 correctly flash the 10F's as-is ? > Maybe with some config file update in XWisp/XWIsp2 ? > Or does it have to be updated in some way ? The programming commands seem familiar, so maybe one of the implemented algorithms would work. But you'd have to add the correct specs to xwisp.py, and add some code to handle the OSCCAL value correctly. Not easy. Reading the programming spec I noted (page 3) that it mentions 14 (code) data bits. Bad case of cut-n-paste? Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu ____________________________________________

Wouter van Ooijen wrote : > > Before I try to understand everything in the > > "Memory Programming Specification" document, > > would the Wisp628 correctly flash the 10F's as-is ? > > Maybe with some config file update in XWisp/XWIsp2 ? > > Or does it have to be updated in some way ? > > The programming commands seem familiar, so maybe one of the > implemented algorithms would work. But you'd have to add the > correct specs to xwisp.py,... Or to XWisp2.c ;-) > ...and add some code to handle the OSCCAL value correctly. For this particular project (during experimenting/development) I could live without the correct OSCCAL value. Anyway, thanks for the update ! Jan-Erik. ____________________________________________

So are there any programmers, outside of the ProProg, that support the 10F? --Joe On Wed, 3 Nov 2004 22:14:29 +0100 (CET), Jan-Erik Soderholm <spam_OUTjan-erik.soderholmTakeThisOuTtelia.com> wrote: {Quote hidden}> Wouter van Ooijen wrote : > > > > Before I try to understand everything in the > > > "Memory Programming Specification" document, > > > would the Wisp628 correctly flash the 10F's as-is ? > > > Maybe with some config file update in XWisp/XWIsp2 ? > > > Or does it have to be updated in some way ? > > > > The programming commands seem familiar, so maybe one of the > > implemented algorithms would work. But you'd have to add the > > correct specs to xwisp.py,... > > Or to XWisp2.c ;-) > > > ...and add some code to handle the OSCCAL value correctly. > > For this particular project (during experimenting/development) > I could live without the correct OSCCAL value. > > Anyway, thanks for the update ! > > Jan-Erik. > > > > ______________________________________________

Jan-Erik Soderholm wrote: > I have a PCB for the EasyProg (from Olin) also, > but that doesn't list the F10's as supported PIC's. > (The ProProg page does, otoh...) Yes, this is true. I haven't merged the enhancements I made to the ProProg firmware back into the EasyProg. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com ____________________________________________

Wouter van Ooijen wrote: > The programming commands seem familiar, so maybe one of the implemented > algorithms would work. But you'd have to add the correct specs to > xwisp.py, and add some code to handle the OSCCAL value correctly. Not > easy. > > Reading the programming spec I noted (page 3) that it mentions 14 (code) > data bits. Bad case of cut-n-paste? I don't know how your Wisp works and haven't looked at the firmware or software, but adding 10F support to my programmers wasn't just adding another 16F part. Some important differences are: 1 - 10F parts don't have a device ID. My programmer software previously relied on this to identify the PIC and select the correct programming algorithm. Most of the work of supporting the 10Fs was on the host software side to deal with no device ID. 2 - The current address in the chip is not 0 after a reset. Even worse, it depends on the program memory size, which depends on the part, which it won't tell you. 3 - Even though there is more than one way to get to the address of the config word, you can only access it immediately after a reset. I ended up creating separate read and write algorithms for the 10F parts, although they were layered on top of the same low level command and data I/O routines the other 16F algorithms used. I don't know if you even have a structure with selectable algorithms with the same upper interface, so maybe you would handle this in a totally different way. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com ____________________________________________

Joe Jansen wrote: > So are there any programmers, outside of the ProProg, that support the > 10F? Who cares, sounds good enough to me ;-) Seriously, I plan on adding 10F support to the EasyProg soon. Most of the work is really in the host software, which has already been done. I "just" have to update the firmware. By the way, the EasyProg firmware source code is available, so anyone who wants to try this themselves... ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com ____________________________________________

Of .....olin_piclistKILLspam@spam@embedinc.com wrote : > > I don't know how your Wisp works and haven't looked at the firmware or > software, but adding 10F support to my programmers wasn't just adding > another 16F part. Some important differences are: > > 1 - 10F parts don't have a device ID. My programmer > software previously relied on this to identify the PIC and > select the correct programming algorithm. Most of the > work of supporting the 10Fs was on the host software > side to deal with no device ID. Wouters software (and XWIsp2) supports explicit specification of the device on the command line. That would take care of that, not ? Not a big deal in that case, IMHO. > 2 - The current address in the chip is not 0 after a reset. > Even worse, it depends on the program memory size, which > depends on the part, which it won't tell you. If the software knows the device (by an option on the command line) it's always the highest program address, AFAIK. That's also where the OSCCAL value have to be read and restored. Anyway, I have an idea for a 10F (-202 probably) application. I guess I'll just use some 16F (or 12F) chip as the proof-of- concept and pre-development environment. I'd guess that, giving it a bit of thought, you could write quite 10F-compatible code on a 14-bit PIC that would be not *to* hard to move over to the 10F later when I have the proper tools... B.t.w, this application is not particaly sensitive to the OSCCAL value. In fact, it would be better if the speed *does* varies a bit from device to device in some random way... :-) :-) Jan-Erik. ____________________________________________

> I don't know how your Wisp works and haven't looked at the firmware or > software, but adding 10F support to my programmers wasn't just adding > another 16F part. Sounds like it could be done by one of the more involved Wisp628 users :) > 1 - 10F parts don't have a device ID. Neither has the 16C84 or 16F84 (16F84 does). > 2 - The current address in the chip is not 0 after a reset. > Even worse, > it depends on the program memory size, which depends on the > part, which it won't tell you. Sounds like something only Microchip could have invented. I hope they patented it and will prevent other chip manufacturers from using it :) I am working on a 'big' update of the firmware which will include (I hope) everything from 10F upto 30F, so doing a small upgrade is not high on my to-do list. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu ____________________________________________

olin_piclist@embedinc.com wrote : > Jan-Erik Soderholm wrote: > > I have a PCB for the EasyProg (from Olin) also, > > but that doesn't list the F10's as supported PIC's. > > (The ProProg page does, otoh...) > > Yes, this is true. I haven't merged the enhancements I made > to the ProProg firmware back into the EasyProg. Hi. You *are* expecting a followup question to that, right ? :-) :-) Any plans for that "back-port" to the EasyProg ? Best Regards, Jan-Erik ____________________________________________

Jan-Erik Soderholm wrote: > I'd guess that, > giving it a bit of thought, you could write quite 10F-compatible > code on a 14-bit PIC that would be not *to* hard to move over > to the 10F later when I have the proper tools... It would be easier to write 10F code on an old 12C508A. That will definitely prevent you from accidentally using interrupts and any of the instructions missing in the 12 bit core. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com ____________________________________________

Jan-Erik Soderholm wrote: >> Yes, this is true. I haven't merged the enhancements I made >> to the ProProg firmware back into the EasyProg. > > Hi. > You *are* expecting a followup question to that, right ? :-) :-) > > Any plans for that "back-port" to the EasyProg ? Yeah, "soon", although not until I get the first real production run of the ProProg going. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com ____________________________________________

Wouter van Ooijen wrote: > I am working on a 'big' update of the firmware which will include (I > hope) everything from 10F upto 30F, so doing a small upgrade is not high > on my to-do list. As fan of Wisp628: - since you mention 'firmware' update: same Wisp628 hardware? (maybe only chip replacement?) - any indication when a first version might be available? - hope you are aware of some more 'odd' PICS such as 16F54/57 Regards, Rob. -- Rob Hamerling, Vianen, NL phone +31-347-322822 homepage: http://www.robh.nl/ ____________________________________________

> As fan of Wisp628: (if I ever talk about a 'cunning' Wisp628 user I probably talk about you :) > - since you mention 'firmware' update: same Wisp628 hardware? > (maybe only chip replacement?) As far as I can see now: replace 16F628(A) by a F88 (or F87), same hardware (with same limitations for chips that require Vcc cycling). > - any indication when a first version might be available? no. > - hope you are aware of some more 'odd' PICS such as 16F54/57 I will check those too. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu ____________________________________________

On Thu, 4 Nov 2004, Olin Lathrop wrote: > Jan-Erik Soderholm wrote: >> I'd guess that, >> giving it a bit of thought, you could write quite 10F-compatible >> code on a 14-bit PIC that would be not *to* hard to move over >> to the 10F later when I have the proper tools... > > It would be easier to write 10F code on an old 12C508A. That will > definitely prevent you from accidentally using interrupts and any of the > instructions missing in the 12 bit core. I prototype for 12C508 and 509 using code for 16F84 that simply has a retfie at org 4 and a #ifdef - selected initialisation section (tris etc) and that's it. Of course I can't use the internal RC for protyping. I made a tiny board that contains the 16F84 socket and has a dip8 male connector to plug into the target board. Peter ____________________________________________

Peter L. Peres <piclistKILLspammit.edu> wrote: > I prototype for 12C508 and 509 using code for 16F84 that simply has > a retfie at org 4 and a #ifdef - selected initialisation section > (tris etc) and that's it. Just an aside... A RETURN at 0x04 would be better than a RETFIE, since it'll keep your interrupt from mistakenly firing more than once. -Andy === Andrew Warren -- .....aiwKILLspam.....cypress.com === Principal Design Engineer === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation ____________________________________________

part 1 805 bytes content-type:text/plain; (decoded 7bit) Olin Lathrop wrote: > 1 - 10F parts don't have a device ID. My programmer software previously > relied on this to identify the PIC and select the correct programming > algorithm. Most of the work of supporting the 10Fs was on the > host software side to deal with no device ID. Hi Olin, Wouter, and Jan-Erik: I just ran into a funny dialog box using MPLAB IDE v6.62 and MPLAB ICD 2 -- check out the attachment... Yes, the current programming specification leads you to believe there is device ID...hmm...either Microchip knows something that we don't or perhaps they did not realize this either? Once again, take a look at the attached dialog box to see what I mean. I got a kick out of it. :) Only time will tell... Best regards, Ken Pergola part 2 3465 bytes content-type:image/gif; (decode) part 3 79 bytes content-type:text/plain; charset="us-ascii" (decoded 7bit) ____________________________________________

Ken Pergola wrote: > Yes, the current programming specification leads you to believe > there is device ID. Where did you see this? I thought I read it thru carefully, but saw no mention of a device ID. I also thought that none of the 12 bit core parts have device IDs in general. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com ____________________________________________

Ken Pergola wrote: > Yes, the current programming specification leads you to believe > there is device ID. Olin Lathrop wrote; > Where did you see this? I thought I read it thru carefully, but saw no > mention of a device ID. I also thought that none of the 12 bit core parts > have device IDs in general. Sorry, I did not proof-read my post -- I left out the word 'no' -- sorry for the confusion. I meant to say: Yes, the current programming specification leads you to believe there is *no* device ID. I'm only jesting due to the dialog box that appeared when I opened up MPLAB IDE with the ICD 2. I thought it was funny and it led me to believe either they forget that this part family has no device IDs, or they have something up their sleeve. :) Best regards, Ken Pergola ____________________________________________

Olin Lathrop wrote: > What exactly did you do to cause that to pop up? I just remember opening up MPLAB IDE v6.62 and then selecting the PIC10F206. I needed to do this to read the factory OSC calibration values on my PIC10F206 parts before I accidentally overwrite them. If you can't replicate that dialog box, just send a quick not and I'll try to post the exact steps I followed. It makes wonder how many other funny messages are lurking in MPLAB IDE -- I like a sense of humor in programmers! :) Best regards, Ken Pergola P.S. I'm really wishing that maybe there is some sort of currently undocumented device ID for these PIC10F parts -- that would be really nice. Probably wishful thinking though... ____________________________________________

Ken Pergola wrote: > I just remember opening up MPLAB IDE v6.62 and then selecting the > PIC10F206. I needed to do this to read the factory OSC calibration > values on my PIC10F206 parts before I accidentally overwrite them. > > If you can't replicate that dialog box, just send a quick not and > I'll try to post the exact steps I followed. I was mostly just curious because this dialog points to an area of MPLAB that is obviously not quite ready yet. I've done 10F development with MPLAB, so this is probably ICD2 related. The only part of MPLAB I've used with the 10F is the build tools outside the IDE, and the IDE for debugging with the simulator. I've always used my own programmer to program real parts. > It makes wonder how many other funny messages are lurking in MPLAB > IDE -- I like a sense of humor in programmers! :) This is definitely better than "Program has performed an illegal operation, all your work has been lost and your files will be scrambled. OK?" > P.S. I'm really wishing that maybe there is some sort of currently > undocumented device ID for these PIC10F parts -- that would be really > nice. Probably wishful thinking though... I seriously doubt there is a device ID lurking in the 10Fs. Most likely this dialog is due to cut and paste from code to handle chips with device IDs, and this part isn't quite finished yet. Sounds like it's a good idea to stay away from ICD2 and 10F parts in version 6.62. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com ____________________________________________

Olin Lathrop wrote: > Sounds like it's a good idea > to stay away from ICD2 and 10F parts in version 6.62. Hi Olin, Well, at least as far as the MPLAB ICD 2 is concerned, it was a rather benign message and did not get in the way. MPLAB IDE v6.62 is marked as "full support" (green light) with the PIC10F parts in conjunction with the ICD 2. At this point all I did was read the devices so that I could archive and mark the OSC calibration values on their underside. I have not tested programming them yet, but I don't see any reason why it should not work. If it proves otherwise, I'll post here... Cool devices! I cut my teeth on the '5x baseline parts years ago and these little buggers bring back memories. :) Best regards, Ken Pergola ____________________________________________

Ken Pergola wrote : > P.S. I'm really wishing that maybe there is some sort of currently > undocumented device ID for these PIC10F parts -- that would > be really nice. Hi. Besides of the lack of verification that you have put the "right" chip into your programmer (and possibly that you have to explicit specify the device i the programmer GUI or command line), what other real drawbacks are there with a missing device ID ? Jan-Erik ____________________________________________

Jan-Erik Soderholm wrote: > Besides of the lack of verification that you have put the "right" > chip into your programmer (and possibly that you have to explicit > specify the device i the programmer GUI or command line), what > other real drawbacks are there with a missing device ID ? Other than that, Mrs. Lincoln, how was the play? You've hit the two reasons exactly. Neither is a show stopper, but are still serious issues. In my programming software, I strive for simple and idiot proof operation to the extent possible. I think it's a LOT nicer to have the programmer tell you what chip it found and automatically configure itself accordingly, than you having to tell it. Both my programmers work this way. There are command line options to specify the target PIC type, and the software aborts with error status if that doesn't match what it finds. I think this is an important feature especially for production use. The worst part is that even when the user tells you what chip is supposed to be out there, it is not possible to reliably verify this in all cases when the chip has no device ID. Jan-Erik, have you built up your EasyProg yet? If so, you can see what I mean. Put any of the supported PICs in the socket and just run PIC_PROG without the -PIC command line option and it tells you which PIC it is and what its revision number is. Maybe you don't think that's a nice feature? Unfortunately that is not possible with 10F parts, or any others that don't have a device ID. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com ____________________________________________

Hi Olin, Olin Lathrop wrote: > In my programming software, I strive for simple and > idiot proof operation to the extent possible. I think it's a LOT nicer to > have the programmer tell you what chip it found and automatically configure > itself accordingly, than you having to tell it. I think there is another serious issue with programmers (in general): the hex file doesn't carry information for which target it destined. Is there any safeguard against loading the wrong hex file? Regards, Rob. -- Rob Hamerling, Vianen, NL phone +31-347-322822 homepage: http://www.robh.nl/ ____________________________________________

Rob Hamerling wrote: > I think there is another serious issue with programmers (in general): > the hex file doesn't carry information for which target it destined. > Is there any safeguard against loading the wrong hex file? Only to a limited extent. My software detects addresses in the HEX file not supported by the particular chip. It would be nice if Microchip defined a standard location at an otherwise unused address that gave some information about the required target PIC, then have the assembler/linker automatically set that from the processor option. Hmm. I suppose I could define something like that and support it automatically in my development environment and programmer software. If nothing is present at the special address, then it acts as before. The hard part would be to get Microchip to adopt it also, or at least not use the same reserved address for some other feature in the future. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com ____________________________________________

olin_piclist@embedinc.com wrote : > Jan-Erik Soderholm wrote: > > Besides of the lack of verification that you have put the "right" > > chip into your programmer (and possibly that you have to explicit > > specify the device i the programmer GUI or command line), what > > other real drawbacks are there with a missing device ID ? > > Other than that, Mrs. Lincoln, how was the play? OK. I got the message :-) :-) It was a dump question, right ? :-) > You've hit the two reasons exactly. > Both my programmers work this way. There are command > line options to specify the target PIC type, and the > software aborts with error status if that doesn't > match what it finds. I think this is an important feature > especially for production use. In a *large* production use (as at Ericsson which is my background), the identification is usualy done at a higher level (PCB/PCA) and then the assembly line management system will tell the programmer what hex file and what "command" to use (using the BOM or other CAD/CAM databases). As long as the pick-n-place equipment put the right device on board (and that is verifiyed in other ways such as using barcodes on the DIP-tubes or SMD-rolls), all should be fine. > Jan-Erik, have you built up your EasyProg yet Sorry, no. I (as others was) got "hit" by the "odd-resitor-values" issue. I havn't had time to get the few needed yet. Now, if the support for 10Fs in the EasyProg gets released before Wouters new Wisp628 firmware, I'd probably fix that. :-) > If so, you can see what I mean. Put any of the supported PICs > in the socket and just run PIC_PROG without the -PIC command > line option and it tells you which PIC it is and what its revision > number is. Maybe you don't think that's a nice feature? Of course, I perfectly understand that. Wouters programming software (which is my main tool) works the same way. > Unfortunately that is not possible with 10F parts, or any > others that don't have a device ID. Pefectly understod. My question was actualy if there was any *other* issues besides of the verification/programming ones, not saying that those issues can be (more or less) serious. So far, the answer seems to be "none". Best Regards ! Jan-Erik. ____________________________________________

On Sun, 7 Nov 2004, Olin Lathrop wrote: > Rob Hamerling wrote: >> I think there is another serious issue with programmers (in general): >> the hex file doesn't carry information for which target it destined. >> Is there any safeguard against loading the wrong hex file? > > Only to a limited extent. My software detects addresses in the HEX file not > supported by the particular chip. > > It would be nice if Microchip defined a standard location at an otherwise > unused address that gave some information about the required target PIC, > then have the assembler/linker automatically set that from the processor > option. Why not parse the .cod or .coff files? Both the processor type and all of the object code is available. The only problem I see with this is that it can expose the source code too. This may be an issue if you're hiring somebody to program your chips for you. Scott ____________________________________________

Jan-Erik Soderholm wrote: >> Jan-Erik, have you built up your EasyProg yet > > Sorry, no. I (as others was) got "hit" by the "odd-resitor-values" > issue. I havn't had time to get the few needed yet. Now, if the > support for 10Fs in the EasyProg gets released before Wouters new > Wisp628 firmware, I'd probably fix that. :-) OK, I've updated the EasyProg firmware to support the 10F parts. Go to http://www.embedinc.com/picprg/sw.htm to download the updated software/firmware. I'm also sending you all the resistors required by the EasyProg. I apologize if this disrupts your procrastination strategy ;-) ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com ____________________________________________

Jan-Erik Soderholm wrote: > Besides of the lack of verification that you have put the "right" > chip into your programmer (and possibly that you have to explicit > specify the device i the programmer GUI or command line), what > other real drawbacks are there with a missing device ID ? Hi Jan-Erik, Other than the fact that you can't programmatically *identify* the target device, none. I'm sure they have good reasons, but with Microchip releasing certain new PICmicros without device IDs, it just feels like we are taking a step back in time to the early days when no PICmicros had device IDs. When PICmicros were introduced with device IDs it was a very welcome addition (to me), so you would think it would be a trend that would not be bucked. Once a convenience factor is added to a product, it's a little hard to not see it added to some new PICmicros that are being released. It's definitely not a huge problem for me, but that's why I said it would be nice if Microchip had included a device ID with the PIC10F. I also feel this way about the products that I call the "Flash reincarnation products" -- like the PIC16F57, PIC16F59, etc. It would have been nice as well for those parts to have been given a device ID. This is just my opinion (coming from the angle of a guy who had developed a PIC programmer in the past, and thus has worked with and implemented various Microchip Programming Specifications) -- it does not mean much to anyone else except to me, but you did ask me a question. :) Best regards, Ken Pergola ____________________________________________

Scott Dattalo wrote: > Why not parse the .cod or .coff files? Both the processor type and > all of > the object code is available. I guess that would solve the problem in cases when the COD or COFF files are available. I'm not sure how comfortable people would be with that though. Everyone just expects to ship firmware around in HEX files. This is also a lot more work than I had intended. I'd rather spend the extra time supporting more PICs. Still, it's something to keep in mind. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com ____________________________________________

On Fri, 5 Nov 2004, Andrew Warren wrote: > Peter L. Peres <EraseMEpiclistspam_OUTTakeThisOuTmit.edu> wrote: > >> I prototype for 12C508 and 509 using code for 16F84 that simply has >> a retfie at org 4 and a #ifdef - selected initialisation section >> (tris etc) and that's it. > > Just an aside... A RETURN at 0x04 would be better than a RETFIE, > since it'll keep your interrupt from mistakenly firing more > than once. Maybe you are right but I have found exemplaries of 16F84 and code that did not like the RETURN and hung under certain conditions when used like this. I think the RETFIE is the right thing to do here, based on experience. If the interrupt would keep repeating the chip would run very slowly (at 1/3 speed ?) I think, running the RETFIE almost back to back, but nothing else would be broken. Otherwise, you are right. Of course there aren't supposed to be any interrupts on a 16F84 used like this (they are disabled at reset and stay that way in my emulation) but glitches and oopses in the real world see to it that there are some from time to time apparently. Peter ____________________________________________

> It would be nice if Microchip defined a standard location at > an otherwise > unused address that gave some information about the required > target PIC, > then have the assembler/linker automatically set that from > the processor > option. > > Hmm. I suppose I could define something like that and support it > automatically in my development environment and programmer > software. If > nothing is present at the special address, then it acts as > before. The hard > part would be to get Microchip to adopt it also, or at least > not use the > same reserved address for some other feature in the future. Now if the PICLIST could agree on something like that, all tool vendors on the PICLIST implement it, and all programmer vendors too. That would almost be a de-facto standard! CCS creates .hex files contain a sort of comment line, starting with a colon, so most progger software will ignore such a line. How about adding a line like ;TARGET=PIC16F628A Now for Olin the assembler specialist: how to you convince MPLAB/MPASM to add such a line? Or maybe automate some post-processing on the .hex file? One note: I often have a program that can run one a number of PIC types. If programmer software requires that the PIC in the .hex file and the actual target agree it *must* provide a way to disable this check. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu ____________________________________________

> Why not parse the .cod or .coff files? Because the .hex file is what you provide to someone (a programming service, on your website for fellow hobbyists, etc) to porgram a chip. And because Jal creates only a .hex file, and I don't feel like modifying it to create another file! Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu ____________________________________________

> I'm sure they have good reasons, but with > Microchip releasing > certain new PICmicros without device IDs, it just feels like > we are taking a > step back in time to the early days when no PICmicros had device IDs. Worse: there are some (18F's with and without motor control firmware, different type markings on the chip) that have the same ID! And this is something a progger definitely needs to know, because the motor control firmware should never be erased. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu ____________________________________________

On Sun, 7 Nov 2004, Scott Dattalo wrote: {Quote hidden}> On Sun, 7 Nov 2004, Olin Lathrop wrote: > >> Rob Hamerling wrote: >>> I think there is another serious issue with programmers (in general): >>> the hex file doesn't carry information for which target it destined. >>> Is there any safeguard against loading the wrong hex file? >> >> Only to a limited extent. My software detects addresses in the HEX file >> not >> supported by the particular chip. >> >> It would be nice if Microchip defined a standard location at an otherwise >> unused address that gave some information about the required target PIC, >> then have the assembler/linker automatically set that from the processor >> option. > > Why not parse the .cod or .coff files? Both the processor type and all of the > object code is available. The only problem I see with this is that it can > expose the source code too. This may be an issue if you're hiring somebody to > program your chips for you. Cannot one strip the source code from a cod file ? I think it's legal for the relevant section to be empty, no ? You are the one who wrote gpsim so you should know I think. Peter ____________________________________________

On Sun, 7 Nov 2004, Rob Hamerling wrote: > > Hi Olin, > > Olin Lathrop wrote: >> In my programming software, I strive for simple and >> idiot proof operation to the extent possible. I think it's a LOT nicer to >> have the programmer tell you what chip it found and automatically >> configure >> itself accordingly, than you having to tell it. > > I think there is another serious issue with programmers (in general): the hex > file doesn't carry information for which target it destined. Is there any > safeguard against loading the wrong hex file? None. This is a real problem. Using checksums is one way to prevent problems. A 16 bit checksum can be traced back to the original hex file. I almost always write it on the chip after burning it. Peter ____________________________________________

On Sun, 7 Nov 2004, Peter L. Peres wrote: > > On Sun, 7 Nov 2004, Scott Dattalo wrote: > >> Why not parse the .cod or .coff files? Both the processor type and all of >> the object code is available. The only problem I see with this is that it >> can expose the source code too. This may be an issue if you're hiring >> somebody to program your chips for you. > > Cannot one strip the source code from a cod file ? I think it's legal for the > relevant section to be empty, no ? You are the one who wrote gpsim so you > should know I think. Hi Peter, Sure you can write a utility to strip the source from a .cod file. That's why I said 'it can expose' as opposed to 'it will expose'. However, I think you're missing the point. The problem is that .hex files strip all symbolic information from the source and consequently prevent device programmers from knowing anything about the device associated with the machine code. If anyone's interested, they can try experimenting with gputils' gpvc and gpvo utilities. These will extract all of the symbolic information from a .cod or .coff file and present it in a human readable form. It'd be trivial (but perhaps tedious) to use libgputils to create a custom program for converting .cod/.coff files into .olin files. Scott ____________________________________________

olin_piclist@embedinc.com wrote : > Jan-Erik Soderholm wrote: > > >> Jan-Erik, have you built up your EasyProg yet > > > > Sorry, no. I (as others was) got "hit" by the "odd-resitor-values" > > issue. I havn't had time to get the few needed yet. Now, if the > > support for 10Fs in the EasyProg gets released before Wouters new > > Wisp628 firmware, I'd probably fix that. :-) > > OK, I've updated the EasyProg firmware to support the 10F > parts. Go to > http://www.embedinc.com/picprg/sw.htm to download the updated > software/firmware. Done. > I'm also sending you all the resistors > required by the EasyProg. Oh, that was realy kind of you ! Many thanks ! Now, let's see if they arrive here before the 10F samples :-) :-) > I apologize if this disrupts your procrastination strategy ;-) With the firmware update, that strategy suddenly changed ! :-) Jan-Erik ____________________________________________

Wouter van Ooijen wrote: > CCS creates .hex files contain a sort of comment line, starting with a > colon, so most progger software will ignore such a line. How about > adding a line like > > ;TARGET=PIC16F628A > > Now for Olin the assembler specialist: how to you convince MPLAB/MPASM > to add such a line? Or maybe automate some post-processing on the .hex > file? I don't know of any way to do this thru the assembler. I think you're right this would require a separate post processing step. But that is also a little dangerous because that step could get out of sync with the processor selection in the source code. What can be done from assembler/linker is to tuck away private information at some special guaranteed unusable address in the HEX file, much like the EEPROM initial values are written to the HEX file at a special address. For better source code portability I would define something like a .extrainfo section in the linker control file, then put the extra stuff into this section but without specifying the fixed address in the source code. This allows the same source code to be used on different families where the extra info might have to be at different addresses. Of course if they are at different addresses for different families, then you still have to determine the family type before reading the extra info. > One note: I often have a program that can run one a number of PIC > types. If programmer software requires that the PIC in the .hex file > and the actual target agree it *must* provide a way to disable this > check. I think it would be desirable for a deliberate override in the programming software and for a way to specify multiple chips in the HEX file. I haven't thought this all the way thru yet, but if the extra info were a text string with keywords and parameters, then new keywords can be added without requiring a new mechanism. Software that doesn't understand a keyword must ignore it. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com ____________________________________________

>>> the hex file doesn't carry information for which target it destined. >>> Is there any safeguard against loading the wrong hex file? >>> Is there a standard for comments in hex files? I'd rather have a standardly-formatted comment (like emacs can use to store mode and variable settings in a file, or unix's use of #/path/file at the top for assorted scripts) than yet another strange hex constant at a mysterious location... BillW ____________________________________________

> Besides of the lack of verification that you have put the "right" > chip into your programmer (and possibly that you have to explicit > specify the device i the programmer GUI or command line), what > other real drawbacks are there with a missing device ID ? It is not a drawback, but probably a reason they haven't put it in - it takes up silicon space, and in a chip that needs to fit an SOT package, they are probably squeezing that pretty hard - which makes me wonder why they have the PC one bit wider than the addressable ROM range. ____________________________________________

On Mon, 8 Nov 2004, Alan B. Pearce wrote: >> Besides of the lack of verification that you have put the "right" >> chip into your programmer (and possibly that you have to explicit >> specify the device i the programmer GUI or command line), what >> other real drawbacks are there with a missing device ID ? > > It is not a drawback, but probably a reason they haven't put it in - it > takes up silicon space, and in a chip that needs to fit an SOT package, they > are probably squeezing that pretty hard - which makes me wonder why they > have the PC one bit wider than the addressable ROM range. What is on my mind now is, if that chip fits in a SOT case and a svery similar chip is the 12C509A f.ex., then the DIP8 capsule should be mostly epoxy ? (suppose one grinds one down and finds *nothing* inside <grin>). I'd like to see a X-ray pic of a 12C509C or such. Spot the grain of sand ? Peter ____________________________________________

Peter L. Peres wrote : > I'd like to see a X-ray pic of a 12C509C or such. Spot the > grain of sand ? Or the DIP-8 version of the 10F's !! Even smaller maybe !? Yesterday I got some white SMD LED's in 0603 package. They are also pretty small ! I was trying to solder on of them to two pads on each side of a 1.2 mm hole (upside down so the LED lights through the hole), but it just kept falling down *throught* the hole :-) Jan-Erik. ____________________________________________

> >What is on my mind now is, if that chip fits in a SOT case and a svery >similar chip is the 12C509A f.ex., then the DIP8 capsule should be mostly >epoxy ? (suppose one grinds one down and finds *nothing* inside <grin>). >I'd like to see a X-ray pic of a 12C509C or such. Spot the grain of sand ? Can't show you an X-ray of a 12c509C but can show you what I found when I peeked in the window of a 12C509A with my Intel microscope :) >http://64.246.11.64/cgi-bin/pv.cgi?dir=decell/12C509 ____________________________________________

Hi, I have seen sometimes a strange line at the end of the .HEX file. It begins with a semicolon (instead of a colon) which is followed by the processor type. I know it is a pure violation of the standard even if it is an useful feature. On the other hand the standard would allow it as it is past the so-called EOF record. I vaguely remember it is produced by the CCS C but I am not sure. Imre On Sun, 7 Nov 2004, Scott Dattalo wrote: {Quote hidden}> On Sun, 7 Nov 2004, Olin Lathrop wrote: > >> Rob Hamerling wrote: >>> I think there is another serious issue with programmers (in general): >>> the hex file doesn't carry information for which target it destined. >>> Is there any safeguard against loading the wrong hex file? >> >> Only to a limited extent. My software detects addresses in the HEX file >> not >> supported by the particular chip. >> >> It would be nice if Microchip defined a standard location at an otherwise >> unused address that gave some information about the required target PIC, >> then have the assembler/linker automatically set that from the processor >> option. > > Why not parse the .cod or .coff files? Both the processor type and all of the > object code is available. The only problem I see with this is that it can > expose the source code too. This may be an issue if you're hiring somebody to > program your chips for you. > > Scott > ______________________________________________

In message <E80D71CF-311A-11D9-A596-000A95E5DF26spam_OUTmac.com>> William "Chops" Westfield <@spam@westfwKILLspammac.com> wrote: > Is there a standard for comments in hex files? I'd rather have a > standardly-formatted > comment (like emacs can use to store mode and variable settings in a > file, or unix's > use of #/path/file at the top for assorted scripts) than yet another > strange hex constant > at a mysterious location... You could - theoretically - add a comment after the EOF marker, assuming the hex loader your programmer software uses conforms to the Intel specs (i.e. stop reading once you hit the EOF marker). Later. -- Phil. | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB, KILLspamphilpemKILLspamphilpem.me.uk | ViewFinder, 10BaseT Ethernet, 2-slice, http://www.philpem.me.uk/ | 48xCD, ARCINv6c IDE, SCSI ... Last Christmas I got a computer for my Girlfriend - Good Trade! ____________________________________________

In message <RemoveME6.1.2.0.0.20041110164056.01dd74e0TakeThisOuTmail.comcast.net>> Danny Decell <spamBeGoned.decellspamBeGonecomcast.net> wrote: > Can't show you an X-ray of a 12c509C but can show you what I found when I > peeked in the window of a 12C509A with my Intel microscope :) > > >http://64.246.11.64/cgi-bin/pv.cgi?dir=decell/12C509 Very nice - if I can get a fairly nice microscope with a camera adapter, I might modify a cheap 2Mpix digicam to make... a homebrew digitizing microscope. Add a halogen lamp (front/backlighter) and three stepper motors (X/Y translation and focus). :) Now if only I could find a decent microscope. Even second-hand microscopes seem pretty expensive (and the Tasco kids 'scopes are just plain crap)... If anyone's got a broken PIC12C508 or similar in a ceramic DIL package (preferably one that's had its CP fuse blown in an ohnosecond of stupidity), I'll have a go at photographing the chip with the hardware I've got (Olympus 2Mpix digicam and Tasco elcheapo scope), but I can't promise brilliant results. Personally, I just want to see if there are any hidden pictures on the chips. See <http://www.molecularexpressions.com/creatures/> to see what I mean :) Later. -- Phil. | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB, TakeThisOuTphilpemEraseMEspam_OUTphilpem.me.uk | ViewFinder, 10BaseT Ethernet, 2-slice, http://www.philpem.me.uk/ | 48xCD, ARCINv6c IDE, SCSI ... I am not young enough to know everything. ____________________________________________

On Nov 11, 2004, at 1:16 AM, Philip Pemberton wrote: >> Is there a standard for comments in hex files? > You could - theoretically - add a comment after the EOF marker... Theoretically, any line that doesn't begin with a colon might be skipped as being a comment line. I was just wondering whether there was something like an accepted standard, especially since the .hex file has become a distribution format as well as something for moving from source code to programming device. It would be nice if they could be tagged with some sort of description, not including my current suggestion of using part of that description as a device type designation... BillW ____________________________________________