| Age | Commit message (Collapse) | Author |
|---|
|
We really don't want SysTick_Handler, which runs the task scheduler, to
run at a higher priority than SVC_Handler, which runs supposedly-atomic
operations like mutex locking and unlocking. I've seen a mutex lock/unlock
mismatch which I think is due to interrupting rt_mut_release at a
particularly inopportune moment.
|
|
receive buffer with half-complete callbacks, and raise the dma priority.
|
|
Also rearchitect the way we handle RPC requests - have a bunch of waiting
dispatch threads rather than continually creating and deleting threads.
|
|
|
|
HAL_UART_MspInit doesn't have to.
|
|
|
|
DMA is more efficient and less prone to miss characters than interrupts.
An open question is if circular mode is really the best. If someone
copy-pastes more than the RX buffer size of configuration into the CLI,
we risk the DMA controller catching up with the reader and overwriting
data not yet read.
Since we don't have flow control back to the users terminal, we will
always fail if too much data is entered before we can process it. The
question is if failing to stuff new data at the end of a buffer might be
better than data being overwritten - thus messing up the commands in
unpredictable ways.
|
|
Integrated into the cli-test program as such:
cryptech> test sdram
Initializing SDRAM
Starting SDRAM test (n = 0)
Run sequential write-then-read test for the first chip
Run random write-then-read test for the first chip
Run sequential write-then-read test for the second chip
Run random write-then-read test for the second chip
Run interleaved write-then-read test for both chips at once
SDRAM test (n = 0) completed
SDRAM test completed successfully
cryptech>
|
|
|
|
This code needs more error checking etc. but together with the Python
script 'filetransfer', a new bitstream may be loaded into the FPGA
config memory like this:
filetransfer --fpga /path/to/bitstream
The bitstream is identified by 'file' e.g. like this:
alpha_test_top.bit: Xilinx BIT data - from
alpha_test_top.ncd;UserID=0xFFFFFFFF - for 7a200tfbg484 - built
2016/05/12(13:59:24) - data length 0xe0164
|
|
|
|
|
|
|
