As discussed in issue card10/firmware#133, the BHI160 changes its
interrupt behavior during initialization.  In commit 2f56ff36
("fix(bhi160): Call bhy_mapping_matrix_set twice for the first time")
a quick workaround for this issue was added.  Replace this hack with
a proper fix by reconfiguring the interrupt on the host side according
to the specification.

(Finally) fixes card10/firmware#133.

Fixes: 2f56ff36 ("fix(bhi160): Call bhy_mapping_matrix_set twice for the first time")
Link: https://git.card10.badge.events.ccc.de/card10/firmware/issues/133#note_5894


Signed-off-by: Rahix <rahix@rahix.de>

Port the bhi160 mutex and hwlock usage in bhi.c to the new mutex API.
This will hopefully increase system stability.

Signed-off-by: Rahix <rahix@rahix.de>

Closes #189

See merge request card10/firmware!363

The call to MAX77650_getDebounceStatusnEN0() in epic_buttons_read()
performs transactions on the I2C bus but is not guarded by locking the
I2C hwlock.  This leads to strange issues like USB mode deadlocking when
writing large files.

Widen the hwlock I2C section to encompass the MAX77650_getDebounceStatusnEN0()
call as well.  This fixes card10/firmware#189.

Signed-off-by: Rahix <rahix@rahix.de>

Port the buttons module to the new hardware lock API which can no longer
fail.

Signed-off-by: Rahix <rahix@rahix.de>

Move hw-locks to new mutex API in multiple steps to keep diffs readable.  The
users of hw-locks are **not** ported to the new-semantics; this needs to be
done as a follow up.  One patch is included, porting the MAX30001 driver in
commit 6da4644e ("chore(max30001): Port to new mutex and hw-lock APIs").

See merge request card10/firmware!356

Using a FreeRTOS mutex directly is deprecated.  Replace it with a
`struct mutex`.  Similarly, the deprecated `hwlock_acquire_timeout()`
is replaced with `hwlock_acquire()`.

Signed-off-by: Rahix <rahix@rahix.de>

Re-add a `hwlock_acquire()` method, but this time without a timeout
parameter.  From a functional point of view, this is just a wrapper
around `mutex_lock()`.

Additionally, add `hwlock_acquire_nonblock()` which behaves like
`mutex_trylock()`.

Signed-off-by: Rahix <rahix@rahix.de>

Rename hwlock_acquire() to hwlock_acquire_timeout() in preparation for
future changes to the hw-lock API.  Change all uses of the hw-lock API
to reflect this change.

This commit does not introduce any functional changes, except getting
rid of the timeout usage warnings.  This change is no-op, because the
hwlock_acquire() implementation already replaces any non-zero timeout
value with portMAX_DELAY.

Signed-off-by: Rahix <rahix@rahix.de>

With the switch to the new mutex API, hwlock_release() cannot fail under
any circumstances.  To emphasize this, make it return void instead of
int (Previously it just always returned 0).

Signed-off-by: Rahix <rahix@rahix.de>

Reimplement the hw-lock module to use the new mutex API.  This slightly
changes the semantics of locking a hw-lock as the new mutex API does not
allow timeouts.  When a hwlock_acquire() with a (non-infinite) timeout
is attempted, a warning is printed to the serial console.

Additionally, instead of returning -EINVAL on use of a non-existent
hardware lock, the new implementation triggers a firmware panic.

Signed-off-by: Rahix <rahix@rahix.de>

The poor-profiler scripts allow profiling card10 (to some degree).

Signed-off-by: Rahix <rahix@rahix.de>

Signed-off-by: Rahix <rahix@rahix.de>

Signed-off-by: Rahix <rahix@rahix.de>

Signed-off-by: Rahix <rahix@rahix.de>

Signed-off-by: Rahix <rahix@rahix.de>

See merge request card10/firmware!337

fuchsi* authored 5 years ago and rahix committed 5 years ago

fix performance problems with pulse logging (caching time string and approximating timestamp via samplecount)

See merge request card10/firmware!361

Signed-off-by: Rahix <rahix@rahix.de>

Closes #192

See merge request card10/firmware!360

Signed-off-by: Rahix <rahix@rahix.de>

With the increased warning-level, GCC warns about three unused fields in
`bleSmpCfg`:

    - maxAttemptTimeout: Maximum 'Repeated attempts' timeout in msec
    - attemptDecTimeout: Time msec before attemptExp decreases
    - attemptExp: Exponent to raise attemptTimeout on maxAttempts

These should probably be set to sensible values but to make !360
mergeable, explicitly set them to zero for now.

Signed-off-by: Rahix <rahix@rahix.de>

Signed-off-by: Rahix <rahix@rahix.de>

By passing `&resched` instead of just `resched`, the internal comparison
in FreeRTOS would always evaluate to rescheduling.  Curiously, only some
GCC versions emit the -Waddress warning for this while others do not ...

Signed-off-by: Rahix <rahix@rahix.de>

Fix sign-compare warnings for these constants.

Signed-off-by: Rahix <rahix@rahix.de>

Signed-off-by: Rahix <rahix@rahix.de>

It does not make sense for the filesize to be given as `int`; it cannot
ever be negative.  Instead, use `size_t` which is unsigned.

Signed-off-by: Rahix <rahix@rahix.de>

Fix all warnings in pycardium/modules.

Signed-off-by: Rahix <rahix@rahix.de>

Fix all warnings in epicardium/modules.

Signed-off-by: Rahix <rahix@rahix.de>

Make the length parameter a `size_t` instead of a `intptr_t`.  A signed
value does not make any sense here and just leads to weird behavior if a
negative value is given nonetheless.

See issue card10/firmware#192

Signed-off-by: Rahix <rahix@rahix.de>

Signed-off-by: Rahix <rahix@rahix.de>

Signed-off-by: Rahix <rahix@rahix.de>