Post by thread:[PIC] MPLAB IDE v7.00 is released

Carlos Marcano wrote: > Could you please elaborate in what is the component download about? Hi Carlos, I think it would be better if I just show you a quote from Microchip: Quote from Microchip: --------------------- === "MPLAB IDE v7.00 is released and is available on the Microchip web site. This version features component download, allowing you to download only the MPLAB components you wish to use. This will usually result in faster downloads than the previous full download. Also available on the MPLAB IDE software web page is a complete zipped version of MPLAB IDE v7.00 installation. This can be downloaded and copied to another PC for non-internet installation. This version can also be used if problems are encountered with the component download. Note that the VDI is now an integrated component and can be installed with the MPLAB installer. It is no longer a separate download. Check the README files for a list of current device support for each component, and for new features in MPLAB IDE v7.00." === I hope that answers your question. Take care Carlos, Ken Pergola ____________________________________________

Thanks Ken, this is very elaborated! Regards, *Carlos Marcano* -Guri, Venezuela- {Quote hidden}> -----Mensaje original----- > De: spam_OUTpiclist-bouncesTakeThisOuTmit.edu [.....piclist-bouncesKILLspam@spam@mit.edu]En nombre de > Ken Pergola > Enviado el: Miércoles, 01 de Diciembre de 2004 17:58 > Para: Microcontroller discussion list - Public. > Asunto: RE: [PIC] MPLAB IDE v7.00 is released > > > > Carlos Marcano wrote: > > > Could you please elaborate in what is the component download about? > > Hi Carlos, > > I think it would be better if I just show you a quote from Microchip: > > Quote from Microchip: > --------------------- (snip) --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.799 / Virus Database: 543 - Release Date: 19/11/04 ___________________________________________

> This version features component download, allowing you to > download only the MPLAB components you wish to use... > [snip] > Also available on the MPLAB IDE > software web page is a complete zipped version of MPLAB IDE v7.00 > installation. This can be downloaded and copied to another PC for > non-internet installation.... OK. So, if one is, like I'm am, running MPLAB on another PC then where the Internet connection is, I can not use the component download, right ? Anyway, the full 7.00 kit is at least a lot smaller then the 6.x kits was... :-) Jan-Erik. ____________________________________________

In message <200412012330.iB1NUq214651KILLspamd1o401.telia.com>> "Jan-Erik Soderholm" <.....jan-erik.soderholmKILLspam.....telia.com> wrote: > Anyway, the full 7.00 kit is at least a lot smaller then > the 6.x kits was... :-) The full kit ZIP file is trashed FWICT. Also, the MPLAB7 installer seems to be severely bugged - I got loads of "Could not register class" (and similar) errors, reinstalled, finally got MPLAB7 working, then found out that it was failing to connect to the ICD2. Haven't Microchip heard of betatesting? Later. -- Phil. | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB, EraseMEphilpemspam_OUTTakeThisOuTphilpem.me.uk | ViewFinder, 10BaseT Ethernet, 2-slice, http://www.philpem.me.uk/ | 48xCD, ARCINv6c IDE, SCSI ... Man who eats too many prunes, sits on toilet, many moons! ____________________________________________

I'm gonna hold off MPLAB7 until somebody says it works OK. No point in fighting more problems... --Bob Philip Pemberton wrote: {Quote hidden}>In message <200412012330.iB1NUq214651spam_OUTd1o401.telia.com>> > "Jan-Erik Soderholm" <@spam@jan-erik.soderholmKILLspamtelia.com> wrote: > > > >>Anyway, the full 7.00 kit is at least a lot smaller then >>the 6.x kits was... :-) >> >> > >The full kit ZIP file is trashed FWICT. Also, the MPLAB7 installer seems to >be severely bugged - I got loads of "Could not register class" (and similar) >errors, reinstalled, finally got MPLAB7 working, then found out that it was >failing to connect to the ICD2. > >Haven't Microchip heard of betatesting? > >Later. > > -- Note: Attachments must be sent to KILLspamattachKILLspamengineer.cotse.net, and MAY delay replies to this message. 520-219-2363 ____________________________________________

