Post by thread:MPSIM yet another gotcha

ARRRGHH!@!! Burned again! It would seem that being a newbee has it's high price in PICland. Being new to the PIC I relied on MPSIM to accurately reflect the PIC's behavior as I learned the subtleties of the device. I -trusted- the tools Microchip supplied would work as advertised. Well, they DON'T. I have spent another dozen hours trying to figure out why my PWM code simulation wouldn't work (when it fact it was OK). It would appear that MPSIM fails to reload CCPR2H when running CCP2 in PWM mode. When TMR2 matches PR2 the book says "the PWM duty cycle will be latched from CCPR2L into CCPR2H on the next increment cycle". My prescaler is 0, the TMR2 is running but IT DOESN'T RELOAD with the new CCPR2L value (half scale) so CCPR1H stays at zero and the simulation never puts up the CCP2 pin (nor loads CCP2H). However, I finally got desperate and burned a '73A anyway, and the code worked _prefectly_ even though the simulation shows that it wasn't working at all. What will it take to get Microchip to put MPLAB into the public domain so that we can FIX IT all the 'undocumented features' like Linux people do? spam_OUTRobert.RolfTakeThisOuTUALberta.ca -- If debugging is the process of removing errors, then programming must be the process of putting them in.

> Van: Robert Rolf <.....Robert.RolfKILLspam@spam@UALBERTA.CA> > Aan: PICLISTKILLspamMITVMA.MIT.EDU > Onderwerp: MPSIM yet another gotcha > Datum: vrijdag 4 februari 2000 8:43 > > ARRRGHH!@!! Burned again! > > It would seem that being a newbee has it's high price in PICland. > Being new to the PIC I relied on MPSIM to accurately reflect the PIC's behavior as I > learned the subtleties of the device. I -trusted- the tools Microchip supplied would work > as advertised. Well, they DON'T. You're right. Use MPLAB for assembling, programming & single-step of *code* (not hardware !) only. I definitely hate it when I have to remember the quirks of both the controller *and* the Emulator/simulator used to test the device. By the way: ever tried to create data for a EEProm ? My version of MPLAB allways tries to show a *assembly*-listing of the EEProm-data (program memory window) ... Next to that, at loading it allways defaults to that window <sigh>, and complains about differences between the choosen processors (EEPROM8 & 24C16B), although the setup is copied from the book ... But, because it's "free" software, we are not expected to complain. Ah well, we just have to live with it --- live *without* it I mean :-) Regards, Rudy Wieser

Caisson wrote: > By the way: ever tried to create data for a EEProm ? My version of MPLAB > allways tries to show a *assembly*-listing of the EEProm-data (program > memory window) ... >.. > But, because it's "free" software, we are not expected to complain. > > Ah well, we just have to live with it --- live *without* it I mean :-) > > Regards, > Rudy Wieser The next version of MPLAB which should be posted this week has a whole list of user-requested features. The tools group is doing its very best to keep MPLAB, MPLAB-SIM, MPASM, PICSTART Plus, PRO MATE II, MPLAB-ICE, MPLAB-C17, MPLAB-C18, MPLINK and MPLIB up-to-date and supporting all the Microchip PICmicros. The simulator was designed as an instruction-based simulator and admittedly will not simulate all the peripherals. That is why there are emulators. For MPLAB-SIM the choice was to make a tool that could help productivity without attempting to simulate all of the subtleties of the hardware. If you look at the assembler/simulator being developed by the GNUPIC group, you'll see the result of opening up the software, as some have requested. It's an admirable effort, but it's a much bigger task than most probably anticipate, and to get complete up-to-date support for all the tools listed above, is tough. BTW, on the program memory window, you can select to view the data in program memory as disassembled code, or as a hex dump if you are just filling it with data. -- ___________________________ | Darrel Johansen | | tempe, arizona | | .....darreljKILLspam.....primenet.com | |_________________________|

