Hi everyone,
My Bus Pirate arrived from Seeed Studio yesterday and I'm very happy! This is an awesome little tool. Thanks for all of your hard work!
After running a (successful) self-test and updating the firmware to v5.9, one of the first things I set about doing was attempting to program an AVR mcu using avrdude (GNU/linux). Firstly, just to see whether I could detect the ATtiny2313 I'd connected, I issued the command 'avrdude -P /dev/bus_pirate -c buspirate -p attiny2313 -v'. After displaying the Bus Pirate header, however, avrdude (v5.10 - the latest) just seemed to hang for a few seconds, before stating "Bus Pirate not responding."
Stepping through the avrdude source revealed a pretty simple problem: avrdude expects the last character on the Bus Pirate prompt line to be '>'. However, with the latest firmware the prompt includes an additional space, i.e. "> ". The prompt is therefore never detected by avrdude, which results in the observed behaviour.
This can be easily fixed by applying the following patch to buspirate.c in the avrdude v5.10 source:
====snip====
259,260c259,260
< /* Prompt ends with '>' all other input probably ends with 'n' */
< return (str[strlen(str) - 1] == '>');
---
> /* Prompt ends with '>' or ' ' all other input probably ends with 'n' */
> return (str[strlen(str)-1] == '>' || str[strlen(str)-1] == ' ');
====snip====
This causes avrdude to work perfectly with my BP, but should the inconsistency be fixed in the Bus Pirate firmware instead?
Thanks again for my new toy!
Tim
Hi Tim,
As you may have already read in this (http://http://dangerousprototypes.com/forum/index.php?topic=1201.0) topic, we were running into the same problem.
I just gave it a quick try on windows 7 64bit, and it works here too.
Thanks! save's me the hussle of flashing the stk500 firmware everytime I need to flash an AVR.
I agree with you on the BP firmware, but as AVRDude support had been broken through v5.something-v5.8 because of a reset confirmation, I'm guessing this little change just sneaked in there along the way.
Hi Rubu, I did see that topic but wasn't convinced that it was the same problem. It seemed from your post that the BP was sending gibberish back to avrdude after the prompt. I didn't observe anything like this, just avrdude failing to detect the prompt..
Tim
edit: woops - missed the line where you said "works here too". Great! So this is the same problem. Weird - what was that strange stuff in your serial dump then I wonder?
This causes avrdude to work perfectly with my BP, but should the inconsistency be fixed in the Bus Pirate firmware instead?
I don't feel it's an inconsistency, we did a major upgrade and overhaul of the terminal mode to add features and make it more user friendly. The binary mode was added specifically for AVRDude, and it stays very consistent. Scripts should not try to parse the command line and expect the output to stay consistent between versions.
I am willing to make some regressions to support AVRDude, for example I already removed the reset confirmation. But, I don't want to be stuck forever (?) with the same UI so that one rogue app can do something it shouldn't.
Maybe a better solution is to present an updated patch to AVRDude:
There is a new write-then-read command that would probably speed up the SPI programming by a TON:
http://dangerousprototypes.com/docs/SPI ... _then_read (http://dangerousprototypes.com/docs/SPI_%28binary%29#00000100_-_Write_then_read)
Also, there is no reason to do the reset. One or twenty 0x00 will enter binmode anywhere that the reset command works, and everything is reset upon entering binary mode. Also, once the v4 is out, reset will cause the USB connection to disappear and reattach, which will reek even more havoc.
Sorry Ian, by inconsistency I only meant that what avrdude expects and what the firmware delivers are in this case two different things. I didn't mean to imply that the user interface supplied by the firmware lacked self-consistency. (Quite this opposite, I really like it and think it's a great improvement over v4.2 that shipped with my BP.)
The patch to the avrdude source which I supplied above fixes this problem, although I only suggested modifying the firmware as I thought this might be easier as avrdude probably has a larger user base at this stage. Although, I completely agree with you that this shouldn't be done if it impedes the development of the Bus Pirate firmware.
I'm happy to supply the patched source to the avrdude devs, but thought it'd be prudent to post it here first to find out what you guys wanted to do.
Thanks again Ian for developing this tremendous tool.
Tim
No need to be sorry! I'm sorry, I didn't mean to come off as a jerk developer :) I just wanted to explain where we were at.
I'll probably remove the space for now, this has caused a lot of people issues. In the long-term it feels a bit unsavory to maintain a set of parameters in the UI for an app that should work exclusively in the binary access mode.
Attached is a firmware update with the spaces removed from the prompts. Probably we could make it even less invasive by only eliminating the space before the first prompt after a reset.
Since it seems like you have a decent grasp of the AVRdude source, would you be willing to submit a few patches to the project? I'll throw in a Bus Pirate v4 prototype too :) In order of importance, here's what I would change:
1. Eliminate the reset, we'd really like to keep the confirmation (but it also might change)
2. Don't parse the command prompt. Any firmware since v2 supports binary SPI mode. On earlier firmwares AVR Dude would also have problems parsing the UI, so it couldn't report the need for an upgrade anyways. I can add a binary version string command if you feel that feature is missing.
3. Assuming the AVR uses a basic !CS/write/read/CS pattern, the new read/write command should speed up programming by 10x or more (from 12 hours on flashrom to minutes).
1. Eliminate the reset, we'd really like to keep the confirmation (but it also might change)
To ensure no funkyness, sending enter a time or two might make sure the Bus Pirate isn't stuck in an option prompt.
[quote author="ian"]
No need to be sorry! I'm sorry, I didn't mean to come off as a jerk developer :)
[/quote]
No worries, you didn't!
Since it seems like you have a decent grasp of the AVRdude source, would you be willing to submit a few patches to the project? I'll throw in a Bus Pirate v4 prototype too :) In order of importance, here's what I would change:
1. Eliminate the reset, we'd really like to keep the confirmation (but it also might change)
2. Don't parse the command prompt. Any firmware since v2 supports binary SPI mode. On earlier firmwares AVR Dude would also have problems parsing the UI, so it couldn't report the need for an upgrade anyways. I can add a binary version string command if you feel that feature is missing.
3. Assuming the AVR uses a basic !CS/write/read/CS pattern, the new read/write command should speed up programming by 10x or more (from 12 hours on flashrom to minutes).
I have a decent grasp of gdb, not so much the avrdude source.. That said, the first two should be easy, but modifying the SPI code might be a little tricker. I'll give it a shot though. (And there's no need for bribery! :P )
Hrm.. it seems that the avrdude trunk (http://svn.savannah.nongnu.org/viewvc/t ... ot=avrdude (http://svn.savannah.nongnu.org/viewvc/trunk/?root=avrdude)) already fixes the prompt detection problem. (The current release is 9 months behind.)
It looks like it was updated to handle the new reset. I would still highly recommend dropping that all together, or there will be no way (aside from ignoring resets) to use AVRDude with Bus Pirate v4.
static int buspirate_cmd_bin(struct programmer_t *pgm,
unsigned char cmd[4],
unsigned char res[4])
It also looks like this function is a good candidate to be replaced by the write-then-read command.
[quote author="tgvaughan"]
Hi Rubu, I did see that topic but wasn't convinced that it was the same problem. It seemed from your post that the BP was sending gibberish back to avrdude after the prompt. I didn't observe anything like this, just avrdude failing to detect the prompt..
Tim
edit: woops - missed the line where you said "works here too". Great! So this is the same problem. Weird - what was that strange stuff in your serial dump then I wonder?
[/quote]
I have no idea, but there pins were quite small and I was just probing with a solid wire, so there's a fair chance I might have slipped for just a split second and the RX disconnected, floated or something like that.
[quote author="tgvaughan"]
Hrm.. it seems that the avrdude trunk (http://svn.savannah.nongnu.org/viewvc/t ... ot=avrdude (http://svn.savannah.nongnu.org/viewvc/trunk/?root=avrdude)) already fixes the prompt detection problem. (The current release is 9 months behind.)
[/quote]
Improving the Bus Pirate support in future releases of AVRdude to make things more robust will certainly be a help. However, I think it's worth keeping in mind that not only do AVRdude releases not happen that often (5.10 was January 2010), it takes even longer for all of the software that bundles AVRdude, such as WinAVR, Arduino IDE, and linux distributations, etc. to update the included version of AVRdude.
Perhaps someone could do an interim compile and post it here?
It sounds odd that they (avrdude community) won't release regular new binaries, there is some development activity according to the svn.
Also editted the wiki a bit to remove some version confusion as the buspirate and avrdude have almost the same version numbering.
[quote author="Sjaak"]
Perhaps someone could do an interim compile and post it here?
[/quote]
Hi Sjaak, this is a bit tricky to do due to the diversity of operating systems out there. I can only give you 32bit x86 Linux binaries. Is this what you're after?
Tim
[quote author="tgvaughan"]
[quote author="Sjaak"]
Perhaps someone could do an interim compile and post it here?
[/quote]
Hi Sjaak, this is a bit tricky to do due to the diversity of operating systems out there. I can only give you 32bit x86 Linux binaries. Is this what you're after?
Tim
[/quote]
No, I don't have any personal use for it ;) I was just asking for the users here.
I guess linux users are capable of compiling the code themself, but a windows compile of the new trunk would be nice.
[quote author="Sjaak"]
I guess linux users are capable of compiling the code themself, but a windows compile of the new trunk would be nice.
[/quote]
Agreed. For the various avrdude programming tutorials out there it would be best to have a place to link to where a compatible windows .exe can be found until the next release occurs. Or the alternate would be using BP 4.x firmware which will work with the current releases of avrdude, and software that includes it like WinAVR.