Open CarlFK opened 4 years ago
That list is actually left-over that we've forgotten to remove and is not used anymore!
The actual lists used are those specified inside the various modes. I believe the first one you mention is actually supported, but perhaps not in any official Mu release yet: https://github.com/mu-editor/mu/blob/master/mu/modes/circuitpython.py#L43
The other one isn't on the list, so yeah I guess it should be added. https://github.com/mu-editor/mu/blob/master/mu/modes/esp.py#L49 Which hardware device is it that get's that VID/PID? Is that the pyboard?
There's some work on a pyboard mode over at #650, as the libraries are different than plain MicroPython, and it should supply different documentation. But just want to make sure I understand this correctly, and this is not a different board.
oh gosh, please remove that code before someone else goes bonkers trying to add a board. I figured I wasn't getting the description string right or something.
both sets of ID's are from the same hardware: https://learn.adafruit.com/adafruit-stm32f405-feather-express
in addition, when I jumper and put it into boot loader mode:
0483:df11 STMicroelectronics STM Device in DFU Mode
Which might be useful to tell the user "Yes a recognized board is plugged in, but no it isn't going to work right now."
All VID=0x239a are now detected as CircuitPython boards by https://github.com/mu-editor/mu/pull/721. I agree this confusing should be removed. I'm sure a PR would be welcome.
I've added a PR to remove that dead code.
As I understand it, https://github.com/micropython/micropython actually sets the same VID/PID for any STM32 device! That's odd! Especially as the f055:9800
is the pyboard
VID/PID, we would want that to make the user use the pyboard-mode
for that (again, see that in #650), but if any other MicroPython device (not the pyboard
unit), might also identify with that VID/PID, that's not easy for us to handle in a nice way.
My current thought is that it might be better to display all devices that are currently connected, instead of only showing those which are recognized. I'm still not certain this is a good idea, what could be the pros/cons with this? Perhaps we should test it. @carlosperate or @ntoll might have an opinion here.
in addition, when I jumper and put it into boot loader mode:
0483:df11 STMicroelectronics STM Device in DFU Mode
Which might be useful to tell the user "Yes a recognized board is plugged in, but no it isn't going to work right now."
I'm not sure I completely understand this part, @CarlFK, could you try to explain it in other words?
The alternative is what @CarlFK suggests in #1110, where users can add additional devices e.g. through some kind of configuration option (e.g. adding a line in a configuration file)
in addition, when I jumper and put it into boot loader mode: 0483:df11 STMicroelectronics STM Device in DFU Mode Which might be useful to tell the user "Yes a recognized board is plugged in, but no it isn't going to work right now."
I'm not sure I completely understand this part, @CarlFK, could you try to explain it in other words?
to flash a new CP or MP onto the board, "..connect the BOOT0 (B0) pin to 3.3V logic. " https://learn.adafruit.com/adafruit-stm32f405-feather-express/dfu-bootloader-details
Similar to double pressing the reset button on the CPX, which changes the id from 239a:8019 to 239a:0018
mu has a list of ID's it supports:
https://github.com/mu-editor/mu/blob/master/mu/modes/base.py#L42-L53
Which does not include: 239a:805a USB_VID = 0x239A USB_PID = 0x805A https://github.com/adafruit/circuitpython/blob/main/ports/stm/boards/feather_stm32f405_express/mpconfigboard.mk#L1-L2
or the MP version: f055:9800 https://github.com/micropython/micropython/blob/b9ec6037edf5e6ff6f8f400d70f7351d1b0af67d/ports/stm32/usb.h#L34-L35