On Mon, 7 Feb 2000, Darrel Johansen wrote: {Quote hidden}> Caisson wrote: > > > By the way: ever tried to create data for a EEProm ? My version of MPLAB > > allways tries to show a *assembly*-listing of the EEProm-data (program > > memory window) ... > >.. > > But, because it's "free" software, we are not expected to complain. > > > > Ah well, we just have to live with it --- live *without* it I mean :-) > > > > Regards, > > Rudy Wieser > > > For MPLAB-SIM the choice was to make a tool that could help productivity > without attempting to simulate all of the subtleties of the hardware. If you > look at the assembler/simulator being developed by the GNUPIC group, you'll see > the result of opening up the software, as some have requested. It's an > admirable effort, but it's a much bigger task than most probably anticipate, > and to get complete up-to-date support for all the tools listed above, is > tough. If I may, Darrel, (since I don't work for microchip, I don't have to be as nice - and I really despise complainers). If you don't like MPSIM (specifically, or MPLAB in general), you have many choices. - You can go off and write your own simulator - You can join the gnupic project and help with gpsim - You can fork out $$ for umps - You can buy an emulator from one of several different sources If you're getting paid to develop code for pics and you're frustrated with MPSIM, then buy an emulator. It will save you money in the long run. Except for the demo program I downloaded about a year ago, I can't really comment on UMPS. But again, if you're getting paid to develop for pics, then I'd suggest you check it out. If you're a hobbyist just getting into pics, then MPLAB/MPSIM is perfect. If you're a hobbyist that's been developing pic code for a while, then you're most probably aware of its limitations (and capabilities). Now to clarify one point made by Darrel, the gnupic project is NOT a result of microchip 'opening up it's software'. It has been evolving in various forms over the last few years. Most recently, there's been just a hand full of us writing software for it. And I've been doing almost all of the simulator portion (and I'd appreciate help ;)). I started gpsim because I was frustrated with a few missing features in mpsim: -- Too slow -- Limited stimulus support -- Limited peripheral support -- Toooo sllooowww These are hardly justifiable reasons to go off and write a simulator, but there are some additional external factors that have motivated my decision as well. (For example, I needed something to take up all of this free time I keep on finding myself having ;). I'd much rather see patches to gpsim than complaints about mpsim. Seriously! In terms of simulator functionality, gpsim is probably somewhere between 20 and 50% as capable as mpsim. Scott PS. Check out http://www.dattalo.com/gnupic/lcd.html to see something we're working on for gpsim.

> Van: Darrel Johansen <EraseMEdarreljspam_OUTTakeThisOuTPRIMENET.COM> > Aan: PICLISTspam_OUTMITVMA.MIT.EDU > Onderwerp: Re: MPSIM yet another gotcha > Datum: dinsdag 8 februari 2000 2:26 > Caisson wrote: > > > By the way: ever tried to create data for a EEProm ? My version of MPLAB > > allways tries to show a *assembly*-listing of the EEProm-data (program > > memory window) ... <Snip> > BTW, on the program memory window, you can select to view the data in program > memory as disassembled code, or as a hex dump if you are just filling it with > data. That MPLAB default's to "Machine-code display" (in the Program-memory window) is not such a big deal. I knew how to choose another representation. But when the "disassembled" commands consisted outof char-garbage, every (re-) load of the project is be followed by processor-mismatch messages and the the Program-memory window again defaults to "Machine-code display", I'm not really impressed. Even less because these error's did not came up after much debugging & reverse-engeneering, but *jumped* at me as I opened up a EEProm oriented project. I was stunned at the fact that such obvious errors where overlooked :-(( Regards, Rudy Wieser

> Van: Scott Dattalo <@spam@scottKILLspamDATTALO.COM> > Aan: KILLspamPICLISTKILLspamMITVMA.MIT.EDU > Onderwerp: Re: MPSIM yet another gotcha > Datum: maandag 7 februari 2000 15:26 <Snip> > If I may, Darrel, (since I don't work for microchip, I don't have to be as > nice - and I really despise complainers). > > If you don't like MPSIM (specifically, or MPLAB in general), you have many > choices. > > - You can go off and write your own simulator > - You can join the gnupic project and help with gpsim > - You can fork out $$ for umps > - You can buy an emulator from one of several different sources <Snip> Responded to privately. Rudy Wieser

Caisson wrote: > > That MPLAB default's to "Machine-code display" (in the Program-memory > window) is not such a big deal. I knew how to choose another > representation. But when the "disassembled" commands consisted outof > char-garbage, every (re-) load of the project is be followed by > processor-mismatch messages and the the Program-memory window again > defaults to "Machine-code display", I'm not really impressed. Even less > because these error's did not came up after much debugging & > reverse-engeneering, but *jumped* at me as I opened up a EEProm oriented > project. I was stunned at the fact that such obvious errors where > overlooked :-(( > > Regards, > Rudy Wieser I know there's a complaint in there somewhere. If you could clarify, I'll make sure that it gets added to the MPLAB "wish-list." -- ___________________________ | Darrel Johansen | | tempe, arizona | | RemoveMEdarreljTakeThisOuTprimenet.com | |_________________________|

> Van: Darrel Johansen <spamBeGonedarreljspamBeGonePRIMENET.COM> > Aan: TakeThisOuTPICLISTEraseMEspam_OUTMITVMA.MIT.EDU > Onderwerp: Re: MPSIM yet another gotcha > Datum: woensdag 9 februari 2000 2:45 > > Caisson wrote: <Snip> > > Even less > > because these error's did not came up after much debugging & > > reverse-engeneering, but *jumped* at me as I opened up a EEProm oriented > > project. I was stunned at the fact that such obvious errors where > > overlooked :-(( > > > > Regards, > > Rudy Wieser > > I know there's a complaint in there somewhere. If you could clarify, I'll make > sure that it gets added to the MPLAB "wish-list." Just a few simple requests (in order of importancy) : 1) Check your product before you release it 2) Check your product before you release it 3) Check your product before you release it 4) Don't add features that work "most of the time", but don't tell you when not. All other wishes are minor, compared to the above. Regards, Rudy Wieser