|
WinPicProg 1.9
| Download Site 1 (400kB) | Download Site 2 (400kB) |
| Download Driver Site 1 (1.5mB) | Download Driver Site 2 (1.5mB) |
NEW - Support Forum!.
This
is the latest revision of my PicProg series, it has undergone fairly
drastic changes, and I've now added support for a limited range of EPROM based
PIC's, in particular the 12C508/9, the 12C671/2, and the 16C505. Because
of the increased number of chips supported, I've changed the Processor
selection to a drop-down box. These supported EPROM PIC's are
the only ones I currently have JW (UV erasable) versions of, if anyone
wants a particular chip adding I'm willing to look into adding it, but
would appreciate an erasable chip sending for testing (as the 16C505JW
was - thank you Gene!).
This
picture shows the main screen, set to write to a PIC12C672, with a file
already loaded and the filename displayed at the top. As the 12C672
doesn't have any on-board EEPROM data area, the buffer area to the right
hand side is blank. Also, as this is an EPROM chip, the 'Blank Chk' box is
visible, as this is checked (the default setting) the chip will be checked
for being blank before programming - any problems with stored Oscillator
Calibration values will result in a prompt, asking for a Yes/No reply
before continuing. If you only want to alter a few bytes (obviously only
ones to zeros), you can do so by un-checking the 'Blank Chk' box,
an already programmed chip can then be written with no checks performed.
With
the addition of the 12 bit EPROM chips I've had to extend the dis-assembler,
it now copes with both 12 and 14 bit code, it also now is able to display
larger source files, and I've added a much
greater range of register and flag labels, it appears to be working
extremely well - as usual, I'll be pleased to hear of any problems or
suggestions. One 'problem' I already know off (and don't really see a
satisfactory resolution for!) is dis-assembling of Org instructions in 12
bit code, with 14 bit code I do this by checking for a blank byte ($3FFF),
but with the 12 bit code a blank byte ($FFF) is a valid instruction 'xorlw
0xff', which amazingly was used in the first code I tried it on!, as
things stand it will be dis-assembled as an Org line - but will still
assemble and run as normal.
Following
previous
suggestions by users I've added a couple of new facilities, firstly I've added a
'ReOpen' option to the File Menu, this displays the last 5 files you
loaded, allowing you to select them with a single mouse click - or by
holding the Ctrl key down and pressing the numbers 1 to 5 - this is shown
clearly in the picture on the left. Secondly,
I've added an 'Auto-Update' option to the 'Options' menu, when turned on this checks for the
loaded hex file changing - if it does change it prompts you to reload it.
However! - if you also have 'Auto-Prog' selected it will automatically
reload the changed file and blow the chip - without any user intervention
(obviously you need a chip in the programmer for this to work!). I've been
using this a lot recently - it makes life very easy - edit the source file
in your usual editor and save it to disk, run MPASM on the file to
produce a .HEX file, and then load the file into the programmer and blow
the chip (so far, nothing new!). Make sure 'Auto-Update' is checked, and
'Auto Prog' is checked, you can then minimize WinPicProg. Having decided
the software needs revising, insert the chip back into the programmer
(erasing a UV chip first), edit the source code with your editor, and save
to disk, run MPASM, make sure the edited file is selected, and press
'Assemble' - assuming MPASM doesn't find any errors the .HEX file will be
updated, WinPicProg will detect the change, reload the file and blow the
PIC.
