I should be able to tomorrow morning; I’ll keep everyone updated 
2 Likes
@dreg who much do you know about avrdudess internals? Is there a nice set of struts we can import and then program directly from the bus pirate? If there is a way we can pull in just the database and programming parts then we could stay synched with the project at minimal effort.
It feels like memory allocation may reveal itself as the real killer feature of BP6 extra ram and BP7 PSRAM.
@ian I’ve only done a couple of PRs in the Bus Pirate driver / doc code for AVRDude to add some simple stuff—I have no fucking clue beyond that, haha. Anyway, once the USB-PS2 Plank firmware is in master and everything’s solid, I can dedicate some time to that if you want.
1 Like
No worries. I had a look. I see useful stuff but I also see GPL 
1 Like
Btw, Lately I’ve also been using PSRAM + RP a lot in my projects — it’s awesome. BP7 PSRAM + the I/O buffers having their own PSU 
, it’s going to be amazing.
1 Like
I’ve used the AVR Dragon to do this for a very long time, but I love having it in the BP - one less piece of kit to have to keep at hand!
3 Likes
and one more “tool” in the swiss-army-knife of electronics. thats exactly why the BP is in my base toolkit.
2 Likes
I just posted in the dude repo: Add support to the Bus Pirate for larger flash chips · Issue #2043 · avrdudes/avrdude · GitHub
3 Likes
Wow, you guys are amazing 
Would it be possible to post a version of the firmware with the changes applied so I could also test?
2 Likes
@chickendipper this is the version
3 Likes
With @mbrugman 's solution and @stefanrueger ’s confirmation and comments, we have everything we need to support families with large chips.
@mbrugman , can you make your PR to the Bus Pirate repo and tag me, please? It would just be a matter of adding the logic @stefanrueger mentioned. If you have any questions, run into any issues, or need help with anything, just let me know.
Thank you all—you’re an awesome team!
3 Likes
I’ll work on that when I get home next week. I’m on holiday in way northern Minnesota this week
5 Likes
I’ll be back tomorrow - I have a volunteer shift at the food pantry until mid afternoon, then I’ll be able to get back on this to automate the usage of the extended high byte write.
@chickendipper - is you haven’t already, you can use the version linked above to do what you need. The dude folks confirmed that it is the correct solution.
Thanks for your patience everyone
Matt
2 Likes
Worked on this today, but the heat & humidity kicked my butt earlier. Probably finish tomorrow morning.
2 Likes
@mbrugman Bad timing! haha @Ian just changed things in that file today. If you don’t have much time, just make a PR with what you’ve got and I’ll take care of finishing it.
1 Like
Good timing, actually!! lol
I just finished and made a PR (not to be merged yet). @Dreg, can you test on your ATMega128 board?
firmware-rp2040-ubuntu-latest.zip (7.0 MB)
firmware-rp2350-ubuntu-latest.zip (6.8 MB)
If it works for you, then it will be good to merge
1 Like
Right now I can only test it on:
ATmega32U4
ATmega328
ATmega2560
2 Likes
I tested on a 328, if you test on 2560 that will show the extended high byte write is working. I forgot that you had a 256, not a 128
1 Like
a 128 would be great for full confirmation, but what I’m looking to see is that my logic of reading the signature to set the “needs high byte” logic is working.
1 Like