AVR programmer using Bifferboard as a hardware interface

153 views
Skip to first unread message

Ivan Zahariev (famzah)

unread,
Apr 9, 2010, 11:25:09 AM4/9/10
to Bifferboard
Hi guys,

Here is my try to develop a free AVR programmer for Bifferboard in
Perl:
http://code.google.com/p/biffavrprog/

It's pretty slow and the main idea is that you can easily download a
bootloader to your AVR chip using your Bifferboard as programming
hardware interface. Then re-program the chip faster via a serial/usb
cable.

Currently there is a database definition only for ATmega16 but there
are instructions at the Wiki which show how you can easily add your
own AVR chip to the supported list.

Give it a try and let me know what you think about it.

Cheers.
--famzah

Radoslav Kolev

unread,
Apr 9, 2010, 12:27:07 PM4/9/10
to biffe...@googlegroups.com
Hello Ivan,

2010/4/9 Ivan Zahariev (famzah) <fam...@famzah.net>:
> Hi guys,

> Currently there is a database definition only for ATmega16 but there
> are instructions at the Wiki which show how you can easily add your
> own AVR chip to the supported list.

That's quite impressive, but what was the reason to reimplement all
this in perl?

To me it looks like adding a new "programmer" backend to either uisp
or avrdude will be trivial. They already support programmers which
basically bitbang the serial or parallel port so just one of those
needs to be changed to use the Biufferboard GPIO lines instead.

This way all data about the MCUs and everything else can be reused.

Best regards,
Rado

biff...@yahoo.co.uk

unread,
Apr 9, 2010, 2:05:48 PM4/9/10
to Bifferboard

Hmmm..... I just can't get on with Perl unfortunately. I would be
interested in adding some assembler to make it faster, but judging
from the code I think someone else will need to re-implement in C
before I start!

If Perl has an equivalent to the Python ctypes module, then the speed
can be significantly improved by using inb/outb operations instead of
the standard GPIO interface. You could add a companion DLL with
these, ioperm(), then read/write the GPIO registers directly in the
PCI address space. See the R8610 data sheet for details, or check the
GPIO module source. You don't need any kernel module to do this, so
long as nothing else is using the GPIO interface independently.

Biff.

biff...@yahoo.co.uk

unread,
Apr 9, 2010, 3:44:09 PM4/9/10
to Bifferboard

Avrdude already has a package. I will have to test this with my
usbtiny at some point:
http://downloads.openwrt.org/kamikaze/8.09.2/rdc/packages/avrdude_5.5-1_i386.ipk

I suppose that if a version was implemented using GPIO SYSFS then the
avrdude developers would incorporate it. You just need to be able to
assign the pins somehow, perhaps that can be done via config file.
It's amazing nobody's done this yet, but I presume that's due to the
lack of adoption of GPIO SYSFS in general.

Biff.

On Apr 9, 7:05 pm, "biffe...@yahoo.co.uk" <biffe...@yahoo.co.uk>
wrote:

M P

unread,
Apr 9, 2010, 6:27:15 PM4/9/10
to biffe...@googlegroups.com
I made a very small, no brainer AVR programmer software that sits on
top of just libftdi. It only supports the (few) AVR models I use
often, but it's fairly trivial to add one and it's 1) fast 2) tiny 3)
doesn't require a config file. Works with FTDI devices with proper
wiring, I use it with ft245 using the bitbang interface.

I could open source that at some point if anyone is interested...

Michael, author of http://gitorious.org/simavr/

> --
> You received this because you are subscribed to the "Bifferboard" Google group - honest!
> To unsubscribe from this group, send email to bifferboard...@googlegroups.com
>
> To unsubscribe, reply using "remove me" as the subject.
>

Ivan Zahariev (famzah)

unread,
Apr 10, 2010, 1:58:16 AM4/10/10
to Bifferboard
@Rado: There are a few reasons to re-implement it in Perl:
1) try to modify "avrdude" yourself and you'll see the beauty of its
implementation and documentation side :)
2) "all data about the MCUs can be reused" - we all probably work with
no more than several chips and supporting all possible AVR chips is
just not necessary in this case; I could have also probably parsed the
avrdude database file, and might do it in the future if there is
demand
3) Perl code is easier to maintain (see reason #1 again)
4) fun and education

@Biff: Perl supports modules written in C (I've never tried them
though). If you provide sample C code, I can try it out. The C code
must have routines for the following:
1) General init/open, if needed
2) Set up the direction ("in" or "out") of a given GPIO pin
3) Read and write from/to a GPIO pin
4) Close + clean up, if needed
5) An example will be appreciated (I reviewed the GPIO kernel module
source but I'm really not into low-level PCI access things and don't
have the time to learn it now)

Why is speed such a factor...? I though everybody uploads a bootloader
once and then forgets about their hardware programmer for a long
time... It seems I was wrong.

