[*sean*]

@Natalya Just posting because I've been wanting to say for a while that I've been following this and it is nice to see a graphical interface for this stuff. Nice job on converting @Mario 's graphics.

 

[joeaax1j]

Hi Natalya, any chance this could eventually be configured/wired to autodim when headlights are turned on?

 

[Natalya]

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.

 

[mudder]

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.

 

[cb88]

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.

 

[Natalya]

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.

 

[cb88]

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.

 

[Mario]

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

 

[mmdepace]

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

 

[Natalya]

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.

 

[mudder]

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.

 

[Natalya]

@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.

 

[Natalya]

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:

        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:

printh 30 30

Expected Output:

Serial1 cmd_str: 0|30|0 0|30|0 �|255|FF �|255|FF �|255|FF �|255|FF �|255|FF

Actual Output:

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.

 

[Natalya]

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.

 

[Natalya]

Tried adding a 100ms delay...

        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:

printh 30 30

Expected Output:

Serial1 Available: 0 0 -1 -1 -1 -1

Actual Output:

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.

 

[*sean*]

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:

        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:

printh 30 30

Expected Output:

Serial1 cmd_str: 0|30|0 0|30|0 �|255|FF �|255|FF �|255|FF �|255|FF �|255|FF

Actual Output:

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>

Amazon.com: 12Pcs MAX485 RS485 Transceiver Module TTL UART Serial to RS485 Instrument Interface Module Max458 Chip RS-485 Communication Transceiver 5V SCM Development Accessories Board for Raspberry Pi : Electronics

Amazon.com: 12Pcs MAX485 RS485 Transceiver Module TTL UART Serial to RS485 Instrument Interface Module Max458 Chip RS-485 Communication Transceiver 5V SCM Development Accessories Board for Raspberry Pi : Electronics

www.amazon.com

 

[Natalya]

I really don't know what the problem is.

 

[mudder]

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'.

 

[*sean*]

Tried adding a 100ms delay...

        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:

printh 30 30

Expected Output:

Serial1 Available: 0 0 -1 -1 -1 -1

Actual Output:

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.

 

[Natalya]

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()) ?