Honda Insight Forum banner

LiBCM Touch Screen Discussion

9518 Views 166 Replies 19 Participants Last post by  Natalya
This thread is for discussing any and all features for LiBCM's touch screen. No idea is too crazy!

For my R&D testing, I've purchased the $50 'enhanced' display, but my goal is to design the firmware to work on any 480x320 Nextion display (basic, discovery, or enhanced series). This display's viewable area is about the size of a credit card:

Once the Nextion firmware gets underway, I'll provide a Nextion 10' cable to anyone who wants one.

Timeline:
I don't expect to develop ANY Nextion features for several months. However, @Natalya expressed interest in possibly designing the Nextion firmware, hence I've started this thread as a public discussion for what we want the display to display.

Why Nextion?
I'm not committed to it... if you have other ideas, convince me why I should use them. Note that any display that will work with LiBCM must support all commands and graphics sent from a standard UART.
121 - 140 of 167 Posts

· Premium Member
Joined
·
1,550 Posts
Hi Natalya, any chance this could eventually be configured/wired to autodim when headlights are turned on?
 

· Engine-Off-Coast
Joined
·
2,760 Posts
I'm not sure how it would be able to know that. I don't want to say "no" but I really don't know how to begin figuring that out.
 

· Linsight Designer
Joined
·
4,812 Posts
Discussion Starter · #124 ·
Hi Natalya, any chance this could eventually be configured/wired to autodim when headlights are turned on?
This would need to be done at the LiBCM level... and yes, it's technically possible**, but almost certainly will never happen. A much simpler option is to just have the user press a button to dim the display.

**One concept: Connect a voltage-translated wire from the 12V headlight circuit to a 5V LiBCM GPIO.
 

· Registered
Joined
·
115 Posts
This would need to be done at the LiBCM level... and yes, it's technically possible**, but almost certainly will never happen. A much simpler option is to just have the user press a button to dim the display.

**One concept: Connect a voltage-translated wire from the 12V headlight circuit to a 5V LiBCM GPIO.
The screen itself also has GPIO and could be wired up to the radio harness... as well as another option that would not involve LiBCM itself. You would just have to program the screen to read the GPIO and have an apropriate resistor divider so the 12V doesn't blow up the 3.3v/5V IO.

Another idea might be wiring up a circuit to have a photoeye detect when to dim the screen. Doable but more in the analog domain and a bit more complicated.... it might have the best results though.
 

· Engine-Off-Coast
Joined
·
2,760 Posts
38400 Baud achieved. (was 9600) No matter what I tried I could not get LiBCM to change the Nextion's baud rate, so instead I set it in the .tft file for the Nextion. I don't have these uploaded yet; I'll let y'all know when it's all on github.
 

· Registered
Joined
·
115 Posts
38400 Baud achieved. (was 9600) No matter what I tried I could not get LiBCM to change the Nextion's baud rate, so instead I set it in the .tft file for the Nextion. I don't have these uploaded yet; I'll let y'all know when it's all on github.
Yeah I've never changed it from the UART either... and all the guides say do it from the TFT.
 

· Premium Member
Southern California
Joined
·
973 Posts
This would need to be done at the LiBCM level... and yes, it's technically possible**, but almost certainly will never happen. A much simpler option is to just have the user press a button to dim the display.

**One concept: Connect a voltage-translated wire from the 12V headlight circuit to a 5V LiBCM GPIO.
Future Pegasus integration would let you query the cluster backlight brightness, and you could automatically set the display brightness using that :)
 

· Registered
Joined
·
313 Posts
My Nextion has arrived. Excited to get it going, but not going to happen for a couple weeks. Thank you for your work on this Natalya.

Would it be an accurate assessment that I could pull your code in to the latest beta firmware by making sure these are included:
LiDisplay.cpp
LiDisplay.h

With changes made to:
LiBCM.h
#include "LiDisplay.h"

