Post by thread:ROM Loader

I think I've actually made somthing that is worth it's salt. I've been developing code that talks between two PICs over a spread spectrun radio link, and have been using the ROMzap boot laoder. The amount of time that saves compared to the old erase/rewrite cycle is amazing. What used to take minutes, and sometimes half an hour, now only takes a few mouse clicks (and the programming time). It certainly eases some frustration. -- Best regards Tony http://www.picnpoke.com spam_OUTsalesTakeThisOuTpicnpoke.com ** Check out the new PicNPoke - up to 50% cheaper **

Cool WHich Spread SPectrum Link? What Baud rate? Howsa bout some details. Kelly At 03:29 PM 2/29/00 +1100, you wrote: {Quote hidden}>I think I've actually made somthing that is worth it's salt. > >I've been developing code that talks between two PICs over a spread >spectrun radio link, and have been using the ROMzap boot laoder. > >The amount of time that saves compared to the old erase/rewrite cycle is >amazing. > >What used to take minutes, and sometimes half an hour, now only takes a >few mouse clicks (and the programming time). > >It certainly eases some frustration. > >-- >Best regards > >Tony > >http://www.picnpoke.com >.....salesKILLspam@spam@picnpoke.com > >** Check out the new PicNPoke - up to 50% cheaper ** > > William K. Borsum, P.E. -- OEM Dataloggers and Instrumentation Systems <borsumKILLspamdascor.com> & <http://www.dascor.com>San Diego, California, USA

