However, the text shows up on the LCD only if I have the serial monitor of the Arduino IDE open.If I close the serial monitor, nothing will show up on the LCD. If I then reopen the serial monitor, the text will print on the LCD.

Is this a normal behaviour? If yes, is there a workaround to avoid it?

To your second point, I'm absolutely with you. But I had to do something like that because I'm waiting the constantly for text input on the serial from the raspberry. Therefore I need to loop it to poll for something on the line.

'/n' is not a single character. It is a multi byte character consisting of a slash 0x2f and an n 0x6e or the value 0x2f6eIf you pass that value to a function that expects char type then the upper 8 bits are truncated and the char value will be 0x6e or a character n which is not a new line.If you intended it to be a newline that is '\n'

If you had warnings turned on in the IDE (which I highly recommend ALWAYS enabling) you would see a nice red warning message in the IDE window warning you about where you were using this "character".

Also, in order to use that with the serial monitor you must make sure that a newline is what is sent when you press the <ENTER> key. The IDE serial monitor has a setting to set what gets sent when that key is pressed.

----BTW, IMO, Microsoft really made a mess of things when it comes to backslahes vs slashes and line terminations - although Apple also screwed up line terminations as well - especially since Unix had figured all this stuff out more than 10 years before either of them came along.

'/n' is not a single character. It is a multi byte character consisting of a slash 0x2f and an n 0x6e or the value 0x2f6eIf you pass that value to a function that expects char type then the upper 8 bits are truncated and the char value will be 0x6e or a character n which is not a new line.If you intended it to be a newline that is '\n'

Does the problem with the two characters solve by using \n or are they also counted as two characters?

I used a function given by the Serial Library, which is called when data is available on the Serial line.

But one problem persists. When I send text to the arduino from the raspberry, the first text input is ignored. So for exemple if I send "Hello", the first time I send it, it is like discarded and not shown on the LCD. When I send it the second time all works as it should.

If I open the Serial monitor, instead and to the same actions as above, the first Input is shown to the LCD too.

Seems strange to me, but maybe there is something I'm overlooking. Any ideas?

I did see the // in your code, but assumed it was some copy mistake.That's why they were missing in my example.

What i showed is not exactly the same as what you did.Because you commented out the condition (that serial is available), your code will wait until it sees the \n.I don't know whether there is some time out There is a time out, you can set its value.But for the duration of that time out or until the \n arrives, execution of code is halted.So that is blocking code.Once the \n passes, the data is sent to the display.

My suggestion (based on what you had before) was sending data to the LCD, regardless of an update to the buffer you created and holding that data.That's also why i made the 2nd remark.But because the condition is still in place, it is less blocking.

But you made some changes to your code, and it improved but still isn't what you want it to be.Did you do your tests sending the same string ?Because that would make it harder to know what exactly is printed to your LCD.In that case it might turn out interesting to send "Hello 1", followed by "Hello 2", and so on.But you might have done some similar test already, i don't know.

Hi.I had a problem with the posting of my thread. I wrote it before you sent your last reply @MAS3, but I don't know if it was posted. For this reason, could you kindly tell me if you are referring to my last reply (4pm) or to the one before it?

Another issue you may soon run into is if the number of characters in the string being printed is more than the number of characters on an LCD line.But we don't know much about your code or your final intentions as you have not shown us your code or told us what you intend to do.

Most lcd keypad shields use a 2x16 display so if you send more than 16 characters to the LCD there will be an issue since since the extra characters will go into LCD memory but will not wrap to the next line on the LCD display.This is because the hd44780 LCD module is very dumb and does not support any sort of line wrapping. In fact the LCD module chips don't even know the LCD geometry of the physical display.

If you want line wrapping, you could use my hd44780 library with the hd44780_pinIO class which supports end of line wrapping.You can install it with the IDE library manager.You can read more about it here: https://github.com/duinoWitchery/hd44780

But you made some changes to your code, and it improved but still isn't what you want it to be.Did you do your tests sending the same string ?Because that would make it harder to know what exactly is printed to your LCD.In that case it might turn out interesting to send "Hello 1", followed by "Hello 2", and so on.But you might have done some similar test already, i don't know.

Due to this part of text, I think you really referred to my last post (4pm), sorry. As you already stated, I did a similar test as the one you said.I declared a variable with value 10 and everytime new data was sent from the raspberry to the arduino (so on the serial line), the variable was first decreased by one and then the value of the variable was printed on the LCD. The result of the test was: the first time I sent the text from the raspberry, nothing showed up on the LCD, the second time I sent a text the number 9 showed up on the LCD, the third time the number 8 and so on.To me it sounds like the first text isn't even correctly received, because in that case, for the second text I sent, the number 8 should have been printed out on the LCD.

Another issue you may soon run into is if the number of characters in the string being printed is more than the number of characters on an LCD line.But we don't know much about your code or your final intentions as you have not shown us your code or told us what you intend to do.

Most lcd keypad shields use a 2x16 display so if you send more than 16 characters to the LCD there will be an issue since since the extra characters will go into LCD memory but will not wrap to the next line on the LCD display.This is because the hd44780 LCD module is very dumb and does not support any sort of line wrapping. In fact the LCD module chips don't even know the LCD geometry of the physical display.

If you want line wrapping, you could use my hd44780 library with the hd44780_pinIO class which supports end of line wrapping.You can install it with the IDE library manager.You can read more about it here: https://github.com/duinoWitchery/hd44780

--- bill

Many thanks for your proactive help!Honestly I already encountered that problem and my tought was to create a special pattern in the text I send (e.g. "/$/") and use the functions that the String class offers to divide my text by that pattern.For example I send "Hello /$/ All!", and take the text until I encounter the /$/ divider, and put it on the first line with lcd.cursor. The part after the divider pattern will then be on the second line, with lcd.cursor.I really don't know if this solution even works or if it is appropriate, because I didn't implement it yet.However I will at first give a try to your library on GitHub.

Unfortunately I already shutdown all my "IoT Infrastructure" for today, so I will post the full code of my Arduino and the python code of the raspberry, tomorrow (I actually will soon do a GitHub repository for my whole project, just in case someone is interested in a diy surveillance system ).

I was indeed addressing both of your posts since my last reply.You asked while referring to the timestamps of your posts, but these forum timestamps are tied to a user's time zone.We seem to be in different time zones so that doesn't help too much in identifying which post you are mentioning.

So you did do a similar test.It's always helpful to tell about what you already did try and what you learned from that.Because someone willing to help can't know what you left out and might suggest things you already tried.But good for you that you already tried that to be sure what's going on is what you suspected to be happening.

bperrybap's library is also my new standard library for these types of displays, i really like it.

So you did do a similar test.It's always helpful to tell about what you already did try and what you learned from that.Because someone willing to help can't know what you left out and might suggest things you already tried.But good for you that you already tried that to be sure what's going on is what you suspected to be happening.

Ok, sorry for that. Next time will be more explicit on my tests. As solution for the moment, I implemented a workaround. I send from the raspberry as first request an empty one, so that it "enables" the LCD.

About my code postings, I didn't post my code because it increased in complexity in a fast way. For this reason I will post my GitHub repository as soon, as it is in a decent status (2-3 days), and refer to it, to show the error.