Hi, I noticed when I followed the [current instructions](2f8d0f4404/README.md?plain=1#L413) in the README to use probe-run, I got an error:
```sh
probe-run --chip RP2040 --list-probes
error: the argument '--chip <CHIP>' cannot be used with '--list-probes'
Usage: probe-run --chip <CHIP> <ELF>
For more information, try '--help'.
```
I'm on macOS Monterey 12.6.5 (21G531) and currently here's my version from probe-run:
```sh
probe-run --version
0.3.8
supported defmt version: 4
```
Once I removed the `--chip` argument I got this:
```sh
probe-run --list-probes
the following probes were found:
[0]: Picoprobe CMSIS-DAP (VID: 2e8a, PID: 000c, Serial: E6616408438E3C21, CmsisDap)
```
I am guessing this is the intended behaviour, and that the `--chip` and `--list-probes` arguments no longer work together.
This removes the hard-coded XTAL_FREQ_HZ variable from the rp-pico UART
examples as it's already defined in this library as XOSC_CRYSTAL_FREQ.
I noticed this as I was looking thru the examples and it seems like most of
them use the rp_pico::XOSC_CRYSTAL_FREQ value instead. I'm new to embedded so
please let me know if I got something wrong here. Thanks!
While the project does have examples, even a simple example such as
blinky doesn't really cover how to get started if you don't want to use
a template.
**Issue**
While using `usb_device` and `usbd_serial` crates with `rp2040_hal`, the first frame from the host device is always getting lost. Consecutive frames work just fine.
**Root Cause**
The `LENGTH_0` region of the `EP_BUFFER_CONTROL` register is always reset (0) while waiting for the first frame. After the first frame failure, the poll operation implicitly sets it to the necessary value (`max_packet_size`) and this clears the problem for the rest of the app execution life time.
The main problem is while resetting and readjustment of the bits needs a step by step operation to avoid potential issues. While doing that and setting `AVAILABLE` bit, the wrong method had been chosen and was invalidating previous changes. Hence the `LENGTH_0` param is reset, too.
**Proposed Solution**
Instead of direct register `write` operation I've used `modify` to keep current bits in the register.
Co-authored-by: Murat Ursavas <mursavas@nebra.com>
If the latency is too high, there is a risk that the status reverts to a
previous state while keeping the interrupt flag up.
This fixes that by relying on ints instead of sie_status to process the
events.
