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

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

This is a multi-part message in MIME format.
--------------020708020607090803010306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 1/26/2014 1:47 AM, Markus Dolze wrote:
> On 23.01.2014 05:58, Fake Name wrote:
>> I apologize for spamming up the list, then.
>>
>> The youtube video seems to be in the mail, at least when viewed on 
>> the mailing-list online viewer 
>> (http://lists.omnipotent.net/pipermail/lcdproc/2014-January/014187.html), 
>> but here it is as a non-inlined URL anyways: 
>> www.youtube.com/watch?v=RsW7MzdMGhg
>>
>> Basically, it's just analog gauges that show current network traffic 
>> in realtime via the LCDProc plugin for PFsense, with some non-linear 
>> scaling (square root scaling). PFSense uses a custom PHP script for 
>> the LCDProc client, rather then the built-in LCDProc client, so there 
>> was some hacking there, which I'd be happy to release (though it's 
>> not germane to the patch). I'd just need to figure out where it went 
>> (bsd and updates are weird).
>>
>> Connor
>
> Hi Connor,
>
> I still have not looked at the driver, but I watched the video and now 
> have a better understanding of what you want to achieve and why you 
> want to use LCDproc for that purpose.
>
> My first thought was: 'Why is he parsing LCDd's output instead of just 
> reading the stat values himself?' I now understand that the values are 
> supplied by pfsense.
>
> Next was: 'Why is he not implementing some existing update protocol?' 
> - Because you need to parse the output. OK for this application. 
> Usually I advice people to implement some existing protocol. Even 8 
> bit micro controllers can be taught to understand control codes with 
> just a few lines of code. (see [1]).
>
> [1] http://mmdolze.users.sourceforge.net/display-with-rotary-encoder.html
>
> Then I checked if a driver already exists that is as simple as yours 
> (except for the timing). To my surprise there isn't.
>
> What I like about your driver is the ability to adapt the frame buffer 
> (size) to other loaded drivers. So one may use your driver well for 
> debugging purpose, too.
>
> However, I suggest the following changes:
>
>  1. Rename the driver to 'simpleserial'. It is 'reallysimpleserial',
>     but I feel this sound like a joke - which it is not.
>  2. Do not rely on the number of calls to flush() to count for one
>     second. Yes, LCDd is coded to 8 Hz, but it is designed as a
>     changeable value. I suggest to use the system's time functions.
>     'timing.h' provides some examples.
>  3. Make the refresh rate configurable. If implementing 2, it is
>     simply the milli seconds until the next update (or 0 to update
>     every time and 1000 as default). This makes it a fully blown
>     serial debug driver.
>  4. Make the serial speed configurable. It doesn't need to support the
>     full range of speeds (like hd44780-serial.c), but some 'low'
>     (9600) or 'high' (115200) speed would be great.
>
> Regards,
> Markus
>
I don't think I can really disagree with any of those ideas.

The reason I didn't implement any existing protocol is because to use 
any of them would require a local frame-buffer in the MCU. LCDproc does 
selective updating (at least in my testing, I looked through *most* of 
the drivers at one point), so you'd have to persist the entire display 
contents continuously, as only the changed character locations are 
updated. This is ideal for things like LCDs, since they by nature have 
local frame-buffers. For this sort of thing, not so much.

While it is completely possible to implement a pseudo-frame-buffer, it's 
*so* much simpler to just do stream-parsing, and not have to keep 
anything in memory.

And yes, I could probably write a script to do what I did that just 
talked to the serial port, but the infrastructure for using LCDproc was 
already there, and it does most of the work.

Anyways

