When iterating over the queue of req_ctx, make sure to unlink each
buffer before processing it. And during processing, ensure all buffers
are reelased back to the memory management.
This way the application on the USB host can control whether the
emulator should emulate that the card be inserted or not. We change the
reset-default back to 'not inserted' (GPIO output 0) and wait for the
application to explicitly request this by issuing
CEMU_USB_MSGT_DT_CARDINSERT.
Depending on which features (and thus USB configurations) are included
in the firmware, we need to re-define the ordering of the configuration
numbers, as the Atmel USBD driver simply assumes that configurations are
numbered 1..N without any gaps in the sequence.
... 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.
So far we have only been working with a single UART/USIM. Let's
make things more data structure driven and pass around handles to
the data structures rather than hardcoding...
In order to handle other USB commands like GET_STATUS, SET_ATR
or GET_STATS, we introduce an intermediary queue. The USB receive
completion call-back puts the command on that intermediate 'main'
queue. From that intermediate queue, the are further
dispatched/processed according to their mesage type.
* ensure the PB8/PB9 pins are actually not in GPIO mode, which they
apparently are on boot-up
* ensure that neither pull-up nor pull-down are enabled on PB8/PB9
* ensure we first start the oscillator, before selecting it
The sum of the above changes seems to make oscillator start-up much more
reliable than before. The time needed for initialization is now pretty
stable, and the occasional 15-20second clock stabiliziation has not been
observed with this change.
When the ISO7816 state machine requires us to transmit something, but
we don't have data ready to transmit, we should switch off TXRDY
interrupt generation.
What's missing is of course the other part that re-enabls TXRDY
generation once new data is available
This also removes the actual queuing code from req_ctx, and
leaves this to the caller. Only tw out of the existing states actually
required the ordering requirement enforced by the qeue, and in the
future we will need to have per-endpoint queues anyway. Both means it
is better to manage queues outside the req_ctx, and leve that as a pure
memory allocator.
We don't want to call into the bulk of card_emu.c from interrupt
context, so let's introduce a ring buffer as a softwre-FIFO between
the USART receiving a byte and the processing of that byte in
card_emu.c, which is then performed from the main loop outside
interrupt context.
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.
