You can compile the firmware for this new target using 'make
BOARD=qmod'.
The QMOD differs from simtrace+owhw in terms of low-level
initialization, as it has an external 12MHz clock at XIN, thus bypasses
the main oscillator and needs different PLL configuration.
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.
We now auto-discover the end-point addresses based on the interface
descriptor. The user can also use the new "--interface" command line
argument to set a non-zero intrerface. In combination, this should
enable support for the remote-sim functionality on the second UART
on OWHW.
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.
... 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...