To allow a valid date to be set the `set_time_face` cycles through the
valid days for a given month. July was incorrectly encoded as having 30
days (it has 31!)
* Sensor Watch Pro board definition
* Disable hot-plugging on SWCLK
* Add rainbow test
* Move interrupt mapping to board config
* New color definition for Pro boards in makefile
Fixes a division by zero bug caused by calling getCodeFromTimestamp
without having initialized the TOTP library with a secret first.
This was happening because the face calls totp_display on activation,
meaning the validity of the secret was not checked since this is
done in the generate function.
Now the validity of the key is determined solely by the size
of the current decoded key. A general display function checks it
and decides whether to display the code or just the error message.
The size of the current decoded key is initialized to zero
on watch face activation, ensuring fail safe operation.
Tested-by: Matheus Afonso Martins Moreira <matheus.a.m.moreira@gmail.com>
Tested-on-hardware-by: madhogs <59648482+madhogs@users.noreply.github.com>
Signed-off-by: Matheus Afonso Martins Moreira <matheus.a.m.moreira@gmail.com>
GitHub-Pull-Request: https://github.com/joeycastillo/Sensor-Watch/pull/385
Forgot to call watch_display_string on the error message.
Of course the message isn't going to be displayed.
Also, increase the buffer size to 10 characters
and output a space to the last position.
This ensures the segments are cleared.
Tested-by: Matheus Afonso Martins Moreira <matheus.a.m.moreira@gmail.com>
Tested-on-hardware-by: madhogs <59648482+madhogs@users.noreply.github.com>
Signed-off-by: Matheus Afonso Martins Moreira <matheus.a.m.moreira@gmail.com>
GitHub-Pull-Request: https://github.com/joeycastillo/Sensor-Watch/pull/385
Allocate an unlimited extent 128 byte buffer once during setup
instead of allocating and deallocating repeatedly. A static buffer
was not used because it fails to be reentrant and prevents multiple
instances of the watch face to be compiled by the user.
The advantage is the complete prevention of memory management errors,
improving the reliability of the watch. It also eliminates the overhead
of the memory allocator itself since malloc is not free.
The disadvantage is a worst case default size of 128 bytes was required,
meaning about 90 bytes will be wasted in the common case since most keys
are not that big. This can be overridden by the user via preprocessor.
The key lengths are checked on TOTP watch face initialization
and if any key is found to be too large to fit the buffer
it is turned off and the label and ERROR is displayed instead.
The base32 encoded secrets are decoded dynamically to the buffer
at the following times:
- Face enters the foreground
- User switches TOTP code
Therefore, there is still some extra runtime overhead
that can still be eliminated by code generation.
This will be addressed in future commits.
Tested-by: Matheus Afonso Martins Moreira <matheus.a.m.moreira@gmail.com>
Tested-on-hardware-by: madhogs <59648482+madhogs@users.noreply.github.com>
Signed-off-by: Matheus Afonso Martins Moreira <matheus.a.m.moreira@gmail.com>
GitHub-Pull-Request: https://github.com/joeycastillo/Sensor-Watch/pull/385
The TOTP face is working in the simulator but fails on the real hardware
when loaded with lots of codes, just like the LFS version.
This is likely caused by the recent refactoring of the TOTP face
which introduced a declarative credential interface for ease of use.
That's accomplished by decoding the secrets at runtime which increases
the RAM requirements. Users are likely hitting memory limits.
In order to mitigate this, the algorithm is changed from decoding
all of the secrets only once during initialization to on the fly
decoding of the secret for the current TOTP credential only.
This converts this face's dynamic memory usage from O(N) to O(1)
at the cost of memory management when switching faces and credentials
which could impact power consumption. Issue is confirmed fixed by
author of issue who has tested it on real hardware. Fixes#384.
Due to variable key sizes, the memory cannot be statically allocated.
Perhaps there's a maximum key size that can serve as worst case?
Also took this opportunity to restructure the code a bit.
Also added code to check for memory allocation failure.
Reported-by: madhogs <59648482+madhogs@users.noreply.github.com>
Fixed-by: Matheus Afonso Martins Moreira <matheus.a.m.moreira@gmail.com>
Tested-by: Matheus Afonso Martins Moreira <matheus.a.m.moreira@gmail.com>
Tested-on-hardware-by: madhogs <59648482+madhogs@users.noreply.github.com>
Signed-off-by: Matheus Afonso Martins Moreira <matheus.a.m.moreira@gmail.com>
GitHub-Issue: https://github.com/joeycastillo/Sensor-Watch/issues/384
