Adjust the 1/2 bit time to match the number of extra cycles in the actual
PIO loop.
Throw out the entire start bit, which results in sampling the data at the
midpoint and not the starting time of a bit (which was causing random
failures on read data).
Tested at 300bps all the way to 2,000,000bps using a loopback connection.
Fixes#360
Fixes#472
Instead of using interrupts, explicitly call the IRQ handler dueing Serial
read/peek/available calls.
Add to keywords.txt for syntax hilighting.
Add poll calls in the SerialUART::write-like calls (write,
flush, etc.)
Really remove division from IRQ routines/
Fixes#468
The FIFO limit was set to 1/2, or 16 bytes on POR and not set by the core,
so for low baud this could result in a LONG time without data moving from
hardware FIFO to the SW ring buffer and timeouts/etc.
Now use the API call which sets it to 1/8, or 4 bytes of data to speed up
the transfer 4x.
Also avoid using the divider in the IRQ routine because it is not clear
from the docs of the Pico SDK IRQ callback routine preserves divider
state or not. If not, doing division in an IRQ could result in random
data corruption in the main app.
Add memory barriers to ensure the order of data into RAM is preserved
and that GCC doesn't reorder writes.
When the Serial software FIFOs overeflowed, the IRQ handler would not
read any more data from the hardware FIFOs. This would cause the
IRQ handler to be continually called as soon as it exited since the
HW FIFOS were not empty.
Now always read every available HW FIFO entry and throw out any that
don't fit in the SW FIFO.
Also fix a too long by half stop bit timing in the PIOSerial receiver.
Adds support to the core for PIO-based, software-created UARTs, up to 8 (the number of PIO state machines) possible.
By using a custom program on the PIO state machines, it allows for very high bit rates and does not require CPU or interrupts.
Bit widths from 5- to 8-bits, 1 or 2 stop bits, and even/odd/none parity are supported.
风飘雨