spresense: Pass the correct USB bus speed after restart

[kamtom480]

This PR solves the problem with Spresense enumeration on Windows and Mac.

[tannewt]

@hathach Any idea why the code size grew? It looks like the CI failures are due to builds running out of space.

[dhalbert]

The difference between Gemma M0 ja before and after this is only about 240 bytes, so I could see a small amount of new code would push it over the edge.

[hathach]

it could be caused by recent PR to the MIDI driver hathach/tinyusb#618 . Flash seems to get tighter each PR. Next time, I will try to refactor endpoint stream = endpoint + fifo which currently used by multiple class driver to claim back some flash.

PS: @kamtom480 are you ok to have PR pending in a few days. I am in middle of other works. Will try to update the stack to claim back 240 bytes then we could get CI fixes for all builds. This is due to the limited flash on other MCUs, nothing wrong with your PR.

[dhalbert]

I think I can fix all of these by doing SUPEROPT_VM = 0. This was already done on some builds, like trinket_m0 -- it just wasn't done consistently.

(A few of these failures are transient network failures.)

[hathach]

I think I can fix all of these by doing SUPEROPT_VM = 0. This was already done on some builds, like trinket_m0 -- it just wasn't done consistently.

(A few of these failures are transient network failures.)

ah great, that would buy us some time to have a better testing for refactor code :)

[kamtom480]

It's ok for me to wait. But I would like this PR to be in the next CircuitPython release.

Currently on the website: https://circuitpython.org/board/spresense/ there are 2 versions of CP that you can choose from: CircuitPython 6.1.0 and CircuitPython 6.2.0-beta.2.

Unfortunately, CircuitPython 6.1.0 does not work for Spresense and CircuitPython 6.2.0-beta.2 only works on Linux.

[hathach]

@kamtom480 It will merge soon enough, after the #4248 is merged that save flash on the samd21 build.

[tannewt]

I merged the PR and triggered a re-run. Hopefully it'll pass.

[kamtom480]

Nice! Thank you! When can I expect the next CircuitPython release?

[tannewt]

@kamtom480 Please rebase this. I can't get it to run the checks against the newest main branch with the size fixes.

We can release a beta this week with these changes.

[dhalbert]

I guess re-running the jobs does not redo the merge :( .

I tried pushing a merge commit, but we don't have permission. However, I was able to build one of the failed builds successfully.

You would do something like this in the branch, or you could rebase (I like merging instead).

$ git fetch adafruit    # or whatever you call the upstream remote
$ git merge adafruit/main
$ git push

[kamtom480]

@dhalbert I've already rebased it but thank you for your help. :)

I added 2 new commits that fix other USB problems on Spresense.

[tannewt]

@kamtom480 Looks like an API changed with the newer version and needs to be updated in CP.

[hathach]

right, the HID callback API is updated to support multiple instance of HID interfaces. They are all listed here hathach/tinyusb#678 . Not all callbacks are used by circuitpython though.

[kamtom480]

I updated the HID callback API used by CircuitPython.

[dhalbert]

qt py haxpress still doesn't fit. Could you change ports/atmel-samd/boards/qtpy_m0_haxpress/mpconfigboard.mk to:

USB_VID = 0x239A
USB_PID = 0x00CC
USB_PRODUCT = "QT Py M0 Haxpress"
USB_MANUFACTURER = "Adafruit Industries LLC"

CHIP_VARIANT = SAMD21E18A
CHIP_FAMILY = samd21

INTERNAL_FLASH_FILESYSTEM = 0
LONGINT_IMPL = MPZ
SPI_FLASH_FILESYSTEM = 1
EXTERNAL_FLASH_DEVICE_COUNT = 1
EXTERNAL_FLASH_DEVICES = GD25Q16C

CIRCUITPY_AUDIOBUSIO = 0
CIRCUITPY_BITBANGIO = 0
CIRCUITPY_COUNTIO = 0
CIRCUITPY_FREQUENCYIO = 0
CIRCUITPY_I2CPERIPHERAL = 0
CIRCUITPY_MSGPACK = 0

SUPEROPT_GC = 0
SUPEROPT_VM = 0

That should make it fit.

[kamtom480]

It has passed all the tests. Thank you for your help!

[dhalbert]

Great! Thanks for persevering while we worked out the build issues.

I believe the reason I couldn't push changes to the PR is that your repo is forked from micropython/micropython, instead of adafruit/circuitpython. This seems to block "friendly" pushes even though you may have set the permission for them. I had the same trouble with @tannewt's fork. This doesn't need to be fixed, but it's worth explaining.

[tannewt]

This seems to block "friendly" pushes even though you may have set the permission for them. I had the same trouble with @tannewt's fork. This doesn't need to be fixed, but it's worth explaining.

(If you want us to be able to push to your fork, then you could add us as collaborators.)

[dhalbert]

@kamtom480 By when would you like a beta release that includes these fixes? We are trying to finish off some significant RP2040 additions/fixes. If necessary, we could do two betas in quick succession.

[kamtom480]

@tannewt @dhalbert I added both of you as collaborators. :)

We had to shift everything by a month. We want to make sure everything works first. So you don't have to do two betas. Thank you for your help!

Are there any estimates when 6.2.0 will be released?

[tannewt]

Are there any estimates when 6.2.0 will be released?

Nope. We are hoping to get there soon by punting much of the RP2040 stuff to the following release. One thing we do want to fix though is the I2C issues on the S2. It's on Dan's plate.