[joeaax1j]

I will say . . . one nice thing about an onboard display is the potential for an easy to read summary of what the charger is doing. I'm thinking about a large font, single word summary like "CHARGING", "BALANCING", etc. It would be nice to be able to quickly see what the charger is doing, without having to get into the car to see the small font display specifics. Then, if you want more specific details, you can always tap the screen to have it go into more specifics. Not sure if this is possible, but maybe instead of the CHARGING, etc. it could show "X min. until full", etc.

 

[*sean*]

Honestly if we go this route, then a (possibly) simpler solution would be to use a raspberry pi (or equivalent), with a touch screen display. At that point, we'd basically have a complete linux box plugged into LiBCM... so the sky is the limit as far as what to do with the serial data coming from LiBCM.

My LTO build is waiting for me to complete a touchscreen that fills the radio opening from edge to edge, driven by a Raspberry Pi mounted in a gutted radio chassis, that replaces the car stereo. But I lose the car stereo, and I've buzzed out a cheap car stereo to control directly from the Pi. This project is perhaps too big. Because even if you were to just have a Pi with a small display in a pre-built box, there's still the question of running it off 12V, tweaking it so that it boots quickly (it will still take seconds to come alive), setting it up with a read-only root so that power loss doesn't corrupt the filesystem, the fact that you are not just maintaining a single application but an entire OS image, etc.

I've decided to go this route, because for all the work involved, "the sky is the limit", there are many things I want to add, and it is not a product so I don't have to support it.

Unless you use a Pi 1 A+, Pi 3 A+ or Pi Zero, they're going to have wifi and bluetooth hardware which you will have to explicitly disable if you are particularly paranoid.

An MVP of a Pi Zero plus a TFT touchscreen display and an RS-485 module talking to another module at the far end, which loads a very minimal window manager (ie TWM) might be a nice starting point.

However, Arduino + TFT touchscreen is a fast booting, well known solution with plenty of graphics recipes on Github. If you want instantaneous booting, check out the AVR128DA28 for which Arduino support exists; the programmer dumps the code directly into flash and your code runs immediately upon power-up unless you explicitly tell the microprocessor how long you want to delay program execution after powerup.

 

[*sean*]

Oh yes, an e-paper display might be nice to have as a way to display battery state when the car is off while consuming negligible current.

 

[Natalya]

Nextion came in today!

 

[minor4326]

Is it possible for the hardware and software for wireless to be incorporated but commented-out? In this way the owner could activate said software. Or have the code very basic and a knowledgeable coder could 'complete' the job after its released. Would @mudder have responsibility for the FCC testing?

 

[mmdepace]

Looking forward to having ability to change configs without using laptop. Currently turning on & off Key_Off_Cell_Balance in the morning and afternoon due to battery getting quite out of balance on morning commute, but do not want to be pulling superwarmed cabin air across it in the afternoon.

 

[mudder]

Is it possible for the hardware and software for wireless to be incorporated but commented-out? In this way the owner could activate said software. Or have the code very basic and a knowledgeable coder could 'complete' the job after its released. Would @mudder have responsibility for the FCC testing?

The LiBCM firmware could theoretically be identical if you used an off-the-shelf BLE<->UART product, which entirely handles the conversion from Bluetooth to serial data. You'd only need to write the software for the phone (or other wireless device).

If someone wants to do all the work writing the iPhone/Android apps, the PHY and LiBCM code will support it... but I will never sell the BLE<->UART hardware with the LiBCM kit... people would need to buy it on Amazon and install it themselves

Looking forward to having ability to change configs without using laptop. Currently turning on & off Key_Off_Cell_Balance in the morning and afternoon due to battery getting quite out of balance on morning commute, but do not want to be pulling superwarmed cabin air across it in the afternoon.

Can you post more info about this in the LiBCM Open Beta support thread? How much voltage delta are you getting after how many miles? Why are you having to disable/re-enable key-off cell balancing each morning and afternoon (LiBCM does this all automatically, so are you worried about battery drain)? etc.

 

[Balto]

Looking forward to having ability to change configs without using laptop. Currently turning on & off Key_Off_Cell_Balance in the morning and afternoon due to battery getting quite out of balance on morning commute, but do not want to be pulling superwarmed cabin air across it in the afternoon.

Yea that's nuts. I haven't grid charged my pack in close to 2 months and have cell balancing OFF completely and I'm only at 0.006 delta right now.

 

[UK_MJN]

One thought from me...
I'd definitely want to change config parameters (e.g. inhibit background charge) and select data of interest, capture peak readings like a bicycle computer etc (I'm well used to those!)
But, I'd like to be able to default everything back to user friendly standard for my partner, regardless of what changes I've made, preferably with just one action/press.

