At higher speeds, it seems we are turning off the transmitter before we
are enabling the receiver. Unfortunately the TXEN bit in the uart mode
register is read-only, so we don't really know if the transmitter is
enabled or not. It seems we can simply keep transmitter + reciver
running at the same time, and use the TXEMPTY bit as reliable means to
determine if we're busy transmtting.
We can now enable CARDEMU_SECOND_UART in owhw/board.h, as it no
longer interferes with operation of the first port (USIM1). Whether
the second port actuall works still remains to be tested at this point.
UDP end-points are streams, so when we receive data on the OUT
endpoint callback, the buffer might contain several commands. When
dispatching the messages, split (segment) them again before dispatching
them to their respective handlers.
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.
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.
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.
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
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.