Philip Pemberton wrote : > "Jan-Erik Soderholm" <RemoveMEjan-erik.soderholmTakeThisOuTtelia.com> wrote: > > > Anyway, the full 7.00 kit is at least a lot smaller then > > the 6.x kits was... :-) > > The full kit ZIP file is trashed FWICT. Another message tonight said it wasn't. > Also, the MPLAB7 installer seems to be severely bugged - I got loads > of "Could not register class" (and similar) errors,... On what Windows version ? Are you " local administration" on your PC ? > reinstalled, finally got MPLAB7 working, then found > out that it was failing to connect to the ICD2. > > Haven't Microchip heard of betatesting? Sure they have. And what's more, you are part of it ! :-) :-) Jan-Erik. ____________________________________________

In message <spamBeGone41AE5EB9.1030101spamBeGonecotse.net> Bob Axtell <TakeThisOuTengineerEraseMEspam_OUTcotse.net> wrote: > I'm gonna hold off MPLAB7 until somebody says it works OK. > No point in fighting more problems... Just rebooted and it started working - awful nice of Mchip to "forget" to make the installer pop up a "You really should reboot before running Mplab" msgbox, but there you go. MPLAB 7 seems to work fine now. I wish it hadn't splattered MPASM and similar files all over the HDD though. I wanted everything in F:\MPLAB, yet it installed MPASM in C:\Program Files. There's a reason the C partition is only 4GB (makes it easier to Ghost)... Later. -- Phil. | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB, RemoveMEphilpemTakeThisOuTphilpem.me.uk | ViewFinder, 10BaseT Ethernet, 2-slice, http://www.philpem.me.uk/ | 48xCD, ARCINv6c IDE, SCSI ... Hey, don't ask me, I'm just an Anthropomorphic Personification. ____________________________________________