Edit: same goes for mechanics and government testers, make it nice and simple with one press.

 

[Natalya]

Downloading Nextion software right now. Really excited about this.

 

[WillS]

Long time lurker here ... the phone app would be a nice addition to whatever customized monitors and controls have already been developed for honda hybrids. If anyone has found an app that works even semi functional for insight or any other honda hybrid, don't be shy, share your experiences. A cool / hot? project for someone into building phone apps for honda. I even wish my hds would connect to the IMA without a second board add on or software update from the vendor on the other side of the planet.

NiMH is a love hate relationship

 

[Natalya]

Hey @mudder what pins do I wire the Nextion to?

So far I've got the most rudimentary display ever... just a SoC % number display, a bar graph of it, and a spot for the LiBCM software version number. I want to test it out all hooked up before I go further.

 

[mudder]

The pins hook up to the "LiDisplay" shrouded right angle connector marked "LiDisplay", which is just to the right of the USB connector (and accessible even with the clear cover installed). The pins are VCC/RX/TX/OD**, in that order.

**OD: Open Drain. This allows LiBCM to turn the Nextion display off entirely when the car is off (to save power). You can control the OD state with functions gpio_turnHMI_off() and gpio_turnHMI_on(), which are presently configured to turn the display on whenever the key is on... so for now the display should turn on when the key is on, and off when the key is off.

...

Next we need to write the firmware for LiBCM to send/receive serial data to/from the Nextion... that's not too much work and I can do that this week. I need to know what data I'm supposed to send to the Nextion... the Nextion Editor should give you a list of configuration parameters based on whatever code you write. Let me know what those custom packets are and I'll add them to the LiDisplay.c framework this week.

We should test both sending and receiving data... so maybe add a button to make LiBCM beep the buzzer (so we can verify it works without affecting the actual runtime code).

 

[Natalya]

I was able to program a rudimentary display for the Nextion, and it shows, but so far I can't get anything on the screen to update from LiBCM. In LiBCM.cpp I'm using the Serial1 functions. Are they correctly set up to send data on the wires going to the Nextion?

 

[retepsnikrep]

This was my Nextion stuff in a zip file.
I drove it with an OBDIIC&C (logging port) on the bench for testing.
Might be useful for you. I haven't looked at it for over a year.

 

[mudder]

I was able to program a rudimentary display for the Nextion, and it shows, but so far I can't get anything on the screen to update from LiBCM. In LiBCM.cpp I'm using the Serial1 functions. Are they correctly set up to send data on the wires going to the Nextion?

See LiDisplay.cpp... I will pull pretty much anything logical you write inside this file.
Inside I've defined the following abstraction functions (to Serial1):
LiDisplay_begin() //this will correctly setup LiBCM to transmit/receive data to the Nextion
LiDisplay_bytesAvailableForWrite()
LiDisplay_writeByte()
LiDisplay_readByte()
LiDisplay_bytesAvailableToRead()

...

My recommendation is to mirror the function USB_userInterface_handler()... as something like "LiDisplay_hander()"... that'll be the only function you call outside of LiDisplay.cpp (every time the main loop executes)... so if LiDisplay wants LiBCM to do something, then LiDisplay_handler() needs to call out (into the other files) as needed.

...

LiBCM isn't going to have the bandwidth to update every display element on LiDisplay every time through the main loop... so you need to update one (or maybe a few) items each time through the loop. You can see how I do this with the existing 4x20 display by looking at the state machine within lcd_refresh().

It doesn't have to be the same, but again, just a framework on how to build a state machine to transmit just a little bit of data each call... the goal is to NEVER send more data than there is room for it in the serial transmit buffer (63 bytes max). You can query this value with LiDisplay_bytesAvailableForWrite(). If you overfill the buffer, you won't lose data, but the code will hang until there are fewer than 63 bytes in the transmit buffer (i.e. the serial transmit buffer is blocking when full)... so never overfill the buffer or LiBCM won't meet timing.

LiBCM's superloop runs at 100 Hz... I believe the default Nextion baud rate is 9600 bps... at that rate, you shouldn't send more than ~20 ascii characters per iteration (or you will immediately/eventually overflow the buffer). Of course, if the buffer is empty, you can fill it completely (all 63 bytes) in one run... but then you can't send anything until the buffer is less full again. If you want to send more than that, then you'll need to increase the baud rate (if possible).

LiDisplay_readByte() also has a 63 element buffer, so you should read it entirely whenever data is available (because at 9600 baud LiDisplay can overflow the receive buffer in 3 cycles). As before, I recommend reading into a circular buffer similar to USB_userInterface_handler.

