firmware merge requestshttps://git.flow3r.garden/card10/firmware/-/merge_requests2021-09-19T15:58:00Zhttps://git.flow3r.garden/card10/firmware/-/merge_requests/486Update to microptyhon v1.172021-09-19T15:58:00ZschneiderUpdate to microptyhon v1.17Closes #232Closes #232https://git.flow3r.garden/card10/firmware/-/merge_requests/485Update CHANGELOG2021-09-19T16:04:23Zrahixcard10@rahix.deUpdate CHANGELOG@schneider, did I miss anything?@schneider, did I miss anything?schneiderschneiderhttps://git.flow3r.garden/card10/firmware/-/merge_requests/484Fix epic_sleep() calls delaying load of new app2021-09-19T15:35:34Zrahixcard10@rahix.deFix epic_sleep() calls delaying load of new appWhen core 1 repeatedly calls `epic_sleep()`, this could delay an
epic_load() from core 0 because the reset interrupt can only be
delivered after such a call completed.
To work around this, add calls into `do_load()` to notify the dispat...When core 1 repeatedly calls `epic_sleep()`, this could delay an
epic_load() from core 0 because the reset interrupt can only be
delivered after such a call completed.
To work around this, add calls into `do_load()` to notify the dispatcher
task that it should return early from calls like `epic_sleep()`. This
gets a bit tricky because the dispatcher task also uses
`ulTaskNotifyTake()` to wake up when new API calls arrive. To make sure
we still break out of `epic_sleep()`, we need to call
`xTaskNotifyGive()` twice in the wait loop.schneiderschneiderhttps://git.flow3r.garden/card10/firmware/-/merge_requests/483card10.cfg: Add config option for flashlight LED2021-09-19T14:47:16Zrahixcard10@rahix.decard10.cfg: Add config option for flashlight LEDAdditionally, add `--open` flag to `./Documentation/build-docs.sh` and fix docs builds for Sphinx 4.Additionally, add `--open` flag to `./Documentation/build-docs.sh` and fix docs builds for Sphinx 4.schneiderschneiderhttps://git.flow3r.garden/card10/firmware/-/merge_requests/482ci: Expose artifacts for debug builds2021-09-19T09:57:42Zrahixcard10@rahix.deci: Expose artifacts for debug buildsAs requested.As requested.https://git.flow3r.garden/card10/firmware/-/merge_requests/481Dynamically scale system clock based on load2021-09-19T11:32:41ZschneiderDynamically scale system clock based on loadRequires at least !478 to be merged first.
This dynamically adapts the system clock speed based on the following parameters:
- Is the second core currently waiting for epicardium to finish an API call?
- Is USB connected?
- Do we hav...Requires at least !478 to be merged first.
This dynamically adapts the system clock speed based on the following parameters:
- Is the second core currently waiting for epicardium to finish an API call?
- Is USB connected?
- Do we have enough time to reasonably go to sleep?
It tries to keep time on epicardium roughly in line with the wall clock. Slight drift is expected though.
@rahix I'm wondering if I should add a call to the epicardium API which explicitly turns on this behaviour. The current downside is that l0dables will experience a significant drift in their systick time.
Together with the other changes we achieve the following consumption (BLE off):
- Simple `time.sleep(1)` loop with display off: 2.29 mA (before: 6.13 mA)
- G-Watch: 3.99 mA (before 7.7 mA)
This equates to 90% - 160% longer battery life.
With BLE active, the consumption increases by 0.92 mA (no connection) / 1.43 mA (active connection). In this case we are looking at 68% to 100% longer battery life (assuming that the extra BLE consumption is the same in current master).https://git.flow3r.garden/card10/firmware/-/merge_requests/480Pycardium: Use sleep API call while sleeping2021-09-17T18:15:03ZschneiderPycardium: Use sleep API call while sleepingBased on !475 which should be merged first.
This allows pycardium to signal epicardium that it is ready to sleep and that the system can reduce power consumption by going to a light sleep mode.
At the moment it increases interrupt late...Based on !475 which should be merged first.
This allows pycardium to signal epicardium that it is ready to sleep and that the system can reduce power consumption by going to a light sleep mode.
At the moment it increases interrupt latency on pycardium side from 1 ms to around 100 ms. I'll try in a next step to reduce that and break the sleep on epicardium side earlier if that happens. Not sure if this has any noticeable impact on behaviour though.rahixcard10@rahix.derahixcard10@rahix.dehttps://git.flow3r.garden/card10/firmware/-/merge_requests/479feat(personal-state): Convert personal state to use the work queue2021-09-15T19:11:38Zschneiderfeat(personal-state): Convert personal state to use the work queueThis reduces the power consumption of the system by around .1 mA when
the personal state is not active (and dynamic frequency scaling of the
system clock is active)This reduces the power consumption of the system by around .1 mA when
the personal state is not active (and dynamic frequency scaling of the
system clock is active)rahixcard10@rahix.derahixcard10@rahix.dehttps://git.flow3r.garden/card10/firmware/-/merge_requests/478change(backlight): Keep PWM stable when changing PCLK2021-09-19T09:22:33Zschneiderchange(backlight): Keep PWM stable when changing PCLKThis is in preparation to support switching the system clock on the fly.
Changing the prescaler of the timer was found to be the easiest option and
appears to be glitch free.
Timer frequency is now held close to a value which can be a...This is in preparation to support switching the system clock on the fly.
Changing the prescaler of the timer was found to be the easiest option and
appears to be glitch free.
Timer frequency is now held close to a value which can be achieved both
with a 48 MHz PCLK (96 MHz system clock) and a 7.5 MHz PCLK (15 MHz
system clock).
If even lower PCLKs should be supported, the frequency of the timer has
to be changed as well.rahixcard10@rahix.derahixcard10@rahix.dehttps://git.flow3r.garden/card10/firmware/-/merge_requests/477change(uart): Use low power HIRC8 for uart clock2021-08-17T09:20:05Zschneiderchange(uart): Use low power HIRC8 for uart clockThis is in preparation of changing the system clock dynamically. The UART needs a stable clock and AFAIK this clock is specifically designed to work well with the UART. It can stays constant during (light) sleep phases.This is in preparation of changing the system clock dynamically. The UART needs a stable clock and AFAIK this clock is specifically designed to work well with the UART. It can stays constant during (light) sleep phases.rahixcard10@rahix.derahixcard10@rahix.dehttps://git.flow3r.garden/card10/firmware/-/merge_requests/475change(pycardium): Switch systick to 32 kHz clock source2021-09-16T18:05:10Zschneiderchange(pycardium): Switch systick to 32 kHz clock sourceThis is in perparation of epicardium being allowed to change the system
clock source. By using the alternate clock source for the systick, we
can keep accurate (tick) time on pycardium.This is in perparation of epicardium being allowed to change the system
clock source. By using the alternate clock source for the systick, we
can keep accurate (tick) time on pycardium.rahixcard10@rahix.derahixcard10@rahix.dehttps://git.flow3r.garden/card10/firmware/-/merge_requests/474Disable core 1 interrupts during API calls2021-07-25T22:02:27Zrahixcard10@rahix.deDisable core 1 interrupts during API calls@schneider, this is for you :) I _think_ I've managed to figure out how to solve the lockup you observed in a way that's both compatible with the old (non-masking API calls) and new (irq-masking API calls) schemes. Please take a close ...@schneider, this is for you :) I _think_ I've managed to figure out how to solve the lockup you observed in a way that's both compatible with the old (non-masking API calls) and new (irq-masking API calls) schemes. Please take a close look though, I'm a bit scared that I might have again missed something here...
Commit 7fb481780ac0 ("feat(lifecycle): Allow core 1 to disable interrupts during API calls") is the important part. The commit message explains the details:
> When interrupts are disabled during API calls on core 1, we can only trigger a core 1 reset when there is no API call ongoing. This means that the lifecycle machinery needs to allow any running API calls to complete before it has a chance to see its reset interrupt delivered.
>
> This is complicated because we cannot synchronize on core 1 triggering an API call - the best we can do is stop the dispatcher, check whether our reset interrupt was delivered, and if not, give it another chance to process an API call.
>
> Additionally, "give it another chance to process an API call" means that the IDLE task must run, because this is currently a prerequisite to scheduling the dispatcher (see [API call mechanism](https://firmware.card10.badge.events.ccc.de/epicardium/overview.html#internals)). The only way to facilitate this is with a sleep that is long enough that it will eventually let core 0 go idle. It seems that an 8 tick delay does the job quite fine.
>
> Thus, implement a busy loop which provides the above requirements and with that makes Epicardium prepared for payloads which perform API calls with interrupts disabled.
Ontop, I then added the critical section in the API caller code in commit 927411099163 ("feat(api-caller): Hard-disable all IRQs during API calls"). Note that I am currently disabling absolutely everything here - we might want to revise this in the future to allow some kind of "NMI execution stage" which can still run but then cannot call API calls. Doing this would break the sleep-usecase again, though...schneiderschneiderhttps://git.flow3r.garden/card10/firmware/-/merge_requests/473CTX Rendering2021-09-19T14:45:58Zrahixcard10@rahix.deCTX RenderingSo, I decided to push the current state of my ctx integration work here to have a place to
track the progress where other's can also provide feedback instead of just me
hacking away on my own.
I tried to keep the changeset as clean as p...So, I decided to push the current state of my ctx integration work here to have a place to
track the progress where other's can also provide feedback instead of just me
hacking away on my own.
I tried to keep the changeset as clean as possible so it should be easy to
follow along by looking at the individual commits.
Once again, huge thanks to pippin for the [_ctx_ library](https://ctx.graphics/)!
## Current Status
Right now, basic integration on _Epicardium_ side is done. This means that all
rendering in Epicardium is now done via _ctx_, ~~with one notable exception being
the `epic_disp_blit()` function~~ (this is now resolved!).
So far, no Epicardium API for _ctx_ exists yet, instead all the existing drawing
API calls were updated to use _ctx_ under the hood. This provides nice insight
into where visual regressions are happening - Mostly it is looking pretty good
already, though :) Here's a few pictures (left is _ctx_ but I hope that's obvious):
<details><summary><b>Click to expand comparison pictures</b></summary>
![splash](/uploads/007b51ab80a9b9be28e36da63fb9759c/splash.png)
![menu](/uploads/b0440cdc7f5a6a9e5c4b97e790e0ede5/menu.png)
![text](/uploads/5fdf9dc2085cb4b258dbd4c9632ef5cf/text.png)
![mm1](/uploads/a08c770c019f6ec5e9e945e1ad989890/mm1.png)
![mm2](/uploads/562f2bd9f12c88d139f8e00cfe17b601/mm2.png)
</details>
The next step will be to refactor the `epic_disp_blit()` function so it does not
depend on _gfx_ anymore and once that's done, I'll start working on the
Pycardium side and Epicardium API for _ctx_.
## Known Bugs/Regressions
Here is a list of visual artifacts I came across so far. This is mostly for
reference - we should evaluate whether it is worth fixing them or whether we
accept that some legacy code will look slightly off.
- [x] I am unsure what exactly is going on but it seems that pixels set by
`ctx_set_pixel_u8()` are slightly less bright than e.g. those from
a rectangle. For example, notice the few manually written pixels on the end
of each 7-segment segment:
<details><summary>Click to show example picture</summary>
![pixel-color](/uploads/ef9fe6a756c034c9dfa4a93828150652/pixel-color.jpg)
</details>
- [ ] Some `simple_menu` based apps with custom row rendering code will look wrong (background color does not strech to the right screen border). I fixed this for the `personal_state` app, but I am not sure whether there is a viable solution for everything else...
- [ ] `epic_disp_print()` and `epic_disp_print_adv()` no longer wrap text at the screen border.
- [x] This circle appears cut off:
```python
d.clear().circ(80, 40, 30, col=color.CAMPGREEN).update()
```
<details><summary>Click to show example picture</summary>
![IMG_20210525_121708](/uploads/d3cc7efe1f153fe2be887393795c15c8/IMG_20210525_121708.jpg)
</details>
- [x] A pattern of rectangles which "touch" but don't overlap leaves stripes between them:
```python
d.clear()
for i in range(40):
d.rect(10, i * 2, 150, i * 2 + 1, col=color.WHITE)
d.update()
```
<details><summary>Click to show example picture</summary>
![IMG_20210525_122737](/uploads/b57197db3fe87db1a1d3585cbc6dd31f/IMG_20210525_122737.jpg)
</details>
- [ ] [xeyes](https://badge.team/projects/xeyes) needs to visit a doctor ASAP! I believe this comes from xeyes overdrawing the previous pupil in white before redrawing the new one.
<details><summary>Click to show example picture</summary>
![IMG_20210525_123242](/uploads/7cbdb53ce965685e99cefe0b98455ab1/IMG_20210525_123242.jpg)
</details>
- [x] For everything else which I found so far, I already added workarounds ;)
Cc: @schneider
Cc: @pippinhttps://git.flow3r.garden/card10/firmware/-/merge_requests/472Cleanup epicardium structure2021-04-11T20:03:04Zrahixcard10@rahix.deCleanup epicardium structureAs discussed, I pulled apart the modules directory a bit. This is only the start, of course there's lots more cleanup that can be done in the future...As discussed, I pulled apart the modules directory a bit. This is only the start, of course there's lots more cleanup that can be done in the future...https://git.flow3r.garden/card10/firmware/-/merge_requests/470Add epic_fs_is_attached(), os.fs_is_attached(), and make the menu automatical...2021-04-07T19:41:09Zrahixcard10@rahix.deAdd epic_fs_is_attached(), os.fs_is_attached(), and make the menu automatically return from USB modeAdd a new API call to check whether the filesystem is attached to card10 or to a connected USB host (in which case it is unavailable to card10). Make the menu check this and automatically exit "USB storage mode" when a host ejects the d...Add a new API call to check whether the filesystem is attached to card10 or to a connected USB host (in which case it is unavailable to card10). Make the menu check this and automatically exit "USB storage mode" when a host ejects the device.v1.18schneiderschneiderhttps://git.flow3r.garden/card10/firmware/-/merge_requests/469Release 1.17 - R2R Rocket2021-04-04T12:22:57ZschneiderRelease 1.17 - R2R Rockethttps://git.flow3r.garden/card10/firmware/-/merge_requests/467Update CHANGELOG2021-04-04T11:47:23Zrahixcard10@rahix.deUpdate CHANGELOG@schneider, please take a look if everything BLE related looks right. The rendered CHANGELOG is here:
https://git.card10.badge.events.ccc.de/card10/firmware/-/blob/rahix/changelog/CHANGELOG.md@schneider, please take a look if everything BLE related looks right. The rendered CHANGELOG is here:
https://git.card10.badge.events.ccc.de/card10/firmware/-/blob/rahix/changelog/CHANGELOG.mdv1.17schneiderschneiderhttps://git.flow3r.garden/card10/firmware/-/merge_requests/466Make sleep work again when BLE is disabled2021-04-03T21:42:03Zrahixcard10@rahix.deMake sleep work again when BLE is disabledIn commit 4944aa485d02 ("fix(ble): Update to changes from new SDK")
a call to `BbDrvDisable()` was added to `sleep_deepsleep()`. This
function must, however, only be called when BLE was previously
initialized, otherwise a wakeup from de...In commit 4944aa485d02 ("fix(ble): Update to changes from new SDK")
a call to `BbDrvDisable()` was added to `sleep_deepsleep()`. This
function must, however, only be called when BLE was previously
initialized, otherwise a wakeup from deepsleep will not be possible (if
it ever reaches it?).
Fix this by reworking the BLE enabled check to also be usable here, to
only call `BbDrvDisable()` when BLE is active.
Fixes: 4944aa485d02 ("fix(ble): Update to changes from new SDK")
Fixes: #231v1.17schneiderschneiderhttps://git.flow3r.garden/card10/firmware/-/merge_requests/465fix(sdk): Prevent endless loop on I2C error2021-04-02T23:21:08Zschneiderfix(sdk): Prevent endless loop on I2C errorThe read operation needs to wait until the stop bit it sends on error is
handled. Otherwise a following write operation will loop.
Closes #226The read operation needs to wait until the stop bit it sends on error is
handled. Otherwise a following write operation will loop.
Closes #226https://git.flow3r.garden/card10/firmware/-/merge_requests/464Add config option to disable low battery check2021-04-03T20:24:57Zrahixcard10@rahix.deAdd config option to disable low battery checkWe have encountered a device where the connection from the PMIC's ADMUX
pin to the MCUs ADC is severed and thus the low battery check would
trigger immediately.
For making such devices still usable, add a config option to disable the
lo...We have encountered a device where the connection from the PMIC's ADMUX
pin to the MCUs ADC is severed and thus the low battery check would
trigger immediately.
For making such devices still usable, add a config option to disable the
low battery check entirely.
Fixes: #227v1.17schneiderschneider