[Cryptech Tech] stm32 <- UART -> cryptech_muxd

[Peter Stuge]

Moving this to tech at ..

Rob Austein wrote:
> Peter Stuge wrote:
> > I don't see why serial I/O on the STM32 should ever cause a problem,
> > assuming that the UART code is interrupt driven with some buffering.
> > Do you or Paul know if that is the case?
> 
> The top-level UART is in sw/stm32/projects/hsm/hsm.c, using library
> routines elsewhere in the stm32 library swamp.  Yes, it has a buffer,
> and I think it's interrupt driven most days of the week, but Paul has
> tried various approaches and would be a better source of information
> for what it is today.

The current code is using DMA and a buffer in SDRAM. git log shows
that Paul has also tried the CMSIS interrupt mode.

I would suggest to skip DMA and to use interrupt receive with a
minimal own interrupt handler, not use the CMSIS HAL interrupt handler,
and have a 512-or-so byte buffer in *SRAM*. This would be the lower
interrupt handler and should be as few instructions as possible;
really only read the UART data register DR and append to buffer.

Paul had an SRAM buffer as DMA destination in commit 2b6b9f, but I
would suggest going a few steps further. It should be easy to ignore
HAL for this.

Blocks of say 64 bytes (or timeout) can then be copied to SDRAM for
higher level code with DMA if neccessary - that's fine - but it may
not be trivial to do that (I just don't know; I avoid CMSIS) and then
either use-in-place or CPU copy would work too.

I would also suggest adding a receive overrun flag (or counter)
somewhere, which gets reset only on stm32 reset.


Rob Austein wrote:
> Peter Stuge wrote:
> > Is there also an output queue towards the STM32? Or is the request from
> > each client simply sent out right away, tagged with the new client handle?
> 
> There's a lock to serialize simultaneous requests from multiple
> clients, but otherwise muxd passes requests along immediately.
> 
> Code is sw/libhal/cryptech_muxd.  Be warned that the stuff that looks
> like threading is really cooperative multitasking again.

Thanks! I think we'll be able to simplify it significantly if/when we
want, by taking more advantage of what USB has to offer.

Anyway, one step at a time.


//Peter