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.
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.
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.
On Apr 9, 5:27 pm, Radoslav Kolev <rado...@gmail.com> wrote:
> 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.
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:
> 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.
> On Apr 9, 5:27 pm, Radoslav Kolev <rado...@gmail.com> wrote:
> > 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.
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...
> 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: >> 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.
>> On Apr 9, 5:27 pm, Radoslav Kolev <rado...@gmail.com> wrote:
>> > 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
> -- > You received this because you are subscribed to the "Bifferboard" Google group - honest! > To unsubscribe from this group, send email to bifferboard+unsubscribe@googlegroups.com
> To unsubscribe, reply using "remove me" as the subject.
@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
On 9 Апр, 21:05, "biffe...@yahoo.co.uk" <biffe...@yahoo.co.uk> wrote:
> 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.
> On Apr 9, 5:27 pm, Radoslav Kolev <rado...@gmail.com> wrote:
> > 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.
> 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.
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.
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).
> 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 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.
> 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:
> 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.
> 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.
- 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:
> > 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.
> - 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:
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.
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.
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):
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.
