Mini Usb Programmator
Mini Usb Programmator
Italian version
Quick facts
Another programmer?
USB & HID firmware
Control programs
GTK graphical interface
MFC Graphical interface
Command-line interface
How to ...
Supported devices
Communication protocol
The circuit
Voltage regulator
How to contribute
Download
History
Links
Contacts
Quick facts
USB 2.0 Full Speed interface, HID class (same as keyboards, mice, etc.)
Self powered
Hardware generated timings for maximum speed and reliability (writes a 18F2550 in
15s)
Doesn't saturate your CPU and doesn't suffer when other programs are running
Picture of a prototype:
Another programmer?
In the last few years, as serial and parallel interfaces have almost disappeared, electronics
enthusiasts find even more difficult to program microcontrollers; old time programmers don't
work any more; common solutions include using USB to serial adapters (which can't accept
direct access but only slow API calls), or add-on interface chips, like FTDIxxxx, which appear
substantially as serial interfaces and require custom or proprietary drivers.
So why not use PIC controllers and their native USB interface?
After searching a while I couldn't find an USB programmer which was at the same time
functional, free, and open source, so I decided to design one.
Open source means that all sources and schematics are given free of charge with the rights to
modify and release them.
Control programs
I initially thought of modifying an existing software, for example winpic or picprog, but I
found it would be too difficult because I use packetized communications instead of serial; so I
had to write one (two) from scratch.
Unfortunately, or fortunately, since I'm not a professional programmer I kept features at
minimum; the result are very small but fast programs that don't use your CPU for nothing.
For most devices the code is verified while programming; for the others immediately
following the writing phase.
Ideally you should have the same version number for both software and firmware, except for
the last number which indicates minor changes and bug fixes; however I tried to keep the
same protocol with each release, so that apart from new features it is often possible to use new
software with older firmware and vice versa.
In case you wonder, the reason why it's not possible to program directly from MPLAB is not
technical: Microchip does not release specifications of how to interface with its program; if
you want them you have to be a commercial manufacturer and sign a non disclosure
agreement, which is clearly impossible for a GPL2 open source project.
On the contrary, integration with Piklab is possible and I hope will be done soon; right now
the custom programmer interface lacks some essential parameters, but whoever has the ability
and time can fix it for sure.
GTK graphical interface for Windows and Linux (v0.9.1)
OPGUI uses the GTK libraries so under Windows it's necessary to install the GTK Runtime
Environment.
A screenshot of Opgui:
A quick guide: buttons to read, write, load and save files are on the toolbar.
The "Data" tab shows what the programmer is doing.
On the "Device" tab it's possible to choose the device and modify some programming options,
such as writing ID and calibration words, using the eeprom etc.; only settings compatible with
the current device are considered.
Under "Options" are various general settings: USB connection, errors, log file, expansion
boards; using the "Hardware Test" function and a voltmeter is possible to check that the
circuit is working.
The "I2C/SPI" tab is useful for communicating with generic I2C and SPI devices; in case of
I2C it's always necessary to specify the control byte (and address, if not zero); RW bit is
handled automatically.
For example, to write manually 3 bytes on a 24xx16 at address 64 write: A0 40 1 2 3
From version 0.7.10 it is included an ICD debugger, working more or less like pdb; in
addition it supports coff files.
The "I/O" tab allows to control individual I/O lines and the power supplies.
Under "Utility" there are functions to convert a single hex line to data and vice versa.
There is no installer since there aren't any libraries and the executable is very small.
The program accepts hex8 and hex32 files, and also binary files in case of serial memories.
Supported languages are currently English and Italian; to add other languages it's necessary to
generate the languages.rc file (-langfile option) and to modify it; the language id is before the
respective strings, enclosed in square brackets [].
The language is chosen at startup by matching the system language (it can also be forced with
-lang).
To enable access to the programmer under Linux see chapter Command line interface.
You can find more info on the OpenProg and Opgui user's guide or in the source code guide.
To compile the program from source (optional) you need to install the GTK libraries, GCC
and the maketools (MinGW/MSYS in Windows); then write:
> make
To install it under Linux(if you wish):
> make install
Download the compiled program ... or the sources.
Graphical interface for Windows (v0.9.1)
OpenProg is a C++ application written with Visual C++ 6 and MFC.
A screenshot of OpenProg:
Only the basic programming functions are implemented; it was the fist GUI of the project, but
currently development continues on OPGUI, so it may be dismissed in the future.
It has the advantage of working without any additional library.
Usage is the same as OPGUI; works with XP, VISTA, 7, 8.
Command-line options are:
-d <device> , selects a target
-r <file name> , reads the target and writes to file
-w <file name> , writes a file to the target
-gui , do not exit after writing or reading (only if -w or -r are specified)
You can find more info on the OpenProg and Opgui user's guide or in the source code guide.
It may be of interest the fact that the DDK (driver development kit) is not required for
compilation; I link explicitly to the system library hid.dll and manually load the functions
needed.
Download application ... or sources (Visual Studio 6 workspace)
-h, help
help
-HWtest
hardware test
-i, info
informations about programmer
-i2c_r <N Ctr Addr>
read N bytes from I2C bus
-i2c_r2 <N Ctr Addr(2)>
read N bytes from I2C bus (16b address)
-i2c_w <N Ctr Addr Data> write N bytes to I2C bus
-i2c_w2 <N Ctr Addr(2) Data>
write N bytes to I2C bus (16b address)
-i2cspeed <speed>
set I2C speed: 0=100k,1=200k,2=400k,3=800k"
-icd <val>
enable ICD (goto address)
-id
use ID
-l, log [=file]
save log
-lang <language>
load <language> strings
-langfile
write all strings to file
-lock <val>
write lock byte (Atmel only)
-mode <mode>
SPI mode: 00,01,10,11
-osccal
loads osccal from file instead of using the value saved before
erase
-p, path <path>
programmer path [/dev/usb/hiddev0]
-pid <pid>
programmer pid [0x100]
-r, reserved
read reserved area
-rep <n>
report size [64]
-s1, S1
Multiple programming triggered by S1
-s, save <file>
save Ihex file
-se, saveEE <file>
save EEPROM on Ihex file (ATxxxx only)
-spi_r <N>
read N bytes from SPI bus
-spi_w <N Data>
write N bytes to SPI bus
-spispeed <speed>
set SPI speed: 0=100k,1=200k,2=300k,3=500k" NL
-support
supported devices
-use_BKosccal
copy BKosccal to osccal
-v, version
version
-vid <vid>
programmer vid [0x4D8]
-w, write <file>
write Ihex file
-we, writeEE <file>
write EEPROM on Ihex file (ATxxxx only)
Examples:
> op -h
> op -d 18F2550 -ee -s read.hex
> op -d 16F628 -ee -w write.hex
> op -i2c_r 8 A0 0
address 0
#help
#reads code and EEPROM and saves to file
#writes
#reads 8 bytes from I2C bus, control byte A0,
A frequent error is to write the device name with lowercase letters instead of uppercase:
write 16F628, not 16f628
A makefile is included, so to build the application you need GCC and the maketools
(MinGW/MSYS on Windows); write:
> make
Then to install it (if you wish):
> make install
How to ...
Erase a device: every device is erased before being programmed; however if you still need to
erase it it's sufficient to write a hex file with valid data (i.e. <0xFF) beyond the implemented
memory.
For example, for PIC12-16:
:020000040000FA
:0144010000BA
:00000001FF
And for PIC18:
:020000040002F8
:020000000000FE
:00000001FF
Change Configuration Word: Config words are usually specified in the hex file, but can be
forced for PIC 10-12-16-18 using the related device options (or via command line).
It's also possible to recompile sources, otherwise to change the hex file directly; in case of
most PIC16 the config word is at address 0x2007, which is stored at 0x400E; the last byte of
the line is a checksum, which can be calculated as the two's complement of the sum of all
bytes in the line.
For example:
:02400E00xxxxCC , where xxxx is the new value and CC the checksum
Change configuration of Atmel AVR: unlike PICs, these devices do not map their
configuration words in the main memory area (so the hex files don't specify any
configuration) and it's necessary to write the desired Fuse/Lock bytes in the device options;
don't write anything in case the default value is fine for the application.
Solve the "Synchronization error" with AVR devices: A possible cause is that the SPI
speed is too high in relation to the CPU speed; the latter has to be > 4 x SPI speed.
There are many possible CPU speed configurations, so the (new) algorithm varies the SPI
speed automatically in order to enter Program Mode.
Obviously the lower the speed the longer it takes to read/write the device; in order to speed up
operations you could write an empty file with a fast CPU configuration, then write the final
file and configuration at high speed.
Some devices include an extremely low speed setting (16 kHz), which is too low even for the
adaptive algorithm; in this case use "write Fuse Low @ 3 kHz" to change Fuse Low to a
higher speed setting, then write in the usual way.
Another cause could be that the serial programming is disabled: this can be done only using a
parallel programmer, and the same is necessary to enable it again.
The third possibility is that the device is configured for external resonator but X2 cannot
move; in case you use the AVR expansion board make sure X2 is not tied to GND.
Check that a device is blank: read it and look at displayed data; only lines with valid data
are displayed, so if there are none the device is blank.
Verify that a write was successful: all write algorithms implement write verification, either
during write or immediately after; if the program reports 0 errors it means that the code was
succesfully verified.
If you want to check again you can read the device and compare with the original data; keep
in mind that frequently not all bits are implemented; for example in PIC16 a data word is 14
bits long, so even if the source data is 0xFFFF it will be written as 0x3FFF; also the Config
Words usually have some bits fixed at 0, which are not checked.
Read the reserved memory area: most PIC devices have a reserved area above the Config
Words which is used for test or calibration purposes; to see it use the relative option before
read; on PIC24-30-33 the executive memory is read as well.
Correctly use OscCal and other calibration words: some devices (eg. 12F5xx) store the
internal oscillator calibration value in the last address of program memory and in a backup
location past the ID words; after erasing all memory the control programs restore the
calibration value taking it from the backup location, unless specified otherwise; other options
are: use the old value (which should be the same as the backup, if none was changed before),
use what is specified in the .hex file.
Similarly it's possible to overwrite the backup value with the content of the .hex file, using
option "write ID and BKosccal"; in this case the ID locations will be written as well, if
specified in the .hex file.
To overwrite the other calibration values use option "write Calib1 and 2".
Supported devices
I tried this programmer with a small number of devices (those I own plus some tested by other
users) indicated in bold; the other devices are supported but not tested; however, considering
that for every device family at least one has been verified, all of them should work without
problems.
Please let me know if you verify operation with the untested devices.
Also contact me if you need other algorithms or code new ones by yourself.
Take notice:
LF series PICs are used exactly as the F ones;
Atmel AVR devices with varius suffixes are grouped together whenever the programming
algorithm is exactly the same, eg. ATmega8 and ATmega8A;
EEPROM memories comprise all versions with VDDmax=5V, eg. 242LC56, 24AA256, etc.;
93x memories use 2 different algorithms, for the 93S series and for all the others, indicated
with 93x (93xA have 8 bit organization).
devices supported for read and write:
10F200, 10F202, 10F204, 10F206, 10F220, 10F222, 10F320, 10F322,
12C508, 12C508A,12C509, 12C509A, 12F508, 12F509, 12F510, 12F519,
12F609, 12F615, 12F617, 12F629, 12F635, 12F675, 12F683,
12F752, 12F529T39, 12F529T48,
12F1501, 12F1571, 12F1572, 12F1612, 12F1822, 12F1840,
16F505, 16F506, 16F526, 16F527, 16F54, 16F57, 16F570, 16F59,
16F610, 16F616, 16F627, 16F627A, 16F628, 16F628A, 16F630, 16F631, 16F636, 16F639,
2400, 2401, 2402, 2404, 2408, 2416, 2432, 2464, 24128, 24256, 24512, 241024, 241025,
25010, 25020, 25040, 25080, 25160, 25320, 25640, 25128, 25256, 25512, 251024,
95010, 95020, 95040, 95080, 95160, 95320, 95640, 95128, 95256, 95512, 95M01, 95M02,
251005, 252005, 254005, 258005, 251605, 25X05, 25X10, 25X20, 25X40, 25X80, 25X16,
25X32, 25X64, 25X128, 25Q40,
93S46, 93x46, 93x46A, 93S56, 93x56, 93x56A, 93S66, 93x66, 93x66A, 93x76, 93x76A,
93x86, 93x86A,
DS2430, DS2431, DS2433, DS28EC20, DS1820,
11010, 11020, 11040, 11080, 11160
devices supported for read only:
12C671, 12C672, 12CE673, 12CE674
Important!! Don't use 3.3V devices without the 3.3V expansion boards, otherwise permanent
damage may occur; the software verifies that such adapters are present before starting to
program, but obviously you need to select the proper device; the 3.3V devices are:
12F1xxx,16F1xxx,18FxxJxx,18FxxKxx,24Fxxx,24Hxxx,33Fxxx.
Some of them have 5V variants; if you need to program at 5V you can select the option "Don't
require LV boards". Also don't put any 24F-33F on the 30F socket, which works at 5V.
Communication protocol
To design a communication protocol we must take into account some often contrasting
requirements:
transfer speed and efficiency, code size, adaptability and expandability.
Differently from serial links, USB is packet based; a packet is received altogether, but HID
devices can only exchange them every ms, so it is out of question to manage timings directly
as with serial ports.
It's necessary to introduce synthetic commands that the microcontroller can use to recreate the
proper waveforms.
Furthermore, one objective of a reliable programmer is to be independent from the host speed
and CPU occupation, so the task of generating waveforms would anyways be given to the
microcontroller.
In general we can find two types of programmers: simple serial programmers only take
commands to change voltage levels; host software manages both timings and programming
algorithms but needs all the CPU time and is dramatically affected by other processes running
on the system.
At the other extreme are "smart" programmers, which autonomously manage timings and
algorithms, but must be updated to support new devices and tend to require much memory to
store code.
I chose a combination of both: ICSP (In Circuit Serial Programming) commands are
implemented in firmware, but the host software manages the algorithms.
In order to increase speed and efficiency some instructions correspond to sequences of
frequently repeated commands, such as sequential reads.
The advantage of this approach is that timings are very precise, while the extreme variety of
algorithms does not increase the firmware code size.
Another advantage is that once the basic commands are verified the development of
algorithms is done on the PC, without the need for frequent firmware updates.
For example, this is the sequence used to enter program mode for 16F628 and read DevID:
SET_PARAMETER
SET_T1T2
1
100
EN_VPP_VCC
0x0
SET_CK_D
0x0
EN_VPP_VCC
0x4
NOP
EN_VPP_VCC
0x5
NOP
LOAD_CONF
0xFF
0xFF
INC_ADDR_N
0x06
READ_DATA_PROG
...
Notes
NOP
0x00 none
echo
no operation
PROG_RST
0x01 none
echo + 10B
PROG_ID
0x02 none
echo+ 6B
CHECK_INS
0x03 1B
echo + 1B
FLUSH
0x04 none
none
VREG_EN
0x05 none
echo
VREG_DIS
0x06 none
echo
SET_PARAMETER
0x07 1B
echo
SET_T1T2 (=0):
T1 & T2
SET_T3 (=1):
T3(H,L)
SET_timeout (=2): timeout(H,L)
SET_MN (=3):
M, N
WAIT_T1
0x08 none
echo
WAIT_T2
0x09 none
echo
WAIT_T3
0x0A none
echo
WAIT_US
0x0B 1B
echo
waits N us
echo +2B
echo +1B
echo
echo
echo +1B
echo
READ_ADC
SET_VPP
EN_VPP_VCC
SET_CK_D
READ_PINS
LOAD_CONF
0x0C none
0x0D 1B
0x0E 1B
0x0F 1B
0x10 none
0x11 2B
LOAD_DATA_PROG
0x12 2B
echo
LOAD_DATA_DATA
0x13 1B
echo
0x14 none
echo +2B
READ_DATA_DATA
0x15 none
echo +1B
INC_ADDR
0x16 none
echo
INC_ADDR_N
0x17 1B
echo
BEGIN_PROG
0x18 none
echo
BULK_ERASE_PROG
0x19 none
echo
END_PROG
0x1A none
echo
BULK_ERASE_DATA
0x1B none
echo
END_PROG2
0x1C none
echo
ROW_ERASE_PROG
0x1D none
echo
BEGIN_PROG2
0x1E none
echo
CUST_CMD
0x1F 1B
echo
PROG_C
0x20 2B
echo +1B
CORE_INS
0x21 2B
echo
SHIFT_TABLAT
0x22 none
echo +1B
TABLE_READ
0x23 none
echo +1B
TBLR_INC_N
0x24 1B
TBLW_INC_N
TBLW_PROG
0x25 2B
0x26 (2N+1)B
0x27 4B
echo
echo
echo
TBLW_PROG_INC
0x28 4B
echo
SEND_DATA
0x29 3B
echo
READ_DATA
0x2A 1B
echo+1B
echo
I2C_INIT
0x2B 1B
I2C_READ
0x2C 3B
echo+1+NB
I2C_WRITE
0x2D 3B+NB
echo
SPI_INIT
0x2E 4B
0x2F 1B
echo+1+NB
echo
SPI_READ
0x30 1B
echo+1+NB
SPI_WRITE
0x31 1B+NB
echo+1B
0x32 2B
echo
0x33 3B
EXT_PORT
AT_READ_DATA
AT_LOAD_DATA
CLOCK_GEN
0x34 3B+2N
0x35 1B
echo+1B
echo
SIX
SIX_LONG
SIX_LONG5
0x36 3B
0x3E 3B
0x49 3B
echo
echo
echo
SIX_N
0x3F 1+3NB
echo
REGOUT
0x37 none
echo +2B
ICSP_NOP
0x38 none
echo
TX16
0x39 1+2NB
echo+1B
RX16
0x3A 1B
uW_INIT
0x3B none
echo
Initializes MicroWire
communication
uW_TX
0x3C 1B+NB
echo+1B
uW_RX
0x3D 1B
echo+1+NB
OW_RESET
0x40 no
echo+1B
OW_WRITE
0x41 1B+NB
echo
OW_READ
0x42 1B
echo+1+NB
UNIO_STBY
0x43 no
echo
SET_PORT_DIR
0x45 2B
echo
READ_B
0x46 no
echo+1B
Reads IO port B
READ_AC
0x47 no
echo+1B
UNIO_COM
AT_HV_RTX
0x48 1B+2NB
echo+1B
READ_RAM
0xF0 2B
echo+3B
WRITE_RAM
0xF1 3B
echo+3B
none
LOOP
0xF2 none
Many components are optional, are only needed to program some types of devices or for
future applications: expansion connectors CONN2-3, protection resistors R11:23 (considering
their cost why not use them?), I2C pull-up resistors R26-27, S1 switch, ICSP-IN CONN4
(right now it's used to program the main microcontroller without extracting it).
The pcb was optimized to fit the solder side, however a few jumpers are needed on the
component side; if you want you can avoid that by using a double side pcb.
Pay attention to the orientation of transistors: Q1's emitter to the left, Q2 up, Q3 and Q4 right.
Once connected to the PC, a working circuit blinks D2 at 4Hz until the enumeration is
completed, then at 1Hz.
To verify that everything is working correctly use the "Hardware Test" function in the control
program: in this mode, to be executed without target devices, all the outputs (CK, D, PGM,
VDDU, VPPU, which can be reached on pins 14-15-12-1-4 of U3, with respect to GND, pin
5) are activated in various combinations; if the measured voltages correspond to what is
presented on screen then the hardware is correctly assembled.
VPP voltage could be different from the set value by up to 1V; this is due to the fact that the
DCDC converter takes VCC as reference voltage; the latter comes from the USB cable and
can vary from 4.75V to 5.25V; in addition the feedback voltage divider (R1-R2) can introduce
another 5% of error.
The most common causes of malfunction are:
incorrect orientation of transistors,
incorrect inductor value,
pcb defects like shorts or opens,
unsoldered capacitors,
main microcontrollorer not programmed or incorrectly programmed (with LVP option).
Component list:
U1 12Mhz quartz (also 4, 8, 16, 20; reconfiguration of input divider options is required)
U2 18F2550 (also 2450,2455,2458,2553,4450,4455,4458,4550,4553)
U3 20p socket.
U4 8p socket.
Q1-2 BC557 (or any PNP, pay attention to polarity)
Q3-4 BC547 (or any NPN, pay attention to polarity)
D1-2 LED
D3 1N4148 (or any diode, better if Shottky)
L1 100uH resistor type or other
R1 22K
R2 12K
R3 100K
R4:6 10K
R7 1M
R8-9 2.2K
R10 10K
R11:23 100
R24-25 330K
R26-27 10K
C1 22-100uF 25V
C2-3 22pF
C4 >= 220nF
C5 100nF
C6 10uF
C7-8 100nF
CONN1 USB type B
CONN2-3 10 pin female stripline
CONN4 5 pin stripline
How to use
The basic circuit can host PIC devices with 8, 14, 18, and 20 pins (except 10Fxxx); they
should be inserted in U3 with alignment to pin1:
8-20 pin PICs (same as main board, but there's more space for a ZIF socket) + ICSP
conn.
3.3V PIC16-18 + ICSP conn. (this board has also a 3.3V regulator)
ST72 (future)
Components for the expansion boards are indicated in the schematic diagram; diodes can be
of any kind; TBD resistors should not be mounted.
In assembling the adapters I suggest to insert the expansion connectors from the component
side, and keep their plastic spacer on that side; this improves the solder strength, especially
during extraction.
In case of 3.3V devices, the presence of a 3.3V adapter (which has RB1 and RB0 shorted) is
checked by the software in order to avoid irreversible damage.
The 16F1xxx could be programmed also without such adapter (only the 16LF1xxx need it),
but the check is present for both so there is no chance of confusion.
Due to the impossibility of erasing dsPIC30 protection registers at 3.3V, these devices are
now powered at 5V; who already made the adapter (prior to v. 1.7) can easily modify it.
The following images show how to insert various target devices in the expansion boards:
Smaller devices have to be aligned to pin 1 of the respective socket, for example 8 pin PICs in
the 20p. socket, or the ATTiny2313 in the 28p. socket.
Target chips can also be programmed in circuit by routing ICSP signals
(VPPU,VDDU,ICD,ICK,GND) to the application board; these signals are present in the main
module expansion connectors or in some expansion boards as a discrete connector; note that
low voltage devices require ICSP signals from a low voltage expansion board.
In order to use SPI Flash memories it's necessary to modify the EEPROM adapter to lower the
supply voltage to 3.3V; below is the schematic diagram:
The ICSP-IN connector is used to program the main micro without extracting it, by means of
another programmer.
ATTENTION: the ATMEL AVR board has presently a bug that prevents 28 pin devices (eg.
ATMega8) from entering program mode when they are not configured with the internal
oscillator.
In order to share the same socket with 20 pin devices (eg. ATTiny2313), pin 10 is forced to
VSS; but this pin corresponds to X2 in the bigger devices, and has to be floating when the
oscillator is external.
To fix the bug it's sufficient to keep X2 floating, in one of the following ways:
a) bend pin 10 outwards on the target device so that it stays out of the socket.
b) cut the trace between pin 10 and VSS, but reconnect it when using 20 pin devices.
In the future the adapter board will be modified including a jumper to short pin 10 to VSS.
Pin mapping of various connectors in the main and expansion boards:
Various
functions
ICSP
RB7
PGM
RB6
ICSP
clock
RB5
ICSP
data
I2CEEPROM
SPIEEPROM
SPIATMEL
A2
uWOneWire/UNIO
EEPROM
W (6)
RB4
A1
HLD
RB3
A0
CS
S (1)
Device
PRE (7)
clock
RB2 expansion
RB1
Clock
Clock
SPI Clock
Clock
RB0
Data
Data out
(MISO)
Data out
(MISO)
Data out
Data in
(MOSI)
Data in
(MOSI)
Data in
WP
RESET
RC7
RC6
WP
RC5
USB D+
RC4
USB D-
RC2
DCDC
PWM
RC1
controls
VDD
RC0
controls
VPP
Data IO
RA5 expansion
RA4 expansion
RA3 expansion
RA2
LED 2
RA1
LED 1
RA0
ADC for
regulator
RE3
S1 switch
The schematic diagram was drawn with Gschem, an open source program that comes with
GEDA suite.
In their website it's not evident (as they all use linux), but it's also possible to run the program
in windows under cygwin; I suggest to use the latest version (you need to compile sources).
PCBs were drawn with PCB; in this case there is also a (somewhat limited) windows version.
With a little effort the circuit can also be mounted on experimental boards, without pcb.
Schematic diagram of base module: .pdf, .png; expansion boards: .pdf; everything in gschem
format: Oprog.sch
Pcb of main module: .pdf, .png; main module + expansion boards: .pdf (also mirrored), .png;
everything in PCB format: Oprog.pcb
Complete archive, includes sources, gerber, pdf, png
How to program the main micro the first time?
The ADC converter presently uses the 5V supply as a reference, so the output voltage will
follow it; it is possible to connect an external reference to RA3 to improve the overall
precision.
Switching frequency is 90 kHz, which is well over the cutoff frequency of the output LC filter
(~2,3 kHz).
The performance is limited by losses due to the transistor, diode, inductor, but since the load
is very low we can use low-cost (even recycled) components; to improve load capability
switch to a better transistor, a Shottky diode, a higher rated inductor.
Anyways, in order to design a suitable regulator (block C above) it's necessary to work in s
domain and model the converter itself; this has fortunately been done already, some info is
available for example here.
With present component values the boost converter operates in dicontinuous mode; critical
current is:
Icrit=Vu*T/(16*L)=86 mA
well over expected load, supposed to be 1 mA.
Other parameters:
Vi=5
Vu=12.5
D=(Vu-Vi)/Vo
L=100e-6
C=47e-6
I=1e-3
R=12/I
Rl=1.6 (inductor series resistance)
T=1/90e3
vu
1
vu
M-1
Vu
2M -1
--- = Gdo ---------- where Gdo = 2 --- ------- , M = ---, wp =
---------D
1 + s/wp
D
2M -1
Vi
(M-1)
RC
Transfer function results to be:
vu
127.58
-- = ------------D
0.22031 s + 1
It seems that the system, in closed loop, would be stable even by itself; however it would have
a steady state error of 1/DCgain.
It's better to use a controller with a pole on the origin and a zero to stabilize everything, for
example the following controller:
D
0.25 (s + 50)
C = --- = ------------err
s
Overall transfer function would be:
vu
144.77 s + 7238.4
-- = ----------------vi
s2 + 4.539 s
The system is stable, with a phase margin of ~75.
Since we operate in the digital domain we must choose the sampling frequency.
It can't be too high because of execution speed; if too low it limits the regulator bandwidth; a
period of 250 us was a good compromise.
The various transfer functions are converted to z domain using bilinear transformation:
vu
0.018199 z2+ 0.00022607 z - 0.017973
-- = -----------------------------------vi
z2 - 1.9989 z + 0.99887
The controller is:
D
0.25156*z - 0.24844
C1 - C2 z-1
C = --- = ------------------- = ----------err
z - 1
1 -z-1
a=12/34
Vu=C'H(Vi-aVu)
Vu
C'H
-- = -----Vi
1+aC'H
To compare with the previous model we can multiply both terms by a; simply remembering to
change the set point we can decide that the new input is Vi/a, and equate with the previous
expression:
Vu
aC'H
CH
---- = ------ = ---Vi/a
1+aC'H
1+CH
aC'=C
aC1' - aC2' z-1
C1 - C2 z-1
aC'= --------------=
C
=
-----------1 - z-1
1 - z-1
aC1'=C1
aC2'=C2
Since the hardware works with 10 bit digital data we can go from D/err to pwm/[err]:
[err]=err*1024/5
pwm=D*1024
D
pwm/1024
pwm
C1' - C2'z-1
C'= --- = ------------ = ------- = -----------err
[err]/1024*5
[err]*5
1 -z-1
pwm(1 - z-1)=[err](5*C1/a - 5*C2/a z-1)=[err](3.564 - 3.52 z-1)
It's clear that integer multiplications can't be used with these coefficients; the easiest solution
is to work with fractional values (i.e. divide output by 2N and multiply coefficients
accordingly); considering that pwm output is 10 bits wide and left-aligned, we can easily
work with values divided by 64.
pwm(1 - z-1)=[err](k1 - k2 z-1)/64
k1=5C1/a*64=228.12 ~ 228
k2=5C2/a*64=225.25 ~ 225
Following are step responses of continuous-time system (blue), discrete-time system (red),
discrete-time system with approximate cefficients (green); As you can see they're almost
coincident.
For all calculations I used Octave, an open source mathematical modeling tool; version 3 has
just been released, and it can be used also under the famous windows (almost)operating
system.
If someone is interested these are the modeling scripts I used.
The real code for the control function was written in assembly; this is necessary for
performance reasons.
In fact our C compiler calls a library function to perform multiplications, so it has to save
many variables on the stack causing a delay; in this case the resulting execution time had
reached 50 us, which is a significant fraction of the sampling period.
Instead, by avoiding function calls and manually coding the 16x8 bit multiplication (see k1 &
k2), the execution time is down to 12 us.
Some real waveforms:
Step response to load change (load on top trace, AC coupled output on bottom tr.), 50ms/div
Step response to set point change (from 11,5 to 12,5 V), 50 ms/div
How to contribute
The best way to contribute to this project is to build it, use it, and report bugs or suggestions.
Also there are still many devices to test; check the list in supported devices.
Whoever has the know-how and patience can also expand support to other devices.
Or if you have a device that is not supported you can send it to me so that I can work on it.
If you find this project useful write me a couple of lines:
, and if
you modified it show me your work.
On SourceForge you can find some forums where you can discuss about this project; you
could also recommend it or write a (hopefully positive) review.
Downloads
Schematic diagram and pcb: complete archive.
Firmware: complete MPLAB project or compiled firmware (.hex) or a version for 18F2450
(0.8.0) (with reduced functionality, see the circuit).
opgui (GTK GUI for Linux & Windows): sources or application
OpenProg (windows): application only; sources (Visual Studio 6 workspace)
OP (command-line for Linux & Windows)
OpenProg and Opgui user's guide
Octave scripts
History
a long time
need for a reliable and free USB programmer
ago
2007
experiments with USB PIC and varionus firmwares; voltage regulator
2008
first prototypes and software
July 2008
documentation and website, released version 0.3
August 2008 version 0.4: added support for I2C EEPROMs
November
version 0.5: I2C & SPI bus, added some ATMEL devices
2008
January 2009 control programs v0.5.1: added some PIC devices, removed some bugs
control programs v0.5.2 and v0.5.3: added some PIC an Atmel devices,
March 2009
removed some bugs
April 2009 schematic diagram and pcb v1.4: changed Atmel adapter
June 2009
version 0.6: fully GPL2 USB firmware, added 93Sx6 MicroWire EEPROMs
September
version 0.6.1: solved some SPI bugs, added some Atmel devices and 93Cx6C
2009
October
control programs v0.6.2: bugfix
2009
version 0.7.0: added PIC24 and SPI EEPROMs;
January 2010
circuits v1.5: expansion board for 3.3V PIC24-30-33
February
control programs v0.7.1: added some PIC18 and Atmel devices; bugfix
2010
March 2010 control programs v0.7.2: added some MicroWire eeproms; bugfix
November
2014
the future
Links
Open Programmer on SourceForge
USB 2.0 standard
HID page on USB.org
pdb, a simple ICD debugger for PIC16
Quick guide to a HID firmware
USB Central
USB & PIC
Microchip
Atmel
hiddev documentation
Winpic
ICprog
Octave
gEDA-Gschem
PCB
GNU/GPL
Piklab IDE for PIC microcontrollers
USBPicprog, another open source programmer
Cygwin, a linux environment inside windows
Contacts
For informations or comments:
Alberto Maccioni
You can also post your questions on the forum on sourceforge.
Thanks
I'd like to thank all the people that contributed to the growth of this project, in particular:
Anselmo for helping with linux/git, Sandro for the highly professional PCBs, Alessandro for
testing many devices, Ken for testing many AVR devices, Luigi for testing OneWire
memories, Mihaly for testing SPI Flash memories.
Top