Cheers.
--Ivan

Radoslav Kolev

unread,
Apr 10, 2010, 3:10:37 AM4/10/10
to biffe...@googlegroups.com
Hi Michael,

2010/4/10 M P <buse...@gmail.com>:


> I made a very small, no brainer AVR programmer software that sits on
> top of just libftdi. It only supports the (few) AVR models I use
> often, but it's fairly trivial to add one and it's 1) fast 2) tiny 3)
> doesn't require a config file. Works with FTDI devices with proper
> wiring, I use it with ft245 using the bitbang interface.
>
> I could open source that at some point if anyone is interested...

There are currently patches for avrdude and uisp to support
synchronous bitbanging on FTDI chips but all I have seen use the
proprietary FTDI libs. I would prefer a libftdi solution.

Again in my opinion it's better to integrate into avrdude, but if you
publish your code most probably someone will adapt it.

Regards,
Rado

Radoslav Kolev

unread,
Apr 10, 2010, 3:27:19 AM4/10/10
to biffe...@googlegroups.com
2010/4/10 Ivan Zahariev (famzah) <fam...@famzah.net>:

> @Rado: There are a few reasons to re-implement it in Perl:
> 1) try to modify "avrdude" yourself and you'll see the beauty of >its implementation and documentation side :)

Yes, I agree that developer docs are kind of non-existant, but I
checked the source and it doesn't look that bad. I've definitely seen
much worse :). Since there is already general bitbanging implemented
it seems all you have to do is provide a couple of functions to
get/set a pin value and fill in a struct to represent your new
programmer. You can look at how the serial/parallel bitbang
programmers are handled. If I find some time today I may give it a
try.

> 2) "all data about the MCUs can be reused" - we all probably work with
> no more than several chips and supporting all possible AVR chips is
> just not necessary in this case; I could have also probably parsed the
> avrdude database file, and might do it in the future if there is
> demand

Yes I agree most people (including me) just use a few chips, but even
then ... I guess I'm just lazy.

> 3) Perl code is easier to maintain (see reason #1 again)

Well, it depends who wrote the Perl/C/whatever code in question :).

> 4) fun and education

Can't argue with that one!

> Why is speed such a factor...? I though everybody uploads a bootloader
> once and then forgets about their hardware programmer for a long
> time... It seems I was wrong.

Well, may be you want to use each and every byte of flash and don't
want to waste 1-2K for a bootloader. Also on a lot of projects that
don't actually require PC connectivity there is no hardware provided
for a serial connection.

Just so I can get a general idea, what kind of slow are we talking
about? How long does it take to load let's say an 8K hex using your
perl programmer now? I have used serial and parallel bitbanging
programmers before and while not lightning fast the speed was
tolerable. Using the GPIOs shouldn't be slower.

Rado

biff...@yahoo.co.uk

unread,
Apr 10, 2010, 8:06:58 AM4/10/10
to Bifferboard
On Apr 10, 8:27 am, Radoslav Kolev <rado...@gmail.com> wrote:
> programmers are handled. If I find some time today I may give it a
> try.

If avrdude supports Bifferboard GPIO I would definitely use it, so I
look forward to seeing this, whether it uses SYSFS, or something
faster it will still be useful.

> Yes I agree most people (including me) just use a few chips, but even
> then ... I guess I'm just lazy.

Yes, me too, ATMega168, ATTiny2313 is about all I ever use.

> > Why is speed such a factor...? I though everybody uploads a bootloader
> > once and then forgets about their hardware programmer for a long
> > time... It seems I was wrong.
>
> Well, may be you want to use each and every byte of flash and don't
> want to waste 1-2K for a bootloader. Also on a lot of projects that
> don't actually require PC connectivity there is no hardware provided
> for a serial connection.

I *never* use a bootloader, and I suppose it depends what you want to
do with the serial port (assuming the bootloader uses the serial
port).

> Just so I can get a general idea, what kind of slow are we talking
> about? How long does it take to load let's say an 8K hex using your
> perl programmer now? I have used serial and parallel bitbanging
> programmers before and while not lightning fast the speed was
> tolerable. Using the GPIOs shouldn't be slower.

The overhead of using the sysfs interface will significantly exceed
the overhead of bitbanging a parallel port. One uses a file operation
and userland->kernel translation layer, whereas the other uses simple
IO port access. I think I need to write something up about doing
really fast IO on the Bifferboard. Actually this is where Ivan's
approach may be better, because we can do the SPI bit shifting with an
unrolled assembler loop instead of only having control of individual
GPIO operations (and presumably function call overhead for each bit
transition).

> Rado

regards,
Biff.


Radoslav Kolev

