Re: Ultra-minimial module for using LCD proc with custom hardware

Hi,

On 28.01.2014 06:35, Fake Name wrote:
> 
> Ok, here is a updated patch that includes the suggested changes.
> 
> 2. Updates are now managed through a internal timing system, though the
> overall updates are still managed by flush() call rate (is there a
> better way to get internal callbacks?). This means the *maximum* rate
> possible is 8 hz, though I think that's probably plenty, and I didn't
> want to play with threading.

I too think there is no use in updating more often than LCDd updates the
screens.

> 3, 4.  Baud rate and update-rate are configurable. Baud rates were
> stolen from the Cfontz driver, so available rates are 1200, 2400, 4800,
> 9600, 19200, and 115200.
> 
> ~~The internal timing is measured via gettimeofday(), which is the same
> way this is measured in the main server loop (in main.c). However, it's
> worth noting that this is *not*a good way to get delta-times, since
> gettimeofday() is *not monotonic*. This means that if the clock goes
> backwards such as during daylight-savings-time or NTP updates, you can
> have inaccurate or excessive delays. For example, if something is
> scheduled for 125 ms in the future, and the clock is set back an hour,
> the next update will not occur for an hour + 125 ms.
> The main loop is doing some lag calculation stuff, and I have not looked
> at it deeply enough to determine if it fixes the possible DST/NTP
> issues, I think it may (`(t_diff < 0) )`) would prevent negative times,
> though with some jitter around the transition period, but it would be on
> the order of a few seconds only, I think.
> 
> It's a pretty minor issue, but it's worth looking at.
> FWIW, the "proper" way to deal with this is to use
> clock_gettime(CLOCK_MONOTONIC), but that requires linking against librt
> (lib realtime). It may not be enough of a problem to bother with.~~
> 
> Never mind, I examined the stuff in main.c more closely, and it's doing
> a bit of checking to ensure that any excessively large time-steps cause
> the delta tracking mechanisms to be reset. I still think switching to
> CLOCK_MONOTONIC is /probably/ a good idea, but the inconvenience of
> having to link against librealtime mean it's likely not worth changing.

Thanks for pointing that out. At least on FreeBSD, clock_gettime() is
part of the standard C library. However, not all systems need to
implement a monotonic clock, as it is optional in Posix. Therefore, we
would need to check for it and have a fallback in place. Really, there
has been no real problem with it in the past decade.

But driver writers using gettimeofday() for timing should be aware of
the fact.

> 
> Anyways, I implemented similar checking to the things in main.c in my
> timer loop, so it should be safe as well.
> 

Put your driver on my todo list.

Regards,
Markus