card10 issueshttps://git.flow3r.garden/groups/card10/-/issues2023-12-05T20:52:41Zhttps://git.flow3r.garden/card10/firmware/-/issues/240Update Micropython to fix GCC 12 errors2023-12-05T20:52:41ZFrançois RevolUpdate Micropython to fix GCC 12 errorsTrying to build on a recent Debian Sid with GCC 12.3.1 I get an error:
```
../py/stackctrl.c:32:32: error: storing the address of local variable ‘stack_dummy’ in ‘mp_state_ctx.thread.stack_top’ [-Werror=dangling-pointer=]
32 | MP_...Trying to build on a recent Debian Sid with GCC 12.3.1 I get an error:
```
../py/stackctrl.c:32:32: error: storing the address of local variable ‘stack_dummy’ in ‘mp_state_ctx.thread.stack_top’ [-Werror=dangling-pointer=]
32 | MP_STATE_THREAD(stack_top) = (char *)&stack_dummy;
../py/stackctrl.c:31:18: note: ‘stack_dummy’ declared here
31 | volatile int stack_dummy;
| ^~~~~~~~~~~
```
This was [fixed in Micropython upstream](https://github.com/micropython/micropython/commit/f1c6cb7725960487195daa5c5c196fd8d3563811).
Applying the patch manually on the submodule brings another error:
```
main.c:342:6: error: conflicting types for ‘mp_import_stat’ due to enum/integer mismatch; have ‘uint(const char *)’ {aka ‘unsigned int(const char *)’} [-Werror=enum-int-mismatch]
342 | uint mp_import_stat(const char *path) {
| ^~~~~~~~~~~~~~
```
… which I supposed was probably fixed too upstream.https://git.flow3r.garden/card10/meta/-/issues/1GDPR Compliance2023-08-02T22:03:08ZPhileasGDPR ComplianceThis ticket is for tracking our progress with GDPR Compliance...
Create document that explains and highlights:
* [ ] how and what kind of data we are using for what
* [ ] how we can be contacted for requests (card10 and flow3r matrix c...This ticket is for tracking our progress with GDPR Compliance...
Create document that explains and highlights:
* [ ] how and what kind of data we are using for what
* [ ] how we can be contacted for requests (card10 and flow3r matrix channels mostly)
* [ ] how you can gather your data, where we store it (only locally, temporarily, no outside services outside our hosters)
* [ ] how you can disable/forget all your data (we can)camp23PhileasPhileashttps://git.flow3r.garden/card10/firmware/-/issues/235xeyes: Rewrite using new CTX API2021-10-29T20:10:38Zschneiderxeyes: Rewrite using new CTX APIhttps://git.flow3r.garden/card10/firmware/-/issues/234Pycardium time module does not update time if time zone is changed until inte...2021-09-19T11:02:23ZschneiderPycardium time module does not update time if time zone is changed until interpreter is restartedhttps://git.flow3r.garden/card10/firmware/-/issues/233Follow-up from "Dynamically scale system clock based on load"2021-09-19T10:33:39Zrahixcard10@rahix.deFollow-up from "Dynamically scale system clock based on load"The following discussion from !481 should be addressed:
- [ ] @rahix started a [discussion](https://git.card10.badge.events.ccc.de/card10/firmware/-/merge_requests/481#note_8674):
> In this implementation, we have a kind of two-la...The following discussion from !481 should be addressed:
- [ ] @rahix started a [discussion](https://git.card10.badge.events.ccc.de/card10/firmware/-/merge_requests/481#note_8674):
> In this implementation, we have a kind of two-layer tickless idle implementation. First, the `portSUPPRESS_TICKS_AND_SLEEP()` implementation from the FreeRTOS Cortex-M4 port switches the systick to a lower speed when entering tickless idle. Then we use its hooks (`configPRE_SLEEP_PROCESSING()`) to implement our own tickless idle which kind of undoes the systick work from the FreeRTOS port.
>
> Instead, from looking at <https://www.freertos.org/low-power-tickless-rtos.html> we can just drop the FreeRTOS port code entirely and implement `portSUPPRESS_TICKS_AND_SLEEP()` directly. This reduces the amount of useless work done, allows us to theoretically sleep for as long as we want, and de-clutters the codepaths in our sleep routine.https://git.flow3r.garden/card10/firmware/-/issues/229Consider support via gadgetbridge2021-01-09T16:21:09ZschneiderConsider support via gadgetbridgehttps://gadgetbridge.org/ offers support for a few interesting use-cases on Android for a multitude of BLE devices:
https://codeberg.org/Freeyourgadget/Gadgetbridge/src/branch/master/FEATURES.md
Example support for Pebble watches:
htt...https://gadgetbridge.org/ offers support for a few interesting use-cases on Android for a multitude of BLE devices:
https://codeberg.org/Freeyourgadget/Gadgetbridge/src/branch/master/FEATURES.md
Example support for Pebble watches:
https://codeberg.org/Freeyourgadget/Gadgetbridge/src/branch/master/app/src/main/java/nodomain/freeyourgadget/gadgetbridge/devices/pebblehttps://git.flow3r.garden/card10/firmware/-/issues/224Exposure Notifications App tries to run with BLE not enabled.2021-01-06T23:41:40ZPhilip StewartExposure Notifications App tries to run with BLE not enabled.If you open the Exposure Notification App without BLE enabled the app runs and silently fails.
Can we add a a message if BLE is off?If you open the Exposure Notification App without BLE enabled the app runs and silently fails.
Can we add a a message if BLE is off?https://git.flow3r.garden/card10/firmware/-/issues/223FreeRTOS exception waking the MAX86150 task2020-12-26T15:53:54ZschneiderFreeRTOS exception waking the MAX86150 taskHappened after using the MAX86150 for a few hours:
```
2020-12-25 12:12:56.573 --- SYSTEM PANIC ---
2020-12-25 12:12:56.574 --- ---
2020-12-25 12:12:56.577 --- ---
2020-12...Happened after using the MAX86150 for a few hours:
```
2020-12-25 12:12:56.573 --- SYSTEM PANIC ---
2020-12-25 12:12:56.574 --- ---
2020-12-25 12:12:56.577 --- ---
2020-12-25 12:12:56.581 A fatal error occured:
2020-12-25 12:12:56.582 Assertion failure:
2020-12-25 12:12:56.589 "( ( &( pxTCB->xEventListItem ) )->pvContainer ) == ((void *)0)"
2020-12-25 12:12:56.593 failed in "../lib/FreeRTOS/Source/tasks.c:5001",
2020-12-25 12:12:56.597 function: vTaskNotifyGiveFromISR()
2020-12-25 12:12:56.598
2020-12-25 12:12:56.601 Firmware Version:
2020-12-25 12:12:56.602 v1.16-107-gad28755b-dirty
2020-12-25 12:12:56.605
2020-12-25 12:12:56.605 Stack Trace:
2020-12-25 12:12:56.606 0x10013e07
2020-12-25 12:12:56.609
2020-12-25 12:12:56.613 Please report this error to the card10 firmware team!
2020-12-25 12:12:56.617 -> https://git.card10.badge.events.ccc.de/card10/firmware/issues/new <-
2020-12-25 12:12:56.621 --- ====== ===== ---
```
FreeRTOS code:
```c
void vTaskNotifyGiveFromISR( TaskHandle_t xTaskToNotify, BaseType_t *pxHigherPriorityTaskWoken )
{
TCB_t * pxTCB;
uint8_t ucOriginalNotifyState;
UBaseType_t uxSavedInterruptStatus;
» configASSERT( xTaskToNotify );
» /* RTOS ports that support interrupt nesting have the concept of a
» maximum»system call (or maximum API call) interrupt priority.
» Interrupts that are»above the maximum system call priority are keep
» permanently enabled, even when the RTOS kernel is in a critical section,
» but cannot make any calls to FreeRTOS API functions. If configASSERT()
» is defined in FreeRTOSConfig.h then
» portASSERT_IF_INTERRUPT_PRIORITY_INVALID() will result in an assertion
» failure if a FreeRTOS API function is called from an interrupt that has
» been assigned a priority above the configured maximum system call
» priority. Only FreeRTOS functions that end in FromISR can be called
» from interrupts»that have been assigned a priority at or (logically)
» below the maximum system call interrupt priority. FreeRTOS maintains a
» separate interrupt safe API to ensure interrupt entry is as fast and as
» simple as possible. More information (albeit Cortex-M specific) is
» provided on the following link:
» http://www.freertos.org/RTOS-Cortex-M3-M4.html */
» portASSERT_IF_INTERRUPT_PRIORITY_INVALID();
» pxTCB = xTaskToNotify;
» uxSavedInterruptStatus = portSET_INTERRUPT_MASK_FROM_ISR();
» {
» » ucOriginalNotifyState = pxTCB->ucNotifyState;
» » pxTCB->ucNotifyState = taskNOTIFICATION_RECEIVED;
» » /* 'Giving' is equivalent to incrementing a count in a counting
» » semaphore. */
» » ( pxTCB->ulNotifiedValue )++;
» » traceTASK_NOTIFY_GIVE_FROM_ISR();
» » /* If the task is in the blocked state specifically to wait for a
» » notification then unblock it now. */
» » if( ucOriginalNotifyState == taskWAITING_NOTIFICATION )
» » {
» » » /* The task should not have been on an event list. */
» » » configASSERT( listLIST_ITEM_CONTAINER( &( pxTCB->xEventListItem ) ) == NULL );
```
Random advice from the Internet: turn on `configUSE_LIST_DATA_INTEGRITY_CHECK_BYTES` as this looks like a memory corruption:
https://www.freertos.org/FreeRTOS_Support_Forum_Archive/July_2018/freertos_xTaskNotify_assertion_50220597j.htmlhttps://git.flow3r.garden/card10/firmware/-/issues/222Shutdown handler2020-12-20T15:58:37ZPixtxaShutdown handler- Would be nice to have one or two functions, that is/are called before standby (manual/empty batt) and gets a few seconds to run.
- I don't like the long, loud vibration, for me it could be much shorter. Baybe it also would be nice to b...- Would be nice to have one or two functions, that is/are called before standby (manual/empty batt) and gets a few seconds to run.
- I don't like the long, loud vibration, for me it could be much shorter. Baybe it also would be nice to blind an led, show a custumised shutdown screen, deinit hardware on or send a power off message to something
- Together with [Save data to ram](https://git.card10.badge.events.ccc.de/card10/firmware/-/issues/221) it may also be nice to save some data from ram to flash before going to sleep.https://git.flow3r.garden/card10/firmware/-/issues/221Save data to ram2020-12-20T15:56:30ZPixtxaSave data to ram- Save data to ram, so less flash writes are needed and data is not lost when app is changed
- Would be nice to write (maybe also read) data ofer ble from smartphone (spaceapi state, bitcoin price, outside temperature, …)
- keep data whe...- Save data to ram, so less flash writes are needed and data is not lost when app is changed
- Would be nice to write (maybe also read) data ofer ble from smartphone (spaceapi state, bitcoin price, outside temperature, …)
- keep data when sleeping, so nothing gets lost on empty batteryhttps://git.flow3r.garden/card10/firmware/-/issues/220non-blocking reads from serial?2020-11-14T11:16:35ZSven Knebelnon-blocking reads from serial?I'd like to write an app that talks to a program on my PC bidirectionally (kind of as a remote and utility display: send key presses and sensor values from the card10 to the PC, allow the PC to ask the card10 to blink LEDs/update display...I'd like to write an app that talks to a program on my PC bidirectionally (kind of as a remote and utility display: send key presses and sensor values from the card10 to the PC, allow the PC to ask the card10 to blink LEDs/update display contents). The obvious way seems to be the USB-serial.
With `print()` I can send text to the PC, but I would like a non-blocking way to check for data being sent from the PC, so that in an app main loop that reads sensors, controls LED blinking, ... this is just another step that checks for commands coming in.
I'm flexible in what this specifically looks like, some ideas:
* micropython seems to have a streams abstraction that maybe could wrap the serial input and seems to support this: http://docs.micropython.org/en/latest/library/uio.html (referenced from https://firmware.card10.badge.events.ccc.de/pycardium/stdlib.html#uio)
* it could be a function specific to the "standard output" matching `print()`, e.g. a `try_input()` that returns whatever is in the input buffer without waiting or a function to check if there is anything in the input buffer.
Possible workaround: I assume with `input()` I can do a blocking read of a line of text (haven't tested this yet), but that would rely on the PC-side constantly sending newlines to not block the app in that call, which doesn't seem ideal.https://git.flow3r.garden/card10/firmware/-/issues/219GDB: Consider disabling the watchdog when attaching2020-11-04T22:32:55ZschneiderGDB: Consider disabling the watchdog when attachingThe first time you attach to a running card10, the watchdog is still running. This prevents useful debugging until the first reset which then checks the debugger flag and does not initialize the watchdog again.
We could consider to eith...The first time you attach to a running card10, the watchdog is still running. This prevents useful debugging until the first reset which then checks the debugger flag and does not initialize the watchdog again.
We could consider to either
- Disable the watchdog in firmware as soon as we see an attached debugger.
or
- Disable the watchdog from GDB when attaching.https://git.flow3r.garden/card10/firmware/-/issues/216BHI accleration sensor sometimes does not send updates2020-11-04T22:46:57ZschneiderBHI accleration sensor sometimes does not send updatesI've modified menu.py and g-watch/__init_.py a bit:
- Reduce timeout in menu.py to 3 seconds
- Exit g-watch once a sample from the accelerometer comes in
This puts the card10 into a loop where it repeatedly starts the g-watch. After a...I've modified menu.py and g-watch/__init_.py a bit:
- Reduce timeout in menu.py to 3 seconds
- Exit g-watch once a sample from the accelerometer comes in
This puts the card10 into a loop where it repeatedly starts the g-watch. After a few hours it stops doing so because the g-watch does not receive new sensor data anymore.
Backtrace:
```
(gdb) task_backtrace bhi160_task_id
FPU is off
#0 0x10023f30 in vPortExitCritical () at ../lib/./FreeRTOS/./Source/portable/GCC/ARM_CM4F/portmacro.h:229
#1 0x100234de in ulTaskNotifyTake (xClearCountOnExit=536920208, xClearCountOnExit@entry=1, xTicksToWait=536920196, xTicksToWait@entry=2000) at ../lib/FreeRTOS/Source/tasks.c:4599
#2 0x100114bc in vBhi160Task (pvParameters=<optimized out>) at ../epicardium/modules/bhi.c:530
#3 0x10023e20 in ?? () at ../lib/FreeRTOS/Source/portable/GCC/ARM_CM4F/port.c:703
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
```https://git.flow3r.garden/card10/firmware/-/issues/214SpO2: Determine calibration factors for MAX861502023-04-17T09:53:13ZschneiderSpO2: Determine calibration factors for MAX86150!414 introduced a demo app for SpO2 estimation using the MAX86150. It's results for SpO2 are not reliable though.
https://git.card10.badge.events.ccc.de/card10/firmware/-/issues/196 discusses details of how SpO2 is estimated using these...!414 introduced a demo app for SpO2 estimation using the MAX86150. It's results for SpO2 are not reliable though.
https://git.card10.badge.events.ccc.de/card10/firmware/-/issues/196 discusses details of how SpO2 is estimated using these algorithms. We currently implement an algorithm from Maxim based on the code for their RD117 reference design. What we are missing at the moment are the calibration values for the MAX86150 to at least get somehow reasonable results.
![IMG_20200426_015712](/uploads/b3864c60254a484ea49d2dcf76b3f9fb/IMG_20200426_015712.jpg)
The estimated SpO2 values are generally too high. Heart rate seems to work if the finger is pressed on "correctly". I can imagine that it might be necessary to design a (printed) spacer around the sensor to have repeatable results.https://git.flow3r.garden/card10/firmware/-/issues/213Follow-up from "Pycardium Improvements"2021-11-16T22:40:21Zrahixcard10@rahix.deFollow-up from "Pycardium Improvements"The following discussion from !417 should be addressed:
- [ ] @schneider started a [discussion](https://git.card10.badge.events.ccc.de/card10/firmware/-/merge_requests/417#note_7950): (+1 comment)
> When pressing CTRL+C and then C...The following discussion from !417 should be addressed:
- [ ] @schneider started a [discussion](https://git.card10.badge.events.ccc.de/card10/firmware/-/merge_requests/417#note_7950): (+1 comment)
> When pressing CTRL+C and then CTRL+D one now ends up in the menu. I think before the main app was started again. Is that intended?
>
> I'm wondering if we can maybe make use of this: Allow the menu to react to cursor keys or present a small menu on the console as well. Would eliminate the need to press buttons during development.v1.19https://git.flow3r.garden/card10/firmware/-/issues/205Periodically re-seed CSPRNG2020-09-19T22:01:26ZschneiderPeriodically re-seed CSPRNGThe CSPRNG introduced with !399 is only seeded once during boot. It should be re-seeded periodically if possible.The CSPRNG introduced with !399 is only seeded once during boot. It should be re-seeded periodically if possible.https://git.flow3r.garden/card10/firmware/-/issues/202Default Apps2021-11-16T22:40:15ZmalteDefault AppsHi,
I feel like the selection of preloaded apps does not resemble the landscape of *available* card10 apps anymore, and we deserve something like [Niklas Roy](https://git.card10.badge.events.ccc.de/royrobotiks)'s [Control Center](https:...Hi,
I feel like the selection of preloaded apps does not resemble the landscape of *available* card10 apps anymore, and we deserve something like [Niklas Roy](https://git.card10.badge.events.ccc.de/royrobotiks)'s [Control Center](https://badge.team/projects/control_center) as the default app, and apps like CryptKiddie's [Colorful Flashlight](https://badge.team/projects/colorfulflashlight) in the selection of preloaded apps.
On the other side, and maybe I'm missing some points here, I don't really know what to do with apps like LSD Nickname, Personal State, Adventure Time (like, I really like the thought, but the whimsicality of the naming should be reflected in the app itself?), Scope (as long as it is not extended to the functionality teasered in the metadata.json) and, if Control Center (or [Control Centre](https://codeberg.org/mdik/control_centre)😅) would be preloaded, the Analog and Digital Clocks wouldn't be *too* useful as well.
Like, all apps and experiments are awesome! But do they help people who turn on the card10 for the first time to understand all its capabilities, or are they more confusing?
Thank you for your consideration, and sincerely,
Maltev1.19https://git.flow3r.garden/card10/firmware/-/issues/201BLE: Add support for Battery Service and Apple Notification Center Service (A...2020-10-17T13:22:00ZschneiderBLE: Add support for Battery Service and Apple Notification Center Service (ANCS)Adding support for these services (which run on the phone!) would make the card10 usable without a dedicated app on Apple devices.Adding support for these services (which run on the phone!) would make the card10 usable without a dedicated app on Apple devices.https://git.flow3r.garden/card10/firmware/-/issues/200Revisit BLE connection parameters2020-10-17T13:23:52ZschneiderRevisit BLE connection parametersRight now they are chosen based on a mix of defaults from the SDK examples and later optimization.
Apple actually has a small guide for them: https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf (Section 35).
This is...Right now they are chosen based on a mix of defaults from the SDK examples and later optimization.
Apple actually has a small guide for them: https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf (Section 35).
This issue is concerned with connection interval, latency, MTU, etc.https://git.flow3r.garden/card10/firmware/-/issues/198Add proper hardfaults handlers2021-01-16T11:35:00Zrahixcard10@rahix.deAdd proper hardfaults handlersRight now, we don't deal well with hardfaults:
- _Epicardium_ just becomes unresponsive and at some point the watchdog kicks in.
- _Pycardium_ `epic_exit()`s with ret-code 255 which will at least be logged to the console but no user fee...Right now, we don't deal well with hardfaults:
- _Epicardium_ just becomes unresponsive and at some point the watchdog kicks in.
- _Pycardium_ `epic_exit()`s with ret-code 255 which will at least be logged to the console but no user feed-back nor a stacktrace either.
- _l0dables_ don't have any handling by default.
MR !79 has a basic implementation of a HardFault handler which could be repurposed for this in tandem with the new `panic()` functionality.rahixcard10@rahix.derahixcard10@rahix.de