Raspberry Pi Pico (RP2040) support #1083
Conversation
|
This pull request introduces 3 alerts when merging 3614167 into 7dccf5c - view on LGTM.com new alerts:
|
pyocd/probe/picoprobe.py
Outdated
| # ------------------------------------------- # | ||
| def open(self): | ||
| # Only one configuration considered | ||
| self._dev.set_configuration() |
|
Ah, nice to see it all coming together. |
|
This pull request introduces 3 alerts when merging d9fa5c8 into 7dccf5c - view on LGTM.com new alerts:
|
| @@ -0,0 +1,8 @@ | |||
| # 2e8a:0004 Raspberry Pi picoprobe | |||
| # https://github.com/raspberrypi/picoprobe | |||
| SUBSYSTEM=="usb", ATTR{idVendor}=="2e8a", ATTR{idProduct}=="0004", MODE:="666" | |||
There was a problem hiding this comment.
My preference really goes to using a group, rather than the satanic MODE.
But as long as the safer alternatives are suggested (line 7-8) I'm fine with this, as it's simpler for naïve users.
This is more a general comment, as all the .rules files here follow the same pattern.
There was a problem hiding this comment.
Yeah, that makes sense. I just followed the STLink rules that were created by ST. We could change all of the rules to use groups? Just need to add some instructions in comments on how to set up the group for users that don't know, and maybe the MODE based rules, commented out, as an alternative. This would be a separate PR, though.
There was a problem hiding this comment.
The good thing with the rules as they are now is that zero knowledge or extra actions are needed for the user, just drop them in and they work.
A group (or username) based rule needs the user to tailor it according their identity.
Probably, an username rule is easier - as it would not involve:
- Creating an ad-hoc group or selecting an existing one (but hey vary across distributions)
- Making sure the user belongs to the group
Only this step would be needed:
- put the username in the right place in the rule
I might try to write a template this WE, depending on available time - no guarantee.
There was a problem hiding this comment.
I'm sure that's why ST chose MODE based (and it made sense for me).
The ultimate would be to have all 3 variants: "just works", user based, group based. Separated into different folders under ./udev/. That's probably overkill, though. 😁 If you find time, I will happily add your additions!
|
This pull request introduces 4 alerts when merging 962d7ee into 74a0b3a - view on LGTM.com new alerts:
|
- Added methods for sending sequence fragments. - Added methods for specific SWD<->dormant<->JTAG transitions.
- Add DAP_SWD_Sequence command support to pyDAPAccess. - Add swd_sequence() to DebugProbe. - Add SWD_SEQUENCE probe capability. - Update probe server and client.
- Supports HW reset in Picoprobe (if available) - Safe (slow) or bulk (faster) SWD modes - Tested with a Discovery F429 and a Nucleo L476
Picoprobe tested with Pico board from VS Code (cortex-debug): - Flashing - Read and write RAM and variables - Breakpoints and single stepping
- Flash algo is sourced from the https://github.com/rp-rs/flash-algo project.
Trying to select a configration for an USB device that already has one will raise an USBerror exception with "Resource Busy" on Linux (but not on Windows!). This is now accounted for.
This PR includes a number of changes and additions.
Major changes:
rp2040_core0,rp2040_core1,rp2040(alias for core 0). Only one core can be accessed at a time for now, pending full multi-drop SWD support.Other changes:
jtag_sequence()debug probe API.swd_sequence()debug probe API.SWJSequenceSenderclass to allow sending fragments of sequences and perform any single step of the SWD <—> dormant <—> JTAG transitions.