Allow the PlayerApp to turn off the device if it is idle for longer then
the timeout. The timeout is currently hardcoded to 1 minute, this will be
made configurable in the future.
Signed-off-by: Matthias Blankertz <matthias@blankertz.org>
Move the LED control to the utils.LedManager class. For the first
implementation, support two LED patterns 'idle' and 'playing'.
Extend the PlayerApp to set the LED pattern based on playback state.
Signed-off-by: Matthias Blankertz <matthias@blankertz.org>
- Move RC522 connector a bit further away from the MAX98375 module
footprint, so a JST-XH connector can be used here too.
- Update custom rules and fix some DRC warnings (no netlist and layout
changes).
Signed-off-by: Matthias Blankertz <matthias@blankertz.org>
Add a through-hole pad connected to GND next to the MAX98357 gain config
resistor to allow the user to select from all possible gains.
Signed-off-by: Matthias Blankertz <matthias@blankertz.org>
If the tagmode setting is 'tagremains' (the default): Play as long as the
tag is on the reader, with a 5 second timeout (i.e. playback stops when
tag is gone for more than 5 seconds).
If the tagmode setting is 'tagstartstop': Playback starts when a tag is
seen. Presenting a different tag causes the playback to stop and
playback for the new tag to start. Re-presenting the same tag used to
start with a no-tag-time of 5 seconds or more in between stops playback.
Signed-off-by: Matthias Blankertz <matthias@blankertz.org>
Split the tag handling in PlayerApp into two parts: The low level
handling of changed/removed tags from the Nfc reader, including the
timeout processing is moved into the nested TagStateMachine class. The
main PlayerApp has two new (internal) callbacks "onNewTag" and
"onTagRemoved" which are called when a new tag is presented or a tag was
actually removed. This will hopefully make the implementation of #28
"Configurable Tag Handling" cleaner.
Signed-off-by: Matthias Blankertz <matthias@blankertz.org>
As we don't have an API to upload files and create playlists yet, we
used the convention "tag uid as directory name" to allow testing
playback. With the introduction of the database in #39 "Add playlist db"
a builddb() function to initialize the database from the tag directories
was added, but it is not automatically called. To make the developer
experience more ergonomical, add a check for that automatically runs
builddb() when no database exists.
Signed-off-by: Matthias Blankertz <matthias@blankertz.org>
To simplify the playlist handling, enforce that the indices are always
formatted to the same length (5, which allows for 100000 entries, that
should be enough).
Then make the position stored in the Playlist object be a simple integer
instead of a database key. This simplifies the code, and will make
implementing shuffle much easier.
Signed-off-by: Matthias Blankertz <matthias@blankertz.org>
Add documentation of playlist database schema in DEVELOP.md.
Add settings for persist and shuffle to BTreeDB. Implement the different
persist modes. Shuffle will be implemented in a followup commit.
Signed-off-by: Matthias Blankertz <matthias@blankertz.org>
Apply the same pattern as in 6f155ebb55 ("audiocore: Fix small race
window in get_fifo_read_value_blocking") and 2a4033d3ca ("rp2_sd: Fix
race window in sd_spi_wait_complete") to the wait for interrupt in
i2s_stop too.
Signed-off-by: Matthias Blankertz <matthias@blankertz.org>
Similar to the fix in 6f155ebb55 ("audiocore: Fix small race window in
get_fifo_read_value_blocking"), a race and deadlock is possible when
calling __wfi with interrupts enabled. Fix it in sd_spi_wait_complete by
copying the fix from the above commit.
Signed-off-by: Matthias Blankertz <matthias@blankertz.org>
Add a read test to the SD tests in standalone_mp3, and also apply the
drive strength setup and higher clockrate from board_Rev1.py.
Signed-off-by: Matthias Blankertz <matthias@blankertz.org>
The PIO has an internal synchronizer on each GPIO input which adds two
cycles of delay. This prevents metastabilities in the PIO logic (see
RP2040 datasheet p. 374f). For high speed synchronous interfaces such as
SPI this needs to be disabled to reduce input delay.
Signed-off-by: Matthias Blankertz <matthias@blankertz.org>
The code snippet in hwconfig to adjust the drive strength was incorrect:
It was adjusting the wrong pins. This was probably not updated during
some pin shuffling in the breadboard phase.
Fix this by adjusting the correct pins. Experimentation shows that both
setting the slew rate to fast or setting the drive strength to 8 mA
(default: slow and 4 mA) is sufficient to make SD SPI work at 25 MHz on
the Rev1 PCB. For now, the combination 8 mA and slow is chosen (slow
slew rate should result in less high frequency EMI).
Also make the SD clock rate adjustable in hwconfig, and set it to 25 MHz
for Rev1 and 15 MHz for the breadboard setup.
Signed-off-by: Matthias Blankertz <matthias@blankertz.org>
In order to turn the Tonberry device on more reliably even if the power
button is only pressed for a short time, move the setting of POWER_EN
pin to high from the python board_init to the MICROPY_BOARD_STARTUP
macro so that is is started in the C startup code run before the
micropython interpreter is initialized.
Measured time from power on to POWER_EN time was 600-800 ms with the
python board_init, vs. 155 ms for the MICROPY_BOARD_STARTUP.
Signed-off-by: Matthias Blankertz <matthias@blankertz.org>
- Increase the formatting of playlist entries to allow up to 100000
tracks. Also enforce that playlist entries are indexed by integers
using the validate method.
- Add a validate method to validate the data stored in the
btreedb. Optionally dump the contents to stdout. For testing, add a
validate+dump by default when opening the db. This can be removed once
the playlistdb is validated.
Add playlist database based on the micropython 'btree' module.
Supported features are:
* Create playlist
* Load playlist
* Store position in playlist
Different playlist modes will be added in a followup for #24.
Implements #23.
The playlist data is stored in the btree database in a hierarchical
schema. The hierarchy levels are separated by the '/' character.
Currently, the schema is as follows: The top level for a playlist is the
'tag' id encoded as a hexadecimal string. Beneath this, the 'playlist'
key contains the elements in the playlist. The exact keys used for the
playlist entries are not specified, they are enumerated in native sort
order to build the playlist. When writing a playlist using the
playlistdb module, the keys are 000, 001, etc. by default. The
'playlistpos' key is also located under the 'tag' key and stores the key
of the current playlist entry.
For example, a playlist with two entries 'a.mp3' and 'b.mp3' for a tag
with the id '00aa11bb22' would be stored in the following key/value
pairs in the btree db:
- 00aa11bb22/playlist/000: a.mp3
- 00aa11bb22/playlist/001: b.mp3
- 00aa11bb22/playlistpos: 000
Signed-off-by: Matthias Blankertz <matthias@blankertz.org>
