-
Notifications
You must be signed in to change notification settings - Fork 990
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CMSIS-DAPv2: blink LED on bulk interface activity #1008
Conversation
7a130ad
to
5ebaab9
Compare
5ebaab9
to
725b796
Compare
As it turns out, the micro:bit online editors (MakeCode & Python) both constantly pull serial data when connected via WebUSB. This is done to offer some useful features like detecting errors printed to serial and highlighting them in the editor. With this fix, unfortunately, the editors are constantly blinking the DAPLink activity LED as soon as the micro:bit is WebUSB connected, and therefore we cannot tell the difference between the micro:bit seating idle vs flashing (or the user interacting with the target serial), which is technically worse for our users, as seeing the flashing LED activity is quite useful and the behaviour we've described in a lot of the micro:bit documentation. One option we are considering is seeing if there is a way to check the bulk activity traffic, and if possible maybe filter out activity coming from serial data (of course, that would have to be behind a build flag or hook). |
Do you think this could work: https://github.com/mbrossard/DAPLink/tree/pr/uart-dap-led? |
Thanks @mbrossard, unfortunately that didn't work. I think DAPLink/source/usb/bulk/usbd_bulk.c Lines 80 to 81 in 5e04123
Doing this as quick hack did work (vendor IDs 3 and 4 are serial read/write), but not sure how to best integrate it in DAPLink. |
The call stack goes:
I guess we could probably add I guess the only problem is that "philosophically" it's not great to set the HID LED inside of the DAP commands module, and on the other hand checking the DAP command in the USB traffic processing layer is also not ideal. But I'm not sure if there is a better alternative. |
I think we could move the I prefer modifying |
We could use a similar hook to Ideally we'd use the same hook, but if the function declaration needs to go into a header file I'm not sure what's the best place to put it, any suggestions? |
I agree there should only be one hook. The "HID" LED should rather be considered the "DAP" LED. So I would be in favor of renaming I think the default hook could ignore the DAP commands that call |
The easiest way to use a single hook might be to move it to Which approach would you prefer then:
|
Okay, I've created both PRs, feel free to merge whichever you prefer if it's ready to go (comments with improvements, maybe with the naming, are welcomed). |
Fix for #714