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

This is a multi-part message in MIME format.
--===============9020332706442513981==
Content-Type: multipart/alternative;
 boundary="------------010706050601020505010608"

This is a multi-part message in MIME format.
--------------010706050601020505010608
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 1/27/2014 10:11 PM, Markus Dolze wrote:
> 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.
Yeah, most of the above paragraph /should/ have had a strikethrough 
applied to it, but I don't know if something ate the formatting 
(everything between "~~" marks).
Really, I tend to agree that it's probably overkill, and the lack of 
consistent support for a monotonic clock and platform variances makes it 
not worth the effort. Right now, worst case clock errors will result in 
/possibly/ the LCD not updating for ~35 minutes in my code, (since it 
can be configured for fairly long update intervals), or ~2.1 seconds for 
the main event loop. Neither really is too big a deal, as it would take 
a very particular of a confluence of odd events for that to happen, 
/and/ it would correct itself in a relatively short period of time with 
no crash.
I don't see a strong need to deal with the issue, really.

>> 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
>
>
>
Awesome, thanks!

Connor



Sidenote: I continue to be utterly abysmal about e-mail. I think I have 
too many e-mail accounts.

--------------010706050601020505010608
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 1/27/2014 10:11 PM, Markus Dolze
      wrote:<br>
    </div>
    <blockquote cite="mid:[email protected]" type="cite">
      <pre wrap="">Hi,

On 28.01.2014 06:35, Fake Name wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">I too think there is no use in updating more often than LCDd updates the
screens.

</pre>
      <blockquote type="cite">
        <pre wrap="">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 &lt; 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.
</pre>
      </blockquote>
      <pre wrap="">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.
</pre>
    </blockquote>
    Yeah, most of the above paragraph <i>should</i> have had a
    strikethrough applied to it, but I don't know if something ate the
    formatting (everything between "~~" marks).<br>
    Really, I tend to agree that it's probably overkill, and the lack of
    consistent support for a monotonic clock and platform variances
    makes it not worth the effort. Right now, worst case clock errors
    will result in <i>possibly</i> the LCD not updating for ~35 minutes
    in my code, (since it can be configured for fairly long update
    intervals), or ~2.1 seconds for the main event loop. Neither really
    is too big a deal, as it would take a very particular of a
    confluence of odd events for that to happen, <i>and</i> it would
    correct itself in a relatively short period of time with no crash. <br>
    I don't see a strong need to deal with the issue, really.<br>
    <br>
    <blockquote cite="mid:[email protected]" type="cite">
      <blockquote type="cite">
        <pre wrap="">Anyways, I implemented similar checking to the things in main.c in my
timer loop, so it should be safe as well.

</pre>
      </blockquote>
      <pre wrap="">Put your driver on my todo list.

Regards,
Markus



</pre>
    </blockquote>
    Awesome, thanks!<br>
    <br>
    Connor<br>
    <br>
    <br>
    <br>
    Sidenote: I continue to be utterly abysmal about e-mail. I think I
    have too many e-mail accounts.<br>
  </body>
</html>

--------------010706050601020505010608--

--===============9020332706442513981==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
LCDproc mailing list
[email protected]
http://lists.omnipotent.net/mailman/listinfo/lcdproc

--===============9020332706442513981==--