MicroCore icon indicating copy to clipboard operation
MicroCore copied to clipboard

The core doesn't use it's own copy of avrdude.conf and platform.txt when uploading code

Open MCUdude opened this issue 9 years ago • 8 comments

The introduction of the platform.txt gave us lots of under the hood settings to play with. Sadly the documentation isn't the best..

I was thinking about implementing an additional flag in the boards.txt file; {programmer.speed}. If a slow internal clock is selected like 128 kHz, the programmer.speed flag will hold "-B32". if the speed is 9.6 MHz it will hold "-B1". By doing this I can get rid of the "slow programmers" found in the programmers.txt file. Sounds great?

Of course this doesn't go without problems. When the user is uploading the code, the IDE generates an avrdude command before executing it. I discovered there was a typo in the boards.txt file, so the IDE was using it's own copy of avrdude.conf and platform.txt rules when uploading code. I did some changes to fix this, but I can't figure out how the IDE will get the programmers name right. Look at this error generated by avrdude:

/Users/Hans/Library/Arduino15/packages/arduino/tools/avrdude/6.0.1-arduino5/bin/avrdude -C/Users/Hans/Documents/Arduino/hardware/MicroCore/avr/avrdude.conf -v -pattiny13 -c{protocol} -B1 -Uhfuse:w:0xfb:m -Ulfuse:w:0x3A:m -D -Uflash:w:/var/folders/_p/s3kykxss20bbhfmqcg0ctrp80000gn/T/buildfbb3364bdd983a856e968c32e574d2fe.tmp/Blink.ino.hex:i

