On Mon, Jan 30, 2006 at 07:27:50AM -0500, Olin Lathrop wrote: > James Newton, Host wrote: > > Ok then, how about an LVP programmer that uses only non-programmed > > components and takes a stream from a serial port like Tony's ASCII > > programmer. Perhaps the clock signal could be developed without RC > > circuits. > > Why is that better than a high voltage programmer which can always program > the chip regardless of how the LVP bit is set? I think Wouter believes that creating a switched high voltage Vpp interface is a bit of a challenge. He's also concerned that there will be problems if the user has to hand switch the interface. I would literally create a LM317 based regulated 13V and then tie a SPST toggle between the resistor voltage divider point and GND. This will switch between 13V and 1.25V. To complete the circuit I would current limit the LM317 output using a 100 ohm resistor and then tie the same switch between MCLR and GND. That way when the switch is off you have 13V with a 130 mA output and when the switch is on, MCLR is grounded with the junction point of MCLR sinking the 1.25V @ 1.25 mA. > > > Again, the point is to not require any programming software, > > But why? I'm not sure why James thinks this is useful. By using traditional programming software, such a circuit could potentially program any PIC. > There clearly needs to be *some* software between the disk and the > serial port (or whatever port), so why not let that software do a few other > useful things. Requiring no software seems backwards. There is going to be > complexity somewhere. It makes sense to push that complexity onto the host > where developing it is easier, there are essentially no speed and memory > constraints, and the incremental cost is basically zero. Bingo. In fact if you have programming software that separates the programming and hardware interfaces, like pikdev, then adding new hardware is nothing more that writing a new hardware interface class. That's what I was doing for testing my 555 based code dumper. > When I design a programmer I think about the higherarchy of host software, > firmware, and hardware. You want to push complexity as much as possible to > the beginning of that chain except as required to meet the performance and > capability goals. I have just revised my programmer host protocol again to > put less burden on the programmer in a few areas. When I originally started > that several years ago, I was envisioning the programmer performing some > operations at a higher level on its own. These were never implemented and I > later realized that they can be managed from the host without speed penalty. > The programmer firmware performs the lower level operations that the host > can't do fast enough, but as much as possible the host does the "thinking" > and high level control. While I agree on all points, the point I would throw in James' defense is that I am somewhat interested in the OS neutral aspect of performing the conversion then dumping the file. But what Olin proposes can be accomplished simply by having at least one Open Source programmer. Then the code would be portable to other platforms such as a PDA. My lingering question is if this type of code dumper meets its intended occasional use, then how important is it to have verification of the code that is dumped. Is unit testing with a blinking LED type program sufficient to show that the code dumper is completing its one way dump? This would then be followed by the target dump. I ask because this is the true dividing line between just dumping a file to the serial port and using traditional programming software. At the end of the day gentlemen, there's no reason not to do both. James' output file is nothing more than an intermedate representation of the output of a traditional programmer. So it would be trivial to direct the serial output to a file instead of sending it directly to the serial port. > > > but rather > > use a data file that loads a bootloader or like that. The data file > > only needs to be developed once, but having server based software for > > turning a hex file into such a datafile would be very cool as well. > > The data file needs to be developed at least once for each HEX file. You'll > probably do this with a program. Given that that program will execute > instantaneously in human terms, why not run the program each time the data > file is needed from the HEX file. Then you can run it with any HEX file at > any time. Then you realize that since you can make the data file for free > whenever you want it, you don't need to save it. You're making a temporary > data file on demand. It's really just a data stream, since it's not saved > anymore. So now you have a program that reads a HEX file on one side and > writes to a serial port on the other side to "convert" the HEX file > information into whatever is required for the low-complexity programmer to > write it into the target PIC. Sound familiar? The only argument against again is the probability that the programming software you describe is somehow OS dependant. The data stream can be dump using Hypertem, or minicom, or a Palm terminal emulator, or kermit, or whatever the Mac is currently using for serial interfaces. OS neutral. Programming software generally is not OS neutral, which means someone has to take the time to port to each architecture. And when the target to be dumped is really useful, like a bootloader, there can be some value in having the intermediate data stream. No matter the platform, you can then get the file, dump it, and be done with it. Gotta go, I'll tackle the rest later. BAJ -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist