The PLL setting doesn't depend on the 'qmod' board type but on the
combination of the BOARD_MAINOSC and BOARD_MCK #defines. So let's
remove the '#ifdef qmod' from the equation.
The only 'qmod' specific part is whether or not to use the internal xtal
oscillator or not.
Table 42-31 ofd DOC6500 states that the minimum output frequency of the
PLL is 60 MHz. The existing qmod code violated this by configuring the
PLL multiplier output to 12*4 = 48 MHz. Let's use 12*8 = 96 and then
divide that by two to get to the desired 48 MHz.
This might help to resolve the non-working USB on the qmod so far.
* move it out of the function so it actually is present in .rodata,
rather than having a long sequence of stores into a stack buffer
* use 16 bytes per line so it is easier to find + change bits in there
The firmware we used for testing contained some local changes which were
not committed. They primarily relate to the port re-ordering feature as
well as the amount of power (0x32 = 100mA) is now used consequently.
When we reset the hub, the hub will actively drvie the PRTPWR signal of
the SITMRACE12 low, resulting in the SAM3 being shut off. If we want to
"survive" this, we need to set the OVERRIDE before we go into reset.
Right now, we never release the signal again, keeping ST12 enabled
permanently, which is of course not what we want in general.
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...
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.
Harald Welte