unread,
Apr 11, 2010, 10:27:48 AM4/11/10
to biffe...@googlegroups.com
2010/4/10 biff...@yahoo.co.uk <biff...@yahoo.co.uk>:

> On Apr 10, 8:27 am, Radoslav Kolev <rado...@gmail.com> wrote:
>> programmers are handled. If I find some time today I may give it a
>> try.
>
> If avrdude supports Bifferboard GPIO I would definitely use it, so I
> look forward to seeing this, whether it uses SYSFS, or something
> faster it will still be useful.

I added support for a gpio through sysfs bitbang programmer to
avrdude. It takes about 30s to write ~9K to the flash of an Atmega168.

I will clean it up a bit and send the patch here.

Radoslav Kolev

unread,
Apr 11, 2010, 4:46:05 PM4/11/10
to biffe...@googlegroups.com
2010/4/11 Radoslav Kolev <rad...@gmail.com>:

> I added support for a gpio through sysfs bitbang programmer to
> avrdude. It takes about 30s to write ~9K to the flash of an Atmega168.
>
> I will clean it up a bit and send the patch here.

To use this patch:

1. Download avrdude-5.10 source
2. apply patch

From within avrdude-5.10 source dir:

3. run automake (I used version 1.8 and worked fine. The default in my
Ubuntu install was 1.4 and didn't work, so installed 1.8 and
update-alternatives )
4. ./configure
5. make
6. make install, or copy avrdude and avrdude.conf somewhere

A new programmer called gpio is added and the default configuration in
avrdude.conf is:

programmer
id = "gpio";
desc = "Use sysfs interface to bitbang GPIO lines";
type = gpio;
reset = 11;
sck = 13;
mosi = 12;
miso = 9;
;

I used the JTAG pins of the bifferboard and also the 3.3V power supply
to power the ATMega. If you wired your cable differently just adjust
the gpio numbers to match.

After this:

avrdude -c gpio -p m168 -v -U flash:w:file.hex

to write file.hex to flash.

Writing 8K to the flash takes about 30 seconds.

Best regards,
Rado

avrdude-5.10-bb-gpio.patch

biff...@yahoo.co.uk

unread,
Apr 14, 2010, 12:46:55 PM4/14/10
to Bifferboard
Hi Rado,

I haven't tried this yet, but do I need any pull-up resistors, or did
you just wire this straight through?

cheers,
Biff.

On Apr 11, 9:46 pm, Radoslav Kolev <rado...@gmail.com> wrote:
> 2010/4/11 Radoslav Kolev <rado...@gmail.com>:

>  avrdude-5.10-bb-gpio.patch
> 12KViewDownload

Radoslav Kolev

unread,
Apr 14, 2010, 1:45:44 PM4/14/10
to biffe...@googlegroups.com
2010/4/14 biff...@yahoo.co.uk <biff...@yahoo.co.uk>:

> Hi Rado,
>
> I haven't tried this yet, but do I need any pull-up resistors, or did
> you just wire this straight through?

No, just a straight through cable from the bifferboard 6 pin JTAG
connector to the 6 PIN ICSP on the AVR side. Of course Vcc and GND
should be matched, the other is arbitrary and can be adjusted in the
config file.

Say if you have any problems.

Rado

biff...@yahoo.co.uk

unread,
Apr 14, 2010, 8:17:27 PM4/14/10
to Bifferboard
A few comments:

- It seems the trailing space after gpio.h \ is significant! You have
to remove it from Makefile.am to make it compile with the patch.
- The patch you posted to the avrdude ML doesn't work, doesn't even
apply, I think that's because the ML archive viewing software is
munging email addresses in the patch.
- You might consider calling the programmer something other than gpio,
to avoid conflicts with gpio on other platforms. I forgot it's not
just a Linux utility. Perhaps 'gpio-sysfs' is sufficiently unique, or
'sys-gpio', maybe even 'linux-gpio-sysfs'
- I guess the description string should also mention Linux?
- When you were evangelising your patch you forgot to mention that
this can be used by practically any router supported by OpenWrt, since
OpenWrt already has a package build script for avrdude. It seems you
were convincing enough without it, but worth keeping in mind :). When
they release the next avrdude we will have to submit a patch to
OpenWrt to bump the avrdude build, then we can post an announcement on
the OpenWrt forum.

Oh yes, and I almost forgot to say: tested only with ATTiny2313 but it
works a treat. In fact I'd say it's not appreciably slower than my
USBTinyISP, although I only uploaded a small program. I would try the
Perl script as well, but I'm too lazy to configure it for ATTiny2313
which is all I have to hand.

Nice one,
Biff.

On Apr 14, 6:45 pm, Radoslav Kolev <rado...@gmail.com> wrote:
> 2010/4/14 biffe...@yahoo.co.uk <biffe...@yahoo.co.uk>:

Radoslav Kolev

