Re: pyramid display timer/highres issue

Hi list!

On 12.02.2014, at 21:19, Markus Dolze <[email protected]> wrote:
> On 11.02.2014 15:11, J=F6rg Hohwieler wrote:
>> On 13.01.2014 21:20, Markus Dolze wrote:
>>> On 09.01.2014 12:52, J=F6rg Hohwieler wrote:
>>>> It's a long time since I started this thread, but finally I found a
>>>> solution.
>>>> =

>>>> --- pylcd.c.orig        2013-11-19 13:02:20.733699143 +0100
>>>> +++ pylcd.c     2013-11-19 13:02:28.629900897 +0100
>>>> @@ -208,7 +208,7 @@ real_send_tele(PrivateData *p, char *buf
>>>>     write(p->FD, buffer2, len);
>>>> =

>>>>     /* Take a little nap. This works as a pacemaker */
>>>> -    usleep(50);
>>>> +    usleep(30000);
>>>> =

>>>>     return 0;
>>>> }
> =

> Yes, I tested with the longer delay and was not really happy with it.
> Updating the LCD slows down a lot. Title scrolling and fast changing bar
> graphs like the CPU screen slow down noticeable.


Approx. a year back I had looked at the pylcd and could not find a sane val=
ue for that timing that was same time not causing huge delays and still all=
owed proper communication. I then figured that lcdproc was not exactly allo=
wing what I had wanted to do anyways, so I wrote my application without usi=
ng lcdproc, including my own driver for the pyramid display (version 2.3, I=
 believe). I was only able to get good results when I had a second thread h=
andling the response from the display, mainly the ACK messages, but special=
ly the keypress-events.
It's written in C++, uses string, stringstream, iomanip and queue (which pr=
obably can easily be cut away, if needed), but makes mandatory use now of t=
he libftdi and pthread.
If these are no constrains, I'll be happy to ask around at my employer how =
to contribute that as an example. That should not be a big problem, we are =
generally an open source company.

Manuel Dejonghe

******************************* =

PrimeKey Labs GmbH
Krantzstr. 7 (Entrance B)
52070 Aachen
Germany
********************************