|Anonymous | Login | Signup for a new account||2019-06-17 20:35 UTC|
|Main | My View | View Issues | Roadmap | Repositories|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000568||Tunix||FreeEMS Plugin||public||2012-04-06 22:55||2012-04-07 12:20|
|Target Version||0.9.24||Fixed in Version|
|Summary||0000568: Add Optional And Configurable Inter-Char Delay To Serial|
|Description||Although 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 Information||Once 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.|
|Tags||No tags attached.|
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|