platformio / platform-atmelavr

Atmel AVR: development platform for PlatformIO
https://registry.platformio.org/platforms/platformio/atmelavr
Apache License 2.0
136 stars 104 forks source link

Update and improve fuse calculation script #206

Closed MCUdude closed 3 years ago

MCUdude commented 3 years ago

Fix an issue where the lfuse couldn't be calculated for ATmega64 and ATmega128. Make use of the JTAGEN fuse, so that JTAG can be enabled on targets that supports it. Make use of the CKOUT fuse, so the internal clock can be outputted on devices that supports it.

MCUdude commented 3 years ago

The new parameters

board_hardware.jtagen = yes
board_hardware.ckout = yes

should probably be documented though. Note that JTAG and CKOUT are disabled by default, just like it always has.

MCUdude commented 3 years ago

To help out with the documentation of this:

MightyCore targets Has JTAG Supports CKOUT Supports CFD
ATmega1284P
ATmega1284
ATmega644P/PA
ATmega644/A
ATmega324PB
ATmega324PA
ATmega324P
ATmega324A
ATmega164P/PA
ATmega164A
ATmega32
ATmega16
ATmega8535
MajorCore targets Has JTAG Supports CKOUT Supports CFD
ATmega162
ATmega8515
MicroCore targets Has JTAG Supports CKOUT Supports CFD
ATtiny13A
ATtiny13
MiniCore targets Has JTAG Supports CKOUT Supports CFD
ATmega328PB
ATmega328P
ATmega328
ATmega168PB
ATmega168P/PA
ATmega168/A
ATmega88PB
ATmega88P/PA
ATmega88/A
ATmega48PB
ATmega48P/PA
ATmega48/A
ATmega8/A
MegaCore targets Has JTAG Supports CKOUT Supports CFD
ATmega2561
ATmega2560
ATmega1281
ATmega1280
ATmega640
ATmega128/A
ATmega64/A
AT90CAN128
AT90CAN64
AT90CAN32
MCUdude commented 3 years ago

Commit 264859f adds a new oscillator option. You can now use board_hardware.oscillator = external_clock, for application where the chip's clock input is actively driven by an external clock source. This will free up an IO pin on chips that share the XTAL2 pin with IO, like the ATmega328P.

valeros commented 3 years ago

Hi @MCUdude ! Sorry for getting back to you so late. The PR looks great! Before merging could you please shed some light on that new fields jtagen and ckout in the hardware section. As I understand it, that new configs are disabled by default (probably that two different values no, N/A shouldn't be declared at all since they really don't make any difference).

What do you think, if users should explicitly enable them in platformio.ini file, just like you described in the first comment:

board_hardware.jtagen = yes
board_hardware.ckout = yes

Then, in the fuses.py script we can do something like this:

jtagen = board.get("hardware.jtagen", "no").lower()
ckout = board.get("hardware.ckout", "no").lower()
MCUdude commented 3 years ago

Sorry for getting back to you so late.

No worries! I do understand that you guys are quite busy, and this is definitely not a top priority thing.

Before merging could you please shed some light on that new fields jtagen and ckout in the hardware section

jtagen is only for those who either want or have to upload using JTAG. I'm not sure PlatformIO supports AVR debugging yet? I think it would be rarely used, but it's still nice to have for those niches applications. The reason why N/A was introduced was because it doesn't make sense to even mention jtag on targets that don't have it.

The ckout setting will turn on the system clock output on one of the pins. I think it's PB1 on most AVRs. Again, for niche applications, but can be very useful.

Then, in the fuses.py script we can do something like this:

jtagen = board.get("hardware.jtagen", "no").lower()
ckout = board.get("hardware.ckout", "no").lower()

Does this mean that we don't need to specify anything in the manifest files at all to get this PR to work? If so, that's great!

There is one feature I'd like to add as well that are not currently in this PR. The ATmega48PB/88PB/168PB/ 328PB and ATmega324PB have something called clock failure detection. If the external clock for some reason fails (trust me, this has happened to me on production boards I've had manufactured), it can switch to the internal clock automatically. This has to be enabled in the fusebits though. Is it OK if I add it to this PR?

valeros commented 3 years ago

Thanks for the info!

Does this mean that we don't need to specify anything in the manifest files at all to get this PR to work? If so, that's great!

Yes, that's correct. Even if there is no hardware section defined, the default value will be used. So you can safely delete that values from the manifests.

This has to be enabled in the fusebits though. Is it OK if I add it to this PR?

Sure thing, feel free to add any improvements you want.

MCUdude commented 3 years ago

Does this mean that we don't need to specify anything in the manifest files at all to get this PR to work? If so, that's great! Yes, that's correct. Even if there is no hardware section defined, the default value will be used. So you can safely delete that values from the manifests.

Awesome! I'll see if I can modify the commit so the files stay unchanged without cluttering up the commit history. You'll hear from me soon 🙂

MCUdude commented 3 years ago

@valeros after some git wrestling I've removed the changes done to the manifest files. I've also added support for CFD (only available on ATmega324PB and 328PB).

BTW I've edited the post where I've listed which features are supported on what microcontroller.

There's one thing that I'd like to change, but don't know how. If you look at the target configuration print message, it now looks like this:

TARGET CONFIGURATION:
---------------------
Target = atmega1284p
Clock speed = 16000000L
Oscillator = external
BOD level = 2.7v
UART port = uart0
Save EEPROM = yes
Clock output = no
JTAG enable = no
Clock failure detection = no

However, it doesn't make sense to print the Clock failure detection part, because it's not supported by this particular hardware. @valeros Is there a way to mute/not print an option that's not supported by the target, to prevent confusion/misinformation about hardware features?

valeros commented 3 years ago

Is there a way to mute/not print an option that's not supported by the target, to prevent confusion/misinformation about hardware features?

I see here two options:

Overall, looks good to me, many thanks! Could you please also update the docs here https://github.com/platformio/platformio-docs/blob/develop/platforms/atmelavr_extra.rst#id17 and submit a PR in that repository?

MCUdude commented 3 years ago

@valeros I've now improved the print output of this fuses script. I've also updated the documentation and submitted a PR for this 🙂

valeros commented 3 years ago

Many thanks!