<x-flowed>At 03:29 PM 2/29/00 +1100, Tony Nixon wrote: >I think I've actually made somthing that is worth it's salt. > >I've been developing code that talks between two PICs over a spread >spectrun radio link, and have been using the ROMzap boot laoder. > >The amount of time that saves compared to the old erase/rewrite cycle is >amazing. I went to Tony's site last evening and took a look at ROMzap. Looks great! For what its worth, I have a suggestion. I find that i/o is always a problem - having to lose 2 i/o pins (1 if I drop the LED) can be problematic. But I think I see a way to incorporate the LOAD pin into the serial lines. Serial TX from the pic is normally HI. Break the line going from TX to the MAX232, connect TX to pin 2 of a 3 pin header. Connect pin 1 of the header to the input of the MAX232 along with a 10k pullup resistor (maintains idle condition while reading input / selecting program mode). Connect the last pin of the header to ground via a 1k resistor. Change the code (I'm about to try this) so that after the pic is reset, it turns the TX line to an input and reads the level. If HI, just jump to user code. If LO, jump to the programming code but wait until the line goes HI before actually doing anything. The 3 pin programming link can be either a spdt push button or a 3 pin header and jumper. Just a suggestion, Tony. Many thanks for the idea! dwayne Dwayne Reid <.....dwaynerKILLspam.....planet.eon.net> Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax Celebrating 16 years of Engineering Innovation (1984 - 2000) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Do NOT send unsolicited commercial email to this email address. This message neither grants consent to receive unsolicited commercial email nor is intended to solicit commercial email. </x-flowed>

Dwayne Reid wrote: > Change the code (I'm about to try this) so that after the pic is reset, it > turns the TX line to an input and reads the level. If HI, just jump to > user code. If LO, jump to the programming code but wait until the line > goes HI before actually doing anything. Good idea. Actually, I have used a pushbutton switch instead on the project I am working on, but I never thought to put in on the TX line. If I hold the PB switch down at powerup, Program Mode -> update ROM -> Execute code If PB switch is up at powerup, Execute Code I'll try to implement this today. Andy Kunz wrote: > Which spread spectrum? Which PIC chips? Etc. RF Innovations RFI-9256 - about $1K each. http://www.crlabs.com.au/Default.htm > You have a schematic you can share? Just hooks straight upto the PIC16F877 UART on RC6 and RC7. -- Best regards Tony *** PicNPoke - 50% price cut - plus *** *** bonus experimenters parts included *** *** 2 X 20 LCD, 7 seg, relay + driver, *** *** LED, switch, serial EEPROM, more *** http://www.picnpoke.com EraseMEsalesspam_OUTTakeThisOuTpicnpoke.com

Where can I take a look at this ROMzap? ----- Original Message ----- From: "Dwayne Reid" <@spam@dwaynerKILLspamPLANET.EON.NET> To: <KILLspamPICLISTKILLspamMITVMA.MIT.EDU> Sent: Tuesday, February 29, 2000 1:22 PM Subject: Re: ROM Loader > At 03:29 PM 2/29/00 +1100, Tony Nixon wrote: > >I think I've actually made somthing that is worth it's salt. > > > >I've been developing code that talks between two PICs over a spread > >spectrun radio link, and have been using the ROMzap boot laoder. > > > >The amount of time that saves compared to the old erase/rewrite cycle is > >amazing. > > I went to Tony's site last evening and took a look at ROMzap. Looks great! > > For what its worth, I have a suggestion. I find that i/o is always a > problem - having to lose 2 i/o pins (1 if I drop the LED) can be > problematic. But I think I see a way to incorporate the LOAD pin into the > serial lines. > > Serial TX from the pic is normally HI. Break the line going from TX to the > MAX232, connect TX to pin 2 of a 3 pin header. Connect pin 1 of the header > to the input of the MAX232 along with a 10k pullup resistor (maintains idle {Quote hidden}> condition while reading input / selecting program mode). Connect the last > pin of the header to ground via a 1k resistor. > > Change the code (I'm about to try this) so that after the pic is reset, it > turns the TX line to an input and reads the level. If HI, just jump to > user code. If LO, jump to the programming code but wait until the line > goes HI before actually doing anything. > > The 3 pin programming link can be either a spdt push button or a 3 pin > header and jumper. > > Just a suggestion, Tony. Many thanks for the idea! > > dwayne > > > > Dwayne Reid <RemoveMEdwaynerTakeThisOuTplanet.eon.net> > Trinity Electronics Systems Ltd Edmonton, AB, CANADA > (780) 489-3199 voice (780) 487-6397 fax > > Celebrating 16 years of Engineering Innovation (1984 - 2000) > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > Do NOT send unsolicited commercial email to this email address. > This message neither grants consent to receive unsolicited > commercial email nor is intended to solicit commercial email. >

<x-flowed>At 09:07 AM 3/1/00 +1100, Tony Nixon wrote: >Good idea. > >Actually, I have used a pushbutton switch instead on the project I am >working on, but I never thought to put in on the TX line. > >If I hold the PB switch down at powerup, > > Program Mode -> update ROM -> Execute code > >If PB switch is up at powerup, > > Execute Code You still may want to consider SPDT - while the switch is pressed, the MAX232 still sees a HI (idle state) which stops your PC from being freaked out by framing errors. The 1k or so resistor to GND ensures that you don't draw excessive current from TX while it is an output and the switch is pressed. When entering program mode, waiting until the switch is released ensures that TX output is connected back to the MAX232 before attempting communication with the PC. I originally considered just allowing the input of the MAX232 to be held LO while the switch was pressed but had thought that the PC would complain. If that is not the case, then just make the pullup resistor on TX be 2 resistors in series with the switch shorting the midpoint to Gnd. I'd still wait until the line was back HI before trying to talk to the PC, though. dwayne Dwayne Reid <spamBeGonedwaynerspamBeGoneplanet.eon.net> Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax Celebrating 16 years of Engineering Innovation (1984 - 2000) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Do NOT send unsolicited commercial email to this email address. This message neither grants consent to receive unsolicited commercial email nor is intended to solicit commercial email. </x-flowed>

Dwayne Reid wrote: > I originally considered just allowing the input of the MAX232 to be held LO > while the switch was pressed but had thought that the PC would > complain. If that is not the case, then just make the pullup resistor on > TX be 2 resistors in series with the switch shorting the midpoint to > Gnd. I'd still wait until the line was back HI before trying to talk to > the PC, though. Done and new version uploaded. If the PIC sees a logic 0 on the TX line (RC6) then it goes into program mode. The input pin on the 232 chip has a 400K resistor to 5V. The PB switch(link) shorts this line to ground via a 1K resistor. I modified ROMzap.exe so that the serial port is only active during boot programming. That way the PC should ignore the TX line at switch on. -- Best regards Tony http://www.picnpoke.com RemoveMEsalesTakeThisOuTpicnpoke.com

Dwayne Reid wrote: > Hi again, Tony. > > Couple of thoughts and observations: > > 1) I just noticed this - shouldn't you org BOOT.asm somewhere past 0x04 to > avoid interrupt issues? May not be an issue for the app you are working on > but might be for others. I changed the boot code like this org 0h goto start org 4h goto 0x0081 start ; boot code starts here In your source code with no interrupts org 0x0080 ; your code begins In your source code with interrupts org 0x0080 goto start goto Interrupt ; or just put interrupt code here ; causes extra 2 machine cycles each IRQ ; for 1 extra goto instruction start ; your code begins > 2) I just had a look at the new schemo - ground missing at jumction of C8 > and CN1 pin 5. Fixed > question - do all versions of the MAX232 contain that 400K pullup? Don't know off hand. > This is a hell of an idea you had, Tony, something probably as important as > David Tait's simple programmer. Thanks for sharing. No problem. ROMzap has just been upladed again. -- Best regards Tony http://www.picnpoke.com salesEraseME.....picnpoke.com

<x-flowed>At 03:53 PM 3/1/00 +1100, Tony Nixon wrote: {Quote hidden}>I changed the boot code like this > > org 0h > goto start > > org 4h > goto 0x0081 > >start ; boot code starts here > > > > >In your source code with no interrupts > > org 0x0080 > > ; your code begins > > >In your source code with interrupts > > org 0x0080 > > goto start > goto Interrupt ; or just put interrupt code here > ; causes extra 2 machine cycles each IRQ > ; for 1 extra goto instruction > >start ; your code begins Hi again, Tony. I'm somewhat reluctant to make the following suggestions for fear that I might be criticizing or coming off as a 'know it all' - I certainly am not. However, nothing ventured, nothing gained. That said, here goes. I now tend to structure my code as follows: org 0x00 goto ColdBoot org 0x04 ;save context and parse interrupts here ;here is where the parser lives - jump to appropriate ISR minimal ISR code here - if a routine is nice and short, it lives here. Otherwise, its located after any jump tables. ;jump tables live here ; blah blah blah ;actual ISRs live past the jump tables. ;subroutines live here ColdBoot ;start of code The rational is somewhat convoluted and may be flawed. 1) I don't perform any jumps when entering the ISR until the context is saved - on 4K and larger parts, PCLATH may be incorrect and you might be jumping to the wrong page. Thus, I save context, clear PCLATH, THEN jump to the appropriate routines. 2) I like to keep jump tables right near the beginning of ROM space because it means that I can set PCLATH with a single instruction that does not affect any flags (clrf PCLATH). This means that the actual ISR routines usually live past jump table space. There are always exceptions to the rule. In particular, if an ISR is very short and has to be quick, it goes before the jump tables. I'm interested in opinions and thoughts. dwayne Dwayne Reid <EraseMEdwaynerplanet.eon.net> Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax Celebrating 16 years of Engineering Innovation (1984 - 2000) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Do NOT send unsolicited commercial email to this email address. This message neither grants consent to receive unsolicited commercial email nor is intended to solicit commercial email. </x-flowed>

<x-flowed>Yet another couple of thoughts, Tony. 1) Should the program load / run jumper polarity be reversed? Under normal circumstances, TX out is HI while idle. To minimize power consumption, that jumper should be removed unless debug / load work is going on. 2) how about another command to return the start address of the code that is to be loaded? Maybe a 'S' ? The PC would ask for the start address before beginning the load procedure, BOOT.asm would return the address of the label 'RunProg'. This would allow a little more flexibility. I definitely see the conflict with the way I position code VS what BOOT.asm needs to see. The problem is, of course, that you can't be overwriting the code that you are executing. What makes it such a problem is the ISR stuff at 0x04. One possibility is to locate BOOT.asm right at the end of code space, much like Mchip's ICD stuff. This is gonna take more thought at my end. Actually, maybe locating BOOT at the end of code space does fix the problems! There are 4 code spaces between 0x00 and 0x04 - how about something like the following: org 0x00 movlw high(BootLoader) movwf PCLATH goto BootLoader org 0x04 ;ISR stuff near the end of code space, BootLoader ;test TX line and either enter the boot load routine or reset PCLATH and jump to ColdStart. The only thing that would be required to be the same in all versions of the user code are those 3 lines org'ed at 0x00. That also gets rid of the usefulness of that 'S' command I suggested earlier. Thoughts? dwayne Dwayne Reid <RemoveMEdwaynerEraseMEEraseMEplanet.eon.net> Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax Celebrating 16 years of Engineering Innovation (1984 - 2000) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Do NOT send unsolicited commercial email to this email address. This message neither grants consent to receive unsolicited commercial email nor is intended to solicit commercial email. </x-flowed>

