Pavapro - portable AVR programmer

Pavapro is relatively small, pocket-able device, allowing you to operate above microSD card, reading binary files (for now only .bin files are supported) and load those files into target AVR device. In addition to this, fuses files (ASCII text files) can be loaded too and fuses written into AVR.

Apart from that, pavapro allows you to open/edit/save text files, as well as there is also simple file viewer, when you don't want to mess with editor.

As if it wasn't enough, simple ASCII serial terminal is included too, allowing to view incoming data on CMOS or RS232 levels.

Its dimensions are 118x71x19mm, runs on single Li-Ion or Li-Pol battery, consuming approximately 20mA when running - so, classic 600mAh type will allow to run approximately for 30 hours on single charge. It can be charged from USB micro connector, serving as well for firmware update.

The user IO is done via 16-keys keypad and 128x64 OLED display. The electrical IO is 6-pin AVR ISP header (alternatively it can serve as 5xADC input or 4xIO line) and USART on CMOS levels as well as RS232 levels, plus one universal CMOS IO on second 6-pin connector.

Total price of components was around 20EUR + PCB price (could be anything, beginning from 0EUR if you have good fellow hacker, thank you David!)

The develoment of pavapro was done on free (as freedom) or free (as beer for free) tools under Linux and all design source files are freely available on github - so anyone can take the project, build, alter and contribute.

My main development machine runs on Xubuntu, software development was done using Gedit/GCC/Arduino IDE, hardware development - Eagle for PCB design (in fact, the only exception from open-source tools) FreeCAD for 3D modelling and Slic3r/Pronterface for 3D printing.

Though I'm running on FOSS tools, I understand that a lot of people runs windows OS, so I took care to select tools that have windows conterparts.

Myself, while working on pavapro.

Want to build one? Here is how.

Here is video of pavapro, ressurecting dead arduino

And another video, showing other features of pavapro

Project Logs

Collapse

Pavapro 2 is alive
jaromir.sukuba • 09/07/2015 at 20:22 • 0 comments

It's been quiet here for a few months, as I had just a little time for hobbies, though the project was moving on, slowly, look:
I made an expansion board for STM32L152RE Nucleo board.
And it is stacked in usual boring way
But it is alive!
I'm thinking of changing display type. That OLED is nice, but its tiny compared to keyboard and has high power consumption. If I'd change display to something bigger, the OLED screen would take much more juice. Seems like little TFT displays could use less power - like the usual 160x128 pixels I used in #JJ Tricoder and #10$ curve tracer projects.
It seems to be happy with a few miliamps of power for background LEDs, having the biggest share in total display consumption. I considered also EADOGM128 monochromatic display, but the price seems to be quite high. The 160x128 TFT is on ebay for 3USD or thereabouts.
What's next?
jaromir.sukuba • 01/18/2015 at 21:26 • 2 comments
Though Pavapro in its current form will not be not much developed, I strongly think of Pavapro 2. I looked into documentation and searched for FLASH programming of various MCU's. What I found it would be doable for:
- PIC16F1xxx
- PIC18F (including PIC18FxxKxx and PIC18FxxJxx)
- PIC24
- PIC32
- MSP430
- AVR (it is currently done for AVRs with equal or less than 64kB) with unlimited FLASH and ATtiny10 and friends
- AT89 - x51 MCUs
In fact, the programmer part of pavapro wasn't the hardest one. The task would be further simplified by borrowing code from my previous projects: the 8-bit PIC from #1757. PP04 - Camel computer and AT89 from PIC89PROG
I'm a bit reluctant about JTAG. I feel like it's not going to be rocket science, but anyway, implementing JTAG would allow interesting games, like
- svf player for programming programmable logic
- various ARM support
As a result of my love affair of 68HC08 MCUs (before Freescale obsoleted them in short time - lesson learned: never use any MCU from Freescale again) I'm probably going to implement them too. So,
- HC08
More device support is possible, but not in first plan for now
- STM8
- serial memories
Above that all, Implementing not only programming from SD card, but also receiving the programming file from serial line (or USB) would allow to use pavapro2 as quite universal device programmer. Just send hex file into serial port from whatever with serial port (your PC, raspberry, phone, type it into ASR33...) and wait a moment.
What I would definitely change is MCU in pavapro2. Honestly, AVRs are not that convenient to program as I'm used to (PIC, ARM). No debug support in Linux (AtmelStudio based on windows-only Visual Studio, what a cruel joke in year 2015) and various little, but painful nuisances like "pgmspace.h" or annoying fuses (No RSTDISBL, no fun!), sometimes rendering your MCU into OTP part and your device into brick.
In fact, not much of horsepower is required here - ATmega328 was sufficient, in this field. However lack of RAM and FLASH was showstopper for my development. 32k of FLASH was too small, 64kB would be better and 128kB or more is king size. 2kB of RAM was compromise, some 8kB would be nice, but I feel like 32kB or more would be great. I'm not sure whether I'm going to use PIC32 (my favourite PIC32MX795F512H or even new PIC32MZ with half a meg of RAM) or ARM MCU (venerable LPC1769, maybe something newer, like LPC11U68).
Anyway, I want to keep the hardware not more complicated than it is now. I don't want to grow it into huge behemoth.
I'm going to let this idea to mature and see how it turns out.
Result of Trinket EDC Contest
jaromir.sukuba • 01/07/2015 at 22:43 • 0 comments