For what it's worth: -------------------- I opted for the MPLAB IDE v7.00 component download update on my Windows XP SP2 machine and have not had any problems. I'm using MPLAB IDE v7.00. On the Microchip Forums, the Microchip developer moderator is asking people to do the 'NSLOOKUP' thing again for anyone getting a corrupted ZIP file (full installation download). I feel sorry for them and for customers that this is happening again -- as the old saying goes, it's like an old penny that keeps returning. It has got to be terribly frustrating for all parties involved including Akamai. A few new features that I like about MPLAB IDE v7.00: 1) Keyboard and mouse macro recorder and playback functionality 2) MPLAB ICD 2: Option to program the target device after a successful assemble or compilation (ASM or C) I have dial-up and won't download and archive the full installation download for a few days. Olin and Jan-Erik: ------------------ Yeah, I did a cursory check on the PIC10F linker script files and it looks like the configuration word mistake you mentioned is still in there. :( Best regards, Ken Pergola ____________________________________________

In message <200412020025.iB20Pmp25242EraseME.....d1o401.telia.com>> "Jan-Erik Soderholm" <EraseMEjan-erik.soderholmtelia.com> wrote: > On what Windows version ? 2000 Professional > Are you " local administration" on your PC ? login: Administrator password: Do you honestly think I'm stupid enough to post that on a public mailing list? Suffice it to say, as far as the machine is concerned, I am the administrator. > > Haven't Microchip heard of betatesting? > > Sure they have. And what's more, you are part of it ! :-) :-) Ugh. They're worse than Microsoft :-P Seems the mangled file is being purged from Mchip's distribution provider ATM. According to the Mchip employee who just emailed me, it should be sorted out within the next half hour or so. Later. -- Phil. | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB, RemoveMEphilpemEraseMEEraseMEphilpem.me.uk | ViewFinder, 10BaseT Ethernet, 2-slice, http://www.philpem.me.uk/ | 48xCD, ARCINv6c IDE, SCSI ... I could be arguing in my spare time. ____________________________________________

I just downloaded the full install and it appeared to install without problem. I notice they have also fixed the issue in the MPSIM where the timer did not increment on PIC10F204 and 206 targets. What is the configuration word mistake you refer to? Regards, -------------------------------------- Simon Dyer, ph +64 3 963 5522 -------------------------------------- {Original Message removed}

Simon Dyer wrote: > What is the configuration word mistake you refer to? Hi Simon, We recently had a thread about this. Jan-Erik Soderholm and Olin Lathrop mentioned that the linker script files for the PIC10F contain the wrong address for the configuration word -- a mistake. I verified that correcting the mistake in the linker script file does not ultimately solve the problem -- for sure at least in MPLAB IDE v6.62. Anyway, I've left a lot out and I'm too tired to re-hash all the specifics, but all the details are in this thread: RE: [PIC]: Easyprog firmware for Wisp628 (was: 16F628 programmingstrangeness) Best regards, Ken Pergola ____________________________________________

Philip Pemberton wrote : > > On what Windows version ? > > 2000 Professional OK. Same here. Actualy just run the install without any problems at all. Also rebuilt one of my project and all went just fine. I just had to tell MPLAB to use the tools (mpasm and mplink) from the new installation directories. > > Are you " local administration" on your PC ? > > login: Administrator > password: Do you honestly think I'm stupid enough to post > that on a public mailing list? Of course not ! Did I asked for that ? I wasn't even asking about your login user name, I was just asking if, whatever user you was using, if it had admin rights or not. Sigh... > Suffice it to say, as far as the machine is concerned, I am the > administrator. It's enough to have *admin rights*, you don't have to be logged in using the "administrator" username specificaly. Never mind... Jan-Erik. ____________________________________________

Ken Pergola wrote : > Simon Dyer wrote: > > > What is the configuration word mistake you refer to? > > We recently had a thread about this. Jan-Erik Soderholm and > Olin Lathrop mentioned that the linker script files for the > PIC10F contain the wrong address for the configuration word > -- a mistake... Hi. Well, this morning I'm not that sure about that anymore... The "PIC10F200/202/204/206, Memory Programming Specification", document DS41228D says : "Note: By convention the Configuration Word register is stored at the logical address location of 0xFFF within the hex file generated for the PIC10F200/202/204/206. This logical address location may not reflect the actual physical address for the part itself. It is the responsibility of the programming software to retrieve the Configuration Word register from the logical address within the hex file and translate the address to the proper physical location when programming." Personaly, I hadn't seen that before, and it seems to clear out this issue, doesn't it ? Best Regards, Jan-Erik. PS: The question about wheither this is good or bad design, is a totaly different question, IMHO... ____________________________________________

>>> On what Windows version ? >> 2000 Professional >>> Are you " local administration" on your PC ? >> Suffice it to say, as far as the machine is concerned, >> I am the administrator. > It's enough to have *admin rights*, you don't have to be > logged in using the "administrator" username specificaly. That's not true with all packages for Windows 2000 Professional. (It should be true as it is for other real operating systems.) I have (personal experience) tracked down problems where the user installed a package while logged in as a member of the administrator group. Package behaved oddly and/or failed. These were corporate software support people who knew what they were doing on multiple OSes. Redoing the package install while logged in as Administrator fixed the problems. So it sometimes _does_ matter on Windows. I don't know if this is still true on Windows XP. Lee Jones ____________________________________________

{Quote hidden}>-----Original Message----- >From: RemoveMEpiclist-bouncesspam_OUTKILLspammit.edu [RemoveMEpiclist-bouncesTakeThisOuTspammit.edu] >On Behalf Of Philip Pemberton >Sent: 01 December 2004 23:57 >To: EraseMEpiclistspamspamBeGonemit.edu >Subject: RE: [PIC] MPLAB IDE v7.00 is released > > >In message <RemoveME200412012330.iB1NUq214651KILLspamd1o401.telia.com>> > "Jan-Erik Soderholm" <jan-erik.soderholmSTOPspamspam_OUTtelia.com> wrote: > >> Anyway, the full 7.00 kit is at least a lot smaller then >> the 6.x kits was... :-) > >The full kit ZIP file is trashed FWICT. Also, the MPLAB7 >installer seems to be severely bugged - I got loads of "Could >not register class" (and similar) errors, reinstalled, finally >got MPLAB7 working, then found out that it was failing to >connect to the ICD2. > >Haven't Microchip heard of betatesting? Yes, what do you think you're doing? ;) Regards Mike ======================================================================= This e-mail is intended for the person it is addressed to only. The information contained in it may be confidential and/or protected by law. If you are not the intended recipient of this message, you must not make any use of this information, or copy or show it to any person. Please contact us immediately to tell us that you have received this e-mail, and return the original to us. Any use, forwarding, printing or copying of this message is strictly prohibited. No part of this message can be considered a request for goods or services. ======================================================================= ____________________________________________