Config.h
// #define LCD_4X20_CONNECTED //Comment to disable all 4x20 LCD commands
#define LIDISPLAY_CONNECTED //Comment to disable all LiDisplay commands
#define LIDISPLAY_SPLASH_PAGE_MS 2000

Or, have I not looked deep enough in to all the routines in the MVP firmware, where there may be additional calls to your code. If it goes much beyond this, I'll probably just use your firmware as is and update when available.

Thanks
 

· Engine-Off-Coast
Joined
·
2,760 Posts
I can't speak to that. Mine is based off mudder's "main" branch. I last worked on it a week ago but I don't know when he most recently updated main off the top of my head. I have a standard setup with a 5MT and it works, I can't really say much more. I have some updates that aren't pushed yet maybe I can get to those today.
 

· Linsight Designer
Joined
·
4,812 Posts
Discussion Starter · #131 ·
In regards to "mudder's 'main' branch:
It's been a while since I updated 'main': 2022SEP03.
My 'prerelease' branch was last updated: 2022OCT14.
My local (uncommitted prerelease) branch was last updated 2022NOV10. My goal is to push all these changes to 'prerelease' before Tuesday morning... no idea if that will happen.

I really do wish I had half a dozen engineers working on this project... it would certainly get done faster.

...

I think what @mmdepace is asking is: "Can I place @Natalya's LiDisplay.h & LiDisplay.cpp files into @mudder's prerelease branch?" The answer is almost certainly no, and even if it did 'work' there's no guarantee it would work correctly.

@Natalya has been getting the short end of the stick on this firmware development process. Here she is spending her free time creating this code, and I'm just sitting on her merge requests for weeks/months on end. I also haven't even tried to use her LiDisplay firmware again for over a month. It's not fair to her and for that I apologize. Thank you for your patience and continued effort, despite my poor co-engineering skills.
 

· Engine-Off-Coast
Joined
·
2,760 Posts
@mudder It's all good! If you can eventually get all the prerelease branch stuff merged into main then I can update mine with the updated main code and at that point LiDisplay will be ready to be pulled into main.
 

· Engine-Off-Coast
Joined
·
2,760 Posts
I cannot get communication from the Nextion to the Arduino to work reliably. I can't tell if the data is being sent wrong from the Nextion, or received wrong by the Arduino. I can't reliably send even two bytes.

Example Arduino code:
Code:
        if (cmd = Serial1.available()) {
            Serial.print(F("\nSerial1 cmd_str: "));
            Serial.write(cmd);
            Serial.print('|');
            Serial.print(cmd);
            Serial.print('|');
            Serial.print(cmd,HEX);
            Serial.print(' ');

            buffer = Serial1.read();
            Serial.write(buffer);
            Serial.print('|');
            Serial.print(buffer);
            Serial.print('|');
            Serial.print(buffer,HEX);
            Serial.print(' ');

            buffer = Serial1.read();
            Serial.write(buffer);
            Serial.print('|');
            Serial.print(buffer);
            Serial.print('|');
            Serial.print(buffer,HEX);
            Serial.print(' ');

            buffer = Serial1.read();
            Serial.write(buffer);
            Serial.print('|');
            Serial.print(buffer);
            Serial.print('|');
            Serial.print(buffer,HEX);
            Serial.print(' ');

            buffer = Serial1.read();
            Serial.write(buffer);
            Serial.print('|');
            Serial.print(buffer);
            Serial.print('|');
            Serial.print(buffer,HEX);
            Serial.print(' ');

            buffer = Serial1.read();
            Serial.write(buffer);
            Serial.print('|');
            Serial.print(buffer);
            Serial.print('|');
            Serial.print(buffer,HEX);
            Serial.print(' ');

            buffer = Serial1.read();
            Serial.write(buffer);
            Serial.print('|');
            Serial.print(buffer);
            Serial.print('|');
            Serial.print(buffer,HEX);

            buffer = 0;
        }
