Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000475FirmwareSerial Commspublic2011-12-10 21:142011-12-12 08:45
ReporterFred 
Assigned ToFred 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version0.2.0-SNAPSHOT 
Target Version0.2.0Fixed in Version0.2.0 
Summary0000475: Improve Efficiency And Correctness Of SCI ISR
DescriptionRight 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.
TagsNo tags attached.
FirmwareVersion
Issue TypeImprovement
Risk of Breakagemedium
Attached Files

- Relationships

-  Notes
User avatar (0000972)
Fred (administrator)
2011-12-10 21:16

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!
User avatar (0000974)
Fred (administrator)
2011-12-10 22:23

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.
User avatar (0000975)
Fred (administrator)
2011-12-11 00:06

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.
User avatar (0000986)
Fred (administrator)
2011-12-12 08:45

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
Powered by Mantis Bugtracker