> "Note: By convention the Configuration Word > register is stored at the logical address > location of 0xFFF within the hex file generated > for the PIC10F200/202/204/206. This > logical address location may not reflect the > actual physical address for the part itself. > It is the responsibility of the programming > software to retrieve the Configuration > Word register from the logical address > within the hex file and translate the > address to the proper physical location > when programming." Well, that's one way to fix a bug :-) RM ____________________________________________

Russell McMahon wrote : > > "Note: By convention the Configuration Word > > register is stored at the logical address > > location of 0xFFF within the hex file generated > > for the PIC10F200/202/204/206. This > > logical address location may not reflect the > > actual physical address for the part itself. > > It is the responsibility of the programming > > software to retrieve the Configuration > > Word register from the logical address > > within the hex file and translate the > > address to the proper physical location > > when programming." > > > Well, that's one way to fix a bug :-) > Hi ! (Yes, I did see the ":-)" )... Just so I understand what you are saying, besides of the smiley, do you still concider this as a "bug" ? Best regards, Jan-Erik. ____________________________________________

On Wed, 01 Dec 2004 18:59:28 -0500, Rolf <spamBeGonelearrSTOPspamEraseMErogers.com> wrote: > Humpfh...... won't run on Win98 (1st edition)..... 6.62 runs just fine > (even though it complains when you start up.....) 7.00 refuses to install. > > Now, if they had a linux version.... Does anyone know if it installs / runs on NT 4.0 (my work development machine)? Thanks, Bill ____________________________________________

Jan-Erik Soderholm wrote: > Well, this morning I'm not that sure about that anymore... > Personaly, I hadn't seen that before, and it seems > to clear out this issue, doesn't it ? Hi Jan-Erik, Good catch! Yes, thanks for posting that -- I missed that important detail too. It looks like all Third Party programmers should be writing and parsing the HEX file the same way that Microchip recommends with regard to the PIC10F configuration word address otherwise things can turn into a mess when people exchange HEX files and use various programmers. :( The one thing that bothers me is that Olin said in a previous thread that he reported the issue to someone at Microchip and they told him it was bug that should be fixed in the next version. No biggie in the end, as the CONFIG directive has worked fine for me with the PIC10F parts, so maybe there was a miscommunication somewhere along the line? As you've implied, the programming specification makes it crystal clear. :) Best regards, Ken Pergola ____________________________________________

