Asking again about options with this display

[Trying_to_learn]

I have one of these displays:

SparkFun 20x4 SerLCD - RGB Backlight (Qwiic) - LCD-16398 - SparkFun Electronics

It has 3 kinds of comms options.
I2C
SPI
and another one...

(What ever)

I sort of have it working, but it isn't perfect.

After more digging I have been told of this:

http://www.cpmspectrepi.uk/raspberry_pi ... gData.html

Which is indicative of timing problems.

Ok, so if it is that, I am guessing that all bets are off and there is SFA I can do about it.

As is I am using the I2C and sending code/messages to it via MQTT to a python(3) program that then sends the messages to the display.

Would there be a way to talk to it directly within Node-Red?
Rather than using MQTT and a python script.

[smcgann99]

@Trying_to_learn

and another one.

Looks like the other one is serial port, did you look at using that with serial out node ?
Do you actually want it connected to the Pi ie in the same location ?

[smcgann99]

@Trying_to_learn

As is I am using the I2C and sending code/messages to it via MQTT to a python(3) program that then sends the messages to the display.

Thinking about it, its the python code that would handle all the data and timing etc. So if it works ok from the command line then using NR to send the same data to the python code shouldn't cause an issue ?

[Trying_to_learn]

Which GPIO pin(s) does the serial out appear?

[smcgann99]

If you just google rpi 4 pinout you will find lots of drawings.

However I wouldn't worry about that, does the display work OK using Python from the command line using any supplied examples ?

[Trying_to_learn]

The display is working as best I can see.

you/we are not on quite the same page.

GPIO pin ....14 is HEADER pin 9.

It would be a LOT easier if it was called PIN 9.

Your question:

@smcgann99

does the display work OK using Python from the command line using any supplied examples

Is confusing.

WORK is a bit vague to use in this sense.
It works as in it shows what I send. But if it is used by Node-Red in an ongoing scenario, these rogue characters appear.

So it is working, or isn't it?

After other digging I have been told there is a known problem with the timing.

(mentioned above)

As this display has a serial in option: would that work if I changed the code and send stuff to it via the serial node - and, of course - moved the wire/s from where they are to pin 9 (GPIO 14) and the serial in on the display.

[smcgann99]

So my question is does it work perfectly from the command line ?

If so then I don't think that sending data to the python scripts from node red would cause any timing issues.

So how are you doing the last bit ?

[Trying_to_learn]

@smcgann99

So my question is does it work perfectly from the command line ?

Again, this is a vague question - to me.

I never talk to it from the CLI. (Command line)

I ONLY use python.

Node-red sends MQTT messages which are received by the python script and it converts them to be able to be sent on the I2C bus.

@smcgann99

sending data to the python scripts from node red would cause any timing issues.

That isn't where the timing issue is claimed to be. It is in the timing of sending messages on the I2C bus.
Native to the RasPi.

I am going to have to connect a monitor and run a program to simulate having a CRO connected to the Pi and look at the timing.

Though if it is a native timing problem I may be better off investing time in working out how to use the serial port on the display.

(and) just now a few other jobs are very important to get resolved.

[smcgann99]

@Trying_to_learn

GPIO pin ....14 is HEADER pin 9.

Pins / GPIO

[smcgann99]

@Trying_to_learn

Again, this is a vague question - to me.

I never talk to it from the CLI. (Command line)

I ONLY use python.

Bearing in mind this is a NR forum and I don't have your display or software -

I'm assuming that you run a python script from the command line ?

@Trying_to_learn

The display is working as best I can see

@Trying_to_learn

WORK is a bit vague to use in this sense.
It works as in it shows what I send

So I do not see how it can be an I2c timing issue, since the python script must be using I2c at this point and works OK.
Can you provide more info on how you get a message from NR into the python script.

[mharsch]

I've just published a node for these displays (Sparkfun SerLCD):

@mharsch/node-red-serlcd

Feedback always welcome; please submit via Github issues.

[Trying_to_learn]

Thanks.

I'll look at it when I can.

Just that in the mean time, I have for things working and found the I2C bus problematic with some displays.

[Trying_to_learn]

Just to put all up to date:

Using the said display and controlling it with the I2C bus:
Now and then weird characters would appear.

As it has a comm port I changed the code to talk to it via the comms port.

It ran for days and no weird characters.

So I am leaving well enough alone.

I2C is problematic. Comm port isn't.

Overview:
Both ways the display was controlled by python(3).

This is because there was no easy way to get the information from NR to the display via the script.
(That is a whole other thing)

So a python program was written and it worked - via I2C.
Things were ok at the start.
Then every now and then weird characters would appear at non addressed positions on the screen.

Asking around it was said that this may be a timing problem. I don't get that as I2C is supposed to be self timed.... But that's what was said by people smarter than me.

I then changed the code and talked to the display via the COMM port.

No weird characters.

What more can I say?

[Trying_to_learn]

I send the message to the python script by MQTT - in both cases.

[smcgann99]

@smcgann99

Looks like the other one is serial port...

That was a while ago - glad you got it working