If any of this is unclear, it's because I wrote it in a hurry. Please ask questions as often as you need to. As always, thanks for any and all firmware help.

 

[mudder]

This was my Nextion stuff in a zip file.
Might be useful for you. I haven't looked at it for over a year.

Did you just get busy? Or was there something you didn't like about Nextion (besides cost)?

 

[retepsnikrep]

Busy mainly.
With all this stuff Arduino/Nextion etc etc you have to put in a lot of work learning a new IDE/structure/language.
I just don't have the time at the moment due to my other PIC based projects/travel plans etc.

 

[Natalya]

I can't get the Nextion to receive any information from LiBCM. Is Serial1 configured properly?

//Copyright 2021-2022(c) John Sullivan
//github.com/doppelhub/Honda_Insight_LiBCM

//LiDisplay (HMI) Serial Functions

#include "libcm.h"

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

void LiDisplay_begin(void)
{
  Serial.print(F("\nLiDisplay BEGIN"));
  Serial1.begin(9600,SERIAL_8E1);
  Serial1.print("page0.t1.txt=" + String('"') + String(FW_VERSION) + String('"'));
  Serial1.write(0xFF);
  Serial1.write(0xFF);
  Serial1.write(0xFF);
  Serial1.print("page0.n0.val=" + String('"') + SoC_getBatteryStateNow_percent() + String('"'));
  Serial1.write(0xFF);
  Serial1.write(0xFF);
  Serial1.write(0xFF);
  Serial1.print("page0.j0.val=" + String('"') + SoC_getBatteryStateNow_percent() + String('"'));
  Serial1.write(0xFF);
  Serial1.write(0xFF);
  Serial1.write(0xFF);
  Serial.print(F("\nLiDisplay SENT"));

  //LiDisplay_writeByte(SoC_getBatteryStateNow_percent());


  //LiDisplay_writeByte(SoC_getBatteryStateNow_percent());

}

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

uint8_t LiDisplay_bytesAvailableForWrite(void)
{
  return Serial1.availableForWrite();
}

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

uint8_t LiDisplay_writeByte(uint8_t data)
{
  Serial1.write(data);
  return data;
}

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

uint8_t LiDisplay_readByte(void)
{
  return Serial1.read();
}

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

uint8_t LiDisplay_bytesAvailableToRead()
{
  return Serial1.available();
}

I'm just trying to get it to display firmware version and SoC when it's turned on. There's only 1 page. t1 is a text box. n0 is a number box. j0 is a bar graph.

 

[Natalya]

Okay forget above post. First progress I've had so far... I got this to display the version number:

//Copyright 2021-2022(c) John Sullivan
//github.com/doppelhub/Honda_Insight_LiBCM
//LiDisplay (HMI) Serial Functions
#include "libcm.h"
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
void LiDisplay_begin(void)
{
  Serial.print(F("\nLiDisplay BEGIN"));
  Serial1.begin(9600,SERIAL_8E1);
  Serial1.print("page0.t1.txt=" + String('"') + String(FW_VERSION) + String('"'));
  Serial1.write(0xFF);
  Serial1.write(0xFF);
  Serial1.write(0xFF);
  Serial1.print("page0.n0.val=" + String('"') + String(SoC_getBatteryStateNow_percent()) + String('"'));
  Serial1.write(0xFF);
  Serial1.write(0xFF);
  Serial1.write(0xFF);
/*  Serial1.print("page0.j0.val=" + String('"') + String(SoC_getBatteryStateNow_percent()) + String('"'));
  Serial1.write(0xFF);
  Serial1.write(0xFF);
  Serial1.write(0xFF); */
  Serial.print(F("\nLiDisplay SENT"));
  //LiDisplay_writeByte(SoC_getBatteryStateNow_percent());
}
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
uint8_t LiDisplay_bytesAvailableForWrite(void)
{
  return Serial1.availableForWrite();
}
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
uint8_t LiDisplay_writeByte(uint8_t data)
{
  Serial1.write(data);
  return data;
}
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
uint8_t LiDisplay_readByte(void)
{
  return Serial1.read();
}
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
uint8_t LiDisplay_bytesAvailableToRead()
{
  return Serial1.available();
}

Still wouldn't update the number with the SoC. But maybe the buffer is overflowed that fast.

To make this work I (temporarily) put LiDisplay_begin() into metsci.cpp because it has a loop. This made the nextion reset over and over again but it did display the version number.

I think what this means is the initial placement of LiDisplay_begin() in MVP.ino in void setup() has it running too early and the Nextion isn't turned on or something so it never gets the data.

So LiDisplay_begin() doesn't need to attempt to display anything.

I'll keep experimenting.