Closed MCUdude closed 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.
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 | ✅ | ✅ | ❌ |
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.
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()
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?
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.
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 🙂
@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?
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:
yes
...
if target in ("atmega328pb", "atmega324pb"):
print("Clock failure detection = %s\n" % cfd)
...
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?
@valeros I've now improved the print output of this fuses script. I've also updated the documentation and submitted a PR for this 🙂
Many thanks!
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.