Dwayne, I have done exactly what you suggest. a. moved the download code to 1F00h for 16f877 and 0F00h for 16f873(not really, I have only '877). b. defined 0004h as load start address. c. defined 0005h as run start address. In downloaded program I just put at 0004h a goto the real ISR and at 0005h the start of user program. I have seen an other downloader that implemented a PW to protect unauthorized download, this helps but not solve the protection of code. Download is really interesting in development cycle but not in production. Claudio Rachiele IW0DZG

<x-flowed>I was obviously up too late last night and forgot to include a couple of important items in regard to putting the boot loader at the end of code space. The boot loader would start programming at address 0x00 - the first 3 lines would always be the same but the 4th line would be resolved by the compiler to reflect the actual start location of user code. BOOT.asm would never have to change once it was loaded because it will always jump to location 0x03 which in turn jumps to user code. org 0x00 movlw high(BootLoader) movwf PCLATH goto BootLoader goto ColdStart ;jump point for boot loader org 0x04 ;ISR stuff near the end of code space, BootLoader ;test TX line and either enter the boot load routine or reset PCLATH and jump to 0x03 which in turn jumps to ColdStart. I'm thinking that I'd want to test for the cause of the reset - if it was *not* MCLR, just clear PCLATH and jump to 0x03. Tony - would it be possible for you to create a version of ROMzap.exe that starts at 0x00 instead of 0x80? Better yet, is it worthwhile to make the first line of zap.dat contain the start address? That would allow us to play around with different memory schemes. Thoughts, comments? dwayne Dwayne Reid <RemoveMEdwaynerspam_OUTKILLspamplanet.eon.net> Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax Celebrating 16 years of Engineering Innovation (1984 - 2000) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Do NOT send unsolicited commercial email to this email address. This message neither grants consent to receive unsolicited commercial email nor is intended to solicit commercial email. </x-flowed>

Hi all, I had some spare time last night, so I changed the ROMzapper, (hopefully for the better). The boot code now loads at address 0f00h for 4K chips, and 1f00 for 8k chips The code at 0000h is movlw high(start) movwf pclath goto start That leaves 1 word at address 0003 for a goto if needed and 0004h is free for normal use. A few conditional code snippets were added to make boot compilation easier. Such as... if PIC8K == 0 list p=16F874 else list p=16F877 endif I rewrote ROMzap.exe to reflect the boot changes, plus I added a port and tris data setup panel so that you don't need to modify the boot.asm code to be compatable with your projects. You can change the port intitialization from within ROMzap. You can also save and load the port data as a text file. The new version has been uploaded. I haven't had time to fully check it out, so email me at the address below if there are bugs, or enhancements needed. -- Best regards Tony http://www.picnpoke.com RemoveMEsalesTakeThisOuTspampicnpoke.com