Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000568TunixFreeEMS Pluginpublic2012-04-06 22:552012-04-07 12:20
ReporterFred 
Assigned ToFred 
PriorityurgentSeverityblockReproducibilityalways
StatusassignedResolutionopen 
PlatformAllOSAllOS VersionAll
Product Version0.9.24-SNAPSHOT 
Target Version0.9.24Fixed in Version 
Summary0000568: Add Optional And Configurable Inter-Char Delay To Serial
DescriptionAlthough the CPU in FreeEMS is around 100x faster than required for a 115200 data stream, we can end up losing bytes on the receive side of things. The reasons for this are as follows:

A single other interrupt can run that takes longer than the time between two bytes arriving and cause the second to be lost.

The serial interrupt can arrive at more or less the same time as one or more other higher priority interrupts while another interrupt is running and get deferred until after the higher priority code has run, resulting in a total deferment of more than the time between two bytes.

The former is quite rare right now and likely to be more rare in future with optimisations, however it does affect missing tooth users a lot. They can't tune at idle in some cases due to this missing feature.
Additional InformationOnce completed thorough testing should be done on all three supported platforms to ensure that there are no regressions in terms of functionality or stability, in either the app or the drivers/OS being used. Especially relevant to mac os x which has been flaky in the past.
TagsNo tags attached.
FirmwareVersionall versions
Attached Files

- Relationships

-  Notes
(0001411)
dandruczyk (viewer)
2012-04-07 12:20

-1

inter-char delay is a BAND AID for a poor design and or lack of hardware capability (i.e, deep enough buffer, hardware flow control, etc). MegaSquirt uses this extensively, do you REALLY want to follow their footsteps here?


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker