micropython / micropython/micropython
rpi2040 gives correct output on logic analizer for 8bit but not for 9bit communication
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 22.1k
- Forks
- 9k
- Avg merge
- 6d 4h
- Merged PRs (30d)
- 16
Description
Port, board and/or hardware
rpi2040
MicroPython version
MicroPython v1.23.0 on 2024-06-02; Raspberry Pi Pico with RP2040
Reproduction
import machine
import utime
# Configure UART1 on GPIO8 (TX) and GPIO9 (RX)
uart = machine.UART(1, tx=machine.Pin(8), rx=machine.Pin(9), baudrate=25000, bits=9, parity=0, stop=1)
# Function to send the known pattern
def send_pattern():
#test bytes
uart.write(bytes([0x55])) # 0x55 (binary 01010101)
uart.write(bytes([0xAA])) # 0xAA (binary 10101010)
uart.write("AAA")
#what I want to actually send
uart.write(bytes.fromhex('0102'))
uart.write(bytes.fromhex('0104'))
uart.write(bytes.fromhex('00F9'))
#uart.write(b'\xAA')
#uart.write(b'\xFF')
# Send the known pattern every 50ms
while True:
send_pattern()
utime.sleep_ms(50)
Expected behaviour
expected to see those values in the logic analyzer
Observed behaviour
the logic analyzer sees this:
| name | type | start_time | duration | data | error |
|---|---|---|---|---|---|
| Async Serial | data | 0.0087 | 0.00042 | 0x0075 | |
| Async Serial | data | 0.00914 | 0.00042 | 0x0029 | framing |
| Async Serial | data | 0.00966 | 0.00042 | 0x0161 | framing |
| Async Serial | data | 0.0103 | 0.00042 | 0x0061 | |
| Async Serial | data | 0.01074 | 0.00042 | 0x002C | framing |
| Async Serial | data | 0.01126 | 0.00042 | 0x0064 | framing |
| Async Serial | data | 0.0119 | 0.00042 | 0x01F9 | |
| Async Serial | data | 0.05908 | 0.00042 | 0x0175 | framing |
| Async Serial | data | 0.05958 | 0.00042 | 0x010A | |
| Async Serial | data | 0.06002 | 0.00042 | 0x0161 | framing |
Additional Information
If I change the program and analyzer to use 8bits instead, things look better. I may have some issues there but the 0x55 and 0xAA are picked up for example.
uart = machine.UART(1, tx=machine.Pin(8), rx=machine.Pin(9), baudrate=25000, bits=8, parity=0, stop=1)
| name | type | start_time | duration | data | error |
|---|---|---|---|---|---|
| Async Serial | data | 0.01646 | 0.00038 | 0x55 | framing |
| Async Serial | data | 0.0169 | 0.00038 | 0xAA | framing |
| Async Serial | data | 0.01734 | 0.00038 | 0x41 | framing |
| Async Serial | data | 0.01778 | 0.00038 | 0x41 | framing |
| Async Serial | data | 0.01822 | 0.00038 | 0x41 | framing |
| Async Serial | data | 0.01866 | 0.00038 | 0x01 | |
| Async Serial | data | 0.0191 | 0.00038 | 0x02 | |
| Async Serial | data | 0.01954 | 0.00038 | 0x01 | |
| Async Serial | data | 0.01998 | 0.00038 | 0x04 |
Code of Conduct
Yes, I agree
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the UART1 RP2040 example with 9-bit and 8-bit settings, using GPIO8 and GPIO9 at 25000 baud, and compare the logic-analyzer output. Check whether the reported framing errors and decoded values match the configured communication; done means 9-bit transmissions are decoded as the expected values without unexplained framing errors.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python, raspberry-pi
- Domain
- embedded-iot
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100