This project won second prize in Trinket EDC contest. Great!
Thanks to all who followed/skulled this project, this feedback was valuable and helped me to put more effort in the project.
Résumé
jaromir.sukuba • 01/03/2015 at 18:25 • 0 comments

When I wrote my first thoughts project log more than month ago, I had no idea whether I'll be able to cram all the functionality into single ATmega328 contained in Trinket pro.
Fortunately, thanks to quite high code density of AVR code, as well as writing in plain C and great fatfs library I used in my project, the goals were met - so I can write the FLASH of target MCU from pavapro, set up fuses, edit and assemble small programs (and acting like small micropower AVR IDE), you can use it as serial terminal, crude e-book reader or you can have shopping list here and look like ultimate nerd in bus or in your favourite coffeehouse. It all took a solid piece of code (more than 3000 lines of code, not counting all the temporary testing code) resulting in full Trinket pro FLASH memory. All what is left is 20 bytes out of 28kBytes of FLASH... the last lines of code were a bit tough, I had to adjust code written previously, to free up a few dozens byte here and there for new code. Looking back, the pavapro seems to be more software than hardware oriented project, though hardware gave me some headaches too. Except of a few design flaws on the PCB (fixed in current HW files on github) and some incorrectly ordered components, I had problems with my 3D printer, that broke one day before deadline. In fact, it was night before deadline, as I'm doing most of the development during the nights, when my 1,5r son is finally sleeping and I have time for my hobbies. It can be seen also on my photo album - I set up for all the photos that didn't get into project logs and the others are in original resolution (I down-scalled all the pictures before uploading, to save your bandwidth when viewing project logs) - where most of the photos are slightly yellow-ish. Meh.
Though, there is a single thing I didn't make until contest deadline: absolutely simplistic and cut-down version of pavapro, without display or proper keyboard - though there is solid ground for building such as device. All necessary routines are already there and working, in fact it is more question of deleting code than writing a code. I had also other plans, for the case when I wouldn't be so FLASH starved - like BASIC or BrainFuck interpreter, I think it would go nicely with the spirit of pavapro.
Now I can consider the project mostly finished and closed, mainly because of the fact the ATmega328 in Trinket pro is full now. I believe some optimization could be used to free a few dozens or even hundreds bytes of memory, nonetheless to bring some more features, more FLASH would be needed. I'm not aware of any 28-pin AVR with more than 32kB of FLASH, compatible with ATmega328p and moving design to ATmega644 or similar would have significant impact on the hardware.
After all, developing pavapro was a great fun, so the meaning of contest was probably fulfilled. I spent nights learning new things, resulting in my own mini-computer, ultimate nerd status symbol and finished open-source project with 100% usage of FOSS development tools.
Want to build one?
jaromir.sukuba • 01/03/2015 at 14:44 • 0 comments