Seems MPLAB still does not like long file paths i.e. greater than 62 characters. :-( _______________________________________ Roy Tauranga New Zealand _______________________________________ --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.802 / Virus Database: 545 - Release Date: 26/11/2004 ____________________________________________

Hopkins wrote : > Seems MPLAB still does not like long file paths i.e. greater than 62 > characters. :-( >From the V7.00 MPLAB IDE Readme file : <quote> - If you use MPASM assembler to assemble a single file (i.e., you do not use the assembler with MPLINK object linker), you will get a COD file which has a 63 character length restriction for file and path names. Shorten your file name or move your file into a directory closer to the root directory (shorten the path name), and try assembling your file or project again. As an alternative, use MPLINK linker with MPASM assembler to create a COFF file, which does not have this restriction. <endquote> And, relocatable code is the way to go anyway... Jan-Erik. ____________________________________________

Ken Pergola wrote: > It looks > like all Third Party programmers should be writing and parsing the HEX file > the same way that Microchip recommends with regard to the PIC10F > configuration word address otherwise things can turn into a mess when people > exchange HEX files and use various programmers. :( I don't see how to reliably determine (from the contents of a hex file only) if the address 0x0FFF contains the config-word for a 10Fxxx or a word of program memory for a different type of PIC. You might guess from the jump in addresses, but that can also occur for program memory! Since the 10F's also don't have a device-ID, the target can only be known to the programmer(software) via its human interface, which is the best guarantee for errors. Regards, Rob. -- Rob Hamerling, Vianen, NL phone +31-347-322822 homepage: http://www.robh.nl/ ____________________________________________

Rob Hamerling wrote: > I don't see how to reliably determine (from the contents of a hex file > only) if the address 0x0FFF contains the config-word for a 10Fxxx or a > word of program memory for a different type of PIC. Hi Rob, I do. As Jan-Erik just pointed out, Microchip says in the programming specification that the PIC10F configuration address should be written to the HEX file designated by address 0xFFF across all PIC10F parts. If *everyone* follows this "standard" then there is no problem. Maybe I did not make my point clear -- I was only talking about the *specific* case of PIC10F parts and the configuration word address in the HEX file. If Microchip is recommending that the PIC10F configuration word be embedded in the HEX file as address 0xFFF for all PIC10F parts, and other third party programmers decide to deviate from this advice and instead use the *true* device configuration word address (0x1FF or 0x3FF) depending on the PIC10F part, then that's the mess I was talking about when people start exchanging PIC10F HEX files and using various programmers. I hope this makes things clearer. Best regards, Ken Pergola ____________________________________________

Rob Hamerling wrote : > I don't see how to reliably determine (from the contents of a > hex file > only) if the address 0x0FFF contains the config-word for a > 10Fxxx or a > word of program memory for a different type of PIC. You might > guess from > the jump in addresses, but that can also occur for program memory! > Since the 10F's also don't have a device-ID, the target can only be > known to the programmer(software) via its human interface, > which is the > best guarantee for errors. > > Regards, Rob. > Yes, but you are talking about "bad design", not ? This thread (or rather threads) started as a discussion about a *BUG* in MPLAB/MPASM in regard to the handling of the config information for the 10F's. At the moment, it seems as MPLAB works as designed and as documented, and hence, I personaly can't see that there is a bug here at all. Now, this might be concidered as "bad design", I've no particular opinion on that, but even if it is, that doesn't automaticly makes it into a "bug". It would be interesting to hear Olin's view on this matter. I have a hard time beliving that he didn't know about that paragraph in the programming specification. And, Olin actualy wrote that MC had confirmed a "bug" that, as I understod it, had something to do with this. I'm a bit confused here... And it would also be interesting to hear how Wouter handles this issue i the new Wisp628 firmware and XWisp software. Best Regards, Jan-Erik ____________________________________________

Jan-Erik Soderholm wrote: > The "PIC10F200/202/204/206, Memory Programming > Specification", document DS41228D says : > > "Note: By convention the Configuration Word > register is stored at the logical address > location of 0xFFF within the hex file generated > for the PIC10F200/202/204/206. This > logical address location may not reflect the > actual physical address for the part itself. > It is the responsibility of the programming > software to retrieve the Configuration > Word register from the logical address > within the hex file and translate the > address to the proper physical location > when programming." What section is this in? I've been using DS41228C and don't remember anything like that. I wonder if this was added as a "fix" to getting the address wrong. I hope this isn't the final answer, because it's a bad design and requires special case checks in programming software. Yuck. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com ____________________________________________

> And it would also be interesting to hear how Wouter handles > this issue i the new Wisp628 firmware and XWisp software. No 10F support yet, but when I add that I would stick as closely as possible to what MPLAB does, being the standard, unless it is a confirmed (!) bug. It would also be worth a look what the various C compilers do (when someone else has already done the investigation, why not copy their conclusion - especially if they happen to agree). For trhe same reason it would be worth looking what Olin does. For a programmer it might be an option to recognise a configuration word at *either* address, maybe with a warning or only when a certain option is specified. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu ____________________________________________

Jan-Erik Soderholm wrote: > It would be interesting to hear Olin's view on this matter. I have > a hard time beliving that he didn't know about that paragraph in the > programming specification. And, Olin actualy wrote that MC had > confirmed a "bug" that, as I understod it, had something to do with > this. I'm a bit confused here... I was not aware of that paragraph. Either I somehow missed it, or it isn't in the C version of that same spec that I based my programmer design on. That was the latest spec at the time. That's why I asked where it is within the document. When I first started doing 10F code and running into this problem in July or August I reported to Microchip about the __CONFIG directive putting the config word at the wrong location. I was told that they were aware of this bug. There was absolutely no mention that FFFh was correct. My suspicion is that this paragraph was added to the spec as an expedience to "fix" the bug. That would really piss me off because not only is it bad design, but now I've got existing HEX files scattered at customer sites that are incorrect according to the new definition. That also means the programmers handle them incorrectly. Now I've got a mess. I'm going to download the new 10F programming spec and compare it with the previous. If they indeed slid this in, I am certainly going to complain about it. Once I've got a clear story from Microchip on this, I'll have to figure out how to address it. What comes to mind now is to make the programming software tolerant. If it's a 10F and there is nothing at FFFh, assume the actual config word address, else use what is at FFFh instead. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com ____________________________________________

olin_piclist@embedinc.com wrote : > Jan-Erik Soderholm wrote: > > > The "PIC10F200/202/204/206, Memory Programming > > Specification", document DS41228D says : > > > > "Note: By convention the Configuration Word > > register is stored at the logical address > > location of 0xFFF within the hex file generated > > for the PIC10F200/202/204/206. This > > logical address location may not reflect the > > actual physical address for the part itself. > > It is the responsibility of the programming > > software to retrieve the Configuration > > Word register from the logical address > > within the hex file and translate the > > address to the proper physical location > > when programming." > > What section is this in? It's on page 2, section "2.3 Configuration Word". It's in a framed box with a grey shaded background. If you have read Rev C, and you havn't seen it, I'm sure it isn't there in rev C... :-) The whole sect 2.3 reads : The Configuration Word register is physically located at 0x1FF and 0x3FF, respectively. It is only available upon Program mode entry. Once an Increment Address command is issued, the Configuration Word is no longer accessible, regardless of the address of the program counter. Note: [the same note as above, in a shaded box...] But why not just download the latest DS41228 ! :-) > I've been using DS41228C and don't remember > anything like that. I wonder if this was added as a "fix" to > getting the address wrong. Seems strange that, if this truly was a bug in MPLAB, they just didn't fix it in the latest MPALB ver 7... Hm, maybe that "bug" MC told you about, actualy was a bug in the docs !? :-) :-) Best Regards, Jan-Erik. ____________________________________________

DS41228B.PDF doesn't have it. DS41228C.PDF has the grey box mentioned refering to 0xFFF Yuck is correct, but is the better way to go. On Thursday 02 December 2004 01:41 pm, Olin Lathrop wrote: {Quote hidden}> Jan-Erik Soderholm wrote: > > The "PIC10F200/202/204/206, Memory Programming > > Specification", document DS41228D says : > > > > "Note: By convention the Configuration Word > > register is stored at the logical address > > location of 0xFFF within the hex file generated > > for the PIC10F200/202/204/206. This > > logical address location may not reflect the > > actual physical address for the part itself. > > It is the responsibility of the programming > > software to retrieve the Configuration > > Word register from the logical address > > within the hex file and translate the > > address to the proper physical location > > when programming." > > What section is this in? I've been using DS41228C and don't remember > anything like that. I wonder if this was added as a "fix" to getting the > address wrong. I hope this isn't the final answer, because it's a bad > design and requires special case checks in programming software. Yuck. > > > ***************************************************************** > Embed Inc, embedded system specialists in Littleton Massachusetts > (978) 742-9014, http://www.embedinc.com > ______________________________________________

part 1 1090 bytes content-type:text/plain; format=flowed; charset=us-ascii (decoded 7bit) For those that have had problems with V7.00 and wish to go back here is MicroChips' archive URL. Silly me deleted v6.4 of the IDE and then I neede to reinstall it. http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1495 Cheers. Philip Pemberton wrote: {Quote hidden}>In message <EraseME41AE5EB9.1030101EraseMEcotse.net> > Bob Axtell <@spam@engineer@spam@spam_OUTcotse.net> wrote: > > > >>I'm gonna hold off MPLAB7 until somebody says it works OK. >>No point in fighting more problems... >> >> > >Just rebooted and it started working - awful nice of Mchip to "forget" to >make the installer pop up a "You really should reboot before running Mplab" >msgbox, but there you go. >MPLAB 7 seems to work fine now. I wish it hadn't splattered MPASM and similar >files all over the HDD though. I wanted everything in F:\MPLAB, yet it >installed MPASM in C:\Program Files. There's a reason the C partition is only >4GB (makes it easier to Ghost)... > >Later. > > part 2 466 bytes content-type:text/x-vcard; name=nino.benci.vcf; charset=utf-8 (decoded 7bit) begin:vcard fn:Antonio Benci n:Benci;Antonio org:Monash University;School of Physics & Materials Engineering adr:Clayton Campus;;Building 27;Clayton;VIC;3168;Australia email;internet:spamBeGoneelectronic.servicesKILLspamspme.monash.edu.au title:Professional Officer / Electronic Services Manager tel;work:+613 9905 3649 tel;fax:+613 9905 3637 tel;cell:+61414924833 x-mozilla-html:FALSE url:http://www.spme.monash.edu.au version:2.1 end:vcard part 3 79 bytes content-type:text/plain; charset="us-ascii" (decoded 7bit) ____________________________________________

Wouter van Ooijen wrote: [about Wisp628/XWisp) > No 10F support yet, but when I add that I would stick as closely as > possible to what MPLAB does, being the standard, unless it is a > confirmed (!) bug. It would also be worth a look what the various C > compilers do (when someone else has already done the investigation, why > not copy their conclusion - especially if they happen to agree). The CC5X compiler (version 3.2A) puts the config word in 0x0FFF for any 10Fxxx.... Regards, Rob. -- Rob Hamerling, Vianen, NL phone +31-347-322822 homepage: http://www.robh.nl/ ____________________________________________

Jan-Erik Soderholm wrote: > It's on page 2, section "2.3 Configuration Word". > It's in a framed box with a grey shaded background. > If you have read Rev C, and you havn't seen it, > I'm sure it isn't there in rev C... :-) Meanwhile I've managed to leave my copy of version C at a customer site that I won't get back to until Monday, and I don't have any copy on my disk anymore. I do remember reading the part about the config word only being accessible right after entering program mode. > Seems strange that, if this truly was a bug in MPLAB, they > just didn't fix it in the latest MPALB ver 7... > > Hm, maybe that "bug" MC told you about, actualy was a > bug in the docs !? :-) :-) I sure hope not, but it is starting to look that way. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com ____________________________________________

olin_piclist@embedinc.com wrote : > I do remember reading the part about the config word > only being accessible right after entering program mode. Yes, correct. When you have sent the "enter programming mode" command to the 10F (any of them), the internal address counter is automaticly set at the config word address, no matter what that happens to be. (Currently 1FF or 3FF). And that's the only time you can write it. You can not later on return to that address by sending that address to the 10F. So, in other words, the important thing is to know *when* to send the config word, not what *address* it happens to be on. To me, when thinking of this "address-less" config word programming, makes the fixed FFF address in the HEX file looking more reasonable. After all, you don't have to make a difference between the different 10F's do you ? That is, in regard to the programming algorithm. Best Regards, Jan-Erik. ____________________________________________

Jan-Erik Soderholm wrote: > So, in other words, the important thing is to know *when* > to send the config word, not what *address* it happens to be on. Right, but you still need to know here it is in the HEX file. > To me, when thinking of this "address-less" config word programming, > makes the fixed FFF address in the HEX file looking more reasonable. > After all, you don't have to make a difference between the different > 10F's do you ? That is, in regard to the programming algorithm. More reasonable if everthing else worked that way. I have to go out of my way in the programming software because of the way the lower levels try to provide some device independence to the higher algorithms. The low levels just present an address space with all the mechanics of how to get to a particular address buried. The upper levels assume don't currently have a special case for reading a program memory location from one address in a HEX file and programming it into the chip at another. Of course this can all be changed, but it will require special case code to detect this 10F silliness. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com ____________________________________________

olin_piclist@embedinc.com wrote : > The upper levels assume don't currently have a > special case for reading a program memory location from > one address in a HEX file and programming it into the chip > at another. Yes, but on the 10F' you do not "program [the config word] into the chip at another [address]". The address in the *chip* doesn't matter, does it ? And you never specify it [for the chip] in the programming process, do you ? Anwyay, I think we agree. I can understand that this could be "differerent" if the software wasn't written that way from the start, and how could it been ? :-) Best Regards, Jan-Erik. ____________________________________________

