Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    LCDProc 0.5.4-dev

    Scheduled Pinned Locked Moved pfSense Packages
    587 Posts 68 Posters 702.9k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • stephenw10S
      stephenw10 Netgate Administrator
      last edited by

      lcdproc-dev is a pfSense package, an updated version of the original lcdproc package which is also still available. It's installed through the webgui is System: Packages:
      If you have manually added some version of lcdproc you should remove it before installing the package.

      Steve

      1 Reply Last reply Reply Quote 0
      • N
        n1ety
        last edited by

        @stephenw10:

        lcdproc-dev is a pfSense package, an updated version of the original lcdproc package which is also still available. It's installed through the webgui is System: Packages:
        If you have manually added some version of lcdproc you should remove it before installing the package.

        Steve

        OK,
        Do I need to download the pfsense CD Image to get ahold of the code?
        I actually ordered the book for pfsense as I want to deploy on a Soekris box later on this year.
        But in the meantime my immediate need is to display weather stats and upload weather stats from a TV news vehicle. Came across a pretty cool weather station that can collect weather data while rolling down the highway.
        I collect this data along with GPS coordinates and upload to studio via an aircard  from a Soekris box.
        I also have an LCD panel on dash for meteorologist to get current stats.
        What I want to do is flash an LED upon successful upload to station, or another LED/Color on failed upload so they know their data is getting sent to station side database.
        Came across this thread about getting the CrystralFontz LED's working. Ready to uninstall the typical LCDProc and use previous posted code with some messaging  but can't find the original LCDProc 0.5.4-dev discussed here.
        Also in code in earlier post it references some *.inc files but those aren't included????

        1 Reply Last reply Reply Quote 0
        • K
          kilthro
          last edited by

          if you are running pfsense the dev version is in the package manager. just have to install it from there.

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            If you want to look at or modify the source for lcdproc-dev it, along with all source code, is here:
            https://github.com/pfsense/pfsense-packages/tree/master/config/lcdproc-dev

            Steve

            1 Reply Last reply Reply Quote 0
            • J
              joako
              last edited by

              Has anyone managed to get lcdexec running or even have a sample config file?

              I have to problems to configure it in Linux but on pfsense with the -dev package all I can manage to get is the fatal error: "no main menu found in configuration"

              I do have [MainMenu] section in the config

              1 Reply Last reply Reply Quote 0
              • M
                menacingm
                last edited by

                Thank you for the code release fmertz. I can confirm that this is working on the XTM 5 series and corrects the improper keymapping.

                However,
                output 1 caused a green slow blink
                output 2 caused a red slow blink
                output 3 caused a green slow blink
                …
                output 6 caused a red/green blink
                ...
                output 9 caused a red/green blink

                I can test further if you'd like but I just wanted to share my experience. StephenW could probably assist with getting this right.

                @fmertz:

                
                telnet localhost 13666
                hello
                connect LCDproc 0.5.5 protocol 0.3 lcd wid 20 hgt 2 cellwid 5 cellhgt 8
                output 1 <—Should start blinking red, rare short blink
                success
                output 2 <—Should start blinking green, rare short blink
                success
                
                
                1 Reply Last reply Reply Quote 0
                • stephenw10S
                  stephenw10 Netgate Administrator
                  last edited by

                  Nine months after the code release and you're still beaten me to it!  ::)

                  Did you have any problems with starting the service? If you read back through this thread you'll see many, many posts with people trying to find the correct command line to start both lcdd and the php client at boot. It seems very much time dependent such that some boxes start OK while the X-e box ends up with two lcdds running and no client. I spent many hours trying to resolve that and never did which is why I never got around to testing fmertz's code.

                  I haven't tried it under 2.0.3 and I know there was some talk of altering the package start sequence.

                  I'm sure we can fix the led control since it looks to be working to some extent.

                  Steve

                  1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator
                    last edited by

                    Reading through the code for the LED sequencing:

                    • API: Updates LEDs as per "state". Here, "state" is supposed to contain the sequence the LEDs are
                    • to be lit by. We need to support Red, Green and Off. Therefore, we need 2 bits to encode the
                    • possible values. So, a 32 bit "state" can host a sequence of 16 separate illuminations. Each
                    • group of 2 bits is examined in sequence, as a time slot, each time output is called, and the
                    • hardware LEDs are updated accordingly.

                    Thus, output 6 translates to:

                    32 bit Binary 0000 0000 0000 0000 0000 0000 0000 0110

                    2-bit seq 0 0  0 0    0 0  0 0  0 0  0 0    0 0  1 2

                    It does seem as if red and green are swapped but otherwise the sequence is as expected.
                    More interestingly try something like:

                    2-bit seq 0 2  0 2    0 2  0 2  0 2  0 2    1 1  1 1

                    32 bit Binary 0010 0010 0010 0010 0010 0010 0101 0101    00100010001000100010001001010101

                    Decimal 572662357

                    Steve

                    1 Reply Last reply Reply Quote 0
                    • stephenw10S
                      stephenw10 Netgate Administrator
                      last edited by

                      Ok, it's simply the values are the wrong way around in the code:

                      case LPC_DEVICE_82801GBGR: 	/* XTM: W83627THG SuperIO */
                      	shift = 0x48;		/* offset for GPIO BASE */
                      	level = SIO_EFIR;	/* SuperIO chip is hard wired */
                      	level2 = SIO_EFDR;	/* to LPC ports 2E and 2F */
                      	p->red_bit = 0x10;
                      	p->grn_bit = 0x20;
                      	break;
                      

                      My original findings:
                      @stephenw10:

                      Then the led can be controlled via CRF1:

                      Control Register F1     Bit5 Bit4	Arm/Disarm LED
                      0x00			0 0		Off
                      0x10			0 1		Green
                      0x20			1 0		Red
                      0x30			1 1		Off
                      

                      Easy fix!  :)

                      Steve

                      1 Reply Last reply Reply Quote 0
                      • M
                        menacingm
                        last edited by

                        My process for updating the driver was pretty simple. Sopped the LCDproc service from the Web Configurator, SSHd into my box and navigated to /usr/local/lib/lcdproc. Renamed sdeclcd.so to sdeclcd2.so and wget the new build. Checked permissions on sdeclcd.so and it needed a chmod +x. Then I was able to start up LCDProc from the webconfigurator with no problems. Haven't rebooted yet so I'll give that a go now and let you all know how it goes.

                        1 Reply Last reply Reply Quote 0
                        • M
                          menacingm
                          last edited by

                          I can confirm that although it was set to start at boot, the service didn't start after a reboot. It did however start right up manually from the webconfigurator. Here are the logs:

                          Apr 27 20:31:56	LCDd: LCDd version 0.5.5 starting
                          Apr 27 20:31:56	LCDd: Using Configuration File: /usr/local/etc/LCDd.conf
                          Apr 27 20:31:56	LCDd: Listening for queries on 127.0.0.1:13666
                          Apr 27 20:31:56	php: lcdproc: Start client procedure. Error counter: (0)
                          Apr 27 20:31:57	LCDd: Connect from host 127.0.0.1:9995 on socket 11
                          Apr 27 20:31:58	apinger: rrdtool respawning too fast, waiting 300s.
                          Apr 27 20:33:44	php: lcdproc: Sync: Begin package sync
                          Apr 27 20:33:44	check_reload_status: Syncing firewall
                          Apr 27 20:33:44	php: lcdproc: Sync: Restarting the service
                          Apr 27 20:33:45	LCDd: Client on socket 11 disconnected
                          Apr 27 20:33:45	LCDd: sock_send: socket write error
                          Apr 27 20:33:45	LCDd: sock_send: socket write error
                          Apr 27 20:33:45	LCDd: sock_send: socket write error
                          Apr 27 20:33:45	LCDd: sock_send: socket write error
                          Apr 27 20:33:45	LCDd: sock_send: socket write error
                          Apr 27 20:33:45	LCDd: sock_send: socket write error
                          Apr 27 20:33:45	LCDd: sock_send: socket write error
                          Apr 27 20:33:45	LCDd: sock_send: socket write error
                          Apr 27 20:33:45	LCDd: sock_send: socket write error
                          Apr 27 20:33:45	LCDd: sock_send: socket write error
                          Apr 27 20:33:45	LCDd: sock_send: socket write error
                          Apr 27 20:33:45	LCDd: sock_send: socket write error
                          Apr 27 20:33:45	LCDd: sock_send: socket write error
                          Apr 27 20:33:45	LCDd: sock_send: socket write error
                          Apr 27 20:33:45	LCDd: sock_send: socket write error
                          Apr 27 20:33:45	LCDd: Server shutting down on SIGTERM
                          Apr 27 20:33:46	LCDd: sdeclcd: cannot release IO-permission for 0x02E!
                          Apr 27 20:33:46	LCDd: sdeclcd: cannot release IO-permission for 0x02F!
                          Apr 27 20:33:46	LCDd: sdeclcd: cannot release IO-permission for 0x378!
                          Apr 27 20:33:49	php: lcdproc: Sync: End package sync
                          Apr 27 20:33:49	LCDd: LCDd version 0.5.5 starting
                          Apr 27 20:33:49	LCDd: Using Configuration File: /usr/local/etc/LCDd.conf
                          Apr 27 20:33:49	LCDd: Listening for queries on 127.0.0.1:13666
                          Apr 27 20:33:50	php: lcdproc: Start client procedure. Error counter: (0)
                          Apr 27 20:33:51	LCDd: Connect from host 127.0.0.1:3180 on socket 11
                          
                          1 Reply Last reply Reply Quote 0
                          • stephenw10S
                            stephenw10 Netgate Administrator
                            last edited by

                            Ah, disappointing but not unexpected.  :(

                            If you run 'ps aux|grep lcd' or 'ps aux|grep LCD' (there is a switch to make it ignore case but I can't remember it!) you may find it has started several instances of lcdd or is hung up waiting for a php instance to close.
                            Edit: It's 'ps aux|grep -i lcd'

                            Brak had some code the he said worked OK but I never got around to testing it. It's really ridiculous, IMHO, that the packages are restarted so many times at boot especially as something like this never needs to be restarted.

                            Steve

                            1 Reply Last reply Reply Quote 0
                            • M
                              menacingm
                              last edited by

                              Brak's lcdproc.inc only made things worse. Didn't fix the startup issues and on reboot a few other services didn't startup.

                              1 Reply Last reply Reply Quote 0
                              • stephenw10S
                                stephenw10 Netgate Administrator
                                last edited by

                                Damn.  :(
                                There is some underlying problem here. It seems to be only an issue with the sdeclcd driver which means most people don't have a problem.
                                There is nothing obvious in the driver that might be introducing a delay. I have to say that reading through François' code is a joy. Compared to my own feeble efforts his is so professional.  ::)

                                Did you try a longer LED sequence?

                                Steve

                                1 Reply Last reply Reply Quote 0
                                • F
                                  fmertz
                                  last edited by

                                  @stephenw10:

                                  Ok, it's simply the values are the wrong way around in the code:

                                  case LPC_DEVICE_82801GBGR: 	/* XTM: W83627THG SuperIO */
                                  	shift = 0x48;		/* offset for GPIO BASE */
                                  	level = SIO_EFIR;	/* SuperIO chip is hard wired */
                                  	level2 = SIO_EFDR;	/* to LPC ports 2E and 2F */
                                  	p->red_bit = 0x10;
                                  	p->grn_bit = 0x20;
                                  	break;
                                  

                                  My original findings:
                                  @stephenw10:

                                  Then the led can be controlled via CRF1:

                                  Control Register F1     Bit5 Bit4	Arm/Disarm LED
                                  0x00			0 0		Off
                                  0x10			0 1		Green
                                  0x20			1 0		Red
                                  0x30			1 1		Off
                                  

                                  Easy fix!  :)

                                  Steve

                                  Thanks for the heads up. I'll update the code accordingly. Not a bad first run, really, considering this was coded "off the spec"…

                                  1 Reply Last reply Reply Quote 0
                                  • F
                                    fmertz
                                    last edited by

                                    @stephenw10:

                                    There is nothing obvious in the driver that might be introducing a delay. I have to say that reading through François' code is a joy. Compared to my own feeble efforts his is so professional.  ::)

                                    Thanks for the kind words about the code. The idea was to make it clean enough to make it acceptable for the upstream project, and make it available to all, whether I am the maintainer or not. It seemed like a shame to have all that gold information posted on this forum in terms of discoveries, and the countless hours of research that to go with them, without someone collecting it and regurgitating it in proper code form so it never goes extinct. Glad to hear someone is actually reading through it, though.  ;)

                                    Altogether, the LCD spec called for a very specific initialization sequence that takes more time. FWIW, the old code did not seem to properly reset the LCD when things went wrong, and a full reboot was necessary to clear things up. When this new sequence was implemented in the new code, just restarting the LCDproc package was enough to reset the LCD. The new delay is coded as:

                                    
                                    	sdec_exec_wait(SDEC_FN_FUNCTION_SET | SDEC_OPT_8_BIT, 15000);
                                    
                                    

                                    15000 micro seconds, 15ms.

                                    Altogether, drivers control hardware, and should be allowed to have whatever timing quirks are required by the device they control. This includes slow initialization sequences, etc. Maybe the controller code needs to be looked at again. The errors from the driver code complaining of not being able to release the I/O ports might indicate there are multiple copies of this driver in memory…

                                    1 Reply Last reply Reply Quote 0
                                    • M
                                      menacingm
                                      last edited by

                                      Stephen & Francois, glad to have you 2 brilliant minds working on this.

                                      I haven't tried the new driver with the new delay and value order yet, running some development projects behind the pfsense box and need it up and stable for a few more weeks.

                                      Stephen, did you get a chance to test to see if this corrects the SDECLCD driver boot initialization errors?

                                      Francois, has the new SDECLCD driver reached a point where it can be committed to the next point release of lcdproc-dev?

                                      Thanks guys

                                      1 Reply Last reply Reply Quote 0
                                      • stephenw10S
                                        stephenw10 Netgate Administrator
                                        last edited by

                                        It's been accepted upstream so I don't see why not.
                                        I still haven't been able to get it to start cleanly and reliably. To work around this I proposed running the new driver but starting it using the shellcmd package. This avoids more than one start. I've been running several boxes like that for a few weeks with no issues. See: http://forum.pfsense.org/index.php/topic,7920.msg344513.html#msg344513

                                        Steve

                                        1 Reply Last reply Reply Quote 0
                                        • jimpJ
                                          jimp Rebel Alliance Developer Netgate
                                          last edited by

                                          The SDECLCD driver is in the current lcdproc-dev package after I bumped it this week by request. I don't have one any LCDs to try it with, but the correct binary appears to be there now (on 32 and 64 bit) included in the main lcdproc binaries, not pulled in separately anymore.

                                          Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                                          Need help fast? Netgate Global Support!

                                          Do not Chat/PM for help!

                                          1 Reply Last reply Reply Quote 0
                                          • M
                                            menacingm
                                            last edited by

                                            I can confirm the latest LCDProc-Dev/Watchguard SDECLCD driver release available through the official PFSense package install still suffers from the same issues. Key mapping is not correct on the Watchguard XTM5 series and the service fails to start on boot.

                                            I'm not sure if the binary jimp is referring to has been pushed to the official package yet, but I will tinker and report back.

                                            Stephen,

                                            I'm having some trouble getting the right shellcmd to start/restart the LCDProc service. Would you mind sharing that ShellCmd?

                                            Thanks,

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.