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 >outfile
command and then made a gzipped tarball out of it.

In a stroke of genius, I realized that there are two sources in which the command protocol was listed. The first of course is in the source of the PC based DOS software. Which was not accessible in my lifetime. But the controller on the other end of the cable, the one on the programmer board, also needs to be able to decipher the commands.
And the source for that software was in a file in the source code tarball. So I started browsing the file ps16B.asm and found the following snippet: 
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    cmmd
Now, 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:
  1. P to program a chip according to some previous commands
  2. R to read the device and send the data back to the host
  3. V to verify the programmed chip. Apparently, the veryfication process is carried out on the host computer, so for the programmer, there is no difference between a Read or a Verify
  4. B to do a blank-check
  5. T to get the version of the programmer
  6. f to send fuse information to the host
  7. 90H to program fuses on the target controller
  8. 88H to do something else
  9. X to start some kind of test sequence

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.

Project abandoned.

Shifted my attention to the AVR line of processors

Follow it in the AVR section.

Page created February 2006,

Page equipped with GoogleBuster technology