unread,
Apr 15, 2010, 3:44:09 AM4/15/10
to biffe...@googlegroups.com
2010/4/15 biff...@yahoo.co.uk <biff...@yahoo.co.uk>:

> A few comments:
>
> - It seems the trailing space after gpio.h \ is significant!  You have
> to remove it from Makefile.am to make it compile with the patch.

It only generated a warning on my machine, but anyway this is fixed
in the patch I sent to avrdude-dev.

> - The patch you posted to the avrdude ML doesn't work, doesn't even
> apply, I think that's because the ML archive viewing software is
> munging email addresses in the patch.

Can you try getting it from here, it's their web based patch tracking system:

https://savannah.nongnu.org/patch/download.php?file_id=20204

But using this version you have to also rerun autoconf and pass the
--enable-gpio option to configure.

It will be great if you can test and confirm this is all working, so
that I know the only change I need to make is to the name and
description.

> - You might consider calling the programmer something other than gpio,
> to avoid conflicts with gpio on other platforms.  I forgot it's not
> just a Linux utility.  Perhaps 'gpio-sysfs' is sufficiently unique, or
> 'sys-gpio', maybe even 'linux-gpio-sysfs'

Yes, sounds reasonable.

> - I guess the description string should also mention Linux?
> - When you were evangelising your patch you forgot to mention that
> this can be used by practically any router supported by OpenWrt, since
> OpenWrt already has a package build script for avrdude.  It seems you
> were convincing enough without it, but worth keeping in mind :).

Good point, I will mention this when I send a revised patch with the new name.

> they release the next avrdude we will have to submit a patch to
> OpenWrt to bump the avrdude build, then we can post an announcement on
> the OpenWrt forum.

I don't know what is their release schedule, but if they include it in
the next release we can do this, yes.

> Oh yes, and I almost forgot to say: tested only with ATTiny2313 but it
> works a treat.  In fact I'd say it's not appreciably slower than my
> USBTinyISP, although I only uploaded a small program.

I'm glad it works :). I tested a serial port bitbanging programmer on
my desktop machine to compare and it's a lot faster. But I think the
reason is that it's a 3.2GHz P4 vs the 150MHz 486 of the bifferboard.
Otherwise the serbb is with similar overhead calling ioctl on every
bit change. Unfortunately I don't have any GPIO on my desktop, nor a
serial port with control lines on the bifferboard to do a more
meaningful comparison.

> Perl script as well, but I'm too lazy to configure it for ATTiny2313
> which is all I have to hand.

I was also thinking to try the perl version but I only had an
ATMega168 all wired up.

Rado

biff...@yahoo.co.uk

unread,
Apr 15, 2010, 6:19:57 AM4/15/10
to Bifferboard
On Apr 15, 8:44 am, Radoslav Kolev <rado...@gmail.com> wrote:
> It only generated a warning on my machine, but anyway this is fixed
> in the patch I sent to avrdude-dev.

I suspect this has something to do with either you not doing a clean
rebuild (re-extracting the tarball) or my version of automake, not
quite the same as yours.

> https://savannah.nongnu.org/patch/download.php?file_id=20204
>
> But using this version you have to also rerun autoconf and pass the
> --enable-gpio option to configure.

OK.

> I don't know what is their release schedule, but if they include it in
> the next release we can do this, yes.

We also can change this:
https://dev.openwrt.org/browser/packages/utils/avrdude/Makefile

To pull the source version as soon as it gets applied if they're too
slow releasing it.

Biff.

biff...@yahoo.co.uk

unread,
Apr 15, 2010, 6:31:35 PM4/15/10
to Bifferboard
Rado,

I've added some code for bypassing the gpiosysfs and accessing the IO
ports directly.

This code will never be incorporated into avrdude by the developers,
that I'm sure of so I didn't bother to do this properly, and you have
to have my avrdude conf settings, however it seems to speed things
up. It's difficult for me to see just how much since I've only got
short AVR programs to play with, however it says

vrdude: Device signature = 0x1e910a
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be
performed
To disable this feature, specify the -D
option.
avrdude: erasing
chip
avrdude: reading input file
"main.hex"
avrdude: input file main.hex auto detected as Intel
Hex
avrdude: writing flash (416
bytes):

Writing | ################################################## | 100%
0.31s

If these timings are correct your 8k flash should be written in 6
seconds. Who knows - my clock might be off, but it will be
interesting to see.

My gpio.c is here: http://sites.google.com/site/bifferboard/Home/howto/serial-terminal-project

Caveat: This code doesn't preserve GPIO settings, and whilst it will
work fine even with rdc321x_gpio loaded the latter may not work
properly afterwards. The price of chaos must be paid :).

I have some other ideas about how to speed things up a bit more, but
this should do for a start.

regards,
Biff.

Reply all
Reply to author
Forward
0 new messages