On Sat, Jun 26, 2004 at 11:36:02PM +0200, Kyrre Aalerud wrote: > Hehe. > If only I could get my LV ICSP to work I could test the loader... > > BTW: If you have a system where you will be using a RS232 connection, why > not use that as the bootloader ? > Saves all the other pinns for regular I/O :) (That's why I made mine USART > based.) You're asking this question of a couple of folks who have well thought out the process. I actually addressed this issue with Tato. But let me throw out a simple example to illustrate. One project on my list is a MIDI sequencer. MIDI is a musical async serial interface, not RS232. But even if it were, for example a caller ID box that uses a modem for the CID interface, the principle is the same. I have a conflicting usage for the port. I need it for the application at one point in time, and I also need it for the bootloader. So I end up having to do cable swaps each and every time I update the software. I know that you're thinking of this as a "in the field" update tool. I use bootloaders as my primary development tool. And the rule of thumb that I use is that the less I have to mess with while developing, the faster I'll get done. So a bit banged interface is an excellent idea for a bootloader. While we'll all agree that it'll take more code space to run, it gives three advantages: 1) That with minor effort, a port pin can be saved. 2) The separate debugging port is available as alluded to below. 3) The designer gets to pick the pin for the interface instead of having it declared by the hardware pin selection. I'll freely admit that Wouter has me quite spoiled when it comes to bootloaders. He really thought out the issues, and followed it up with designs that make sense. So everything else that comes along (including Wouter's own ZPL) gets the comparison to the following feature list: 1) Single pin or less interface. 2) Less than 200 bytes in size. 3) User choosable bootloader pin. 4) Transparancy to the target application. Ideally any hex file should be loadable and executable without modification. except for... 5) Self protection. The bootloader should always be available even if the load fails. It shouldn't overwrite itself. 6) Verification. The application should not execute on a failed load and the PC application should be made aware of the failure. 7) Debugging interface for the application. 8) permanently utilize no resources other than program memory and the I/O pin from step 1. 9) Be available for all self writable PIC chips. As of right now no loader that I know of meets all of these criteria. * Wloader right now is the closest meeting 7 of 9 (failing #9 for 18F and the 16F88/16F819 family parts and #2 IIRC). * ZPL fails #6, #7, #3 on a technicality, and #9. Maybe #2 also * Tato's PLoader fails #5 and #9 and is currently written so that #1 fails as it uses 2 I/O pins. But a Wloader style interface can easily be added. Also I don't think it's application transparent, so #4 is out * Yours fails #1, #3, #8 (all due to the USART) and #4, and of course has the #9 issue. * Tiny fails #1, #3, #8 due to the USART. Currently it fails #9 because it doesn't do the 16F88 and 16F819 though it does have 18F support along with the 16F87X parts. It also fails #5 trusting the PC app to not overwrite it. Also personally I have a #10 which is Linux based application applicability. Not on the main list because it's relevant only to me. This has two phases: Can the source be compiled with gpasm, and is there an application for loading and executing applications. ZPL may meet both, the ZPL16F that I wanted to write definitly met both. Both Tiny and Wloader used a couple of macro contructs that threw gpasm off. Ploader assembles just fine, and Woj's linwload can be transformed in less than an hour. Same for yours and Tiny, while both linwload and Wouters XWISP in python drives Wloader. Wouter also wrote the ZPL interface in python, and I've tested it a couple of times too. So my analysis is as follows: * PLoader is my new frontrunner. It's small, bit bangs, works for the 18 pin nanowatt self programmable parts already. Also it assembles no problems. Throw in some transparancy, some verification, and a single pin interface (all pretty easy to do) and call it a day for now. Later on up port it to the 16F87X[A] and 18F (especially the 40 pin nanowatt huge 18F4320!) and have a great all around tool for development. * WLoader is close. It's already successful in my book. Really only requires the 4-8 block write and pre-erase of blocks to work for 16F87XA (which Wouter has already done from what I understand) and 16F88/16F819. No current 18F port yet. * ZPL is intriguing. Only requires a MCLR pin to work! No verification or debugging capabilities. Also currently no 16F downport (I hope to get to it soon. I started preliminary testing a couple of months ago.) * The USART based loaders are a decision on the dedication of the USART to the task. But ideally I'd like to pick one and stick to it like glue. So the closer the target fits to the list above, the better the overall value. BAJ > > Kyrre > > > ----- Original Message ----- > From: "Byron A Jeff" > To: > Sent: Saturday, June 26, 2004 11:21 PM > Subject: Re: [PIC:] 16F88 RS232 bootloader. > > > > On Sat, Jun 26, 2004 at 01:40:56PM -0700, Bob Axtell wrote: > > > I am VERY interested in the F1688 Bootloader project. I have a > > > specific need for one, so that the client can change the 688 firmware > > > whenever needed. > > > > I think we all have a need for a 16F819/16F88 bootloader! Have you taken a > > look at Tato's PLoader here?: http://propic2.com/ploader > > > > It's a bit banged serial loader targeted for the 16F819. While I haven't > > gotten to testing yet, it should work fine for a 16F88 as written, and > with > > trivial modifications (setting/resetting PCLATH) the loader should be > > able to move to the last page of the 16F88 program memory space. > > > > See my post to Victor as to why I like the bit banged idea. > > > > Now Kyrre's is sounding like a tight USART based loader what will have its > > uses too. > > > > I'm glad that I can stand on the sidelines and cheer, because I do think > that > > it'll benefit many of use as we proceed. > > > > > > > > It might be very helpful if you make 1 or 2 more registers available for > > > debugging, where you can press the reset button, and if those registers > > > are not the DEFAULT value, let them be read by your bootlegger as a > > > primitive debug tool. The way it would work is to copy to these > > > registers anything valuable you'd like to see, or verification of a > > > pathway (by setting bits in the debug register as the particular routine > > > is passed through) > > > > That's one way to tackle it. I'll tell you how I've handled it in the > past. > > When using Wouter's Wloader on my 16F877 projects in the past, I realized > > (with a light switch from Woj, the author of linwload) that the single pin > > serial interface was still available when the application was running. So > > instead of just having a couple of registers, that it's possible to send > > messages and data through the bootloader serial interface. You can see a > sample > > of this in action in my sunrise/sunset outdoor light controller here: > > > > http://www.finitesite.com/d3jsys/clock.asm > > > > THe dbgout routine along with delay/idelay near the bottom will send a > single > > char down the bootloader serial interface. Routines like printdate and > printstr > > then use the single character routine to send messages. It made desktop > > testing trivial as you could program, execute, and debug all in a single > > session with a single application. Finally note how the use of the Timer 2 > > period register makes short work of the bit rate generator. > > > > [IDLE THOUGHT ALERT!]: It would even be cooler if the USARTs bit rate > generator > > could be decoupled from the USART hardware and be used as a 4th > independant > > self resetting on rollover timer. I'd use it like I'm using timer 2 here > but > > bitbang the serial interface with it.[/IDLE THOUGHT ALERT!] > > > > > > > I'll be glad to help you guys debug or verify the Bootloader; having a > > > card made right now... > > > > I need to wire up a quick card and get to testing. But my lawn tractor > needs > > to be fixed first. Priorities, Priorities! > > > > BAJ > > > > -- > > http://www.piclist.com hint: The list server can filter out subtopics > > (like ads or off topics) for you. See http://www.piclist.com/#topics > > > > -- > http://www.piclist.com hint: The list server can filter out subtopics > (like ads or off topics) for you. See http://www.piclist.com/#topics -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics