RE: Real UART TX transmit depth?

samsonc — Sun, 23 Jul 2017 22:45:16 GMT

The framing/deframing code is not running in the ISR. There is just a standard circular buffer from the ISR to the framing/deframing code. In fact, I'm thinking about moving the framing code into the ISR, as it should reduce overall time spent from passing the bytes back and forth, and the deframing code is quite fast (a few us / byte, still working on it). I am not as concerned with latencies up to ~50us for the rest of my code - I'm really only concerned with the outright number of CPU cycles taken by the communications code, as some of the other modules are CPU heavy.

Again, I agree and wish it were so easy to switch to the nRF52 for this project - I'm using it for a parallel project, and I really love all of the improvements - but for the reasons above (lots of cycle sensitive code in other SW modules to retest and rewrite + existing HW) I don't think it's really an option.

RE: Real UART TX transmit depth?

Turbo J — Sun, 23 Jul 2017 12:07:55 GMT

UART TX buffer depth is actually more than documented - you can actually stuff 3 bytes in, and those same 3 bytes will come out.

Show us your test code, you more likely made a mistake somewhere when you tested that behaviour.

The only way to improve performance on the NRF51x is to make the ISRs even shorter, IMHO that means moving the framing/deframing code out of the handler fuction and into main() loop.

As there are about 160 clock cycles per byte at 1Mbaud and an ISR would take at least 24 for housekeeping alone, there will be a significant slowdown in main() processing at the time of data transfer.

If you CPU speed is too slow you will need to upgrade to NRF52x - the redesign might actually be cheaper than spending many hours trying to improve the software.