Byron A Jeff wrote: > On Sat, Feb 24, 2007 at 07:48:21AM -0700, Bob Axtell wrote: > >> Byron A Jeff wrote: >> >>> On Sat, Feb 24, 2007 at 08:53:06AM -0500, Byron A Jeff wrote: >>> >>> >>>> On Thu, Feb 22, 2007 at 07:21:24AM -0500, Olin Lathrop wrote: >>>> >>>> >>>>> Alan B. Pearce wrote: >>>>> >>>>> >>>> So you need the following: >>>> >>>> 1) Nanowatt enabled >>>> 2) BODEN enabled with low ram retention voltage (seemes to be 4.35V and 1.5V >>>> respectively for all the sheets I checked) >>>> 3) Decoupled BODEN and PWRTMR >>>> >>>> >>> I missed the obvious which is the part needs to be self programmable. >>> >>> >>> >>>> I'm only bummed out because the 16F887 doesn't decouple BODEN and PWRTMR. That >>>> would have been the perfect target for me. >>>> >>>> >>> Now I'm confused. I'm almost certain that I read for the 16F887 that the 72ms >>> PWTTMR would be invoked on a BOD regardless of if the bit were set or not. >>> Wistfully I pulled the datasheet again (a different one?) And found this on >>> page 210 (emphesis mine): >>> >>> "The Power-up Timer will now be invoked, IF ENABLED and will keep the chip in >>> Reset an additional 64 ms." >>> >>> Now that's excellent news! I must have been reading a different data sheet >>> because note this line says 64 mS and I know I read a page that said 72 mS. >>> >>> To program, just wiggle the power line. Wow! >>> >>> BAJ >>> >>> > > >> for F88: WHAT reg/bit is tested to determine the voltage bit HI or LO? >> > > A quick explanation of how Wouter's Zero Pin Bootloader (ZPL) works. It > measures the run time between resets. To clock a zero bit you run for > a short length of time, for a one bit your run for a longer bit of time > before resetting. Since memory is retained between resets you can simply read > the count of the previous runtime when you reboot. Based on that count you > clock in a one or zero bit. > > The ingenious part is Wouter's tying of the bit time to the serial port, which > because of its async nature must be precisely timed. > > I made a PDF of Wouter's original ZPL entry. You can find it here: > > http://www.finitesite.com/d3jsys/zpl.pdf > > The basic idea is that the chip runs normally when the TX line of the serial > port is idle and resets when a zero bit is sent. So the start bit and any > subsequent zero bits on TX resets the PIC. > > Wouter constructs specific characters that causes a precise run time. > For example the pattern. > > IIII S 1 0 111111 s IIII > > Where I-idle (a 1 bit on TX), S-Start (a zero bit), s-stop(a 1 bit) > > The part runs normally until the start bit, which resets it. It then > starts running again for the run time of the one 1 bit after the start bit, > is reset for the next cell and then runs normally for the rest of the > character including the stop bit and subsequent idle. > > If we count the run time after the stop bit we get a precise count. Say for > the sake of argument it's 30. Now compare to this pattern... > > IIII S 11 0 11111 s IIII > > Note that it runs twice as long after the start bit. So the count should > be around 60. > > So the run time can be used to clock in bits. Personally I also wanted a > special "reset packet" bit. Something like: > > IIII S 111 0 1111 s IIII > > So that the part knows when a new packet is starting. > > BTW the run time after the mid character reset is the time used to determine > the previous bit and to clock it in. > > >> is it BOD? >> > > Nope. All resets will be BOD resets. > > >> What is the procedure to determine a >> data flag that means "go to programming mode?" >> > > Wouter's idea was simple. Any extremely long run times was considered to be > normal operation. Only super short run times are considered to be programming > operations. > > >> I have some ideas, but you guys are heavy hitters... >> > > Wouter's the heavy hitter here. I'm just an interested interpreter. > > >> what happens next? >> > > Truthfully Wouter has already done the hard part. There's already a working > ZPL implementation for the 18F family done. You can find his original > entry here: > > http://www.circuitcellar.com/flash2002/Honorable/M285.zip > > I'm not sure if he has an update. The only small change here is that we're > switching from a pin based reset to a BOR based reset. Another problem is > the fact to ensure a BOR based reset you have to drop the voltage for a minimum > of 100 uS. That means you'd have to slow the serial port down to 9600 BPS to > ensure cells that are 100 uS long. However I guess you could simply double or > triple faster cells to ensure that the resets are 100 uS. So instead of a > 9600 BPS character of S 1 0 111111 s you could double the speed to 19200 and > 52 uS cells and send S 0 1 00 1111 s and S 0 11 00 111 s. Wouter's original > PIC ran at 115.2k with 8.7 uS cells so the 5 cell runtime after the midcell > reset was 40 uS. The runtimes here are 250 uS and 200 uS, which should be > enough time. The good thing is that the reset frame bit I'd like to have > is easily implementable with S 0 111 00 11 s. Still an absolute full 32k > write to an 18F would take upwards of 7 minutes @ 19.2k based on Wouter's > timing of 70 seconds @ 115.2k. So it wouldn't be the fastest programmer on > the block. > > Hope this helps, > > BAJ > Good explanation. I assumed Wouter's ZPL scheme was manchester code (falling edge begins/ends a new bit, bit time measured, if pulse width was > 50% it was a ONE, less than 50% it was a zero, which is also what I use as a production diagnostic tool). Thanks for a GREAT explanation. My production diagnostic tool is more than 7 years old. ONE PIN is dedicated as a diagnostic I/O. When powerup happens with that pin held LOW, diagnostic info is requested; when left OPEN (HI) nothing happens. Diagnostic information is usually about 80 bits of information, a three-bit "start flag" , and a 20% gap. Speed ranges from 0.5mS/bit to 5ms/bit; this code is NOT time-critical except within the bit itself, so it works perfectly with RC-based products. I used it first on a PIC16C54 robot-controller product. Normally the diagnostic data includes each of the port regs, each of the TRIS regs, and several critical internal registers, and each product uses different registers. Since 80 bits is only 9 8-bit registers, the idea is to allow a monitoring technician clues as to why the product is not (or is) working properly. For PICs with A/D converters, verifying the A/D values also verifies the VDD as a secondary result. To pickup the data, I used an old DOS machine at first, but a PIC works better, because the DOS tick interrupt causes problems at some speeds. Later I designed a small PCB with a PIC on it that retreived the data and sent it on to a 9600b Windows host. Very small, about the width of a DB9 connector but very powerful. On most systems, it stole GND and 5V from the running device. So I was originally thinking about expanding that system to perform bootloading functions as well.... --Bob -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist