zevero
Experimental serial support for atmega 328p
Hi Zevero,
I have added serial support for atmega328p, and have made it an option in the Makefile. When enabled, the bootloader will first wait for serial, and if it detects serial flashing took place, mmc flashing will be skipped. The option is disabled if UART debugging is enabled, for obvious reasons.
I have also added a few compiler optimizations, they are not strictly necessary, I get a bootloader for 328p, with serial at 3992 bytes. But with the optimizations, size is reduced to 3696 bytes, which is almost an 8% saving.
PS: Sorry my commit history is a bit messy.
Regards,
Jadin
Wow! Before pulling I think we should test.
I am concerned with FAT32 beeing disabled... I (and presumably others) use at least 4 GB SD-Cards. I have never tried switching off FAT32 support. But I suppose it won't work?
Good point with regards to fat32 and sd cards > 2gb. I just had a look again, compiling for both fat16 and fat32, produces a bootloader at 4142 bytes, just a few bytes too big. However, compiling with just fat32 support, 3922 bytes, and just fat16 3696 bytes.
I will test later tonight, but I doubt petitFat will read fat32 cards with fat32 disabled. For now, I'm going to leave my master as is, and have left fat32 as the default for now, since at least you can format smaller sd cards to fat32.
I will create another branch where I'm going to start disassembling and rewriting parts of stk500v1.c. We can save some bytes by using common uart and program flashing code.
Ok ... I did not realize that we can fit FAT32 only in 3922 (or I guess 3972 for atmega1284p). Thats just perfect! Is there anyone still using FAT16? It is getting difficult to buy SD-Cards with 2 GB or less...
I would be OK with only supporting FAT32.
@per1234 what do you think?
I recently did a some shopping on Aliexpress for cheap SD cards to use with Arduino so I don't chance messing up my nice ones and I saw that you can get the <1 GB SD cards for very cheap. Even 128 MB is probably more than anyone could need. On the other hand I noticed that usually they are available on multi-item listings and the lower capacity card options are sold out so they may just be added by the seller to have the listing show up higher in the "sort by price low to high" search results. I ended paying ~$2 more to get 4 GB cards that will useful for other purposes but I could definitely see cases where someone is just trying to keep the BOM cost as low as possible. I'm picturing something like a kit for an Arduino game console that includes multiple SD cards, each with a different game on it.
I think it would be ideal to support the widest range of cards but fitting serial upload support in a 4 kB boot section is probably more useful to the average user.
Could we add a configuration parameter to the makefile to make it easy to enable/disable FAT16 support? I can add a custom menu to the Arduino IDE's Tools menu to offer both options for people installing the bootloader that way.
This i great! This is exactly what i needed for my 1284p and 328p projects. Fat32 is all i would need. But i agree that options in the board menu would be the best route for the end user. I dont think fat16 would turn up often at all for most of us. Great work though. Ill test it out later on all my sd enabled projects. Just curious, is this working on 1284p yet?
Sent from BlueMailhttp://www.bluemail.me/r?b=9531 On May 1, 2017, at 3:03 AM, per1234 <[email protected]mailto:[email protected]> wrote:
I recently did a some shopping on Aliexpress for cheap SD cards to use with Arduino so I don't chance messing up my nice ones and I saw that you can get the <1 GB SD cards for very cheap. Even 128 MB is probably more than anyone could need. On the other hand I noticed that usually they are available on multi-item listings and the lower capacity card options are sold out so they may just be added by the seller to have the listing show up higher in the "sort by price low to high" search results. I ended paying ~$2 more to get 4 GB cards that will useful for other purposes but I could definitely see cases where someone is just trying to keep the BOM cost as low as possible. I'm picturing something like a kit for an Arduino game console that includes multiple SD cards, each with a different game on it.
I think it would be ideal to support the widest range of cards but fitting serial upload support in a 4 kB boot section is probably more useful to the average user.
Could we add a configuration parameter to the makefile to make it easy to enable/disable FAT16 support? I can add a custom menu to the Arduino IDE's Tools menu to offer both options for people installing the bootloader that way.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/zevero/avr_boot/pull/24#issuecomment-298313901, or mute the threadhttps://github.com/notifications/unsubscribe-auth/APMzF-xSzFWmXlAAZ4F58ByAgMv-keeXks5r1a2tgaJpZM4NMs3H.
@zevero Actually, I was using fat16, but only because I had received 2gb sd cards with my ethernet shields. I don't think there are any obvious reasons to support fat16, other than we can support it. You are right, it's really hard to purchase small sd cards these days, I actually don't think I can buy 4gb cards locally anymore, the smallest I see are 8gb cards and they are super cheap, the equivalent of about 2 or 3 dollars.
@per1234 I can add an option to the makefile for fat16 support, no problem. Could you perhaps let me know what naming convention you want to use for the bootloaders with serial support, and with fat16/32 etc? I assume something like what I used in my builds will suffice. eg: atmega328_cs4_16000000L_serial_fat32.hex atmega328_cs4_16000000L_serial_fat16.hex
@SergeantSeven Unfortunately, I have only been able to compile successfully for 328p, I know the problem is that there is no definition for 1284p in stk500v1.c. Also, I don't have a 1284p to test on, so hopefully you can help out with this if you have time. Though, this will not even be a problem if we dismantle stk500 and use uart.h and the program flashing function in main.c. This will also reduce this size considerably, my guess is around 300 bytes minimum can be shaved by doing this, then there will be no need to have separate bootloaders for fat16/32 either.
I had a look at your fork, and it looks like this is the route you were taking, I think it's the right way to go, I just wanted to 'get serial working' by any means necessary as I had used avr_boot in a project, and it sucked having to remember which arduino's had avr_boot, and having to upload a firmware to sd card when I just wanted to try something out, or flash a stock bootloader.. At least now, it's a lot easier on 328p boards.
Ah ... I remember now, that I wanted to try stk500 for my atmega1284p but was put off by those missing definitions...
@JadinAndrews > I don't know how much effort you want to put into this ... do you intend to "dismantle" stk500?
I am just not sure if I should pull if not all the other Atmegas work. If I pull I would have to document the current state somehow.
@zevero that's fine, pulling is up to you. Serial does compile for atmega128 as well, but I can't test that, but see no reason why it shouldn't work. Perhaps I can look into adding definitions for 1284p and 32u4 to stk500, then at least most of the atmega's supported by avr_boot will be supported with serial. I don't know how to get this working on a 2560 though.
I do want to take stk500 apart, and only keep what is needed, it's silly to have separate program flashing code in avr_boot and stk500, it might not even be that much work in the end.
We haven't managed to get avr_boot working for uploading from SD to ATmega2560 yet (see https://github.com/zevero/avr_boot/issues/4) so if you can't get serial working for ATmega2560 that won't limit the functionality of the bootloader as it is currently, though it would be great if we could add ATmega2560 support eventually.
Ah I see. Ok, I will have a look to see what I can do about 1284p support at the very least, any pointers that may help me? Also, I need to make a few purchases, I don't own a 1284p for testing, do you have any suggestions about what to get and where?
I just added a few builds for atmega128 and 328p, with serial and different cs pin and fat16/32 configs, please test them out if you get a chance. I am at work, so I can't right now, but they should work as long as I got the cs ports setup correctly..
@JadinAndrews I have a board with a 1284p which I can test. I have looked into stk500v1.c and spi_pins.h and I feel quite a bit intimidated.
If you happen to know how to set AVR_ATmega1284p I would beg you to give it a try, or at least some directions. Otherwise I fear it would take me quite some time for my guessing trial and error approach ...
I don't own a 1284p for testing, do you have any suggestions about what to get and where?
I've gotten by for years a homemade ATmega1284P on a stripboard setup and another one on a breadboard.
I recently got some of these "Minimum System Board": https://www.aliexpress.com/item/ATMEGA16-ATmega32-ISP-Minimum-System-Board-AVR-Minimum-System-Development-Board/32729506217.html To use for testing with ATmega1284P and other DIP-40 AVRs. The price is ridiculously low for a board with a ZIF socket. That one has holes to allow you to solder some resistors and LEDs. They are connected to PA6 and PA7. I actually hacked mine by adding a greenwire on the bottom and cutting a trace so there is one LED and a male pin so I can jumper any pin I want to the LED. I wish it had an FTDI header on it. I'm planning to make an adapter board I can plug onto them for that. It's kind of annoying to me that it has the 10 pin ICSP header because I usually use the 6 pin ISP programmer but it's only a couple bucks for a 10 pin USBasp so not a big deal. The crystal is socketed so you can easily test different clock speeds. There are a variety of versions of that "Minimum System Board" all around the same price. I like the one at the link above because of the LEDs option and it's all through hole but there is another one that has standoff feet installed that was a close contender since I always add those to my boards.
I have one of these sweet ATmega1284P boards on the way to me now: https://www.tindie.com/products/MCUdude/dip-40-arduino-compatible-development-board/ This is made and sold by the guy who wrote MightyCore and a bunch of other really nice hardware packages for Arduino so it's cool that you can support his work and get some nice hardware at the same time.
@zevero I'm the author of spi_pins.h so I can probably answer any questions about that file. As for stk500v1.c, not so much...
Just a quick "I am a noob", I built for atmega128 by mistake, I meant to build for 168. 168 builds as well, but the 128 builds probably won't work because I used ports and boot start address for 168.. Will fix this later, but seems like at least serial should be working for at least 3 boards if there aren't other complications.
@per1234 Thank you for the links! I will definitely get a few of those minimum system boards with my next purchase.
I can't guarantee I can do anything for 1284p support without a unit to test, but I will do some research, and look through bootloaders that do support it.
My understanding is that adding serial upload support for ATmega32U4 will still not allow uploading as you would normally to an ATmega32U4 based Arduino such as Leonardo, Pro Micro, etc. as that is a completely different bootloader. What it will allow you to do is a standard "Uno" type of upload via a USB-serial chip attached to the USART pins, which could still be useful.
I know Optiboot supports ATmega1284P: https://github.com/Optiboot/optiboot/tree/master/optiboot/bootloaders/optiboot and also Ariadne. Here's the commit where support for ATmega1284P was added to that bootloader: https://github.com/LoathingKernel/Ariadne-Bootloader/commit/10c5e7728d04ab03f020554c93106c7ffa984f8f
Thanks fr the info @per1234 Maybe, I should just look at dumping stk500v1.c, and dropping in optiboot. I noticed that's what they did in ariadne the tftp bootloader, will have a look when I get a chance.
I feel like a lot of the optimizations everyone is looking at doing here may have already been done in Optiboot. There may be more that can be done related to the extra SD code of avr_boot but it would certainly be a good start. Optiboot has traditionally not supported >128 kB flash such as ATmega2560, ATmega2561 but that limitation has been overcome: https://github.com/Optiboot/optiboot/pull/190
I started down this path myself but quickly lost interest as I became overwhelmed. I only know so much about this kind of stuff. but I did start to try and dismantle the stk500 code. there are bits and pieces of it we could drop in and modify to work but the optimization part was trickier then I could handle. also, I was going to try and modify the serial parts to utilize avr_boots flashing mechanism. but could not figure out how to translate it from the way stk500 does it. maybe you can shed some light on that for me, once I get my head around that I can be of more help.
@SergeantSeven Here's what I found, stk500 calls a function write_flash_page() inside the function handle_write(). If you look at the definition of write_flash_page() in prog_flash.c, you will see that it is somewhat similar to the doFlash() definition in main.c. The big differences are how the pagebuffers are filled and the page compare stuff.
avr_boot fills the buffer with a call to pf_read (on line 124 of main.c) and stk500 fills it with a for loop on line 428 of stk500v1.c.
A good start would be to use the same pagebuffer for both functions, at least that will save some ram, but won't reduce the size much. The next step would be to modify one of the functions to handle filling the buffer, from either flash or sd. I think it is a good idea to keep the page compare stuff, for both serial and sd flashing, so might be a good idea to modify doFlash() to work with stk500v1.c.
(EDIT: I am not so sure that this will really save as much flash as I had initially hoped. Adding stk500 to avr_boot adds ~700 bytes, but optiboot is less than 512 bytes, which is already a nice saving.)
All this said, I think it is better to focus on 1284p support, by switching to using optiboot instead of stk500v1.
So, I decided to try add definitions to stk500 for 1284, and it compiled (3992 bytes or so). It should work for 1284p as well, I made a build with cs4, could one of you guys please flash and see if it works?
I have a feeling it might work, but I'm not sure which usart port it will use, I assume it will use one of them though...
https://github.com/JadinAndrews/avr_boot/blob/master/build/atmega1284p_cs4_16000000L_serial_fat32.hex
It uses uart port 1, this can be changed in stk500v1.c. If the bootloader works on 1284p devices, I can add an option to the makefile to choose between the two available ports.
I have been able to do serial and SD card upload to ATmega1284P and ATmega328P using your bootloader file. Good work!
I must admit that even though you warned us I was a bit confused when AVRDUDE kept thinking my chip was an ATmega1284 instead of ATmega1284P. I forgot that the bootloader supplies the signature during serial uploads.
I was sidetracked by the uart port 1 comment, actually the bootloader works on port 0, not 1.
@per1234 I am really glad it worked, it was a bit of a shot in the dark, but I realized that the only thing that was missing from stk500 was the initialization of the usart port, and looking over some other bootloaders, I saw that the setup was the same as on atmega 128, and 1280. So literally all I did to get this working on 1284 was to add || defined (__AVR_ATmega1284__) in a few places in stk500. Have a look at the commit for yourself: https://github.com/JadinAndrews/avr_boot/commit/2e5f34a944d7f8f0306f55604837ec5a09c40d5d
It really was that easy..
Sorry about the confusion with regard to the port numbering, I forgot that the ports were zero indexed, this is actually also an error in stk500v1.c, where the ports are numbered from 1-4 for atmega1280. I'll fix this at some point and look at adding defs specifically for 1284p. It wouldn't compile for 1284p, and I didn't have time to figure out why. I literally threw this together during my coffee break.
So after a few small issues are fixed, I believe serial + sd is confirmed working for atmega328p and 1284p, and should be working on atmega128, atmega168, atmega1280 but I doubt there is much demand for those chips.
I can also test ATmega32A and ATmega32U4. ATmega32A is not so commonly used in the Arduino world but there is already good support for it in MightyCore and it's a great price for a DIP-40 microcontroller.
ATmega168 doesn't have 4 kB boot section option (2 kB max) so that one won't be possible to support without optimizing the code down a lot. I can test ATmega168 if the time comes when that is necessary.
Arduino used to make a "Mega 1280" so there are probably still some of those floating around. The Wiring 1.0 board was ATmega128 so there are probably some of those out there, maybe collectors items at this point. ATmega644 has been on multiple semi-popular boards.
Well as far as I know atmega1284 and atmega644 are almost identical, so that should be pretty easy to support. I believe the atmega644 has been used a lot in the 3d printing world? I'm sure they would love to have serial + sd support.
I am curious if my builds for the atmega328p will work on a atmega32u4 or atmega 32A? they seem pretty similar on paper, either way, supporting them would just be a matter of adding definitions as I did for the atmega1284. Unless they're wildly different.
Thanks for pointing out that this will not work on the atmega168, shaving this down to 2kB, seems pretty hard at this stage, but not impossible. I have some ideas to trim this bootloader down a bit, but I think that's a separate issue for now.
Thanks for testing my bootloader files, did you compile, or just use the ones in the build directory?
I agree that the focus of this pull request should be just adding serial upload support. Any optimizations that can be done after that are great but adding this feature in 4 kB is wonderful by itself. It's hard to believe that 2 kB could be shaved off but 2boots has shown it can be done and optiboot did manage to go from the 2 kB standard serial bootloader to 0.5 kB. Even if it's not possible to get to 2 kB, getting it smaller could allow FAT16 to be added back in with FAT32 or leave room for other new features.
I used the files you provided. I figured it was best that we all test with the same files to reduce the number of variables.
@per1234 I'm curious if the readme for avr_boot is incorrect, it says that avr_boot was tested successfully on ATmega168? How is that possible with its 2kB boot section? I am very curious to figure out how 2boots managed all this in 2kB. It does only support fat16, but the difference between fat16 and fat32 with petit fat is really not that massive. There must be more (or less) going on than meets the eye.
@zevero @SergeantSeven do you guys have a 644p to test on? I think that it would be nice to support that mcu with this pull as well, but I don't have one to test.
@zevero wrote that about the ATmega168: https://github.com/zevero/avr_boot/commit/2f2cefac89c6872c7fd4c78fa1105ee03495e9d0 It would be great if I was wrong and it is possible to use with avr_boot. You can get ATmega168 Pro Minis for a little cheaper than the ATmega328P ones and some people even end up buying them by mistake because the sellers use misleading titles on their listings so that is a pretty common part.
If nobody else has an ATmega644P I'd be willing to buy one. I've been meaning to put one on my next Digikey order but haven't recently needed to buy enough components at one time to make one economical. Surprisingly Aliexpress and eBay don't have the usual super low prices on these parts in the DIP-40 package..
I'll also be making a few purchases, but in most cases shipping takes about a month or two to South Africa from abroad.
I do not have a 644P right now. but I will be testing it extensively on my 1284P projects. I'm very happy about this development, great work! and thank you for doing what I started to do but got confused on. lol. As far as optimizations go, trimming this down in size would also be great so that I could add in some features that I need such as version checking and a couple other things. I'll look forward to that branch.
@SergeantSeven Thanks, let us know if it works or if you find some bug in some corner case. I really don't need to be thanked though, if you look at my changes to get serial working I hardly did anything, just included stk500 from 2boots and made a few changes. I'm really glad it's working though!
@per1234 That's perfect! I had a look at some local suppliers and they had 644p's and 1284p's at about the same price as Aliexpress and Ebay. Really surprising, but I guess I will get some as well.
By the way, I've started working on my own bootloader in the meantime, and found this resource very helpful: http://www.avrfreaks.net/sites/default/files/bootloader_faq.pdf
@JadinAndrews the ATmega644Ps arrived today so I'm ready to do testing whenever you are.
@per1234 That was fast.. Glad you received it, I'm still waiting for my orders. I have added a build for Atmega644P, and included the makefile I used, so you can double check the ports I used for the CS pin. I used the same port settings as for the Atmega1284P build.
Let me know if it works!
PS: UART is on port 0
Yeah, the price with shipping was $0.60 USD/ea more but I figured in this case it would be better not to deal with shipping delay of as much as 2 months sometimes. There's also that extra feeling of confidence of getting parts from a trusted supplier. I really haven't had many problems with the super cheap Chinese parts but I'm always a bit suspicious of them.
Once I corrected the BOOT_ADR value and rebuilt the bootloader I was able to upload over serial and SD card to the ATmega644P.
Thank you for pointing that out, may I ask how you get that boot adr? I used the default value from here: http://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega644p Will make the correction now.
Apart from the usual, colors not being as in the picture, or receiving the wrong part, I've also mostly had a good experience ordering from China, the worst issue I had was mislabeled RX/TX pins on some controller. Simple fix, but it took me an hour to check everything else.
You look up the boot start address for the 2048 words boot flash section, which is 0x7800, but that address is in words and we need bytes so to convert you multiply it by two bytes per word, which comes out to be 0xF000. There's also a "Boot size configuration" table in the datasheets, which lists it (also in words) in the "Boot reset address (start bootloader section)" column but I do usually use that fuse calculator because it makes it easy to get the fuse values at the same time.
I got a Chinese Pro Mini or Micro with those pins mislabeled also, definitely confused me for a while.
Thanks for clearing that up, I made that change and rebuilt for Atmega644p. The commit is before your comment, because I was working in a vm and the clock wasn't synchronized. I need to be careful of that.
I think we are almost ready to pull, I just want to get the signature issue sorted out for Atmega1284p and test a bit more.