Me and my PIC
In 1993, I ordered a PICstart 16B development kit. It had a very sturdy Aries ZIF socket that accepted all
chips. It ran off a 9 Volt DC supply and had it's own 78S40 switcher on board. Communications were by means of
a simple serial port.
I did my share of PIC programming with this system. Never failed me. Later I got a code revision so I could also program the newer chips like the 16C71. And then my attention switched to other things and I kind of forgot the PICstart.
Enter the neighbour from next-next-nextdoor. He needed a programme for a simple PIC. I got one and he used it on his computers which run an operating system whose name I will not disclose here. But it included a year as part of the type description. He also needed a C++ compiler for the 16C54.
I don't know how it all ended but a few months ago I got my programmer back and this triggered some thoughts, like how to use if from DOS or even from Linux.... Yummy. Programming PIC's from Linux. That can already be done with many programs. There are even programs that run with the successor of the PICstart line of programmers.
Though the Linux software is mainly free of charge, the required programmers are not. So I decided to see if I could revive the PICstart. DOS is not an option anymore. I got used and addicted to Linux. I keep pressing the Tab key (without any results) and the slashes also run the wrong way. So now I want to try and see how far I get with writing Modula-2 sources to control the MicroChip PICstart 16B programmer board.
Command protocol of the PICstart 16B
The PICstart 16B is connected to the PC via a serial cable. On the programmer board are a power converter,
RS232 circuitry, a 40 pin ZIF socket, plus a microcontroller. On my original board was a 16C62 (engineering
sample) but on the revision is a 17C42 chip.
Now, the 17C42 is a really powerful PIC. It comes close to a Z 8 or Z 80, so it doesn't make sense that the chip is only there for some timing related issues. It would be more logical to assume, the microcontroller does some useful work. Like receiving commands from the host controller and then carrying out the required tasks. And, if needed, report back to the master.
Actually, this is exactly how it's done in the PICstart Plus. The host PC sends single letter commands, followed by parameterlists, if required. Now, the problem was how to get the commands and there protocols.
My first idea was to tap into the RS 232 communications and then try to decipher the codes going back and forth. But this is a time consuming and tricky business. So my next guess was to try and act bold and just send a mail to Microchip and ask them for the command protocol for the now obsolete PICstart 16B.
The answer still has to come. Apparently, the newer programmers like the PICstart Plus still use the same or similar commands and related parameter flows. This was a bit of a disappointment since it meant that I really would have to build the RS232 snooper. Which I quite dislike.
So I started my copy of 'Sourcer', the DOS disassembler. It took ages to load the file. It took ages to do a disassembly and when done, I ended up with a 5 MB file containing 125.000 lines of disassembled code. Forget it. It will take MONTHS to get through that file with a lot of Sourcer restarts. There must be another way....
Early 2005, Microchip released the design of the PICstart 16B to the public. You can download a PDF file with the circuit from this site (through the navigator) called "ps16B.pdf".
They released two files. The afore mentioned PDF file, plus a "ps16B.tar.gz" sourcecode file containing the sources for the 17C42 controller which is on board of the programmer. This tar.gz file is Unix-ready. I stripped all the Carriage Return codes from these source files with the
fromdos <infile >outfilecommand and then made a gzipped tarball out of it.
cmmd movlw 0x60 ; always have timer count ready movwf dly_cnt bsf get_cmmd CIN ; get a char bcf get_cmmd btfsc test_mode goto look_4_test_only btfss pc_present goto look_4_pc_only CJE 0x84,send_type <snip> CJE 'P',pc_program CJE 'R',pc_read CJE 'V',pc_read CJE 'B',pc_blank CJE 0x90,pc_program_fuses CJE 'T',send_version_type CJE 'f',send_fuses look_4_pc_only CJE 0x88,set_pc1 CJE 'X',start_of_test goto cmmdNow, this is a good sign. It means that indeed the command flow is based on single tokens and that the controller on board of the programmer board does a lot of work. Apparently there are 9 commands:
More to come
In order to know what's on, I need to be sure the programmer still works, and how it reacts in a DOS environment. Armed with that knowledge, I will know how the system needs to respond and react as a result of Linux based actions.
Page created February 2006,