The crate just re-exports the com_rs crate. This patch changes usages of
com_rs-ref to use com_rs directly.
Signed-off-by: Jean-Pierre De Jesus DIAZ <me@jeandudey.tech>
fully integrates wifi on and off commands. measured standby power
when wifi is off is "immeasurable" (0 mA), so probably < 1-2mA.
fix ui transitions so that the off request is respected, through
sleep/resume cycles as well.
instead of sharing the wifi buffer loopback has its own buffer.
this eliminates a race condition that happens whenever an Rx
happens to happen on the wifi interface while there's loopback
traffic in progress.
also, i see a lot of opportunities to optimize the net stack now
that i have tweaked this path; it might be interesting to break
the receive interrupt out directly into the COM crate instead
of passing it through LLIO then NET then COM and having COM
drain the RX buffer immediately into a local "infinite" sized
queue.
The llio->net->com loop exists because the interrupt handler
for all the i/o is shared within one hardware block, but maybe
i can create an additional interrupt responder for the com
interface just to optimize things a bit in a future SOC update.
Alternatively, I could move all the interrupts into COM and not
have them resident in LLIO. This would optimize for COM latency
at the expence of I2C latency, but that's probably OK because
I2C is much less latency sensitive (i2c and com interrupt, as
mentioned above, share the same hardware block for external
pin-based interrupts).
This adds the FLASH_VERIFY command, which is going to be used
to help automate some update logic.
The notion of an apilevel has also been added to every com_rs
command; this can be used by the COM to figure out what commands
are valid for talking to the current reported EC version.
The version parsing of the string passed back from the EC has
been replaced with the code in the xous-semver crate.
Was doing disjoint loads and stores on an Atomic, really, should
be using the fetch_add, fetch_sub variants to be proper.
Didn't seem to impact anything but maybe there's a future version
of me that high fives me for doing this.
I wrote in a commit yesterday how there was no ROI on doing this
yet somehow I kept on doing it. I blame poor impulse control.
Turns out there was a series of race conditions and bugs that
caused this thing to "mostly work" on the first go at it but
really hard to debug and get very right.
1. Litex UART has a weird undocumented API. You advance the Rx
FIFO by writing `1` to the PENDING bit, and no other way. However,
you determine if there are any more characters to receive by
reading the EMPTY bit and seeing if it is 1. The previous method
wrote `1` to the PENDING bit and then used the PENDING bit to
see if a character was available, under the theory that the
PENDING bit would be set again if there was still a character.
This is somewhat true, except that the PENDING bit is set only
some amount of time later which is about comparable to a few
CPU instructions, so if you had a fast loop path the PENDING
bit would show as cleared and you'd exit, which would cause
no further interrupts to fire because the interrupt was
effecitvely not acknowledged.
This isn't written up anywhere but I figured this out by
just reading the source code for Litex UART and BIOS:
e8be391504/litex/soc/cores/uart.py (L264-L279)ccd3ab17be/litex/soc/software/libbase/uart.c (L38-L44)
2. I had the Key Injector IP block in the `sys` domain, which
would have its clock cut when the CPU went to sleep, which would
cause input characters to disappear when the CPU went into power
saving. moving this to "always on" domain fixes that.
3. I had the UART PHY in the always on block (so you could
send or receive exactly one character), but not the
separate UART block (which contained the FIFOs).
The UART block would also go into power
savings, and this would cause FIFO entries to go missing.
4. Escape sequences get sent as a burst of characters. The Key Injector
originally did not have a FIFO of its own, so it would only
remember the *last* key of the sequence that was written, causing
some keys to be dropped occassionally. Adding a 16-deep FIFO
to the injector fixes this.
5. The code I had to read out the injector's results was designed with
the "strobe" bit (to indicate that the FIFO had characters) in the
same regsiter as the character itself. Thus the loop that 1. checked
if the fifo was empty then 2. read and forwarded the character
would actually perform two reads from the FIFO. However, this "mostly worked"
I think because the FIFO retains the last value that was written
even when it was empty, so if only one character was read at a time
everything was fine. It only didn't work when you stuffed two characters
in there, as you'd drop the first one. Reading the FIFO once and
then interpreting the code with a bitmask fixes this.
6. The escape sequences, in their full glory with no dropped characters,
required a refactored parsing routine, which I have now added.
7. backspace->delete mappings, the bane of computer engineers since 1960.
OK. very bald yak. Here I lay down the shears next to several
mooshi pillows stuffed with the finest Yak hair.
Now that I understand how smoltcp does ping better I have regrets.
The demo example in smoltcp uses a funky macro that was a bit
misleading. I have gotten rid of that but I probably would have made
different decisions in implementing this had I understood the API better.
Anyways. It works, but has some trouble handling the cases of timeouts
sometimes.
the connection number is re-used for all objects created
within a process space, so you can't `Drop` the connection
immediately when an object goes out of scope. You have to
make sure all instance of the object go out of scope. This
patch adds reference counting to all the objects so that
the `Drop` function works as intended.
Here's an arcane bug for you:
When powering down, the Spartan 7 3.3V I/O drivers will
output a roughly 800us wide glitch as 3.3V falls below around
1.7V, if the 0.95V core voltage comes down first (which it does
because we have an active discharge on 0.95V, but not on 3.3V).
In this case, it's just wide and high enough to cause the
BOOST mode line to engage, which takes the BOOST output
and ties it to VBUS, which is just enough for the system to
think you're powering it back on again. Which is not what
you want when powering down.
The ultimate fix was to put a heftier pull-down on the BOOST
line so that it can't trip the BOOST output into the VBUS.
Another option could be more active discharge FETs, but that
would require a full board spin and we are already at certification,
so we'll stick with the stronger pull-down on BOOST. It seems to
be a robust fix in the worst corner cases we can find.
The downside is that when powering an external USB device,
you are burning an extra 30mW of power overcoming the pull-down,
but typically, any external USB devices plugged into Precursor
will burn far in excess of that, so the delta should be negligible.