1. As I said, I originally wrote this a while ago (more then a year?) 
and at that point, there was *already* a "simpleserial". The 
"reallySimpleSerial" naming kind of *is* a joke.
2. I can do delta-time updating, no problem. I'll look at timing.h and 
throw together a simple timer event loop.
Is there any way to get periodic calls that I can use for checking 
elapsed time short of just hooking into flush(), or is that acceptable? 
Is a separate thread appropriate here? (I mostly know MCU coding, I 
don't know what the proper approach is on more complex projects like this).
3. Same as 2.
4. I didn't do this mostly because I didn't want to have to bother with 
the config file stuff. I'm not too great a programming, I'm mostly a 
hardware guy. I'll revisit it.

Connor



--------------020708020607090803010306
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 1/26/2014 1:47 AM, Markus Dolze
      wrote:<br>
    </div>
    <blockquote cite="mid:[email protected]" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">On 23.01.2014 05:58, Fake Name wrote:<br>
      </div>
      <blockquote cite="mid:[email protected]"
        type="cite">
        <meta content="text/html; charset=ISO-8859-1"
          http-equiv="Content-Type">
        I apologize for spamming up the list, then.<br>
        <br>
        The youtube video seems to be in the mail, at least when viewed
        on the mailing-list online viewer (<a moz-do-not-send="true"
          class="moz-txt-link-freetext"
href="http://lists.omnipotent.net/pipermail/lcdproc/2014-January/014187.html">http://lists.omnipotent.net/pipermail/lcdproc/2014-January/014187.html</a>),


        but here it is as a non-inlined URL anyways: <a
          moz-do-not-send="true" class="moz-txt-link-abbreviated"
          href="http://www.youtube.com/watch?v=RsW7MzdMGhg">www.youtube.com/watch?v=RsW7MzdMGhg</a><br>
        <br>
        Basically, it's just analog gauges that show current network
        traffic in realtime via the LCDProc plugin for PFsense, with
        some non-linear scaling (square root scaling). PFSense uses a
        custom PHP script for the LCDProc client, rather then the
        built-in LCDProc client, so there was some hacking there, which
        I'd be happy to release (though it's not germane to the patch).
        I'd just need to figure out where it went (bsd and updates are
        weird).<br>
        <br>
        Connor<br>
      </blockquote>
      <br>
      Hi Connor,<br>
      <br>
      I still have not looked at the driver, but I watched the video and
      now have a better understanding of what you want to achieve and
      why you want to use LCDproc for that purpose.<br>
      <br>
      My first thought was: 'Why is he parsing LCDd's output instead of
      just reading the stat values himself?' I now understand that the
      values are supplied by pfsense.<br>
      <br>
      Next was: 'Why is he not implementing some existing update
      protocol?' - Because you need to parse the output. OK for this
      application. Usually I advice people to implement some existing
      protocol. Even 8 bit micro controllers can be taught to understand
      control codes with just a few lines of code. (see [1]).<br>
      <br>
      [1] <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://mmdolze.users.sourceforge.net/display-with-rotary-encoder.html">http://mmdolze.users.sourceforge.net/display-with-rotary-encoder.html</a><br>
      <br>
      Then I checked if a driver already exists that is as simple as
      yours (except for the timing). To my surprise there isn't.<br>
      <br>
      What I like about your driver is the ability to adapt the frame
      buffer (size) to other loaded drivers. So one may use your driver
      well for debugging purpose, too.<br>
      <br>
      However, I suggest the following changes:<br>
      <ol>
        <li>Rename the driver to 'simpleserial'. It is
          'reallysimpleserial', but I feel this sound like a joke -
          which it is not.</li>
        <li>Do not rely on the number of calls to flush() to count for
          one second. Yes, LCDd is coded to 8 Hz, but it is designed as
          a changeable value. I suggest to use the system's time
          functions. 'timing.h' provides some examples.</li>
        <li>Make the refresh rate configurable. If implementing 2, it is
          simply the milli seconds until the next update (or 0 to update
          every time and 1000 as default). This makes it a fully blown
          serial debug driver.<br>
        </li>
        <li>Make the serial speed configurable. It doesn't need to
          support the full range of speeds (like hd44780-serial.c), but
          some 'low' (9600) or 'high' (115200) speed would be great.<br>
        </li>
      </ol>
      <p>Regards,<br>
        Markus<br>
        <br>
      </p>
    </blockquote>
    I don't think I can really disagree with any of those ideas.<br>
    <br>
    The reason I didn't implement any existing protocol is because to
    use any of them would require a local frame-buffer in the MCU.
    LCDproc does selective updating (at least in my testing, I looked
    through *most* of the drivers at one point), so you'd have to
    persist the entire display contents continuously, as only the
    changed character locations are updated. This is ideal for things
    like LCDs, since they by nature have local frame-buffers. For this
    sort of thing, not so much.<br>
    <br>
    While it is completely possible to implement a pseudo-frame-buffer,
    it's <b>so</b> much simpler to just do stream-parsing, and not have
    to keep anything in memory.<br>
    <br>
    And yes, I could probably write a script to do what I did that just
    talked to the serial port, but the infrastructure for using LCDproc
    was already there, and it does most of the work.<br>
    <br>
    Anyways<br>
    <br>
    1. As I said, I originally wrote this a while ago (more then a
    year?) and at that point, there was *already* a "simpleserial". The
    "reallySimpleSerial" naming kind of *is* a joke.<br>
    2. I can do delta-time updating, no problem. I'll look at timing.h
    and throw together a simple timer event loop. <br>
    Is there any way to get periodic calls that I can use for checking
    elapsed time short of just hooking into flush(), or is that
    acceptable? Is a separate thread appropriate here? (I mostly know
    MCU coding, I don't know what the proper approach is on more complex
    projects like this).<br>
    3. Same as 2.<br>
    4. I didn't do this mostly because I didn't want to have to bother
    with the config file stuff. I'm not too great a programming, I'm
    mostly a hardware guy. I'll revisit it.<br>
    <br>
    Connor<br>
    <br>
    <br>
  </body>
</html>

--------------020708020607090803010306--

--===============8854184857578745711==
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

--===============8854184857578745711==--