As mentioned in issue #6241 the commit to setup port hooks is now
causing all input/output that are to go to the Mu window to also
go to the LpUart that is defined the port serial.c
and in this case it goes to lpuart4, which on Teensy 4, 4.1 is
used on Arduino Serial2. With this new code this port no longer
works properly.
This is one way to solve it, in that there is a #if defined() that
if not set, all of the code in this file is ignored and the higher
level supervisor stub versions of these functions will be used, which
don't interfere with Serial2 and my test sketch works again.
Note: the PR for Switch to Port Serial Hooks, also changed code in
other ports. I have not tried to see how.
There are other more global fixes for this, in which maybe a higer
level #if that disables the code within the top level supervisor. Or
could be software controlled
Again this may not be the final solution, but at least it gets
Serial2 up and running agin.
This saves 444 bytes on the pygamer build (both commits taken together)
testing performed:
* pygamer (samd51) with ShiftRegisterKeys
* macropad (rp2040) with Keys
* UM feather s2 (esp32-s2) with KeyMatrix
Result:
* all ports still worked nicely
* keys held down at start always registered (>2 trials all boards, >100 trials esp32-s2)
* keys held down are immediately registered after reset() (>100 trials esp32-s2)
* double .reset() is OK, accessing .events throws (only tested esp32-s2)
This warning can happen on clang 13.0.1 building mpy-cross:
../py/vm.c:748:25: error: array index -3 refers past the last possible
element for an array in 64-bit address space containing 64-bit (8-byte)
elements (max possible 2305843009213693952 elements)
[-Werror,-Warray-bounds]
sp[-MP_OBJ_ITER_BUF_NSLOTS + 1] = MP_OBJ_NULL;
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
Using pointer access instead of array access works around this warning.
Fixes issue #8467.
Signed-off-by: Damien George <damien@micropython.org>
Some audio implementations, notably samd, really don't like it when
you return 0 samples of data. This was the case when reaching the
end of an MP3 file.
Now, we read forward in an MP3 file to the next sync word during
"get_buffer", so that we can accurately return GET_BUFFER_DONE when the
NEXT call WOULD HAVE resulted in 0 samples.
Tested with @gamblor21's "laugh.mp3" file on a Trellis M4 Express.
