we want to ensure that the length of every (current or future) message
can be determined by looking at cardemu_usb_msg_hdr.msg_len, rather than
having a length that is relative to the respective specific command.
... among those is a rotor (\|/-) that is printed by the main loop,
so one can observe if the main loop is still executing or the system
is somehow stuck.
The caller might not have edge triggering and just gives us the
current state. we have to use that informtaion to determine the
edges when something is actually switched on or off.
we cannot first chage the state and then transmit the byte
asynchronously later, this introduces race conditions. Do it
in-line by explicit calls to the UART Tx function.
* don't enter a state we are already in
* enable the UART receiver not only when waiting for CLA, but also
generally when we're waiting for more data from the reader
When the USB host software sets this flag, we terminate the
TPDU transmission after the last character in this frame and
transition again to the WAIT_TPDU state.
I couldn't help but to spend my sunday on working towards card
emulation, including
* various state machines in the target about ISO7816 states
* tc_etu timer import from simtrace1
* req_ctx import from simtrace1 (needs renaming and simplifiation)
* USB protocol description as cardemu_prot.h
* some host-based testing code to test the state machines
The code seems to work fine throughout card reset, sending ATR and
receiving the TPDU header of the first APDU, up to the point where it
marks the TPDU header as to-be-transmitted over th bulk-in endpoint.
Sending the ATR must be done inside the firmware for timing
requirements.
From that point onwards, the host needs to respond at the very least
with a procedure byte, and some indication whether or not the card
emulator should continue to transmit data (card->reader), or receive
data (reader->card).
The code is intentionally not hooked up yet with the USB logic nor with
the UART. I want host-based testing completed before doing that.
