I fixed this (to the extent I've been able to test it) before I went on
vacation, but (as Rob deduced) I forgot to push it until today. :P
The basic problem is the amount of processing that takes place in the
interrupt handler (whether it's a direct UART receive interrupt or a DMA
half/complete interrupt). Under heavy loads, we tended to miss
characters, mis-order characters, or stutter characters.
So I revived the essence of commit 2b6b9f, where I've got a larger DMA
buffer than I think I'll need, and a once-every-ms task that pulls data
off, processes it, and queues RPC requests. It tests out well, and the
UART receive queue doesn't exceed 94 characters, which is consistent
with a transmission rate of 921600 baud, modulo a bit of jitter in the
SysTick interrupt.
I don't mind working with CMSIS/HAL, because it's a useful API, and I
don't think it's necessarily the gating factor in my design. Rather, I
think it was all the extra work I was trying to do in the interrupt handler.
I have great hope that this will be more stable, and I can go on to
spend my time on more interesting/useful work.
paul
On 08/07/2017 07:53 AM, Peter Stuge wrote:
> Moving this to tech@..
>
> 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
> _______________________________________________
> Tech mailing list
> Tech@cryptech.is
> https://lists.cryptech.is/listinfo/tech
>
_______________________________________________
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech
