| Age | Commit message (Collapse) | Author |
|---|
|
understanding it 6 months from now.
While I'm at it, try to make it a little more efficient (because 50-60% of
time in a typical profiling run is spent in the function-entry counting),
and collapse profil.c into gmon.c.
|
|
newlib, because memset is called a LOT in the course of RSA signing, and
we need to understand how much time we're actually spending there.
|
|
so the user might be able to copy and paste a generated key into the CLI
for recovery.
Display had been a 32-byte hexdump. Parsing (manual re-entry of the KEK)
had been 8 32-bit little-endian values. This has been a pain point for
literally two years, albeit at a low enough pain level that I've managed
to cringe and ignore it.
|
|
|
|
|
|
This is from October's cleanup binge, but I forgot to commit it at the time.
|
|
|
|
|
|
|
|
|
|
|
|
interrupted) rather than LR (the return address from the function we
interrupted).
Also, change u_short and u_int to unsigned short and unsigned int, since
gcc recently decided that those aren't part of the C99 standard.
Finally, add profilable versions of memcpy, memset, and friends, because
they get called a lot in the course of unit testing, and it would be nice
to know who's calling them.
|
|
A previous version of this code ran over the RTOS, where threads used the
Process Stack, while the SysTick interrupt used the Main Stack. Now
everything's on the main stack, so we need to account for 2 extra words
that SysTick_Handler pushes on the stack at entry.
|
|
|
|
|
|
already a user-callback mechanism with HAL_SYSTICK_IRQHandler() and HAL_SYSTICK_Callback().
|
|
it's easier than setting up a dedicated timer.
|
|
|
|
interrupted) rather than LR (the return address from the function we
interrupted).
Also, change u_short and u_int to unsigned short and unsigned int, since
gcc recently decided that those aren't part of the C99 standard.
Finally, add profilable versions of memcpy, memset, and friends, because
they get called a lot in the course of unit testing, and it would be nice
to know who's calling them.
|
|
A previous version of this code ran over the RTOS, where threads used the
Process Stack, while the SysTick interrupt used the Main Stack. Now
everything's on the main stack, so we need to account for 2 extra words
that SysTick_Handler pushes on the stack at entry.
|
|
|
|
|
|
first place.
|
|
|
|
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.
|
|
buffer, because we've observed out-of-order receives under load.
|
|
receive buffer with half-complete callbacks, and raise the dma priority.
|
|
|
|
|
|
|
|
rather than re-deriving them.
|
|
Also rename all instances of GNUmakefile to Makefile.
|
|
|
|
|
|
|
|
|
|
no longer compiles (sigh).
|
|
|
|
|
|
commits which have been made in other repositories since the last time
anybody bothered to synchronize this. Poster child for why this kind
of recursive hairball belongs in release engineering rather than in
source code repositories which are under active development, but that
yak can wait a little while longer for its shave.
|
|
STM32 HAL code directly.
|
|
This lets us, say, use these sections for stack or heap.
|
|
We don't plan to put initialized data in SDRAM, and we don't have startup
code to copy initialized data, so don't even bother. Further, the linker
will reserve space in FLASH, even for uninitialized data, so just don't.
|
|
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.
|