Example Nextion code from page p0 button b0 touch release event:
Code:
printh 30 30
Expected Output:
Code:
Serial1 cmd_str: 0|30|0 0|30|0 �|255|FF �|255|FF �|255|FF �|255|FF �|255|FF
Actual Output:
Code:
Serial1 cmd_str: |1|1 �|254|FE �|255|FF �|255|FF �|255|FF �|255|FF �|255|FF
I've tried all kinds of permutations, with longer printh chains, but I could only ever get a maximum of 3 bytes back (sometimes) and the rest FF (meaning nothing to read) so I tried a really short one and it still doesn't work.

I don't know what to try next. But until I can send info from LiDisplay to LiBCM we can't use any buttons on LiDisplay.
 

· Engine-Off-Coast
Joined
·
2,760 Posts
Speedometer Car Motor vehicle Gauge Steering part



The screen itself is better than ever. I added LiBCM temp in degrees C beneath the high and low cell voltages. 38400 baud communication rate seems to be working well too. I dropped the screen element refresh rate to 80ms and haven't had any issues.
 

· Engine-Off-Coast
Joined
·
2,760 Posts
Tried adding a 100ms delay...

Code:
        if (LiDisplayWaitingForCommand > 0) {
            LiDisplayWaitingForCommand -= 1;
        }

        if (LiDisplayWaitingForCommand == 1) {

            LiDisplayWaitingForCommand -= 1;

            Serial.print(Serial1.read());
            Serial.print(' ');
            Serial.print(Serial1.read());
            Serial.print(' ');
            Serial.print(Serial1.read());
            Serial.print(' ');
            Serial.print(Serial1.read());
            Serial.print(' ');
            Serial.print(Serial1.read());
            Serial.print(' ');
            Serial.print(Serial1.read());
            Serial.print(' ');

            buffer = 0;
        }

        if (Serial1.available() && (LiDisplayWaitingForCommand == 0)) {
            Serial.print(F("\nSerial1 Available: "));
            LiDisplayWaitingForCommand = 100;
        }
Nextion Code:
Code:
printh 30 30
Expected Output:
Code:
Serial1 Available: 0 0 -1 -1 -1 -1
Actual Output:
Code:
Serial1 Available: 254 -1 -1 -1 -1 -1
I'm pretty sure the message is being sent fast enough. It just doesn't show up correctly.
 

· Registered
Joined
·
2,358 Posts
I cannot get communication from the Nextion to the Arduino to work reliably. I can't tell if the data is being sent wrong from the Nextion, or received wrong by the Arduino. I can't reliably send even two bytes.

Example Arduino code:
Code:
        if (cmd = Serial1.available()) {
            Serial.print(F("\nSerial1 cmd_str: "));
            Serial.write(cmd);
            Serial.print('|');
            Serial.print(cmd);
            Serial.print('|');
            Serial.print(cmd,HEX);
            Serial.print(' ');

            buffer = Serial1.read();
            Serial.write(buffer);
            Serial.print('|');
            Serial.print(buffer);
            Serial.print('|');
            Serial.print(buffer,HEX);
            Serial.print(' ');

            buffer = Serial1.read();
            Serial.write(buffer);
            Serial.print('|');
            Serial.print(buffer);
            Serial.print('|');
            Serial.print(buffer,HEX);
            Serial.print(' ');

            buffer = Serial1.read();
            Serial.write(buffer);
            Serial.print('|');
            Serial.print(buffer);
            Serial.print('|');
            Serial.print(buffer,HEX);
            Serial.print(' ');

            buffer = Serial1.read();
            Serial.write(buffer);
            Serial.print('|');
            Serial.print(buffer);
            Serial.print('|');
            Serial.print(buffer,HEX);
            Serial.print(' ');

            buffer = Serial1.read();
            Serial.write(buffer);
            Serial.print('|');
            Serial.print(buffer);
            Serial.print('|');
            Serial.print(buffer,HEX);
            Serial.print(' ');

            buffer = Serial1.read();
            Serial.write(buffer);
            Serial.print('|');
            Serial.print(buffer);
            Serial.print('|');
            Serial.print(buffer,HEX);

            buffer = 0;
        }
