STM32F4 DMA question

Don't have info on the particular cpu, but most dma type ops that are useful can be set up to autoincrement the address for the next byte and maybe even wrap around at the buffer end ?.

Anyway, why are you having problems with interrupts ?. Unless you are running at a very high baud rate, there should be more than enough time to read the uart data, stick it in a FIFO buffer, do the housekeeping and get out fast. If the system is designed right, you should *never* need to block interrupts from the uart either. With modern processors, interrupt latency should be insignificant.

More info needed ?...

Chris

Interrupt latency is not just a function of the processor's hardware architecture but also (probably more significantly) of any part of the code that keeps interrupts disabled. The latency will be potentially extended by as much as the longest amount of time interrupts are disabled throughout the code base.

I'm not an expert in linux or real-time linux, but I've often thought that must be one key difference between the two.

Even with 486 processors you could find a 10:1 variation in latency (and not just interrupts), depending on what was in the cache. It won't have got better as caches have got larger and memory latency has increased w.r.t. instruction time.

IIRC the i960 allowed the current contents of the cache to be frozen, for just that reason.

Perhaps so, but we have come a long way from the days of 6502 style processors, where, depending on how many devices you wire-or'd onto the irq line, it could take anything up to 100uS just to find out what caused the interrupt, never mind process it.

Haven't used the 32F4 Cortex, but the 32F100 series that I am using has a fully vectored interrupt system that uses a vector address table, much like the old 68000 series from 1983 (?). It took years, but Arm finally got that bit of it right.

Just to put it in context, we are talking about serial comms here and even at ~100K bits/second, that means you have 100uS to deal with each received byte. Believe me, that's a lifetime for a fast cpu like Cortex :-)...

Chris

Of course, but a well designed system should never need to disable interrupts for more than a few cycles. Also,a good cpu design provides facilities for assignment of interrupt priorities, so that critical devices or s/w always get service within a predictable timescale.

Usually, all the instruction timing stuff is in the processor data sheet, so you can work out worst case latency with a fair degree of accuracy...

Chris

There's 14 years difference there: 6502:1975, i486:1989

I think you mean 100us. "S" is for Siemens the SI unit of conductance, or sometimes Samples.

But you are missing the point. I've no quibble with the *average* latency, but the *worst case* latency will be much much higher.

But then my background is that a hard-realtime deadline is just that: a *dead*line.

And, the point being ?. The comment was to illustrate how far things have developed since the early days, where high speed comms was not so easy to program due to timing limitations, or did you think I meant something else ?.

Well, I understood what I meant and it seems so did you, so why the need for the rather pompous correction ?.

All that data should be in the processor data sheet and if you are working that close to the edge, you have to take it into consideration. But, let's keep it in context: The original question to Tim was about problems with serial uart interrupts, not in depth discussions about latency, which i'm sure we are all aware of and not relevant to the context.

Quite used to counting the uS here as well, but much less need for it with the micros we have to work with now. An abundance of riches and choice springs to mind :-)...

Chris

I'm not even sure that the serial port is double-buffered -- I know that I figured out how to get just one byte at a time out via DMA, and my problems disappeared.

Well, I ended up solving the problem another way.

But yes -- it struck me as odd that I should be having trouble. I needed something quick, so bandaiding the problem by allowing more latency seemed like a good idea, at least until I had the leisure to chase down the real problem.

I didn't mean to be critical, just didn't understand what the problem was.

A lot of uarts aren't multi buffered, but they all at least have a holding register for the previously received byte, while the next byte is being loaded by the input shift register. This means you have at least a byte's time to receive the interrupt and process it. Even at 100K bits/second, assuming async, 8,N,1 you have 100uS to process the interrupt and do the houskeeping, ie: modify bits in the uart control register, whatever. On the Cortex M3, for example, interrupt latency, 72MHZ clock, is < 200nS worst case, so it's unlikely to affect anything for serial comms. Instruction cycle times are down on the 10's of nS range as well, so interrupt driven serial comms should be a breeze without having to resort to dma transfer, which just complicates everything,

The problems might have disappeared, but it wouldn't be enough for me not to understand why. Hence the question :-)...

Chris

You have my permission to be critical -- I shouldn't have that much interrupt latency.

That's what I meant by double-buffered, and this one is. So I really have no excuse for the interrupt response time.

Dang. Now I wonder what was going on...