The current (Rev A) design uses an STM32L052K8U MCU, which has 64k of flash, 8k of RAM, and no built-in bootloaders that are of use for #4. The firmware is also running out of headroom, bumping right up against the limit in size. There are still tricks that can be used to crunch it down a bit more, but things are getting uncomfortably close.
Switching to a STM32L072KBx (128k Flash, 20k RAM) or STM32L072KZx (192k Flash, 20k RAM) would have a number of advantages to the project:
Inclusion of a USB DFU bootloader, which would allow end-users to more easily install firmware updates to the device
Less constraints on firmware size, since most of the overhead is framework code that doesn't grow much with additional functionality
The ability to use FreeRTOS. This would make it possible to separate device functionality into separate tasks (sensor polling, keypad management, USB interface) and make overall operation smoother and cleaner.
The downside is that some design changes would be necessary. The pinout is slightly different, and the GPIO pins (for buttons) would move a bit. Also, there might need to be an additional hidden button to pull BOOT0 high to enable the DFU bootloader.
The current (Rev A) design uses an STM32L052K8U MCU, which has 64k of flash, 8k of RAM, and no built-in bootloaders that are of use for #4. The firmware is also running out of headroom, bumping right up against the limit in size. There are still tricks that can be used to crunch it down a bit more, but things are getting uncomfortably close.
Switching to a STM32L072KBx (128k Flash, 20k RAM) or STM32L072KZx (192k Flash, 20k RAM) would have a number of advantages to the project:
The downside is that some design changes would be necessary. The pinout is slightly different, and the GPIO pins (for buttons) would move a bit. Also, there might need to be an additional hidden button to pull BOOT0 high to enable the DFU bootloader.