2-transistor programmer circuit

[robert.rozee]

I have designed a hardware low-voltage PIC programmer that consists of any USB to TTL serial bridge, a couple of transistors and few resistors. the method used is very different to other simple serial port programmers, and does not require hitting the hardware directly or any timing loops.

i would like to see support for this design added to WxPic, however I am a hardware person. how can i best contribute the circuit design, while others handle adapting the WxPic software? in principal, the changes needed to work with the hardware should be relatively simple.

i shall post the schematic and more detailed description in a subsequent post.

cheers,
rob :-)

[admin]

Hi Rob,

Sorry for this late post validation and late response. The traffic on the forum is so low that I am no longer used to monitor new messages.

Due to the very different interface of your programmer I am not sure it will be easy to adapt. But I am ready to think about it. Please post (no more validation should be required this time) the principles of yoru programmer so I can tell you more about what would be the impact.

Philippe

[robert.rozee]

no worries about the delay. it is purely by chance i ended up checking back here myself.

here is the schematic:

USB PIC16F6xxA programmer schematic v2.gif

the following explanation is recycled from postings i have made elsewhere:

the design uses TxD to create PGC pulses, so an output pin on the serial port is freed up. PGD and -MCLR are under software control. PGM is monitored (not directly controlled), with the user instructed to insert a programming jumper (or close switch) at the required point. the end result is that much of the 'magic' behind making a serial port programmer is eliminated.

there are no timing delays involved during programming, everything is interlocked with feedback from the serial port: RxD monitors TxD, DSR monitors DTR. with a PIC16F628A i reckon it should be possible to program a device in a couple of minutes (based on 1mS USB packet boundaries).

i expect speed to be somewhere in the region of 20 words per second, which is fine for downloading firmware once, or for a hobbyist. making a few assumptions about how the USB driver is implemented for a given bridge may enable this speed to be considerably improved upon, but that is getting a bit ahead of things.

the basic algorithm for writing a single bit will look something like:
1. set DTR to desired state (bit value inverted) using 'EscapeCommFunction'
2. wait for DSR to reflect the new state by checking with 'GetCommModemStatus'
3. send out character 0xFF over TxD using 'WriteFile'
4. wait for character 0xFF to be looped back on RxD using 'ReadFile'
5. ... go back to step 1. for the next bit

for consecutive bits of the same value, steps 1 and 2 do not need to be repeated and multiples of character 0xFF can be sent out at step 3 and read back in at step 4. this will effectively double the throughput.

if it can be assumed that order of events will be preserved when changing the state of DTR and sending a character out TxD, then steps 2 and 4 can be skipped while writing a string of bits, at the end of the string then reading back the n character 0xFF's with a single ReadFile. this assumption may only hold true for certain drivers.

the dotted connections in the schematic allow, once the PIC16 device has been programmed, for the serial port to be used to communicate with the just uploaded firmware. this firmware, itself, could then implement a 'stage-2' device programmer - my own specific application is for a firmware that assists in programming PIC32 devices (using a modified branch of pic32prog that i have already got up and running over the last few months).


cheers,
rob :-)

[admin]

Rob,

OK. I see that the main difference with usual programmers is that you don't control programmatically the PGM. So a "wait for PGM is High" has to be added after the "Set PGM High instruction" (that does nothing). I will check what is the impact on the code of such a change. I must admit I did not made any change for at least 2 years and I have forget the details of the software architecture. I hope this will come back soon.

Regards,
Philippe

[admin]

Hi Rob,

The adaptation to your programmer may be possible without any code change. I give below a custom adapter file that should match your hardware.
First of all, please test it WITHOUT any PIC inserted.
Copy the lines below in a file (Rob'sProg.xml for example)
Select the interface type: Custom on COM port defined by FILE
Select the COM port corresponding to your adapter
Select the Rob'sProg.xml file as the custom interface definition file
Click on Initialize button
Unlike in my snapshot below, if all is going well, you should not get "Error testing the Interface"
You should see "button up" in the left panel (as in the snapshot)
Press the Button on your programmer
"button up" should be replaced by "button DOWN"

That's the first step we have to pass before going further.
I will now check if there is an existing programming algo that matches the PIC16F6xxA LVP

Code: Select all

<programmer-control-lines
DataIn="dsr"
VppOnOff="rts"
VddOnOff="nc"
Connect="nc"
ClockOut="txd"
DataOut="dtr"
DataOutWhileReading="1"
PullMclrDown="nc"
ClkEnable="nc"
OutEnable="nc"
OkButton="cts"
RedLed="nc"
GreenLed="nc"
/>


[admin]

Opps I realise I miss one input PIN: DSR. I will check if it can be added to the code. Note that RXD I used in place is not valid either!

[robert.rozee]

i will try and put together some hardware over the next few days and test out your custom adapter file. it is monday morning here in new zealand (12:30am) so i might not get it done until the weekend.

re: the wxpic code not being touched for a couple of years - this seems to be pretty typical. with the vanishing of the ability to talk (directly) to the traditional 'cheap RS232 port programmer' most folks (both hobbyists and the authors of programming software alike) have moved on to different devices. either arduinos, pre-made development boards, or for the brave the relatively expensive PicKit3 and bug-ridden MPLAB.

my hope is to see this trend reversed, if we can get wxpic (and other software) programming PICs with just a couple of transistors. i am a great fan for simple solutions that work!

cheers,
rob :-)

[admin]

Anyway I have to produce a new version of wXPic to manage the DSR. The change of code is very easy (I completed it already). But I would need to put back my compilation environment. Since last time I built wxPIC I upgraded GCC from 4.4 to 4.8.1, a step of 10 years for the compiler, and I have switched from wxWidgets 2.8.0 to 2.9.4.

So before returning to the past I will try to adapt wxPic to this new environment.

[admin]

You can download the WxPic with the capability to manage DSR from the link below:
http://wxpic.free.fr/Resources/WxPic-DSRPatch.exe

It may not have a valid algo for the 16F6xxA but it should be compatible with your adapter.