> >>> Bob Axtell wrote: > >>> > >>>> The programming algorithms for the PIC's have gained tremendous > >>>> complexity > >>>> (needlessly so, methinks) and those parts require a completely new > >>>> approach > >>>> in order to program them. Bob, The parts the original poster was talking about were the 16F870 and 16F777. The algorithms for these flash parts are among the very earliest. The '870 is part of the 87x family and these were the second family of flash PICs, the 16[C/F]84 being the first. The 16F777 algorithm is exactly the same as the 16F7x and again, these are some of the earliest flash PICs. So, "those parts" don't require "a completely new approach in order to program them." They require the older algorithms. > >>> I think the reason for the increased programming complexity > >>> is the effort to speed up the process. By a factor 8 in the > >>> case of the 'A' v.s. non 'A' parts. For the 16F87x Vs 16F87xA this is right of course but don't tie the improvement to 'A' Vs non 'A' as it is not always true. Let's just say Newer Vs older algorithms. >As PIC flash capacity > >>> increases, do you really want to wait 655 seconds (11 minutes > >>> for 10msec/location) for a 65k word part? > >>> > >>> I can live with a more complex algorithm if it saves me 10 > >>> minutes programming time. > >>> > >>> Robert > >> > >> Very good point, Robert. But look at the PIC18F "advances"; it > >> takes 15 payloads to send a single word. Nothing faster about > >> that scheme. Looks like it was developed after hours at Hooter's. > > > > > > Really? > > > > > http://ww1.microchip.com/downloads/en/DeviceDoc/30499b.pdf > > PIC18F6X2X/8X2X > > > > "All instructions are 20 bits, consisting of a leading 4-bit snip... > > Doesn't seem THAT bad. > >Its worse. > > > " > > Typically, all of the program buffers are written in parallel > > (Multi-Panel Write mode). In other words, in the case > > of a 64-Kbyte device (8 panels with an 8-byte buffer per > > panel), 64 bytes will be simultaneously programmed > > during each programming sequence. > >But each one of those 64 bytes, being unique, have to be >shoved into a buffer to be written. 20bits per pop. Plus all >of the table setups. Takes about 15 20-bit writes for each >word written into the PIC18F device. There's not any savings >anyplace that I can see. > >MY math says it takes about 8x what it does to write the >same amount of PIC16F data word. Bob, you math sucks! It is nothing like 8x the overhead. It takes 80x 20 bit shifts to load and program 8x8 panels (64 bytes) worst case. There is no begin program command required, no end program command required and no address increment either. Also, there is no start and stop bit required as for the PIC16 family. It takes 22 clocks to load ONE 14-bit word on the 16F and this is NOT including begin and end programming commands and address increment command. My Math: 18F252: (32 * 20) + (8 * 6 * 20) = 1600 clocks + 1x prog time. 16F877A (32 * (6+16+6)) + (8 * (6+6) ) = 902 clocks + 4x prog time (You could score a win on the extra brackets, or are they braces?) Anyway, bottom line times from a nameless USB programmer: 16F877A (8k x 14-bit) chip erase, code, ID, Config program = 3.6 seconds 18F252 (16k x 16-bit) chip erase, code, ID, config program time = 3.1 seconds 18F8722 (64k x 16-bit) same deal as above = 6.12 seconds Notice that the 18F8722 is 4x the size of the 18F252 but takes less than HALF the program time. Role on microchip advances. Another beer please Mr. Hooter. :-) >snip.. > > I didn't realize the 18F was 32 times more efficient > > at writing. And so what if more commands are required? > > They're sent at megahertz, not the 100 hertz of programming > > time. > >I didn't either. Megahgertz? Gosh, I gotta get better glasses... And calculator too... Regards, Jim Robertson NEWFOUND ELECTRONICS -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist