Correcting outdated comment and some tidying

This commit is contained in:
Nav
2024-03-02 02:00:43 +00:00
parent 4aa8ed30de
commit 1de011f948
2 changed files with 8 additions and 10 deletions

View File

@@ -747,8 +747,12 @@ namespace Targets::Microchip::Avr::Avr8Bit
) const {
return static_cast<unsigned char>(
this->fuseEnableStrategy == FuseEnableStrategy::SET
? enabled ? (fuseByteValue | descriptor.bitMask) : fuseByteValue & ~(descriptor.bitMask)
: enabled ? fuseByteValue & ~(descriptor.bitMask) : (fuseByteValue | descriptor.bitMask)
? enabled
? (fuseByteValue | descriptor.bitMask)
: fuseByteValue & ~(descriptor.bitMask)
: enabled
? fuseByteValue & ~(descriptor.bitMask)
: (fuseByteValue | descriptor.bitMask)
);
}

View File

@@ -72,14 +72,8 @@ namespace Targets::Microchip::Avr::Avr8Bit
* With JTAG and UPDI targets, we have to perform a full chip erase when updating the target's flash memory.
* This means the user will lose their EEPROM data whenever they wish to upload any program changes via Bloom.
*
* The preserveEeprom flag determines if Bloom should preserve the target's EEPROM when performing a full chip
* erase. If enabled, we'll take a backup of the target's EEPROM just before performing the chip erase, then
* restore the backup afterwards.
*
* The backup-then-restore operation can take some time to complete. This can be a source of frustration for
* users who don't care about their EEPROM data being wiped, as it can add minutes to the time it takes to
* upload program changes. This is why the function is optional - setting this flag to false will speed up
* uploads.
* The preserveEeprom flag determines if Bloom should preserve the target's EEPROM by setting the EESAVE fuse
* bit before performing the chip erase.
*
* This parameter is optional, and the function is enabled by default.
*/