As you can see it's not able to figure out what protocol it's using (in my case it's the usbtiny), but when burning the fuses, it's able to figure it out. Here's a copy of the current platform.txt avrdude commands settings:

tools.avrdude.upload.params.verbose=-v
tools.avrdude.upload.params.quiet=-q -q
tools.avrdude.upload.pattern="{cmd.path}" "-C{config.path}" {upload.verbose} -p{build.mcu} -c{protocol} {programmer.speed}  -Uhfuse:w:{bootloader.high_fuses}:m -Ulfuse:w:{bootloader.low_fuses}:m -D "-Uflash:w:{build.path}/{build.project_name}.hex:i"

tools.avrdude.program.params.verbose=-v
tools.avrdude.program.params.quiet=-q -q
tools.avrdude.program.pattern="{cmd.path}" "-C{config.path}" {program.verbose} -p{build.mcu} -c{protocol} {programmer.speed} {program.extra_params}  -Uhfuse:w:{bootloader.high_fuses}:m -Ulfuse:w:{bootloader.low_fuses}:m "-Uflash:w:{build.path}/{build.project_name}.hex:i"

tools.avrdude.erase.params.verbose=-v
tools.avrdude.erase.params.quiet=-q -q
tools.avrdude.erase.pattern="{cmd.path}" "-C{config.path}" -v -p{build.mcu} -c{protocol} -B32 {program.extra_params} -e -Uhfuse:w:{bootloader.high_fuses}:m -Ulfuse:w:{bootloader.low_fuses}:m

tools.avrdude.bootloader.params.verbose=-v
tools.avrdude.bootloader.params.quiet=-q -q
tools.avrdude.bootloader.pattern="{cmd.path}" "-C{config.path}" {bootloader.verbose} -p{build.mcu} -c{protocol} -B32

How can this be solved without having to use the "upload.protocol" from boards.txt? Do you have an idea @per1234?

MCUdude avatar Sep 23 '16 17:09 MCUdude

Here's the current version I'm working on 👍 MicroCore.zip

MCUdude avatar Sep 23 '16 19:09 MCUdude

Try it with the line:

attiny13.upload.protocol=arduino

in boards.txt commented out.

per1234 avatar Sep 23 '16 23:09 per1234

When commenting out that line, the IDE automatically choses the default command instead:

/Users/Hans/Library/Arduino15/packages/arduino/tools/avrdude/6.0.1-arduino5/bin/avrdude -C/Users/Hans/Library/Arduino15/packages/arduino/tools/avrdude/6.0.1-arduino5/etc/avrdude.conf -v -pattiny13 -cusbtiny -Uflash:w:/var/folders/_p/s3kykxss20bbhfmqcg0ctrp80000gn/T/buildfbb3364bdd983a856e968c32e574d2fe.tmp/Blink.ino.hex:i 

Any idea? Theoretically, is this even possible?

MCUdude avatar Sep 24 '16 16:09 MCUdude

Commenting out that line makes Upload do Upload Using Programmer but then we run into the old problem of platform.txt associated with the selected programmer is used for Upload Using Programmer. With the line uncommented it's doing a standard Upload which doesn't seem to expose the properties from programmers.txt, thus the -c{protocol} issue. You could solve this issue by having MicroCore specific programmer options as you've done with MightyCore and removing the attiny13.upload.protocol from boards.txt. When the MicroCore programmer is selected, it will cause the MicroCore platform.txt to be used. Of course this isn't ideal but it's a bit better than the slow programmer entries in my opinion as one programmer selection will work for any MicroCore board configuration.

Other than the increased complication of the user needing to select the correct programmer, the other downside to the custom programmers workaround to the "platform.txt associated with the selected programmer is used for Upload Using Programmer" issue is the extra clutter it adds to the Tools > Programmer menu. If the user has MightyCore, ATTinyCore, and MicroCore installed it gets ridiculously long. A possible solution to this issue would be to install a single programmers package that supports all the cores that require modifications to the platform.txt file used for Upload Using Programmer, such as a custom avrdude.conf file or MicroCore's programmer.speed property. This will generate the correct avrdude.conf path as long as all the cores that use that programmer package keep their avrdude.conf in a consistent location because tools.avrdude.config.path={runtime.platform.path}/avrdude.conf points to the core folder. You can specify a default value in platform.txt for 'programmer.speed' or any other custom properties that any of the cores using the programmer package require so that the cores only need to specify those property if they need a value different from the default. The downside to this idea is that it requires the user to install the core and the programmer package but the programmer package can be installed via Boards Manager. The programmer package could be included in each core's standard Boards Manager JSON file, though I'd have to investigate any possible issues that might be caused by multiple JSON files referring to the same package might cause. If this is something you're interested in considering I can put together a test implementation. My hope would be to get as many possible cores on board for using this package. ATTinyCore is the obvious other but I also need something like this for the avr_boot project(currently I just instruct the user to install MightyCore and use the MightyCore programmers) and I think https://github.com/thomasonw/ATmegaxxM1-C1 could also use this, likely there are more. I'd be happy to work on this at any level that the rest of those involved want me to, whether that's running the whole show, just doing the Boards Manager stuff, or simply providing the seed of the idea as I've done here.

per1234 avatar Sep 24 '16 18:09 per1234

You could solve this issue by having MicroCore specific programmer options as you've done with MightyCore and removing the attiny13.upload.protocol from boards.txt

That's an option, but that's still forcing me to have an additional set of programmers. Having a copy of the "slow" programmers may be useful for other cores with slow clocks.

A possible solution to this issue would be to install a single programmers package that supports all the cores that require modifications to the platform.txt file used for Upload Using Programmer, such as a custom avrdude.conf file or MicroCore's programmer.speed property.

It's also an option, but I don't know if I like the idea on depending on another package in order to get the core working properly. It's also a lot of users that prefers to install the core manually.

To sum it up; using the built in attiny13.upload.protocol=arduino works quite OK. It's not perfect, but you're able to use (almost) any programmer in the programmers list. If someone's using 128kHz as the clock frequency, they'll just have to select a "slow" programmer. Personally I think the way it is right now is better than having to share programmers with other core, and add another dependency. What do you think? My goal is to keep my cores as "simple" as possible, while still being powerful under the hood. As a start I actually think a great feature to the IDE would be to only display the current "core programmers" in the Programmers list. If there weren't any, It will just display default ones. Shouldn't be too hard (for java programmers), right? I think this would clean up the Programmers mess a lot.

MCUdude avatar Sep 24 '16 21:09 MCUdude

Having a copy of the "slow" programmers may be useful for other cores with slow clocks.

That feature would be available either way, the core's boards.txt would just need to define the programmer.speed property. However, I think having a programmers package dependency is better than having a core dependency(unless other core files are needed) because a core dependency will add unnecessary boards to the Tools > Board menu

It's also a lot of users that prefers to install the core manually.

They would just need to install the programmers package manually, it's the same process. As I said, adding an extra step to the installation process is certainly a downside of the idea.

I think the way it is right now is better than having to share programmers with other core

A shared programmers package is not an essential part of the solution, it just provides a way to avoid users having a 2 page list of variations of the same programmers if they have multiple cores installed. I don't know if that advantage outweighs the disadvantage of a more complex installation but I came across the idea by chance while working on avr_boot and thought I should mention it to you.

a great feature to the IDE would be to only display the current "core programmers" in the Programmers list.

I don't like it because that means you can't install 3rd party programmers packages. I realize this isn't a common usage of the Arduino IDE's 3rd party hardware system but I have two packages I made that would be broken.

per1234 avatar Sep 24 '16 22:09 per1234

I'll keep this issue open, as a reminder that this issue isn't solved yet. It works OK as is it, but it isn't perfect

MCUdude avatar Oct 01 '16 21:10 MCUdude

这个核心没有boot的,才1K的空间是无法提供boot的,所以那个boot下载其实只是配置熔丝而已。

bh8fje avatar Dec 02 '18 03:12 bh8fje