Example Nextion code from page p0 button b0 touch release event:
Code:
printh 30 30
Expected Output:
Code:
Serial1 cmd_str: 0|30|0 0|30|0 �|255|FF �|255|FF �|255|FF �|255|FF �|255|FF
Actual Output:
Code:
Serial1 cmd_str: |1|1 �|254|FE �|255|FF �|255|FF �|255|FF �|255|FF �|255|FF
I've tried all kinds of permutations, with longer printh chains, but I could only ever get a maximum of 3 bytes back (sometimes) and the rest FF (meaning nothing to read) so I tried a really short one and it still doesn't work.

I don't know what to try next. But until I can send info from LiDisplay to LiBCM we can't use any buttons on LiDisplay.
You could try putting one of these on each end of the connection. Since you are only going one way, you can tie the enable pins high on one end and low on the other.

<edit> never mind. I misread your post. You are trying to go both directions. This may work (assuming that the problem is noise and not a software issue) but you would need an extra GPIO signal on each end to set the transceiver state to send or receive.</edit>
 

· Linsight Designer
Joined
·
4,812 Posts
Discussion Starter · #138 ·
You should add code to LiBCM to output the serial data it receives from Nextion via the USB serial port... that'll let you know what LiBCM 'sees'.
 

· Registered
Joined
·
2,358 Posts
Tried adding a 100ms delay...

Code:
        if (LiDisplayWaitingForCommand > 0) {
            LiDisplayWaitingForCommand -= 1;
        }

        if (LiDisplayWaitingForCommand == 1) {

            LiDisplayWaitingForCommand -= 1;

            Serial.print(Serial1.read());
            Serial.print(' ');
            Serial.print(Serial1.read());
            Serial.print(' ');
            Serial.print(Serial1.read());
            Serial.print(' ');
            Serial.print(Serial1.read());
            Serial.print(' ');
            Serial.print(Serial1.read());
            Serial.print(' ');
            Serial.print(Serial1.read());
            Serial.print(' ');

            buffer = 0;
        }

        if (Serial1.available() && (LiDisplayWaitingForCommand == 0)) {
            Serial.print(F("\nSerial1 Available: "));
            LiDisplayWaitingForCommand = 100;
        }
Nextion Code:
Code:
printh 30 30
Expected Output:
Code:
Serial1 Available: 0 0 -1 -1 -1 -1
Actual Output:
Code:
Serial1 Available: 254 -1 -1 -1 -1 -1
I'm pretty sure the message is being sent fast enough. It just doesn't show up correctly.
The "-1" is what Serial.read() returns if there is no data available. Serial.read() does not wait until data is available.

Serial.available() tells you if there is at least one byte available. If you try to read more bytes than are available, you will start getting -1 when there is no byte for Serial.read() to return.

So if you are using Serial.avaiable() to see if ANYTHING has come in, you can then call Serial.read() in a loop, but once you get a -1, that means there's no more data in the serial buffer.

If you sit in a tight loop waiting for Serial.read() to return something other than -1, or sit in a tight loop waiting for Serial.available() to return true, other code won't be able to run, something you have undoubtedly already expreienced. This is called blocking. There are many strategies for dealing with this. Welcome to the world of cooperative multitasking.
 

· Engine-Off-Coast
Joined
·
2,760 Posts
You should add code to LiBCM to output the serial data it receives from Nextion via the USB serial port... that'll let you know what LiBCM 'sees'.
I thought that's what I was doing here. Are you saying there's a more direct way than to use Serial.print(Serial1.read()) ?
 
121 - 140 of 167 Posts
Top