Re: Ultra-minimial module for using LCD proc with custom hardware
Markus Dolze <[email protected]> Sun, 26 Jan 2014 10:47:05 +0100
| Newsgroups | gmane.comp.sysutils.lcdproc |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============4519109117999088820==
Content-Type: multipart/alternative;
boundary="------------000006090202020100010008"
This is a multi-part message in MIME format.
--------------000006090202020100010008
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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
--------------000006090202020100010008
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 text="#000000" bgcolor="#FFFFFF">
<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 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>
</body>
</html>
--------------000006090202020100010008--
--===============4519109117999088820==
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
--===============4519109117999088820==--