Jan-Erik Soderholm wrote: > Yes, but on the 10F' you do not "program [the config word] > into the chip at another [address]". If you were writing programming software just for the 10F, you could easily do it that way. However, my existing software does specify the address and data at the higher levels, then the lower levels simply implement that. There is currently no means in the architecture for the higher levels to specify "program this word right after entering programming mode". This sort of low level detail is deliberately hidden from the higher layers. > The address in the *chip* doesn't matter, does it ? And you > never specify it [for the chip] in the programming process, > do you ? But the upper levels DO specify it, even though it is not actually transmitted to the chip as such by the specific chip driver. > Anwyay, I think we agree. I can understand that this could be > "differerent" if the software wasn't written that way from the start, > and how could it been ? :-) It breaks what has so far been a nice clean driver architecture. Once everything is initialized and the right driver is installed, the higher levels don't need to know anything about the specific programming algorithms of the various chips. They just say "write this value at that address". In the case of the 10F driver, it detects the config word address and does a device reset, but this is hidden inside the driver. This was a nice clean architecture and has worked well to support a variety of different programming algorithms - until now. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com ____________________________________________

part 1 821 bytes content-type:text/plain; format=flowed; charset=us-ascii (decoded 7bit) Why ! Coz for some unexplained reason which has not been explored nor investigated MPLAB 7.00 will not run on my 98SE PIII 550MHz test box. It crashes during any editing session. I gave up as I was desperate to get a project finished on time and I knew that v6.4 was working fine. I'll return to the problem some time in the future to sort out why but for now I'm happy Cheers. Antonio Benci Jan-Erik Soderholm wrote: {Quote hidden}>Antonio (Nino) Benci wrote : > > > >>For those that have had problems with V7.00 and wish to go >>back here is MicroChips' archive URL. Silly me deleted v6.4 >>of the IDE and then I neede to reinstall it. >> >> > >Why ? > >Regards, >Jan-Erik. >_____________________________________________