Yes, you can. Basically, you have three alternatives with decreasing difficulty level:
1. Use fully populated custom PCB:
That is the variant I chose for my device. It includes soldering AVR in QFN package, so some degree experience and laboratory equipment (though cheap one) is needed.
Eagle schematics and PCB layout, as well as schematics in PDF or PNG formats for simple viewing are available on github.
2, Use custom PCB, partially populated with easy to solder SMD parts and factory made Trinket pro.
This is somehow easier alternative, as all you need is a bit of steady hand. Take the PCB, ignore the dense middle part containing Trinket pro "clone" and solder the real Trinket pro via pin headers. Then populate the rest of SMD components. Don't worry, no QFN packages.
3, Don't use custom PCB at all.
You can choose this alternative, when you don't feel like SMD soldering is for you. Just take schematics and take look at the blocks. You can see Trinket pro 3V and LiIon backpack sections and replace it with factory made Trinket pro and LiIon backpack. In the original schematics, the other parts are SMD components, but with through-hole counterparts available too.
By the way, before could lay my hands on the real Trinket pro and my PCB, I did all the software development on my temporary PCB, assembled on pieces of protoboard.
Disregarding what hardware you use, software can be found on github easily to build and load with arduino IDE.
Happy hacking!
It works!
jaromir.sukuba • 01/03/2015 at 00:57 • 0 comments
I printed the case and settled Pavapro PCB into it, added battery and now it seems to work as expected. I had to fix a few minor bugs, though.
During the print, thermistor on my 3D printer's hotend lost contact, regulator cranked up temperature to the point where hotend started to melt, rendering my printer unusable. You know, day before deadline. Fortunately I had some spare hotend, though giving me horrible results, I managed to finish the case for pavapro. This is how it looks
Usually, I don't have yellow hands - just the light is bad. Look into the case. Everything fits nicely
I updated the firmware to make support for those actions:
- AVR FLASH memory writing
- AVR fuses writing
- AVR assembly source to binary assmbling
- text editor
- file viewer
- serial terminal
All those functions took almost all the FLASH memory
I have some 20 bytes of FLASH left. As a first demo, I uploaded video of pavapro resurrecting brain-dead Arduino.

In next project log, I'll cover the firmware of pavapro in more detail.

The keyboard in pavapro has this layout:
Pinout of the two 6-pin connectors can be seen from schematics (one of them is standard AVR ISP 6-pin connector). Pavapro was tested on both 3,3V and 5V targets. For various AVR-, you need to change program page size. I wrote more about page size parameter this log. It is sinle parameter, found under "Settings" entry. You can change it to 16, 32 or 64 bytes, as indicated by 10, 20 or 40 hexadecimal number.
Pavapro was tested on ATtiny2313 and ATmega328p MCUs, though it should work on most of the 8-bit AVR devices with FLASH under 64kB, except of ATtiny10 and similar - those have different programming interface, as well as X-mega devices.
Final hardware running
jaromir.sukuba • 01/01/2015 at 20:10 • 0 comments

Yesterday I soldered the PCB and today I flashed the firmware, previously developed on the experimenter’s board:
Except of single hardware difference (I ordered PCF8574 instead of PCF8574A - easily to workaround by two #define lines) it ran on the first try.
Needless to say, I made a few mistakes on the board during the design (I mentioned missing pull-ups on I2C bus before, did I?). Probably the most serious one is GND and VCC pins swapped for the display. Fortunately, I spotted it before powering the board, though after the display was soldered in place. Probability of releasing the blue smoke from display controller would be quite high if unnoticed. To fix it, I made this ugly workaround:
Never mind, I'm adjusting the original design to fix the bugs, so if somebody would ever decide to replicate my design, it will be (hopefully) error-less.
The current firmware allows to program FLASH and fuse bits of target MCU, edit text files on SD card and assemble AVR source files into binary (to be flashed with the on-board programmer) - I plan to film a short video demonstration. It grew pretty huge
64kB trinket pro would be nice for this project. Currently I'm designing case for it and the first case revision is in the print, as I'm writing this.
It has round corners, lawsuit, anyone?
Switching on the soldering iron and a lot of pictures
jaromir.sukuba • 12/31/2014 at 13:04 • 0 comments

I received nice gift from fellow hacker yesterday - my nice, shiny, homemade PCB. Double sided PCB, with no soldermask, but I can live without it.
I didn't enjoy it very long, as I had a lot of work to do.
Read more »
Keyboard works, target AVR programmed
jaromir.sukuba • 12/28/2014 at 13:06 • 0 comments

When doing some bigger projects - like this one - I like to build it in blocks, test each one separately and then, when everything seems to be OK, connect it together. Sometimes I use one block to test some other. So I made OLED display running and used it to debug SD card connection and FAT filesystem. Now, as I started to work on AVR ISP programming routines, I decided to connect keyboard first and make it running.
Read more »
Assembler assembling assembly sources
jaromir.sukuba • 12/26/2014 at 13:40 • 0 comments

While I'm still waiting for my PCB, I did a bit of work on software. In fact, I should have done my high-level programmer routines, as the low-level ones already do work, but I was impatient enough to start to work on the AVR assembler.
The assembler isn't that complicated piece of software - in theory, at least.
Read more »