|Anonymous | Login | Signup for a new account||2019-03-18 22:44 UTC|
|Main | My View | View Issues | Roadmap | Repositories|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000475||Firmware||Serial Comms||public||2011-12-10 21:14||2011-12-12 08:45|
|Target Version||0.2.0||Fixed in Version||0.2.0|
|Summary||0000475: Improve Efficiency And Correctness Of SCI ISR|
|Description||Right now a lot of code runs for RX every single time, regardless of whether there is a byte waiting or not. Additionally, various errors are checked for when they can't possibly happen, etc. Fix this situation saving CPU time and making results more consistent with reality.|
|Tags||No tags attached.|
|Risk of Breakage||medium|
Old data was:
3.8125/3.8750 micro seconds for a normal RX byte and 4.1875 for the first or last byte
tx is 3.5000us for a normal byte, and 2.8750 for the second to last hacky byte and 3.1250 for the last byte
5.1250 for both tx/rx normal bytes, but it was hard to find!
Fixed in 1c7954b16ba9219239134e8d5b1bf256d0054b25.
2.8750/2.9375 for the first and subsequent tx bytes, 2.5000 for the last byte, 2.3750 for the second to last byte
4.1250 for the first byte, 3.7500 for a normal rx byte, 3.6875 for the last one.
RX and TX together is unchanged at 5.125
Given the primary direction of flow, that's a saving of around 18% for transmission with a small gain in reception speed too.
Behaviour is slightly different in that multiple RX errors can be counted on the same byte and thus the sum of them could be larger than the number of lost packets. Additionally RX errors will never mess up a transmission as they could have before.
|25 bytes MORE space for reducing the rx line to one from two in the inline function, no change in speed of functionality. Line 86 in commsISRs.c in the above hash. I guess it gets called 5 times and the loss is 5 bytes each. I'll do this anyway once I pull out the checksum and size calcs for issue 0000152 just to keep the code clean and concise.|
More fixes available in 256ed4fc49a2206fb640e78c1f03ecfbe55e8941 produce these results:
TX byte, start and mid stream is 2.6250/2.6875us (0000063:0000009% faster), second to last is 2.3750 (unchanged) and last is 2.5000 (unchanged).
RX byte, first is 3.8750, 3.4375 for normal bytes, 3.3750 for second to last, 3.3125 for the last, around 9% faster overall.
Double rx/tx 4.3125us, much better, but so rare that we don't care.
|Copyright © 2000 - 2011 MantisBT Group|