Does this Newhaven LCD display send data to the MCU? - Page 1
Forum section: electronics / projects

author: VinzC
author_rank: Frequent Contributor
timestamp: March 26, 2016, 01:11:20 pm
content: Hi all.I've been looking for an LCD display for my project and it looks like theNHD-C0216is the one. The only thing is my microcontroller is powered with 5V and the C0216 requires 3V. Not a big deal but there's something vague as per the datasheet: there are two instructions for which it is not specified whether the MCU is supposed to read data or not, namely "read busy flag and address" and "read data from RAM".It's especially troubling given theSIpin (5) is described on page 4 as "Serial *input* data". If the pin is only an input to the display module then I only have to shift levels down from 5V to 3V, which I can do using only diodes (likeBAT54WS) and pullup resistors.So is thatSIpin is a bi-directional or a one-way data line?

author: mariush
author_rank: Super Contributor
timestamp: March 26, 2016, 01:44:17 pm
content: The controller is a clone or a version of ST7032 as it's said in the datasheet. Those two instructions are optional for you.You can use the "read busy flag" to speed up your interaction with the lcd screen... if you don't use this, your code just has to estimate how much the previous command took and wait that much time before sending new commands, otherwise the commands could be ignored. The time needed for commands to execute is listed in datasheet, most instructions take 15-30us (microseconds) depending on the controller's operating frequency. Some instructions like clear screen for example takes more time to execute, about 1ms (so basically if your code says clear screen and then immediately writes one character on lcd, that command may be ignored and character may not show up because the lcd controller is still busy clearing the screen.. hence why you'd check if busy before sending command to write character.. but you can just as well add a delay of 1ms after the clear screen command.So you can make it one way only.Same for read data from ram which just reads data from the internal ram of the controller (which holds the 2x16 characters and the built in font table and so on) ... if you don't need to read data from the controller, it should basically be one direction only.Seehttp://akizukidenshi.com/download/ds/sitronix/st7032.pdfmaybe it has more details, but I think the newhaven datasheet also links to a similar pdf somewhere inside.

author: marshallh
author_rank: Unknown
timestamp: March 26, 2016, 10:35:57 pm
content: Almost all newhaven displays are relabeled models from aliexpress, maybe they contacted a fab over there and got some custom ones.

author: VinzC
author_rank: Frequent Contributor
timestamp: March 27, 2016, 06:41:47 pm
content: Quote from: mariush on March 26, 2016, 01:44:17 pmThanks a lot mariush, that's indeed quite valuable information. I think I'll go and use the one-way link. I find it's simpler to just add wait instructions than poll until the display is no longer busy — polling or wait, it's always locking the MCU doing nothing anyway so... And I don't expect I'll ever have to read the RAM for my project. Makes the one-way link definitely worth it.

author: macboy
author_rank: Super Contributor
timestamp: March 28, 2016, 05:43:28 pm
content: Quote from: VinzC on March 27, 2016, 06:41:47 pmThat's not quite true. I do the busy flag polling (on HD44780 displays)priorto sending a command. After sending a command, the driver returns immediately, freeing the MCU to do other work (figuring out the next char to write for example) while the display is busy. Then when the MCU is ready to send another char to the display, it waits if busy (usually not) and then sends it.

author: VinzC
author_rank: Frequent Contributor
timestamp: March 28, 2016, 09:00:26 pm
content: Quote from: VinzC on March 27, 2016, 06:41:47 pmQuote from: macboy on March 28, 2016, 05:43:28 pmThe code samples I read led me to the conclusion that sending strings, whatever the length, must generally obey to a given sequence of timed operations, during which the MCU is monopolized to that task since it's a single-task CPU. (It'd be interesting though if there were an interrupt when the display is ready.) So I expect send-and-wait to somehow simplify the algorithm. Unless I missed something of course.

author: macboy
author_rank: Super Contributor
timestamp: March 29, 2016, 03:56:14 pm
content: Quote from: VinzC on March 28, 2016, 09:00:26 pmMost of the time, the display executes simple commands much faster than the specified maximum. Also I find that there is usually enough work for the CPU to do in between characters, that by the time the CPU is ready to send the next one, the display is ready to receive it. So you don't sit and spin wasting much time if any at all. If you do the command-then-delay method, you are guaranteed to wait the absolutemaximumtimeeverytime. Then the CPU does some work to determine the next character to send, which means even more delay, then finally it sends that command and waits again. I assure you that the string write will be slower - much slower - with a fixed post-command delay method than the pre-check method I described.

author: Dago
author_rank: Frequent Contributor
timestamp: March 30, 2016, 05:41:28 am
content: I think I've used the I2C-version of this display on some work project and you CAN read the busy bit from the display but it is not completely necessary (you can just wait for the worst case delay).But the issue is that to read that busy bit you had to do something that completely violated the I2C bus specification and I couldn't figure out how to do that without some bitbanging with a GPIO or something. I think you had to send a write package to the bus, send command to read busy bit and then read the busy bit without a read package or something like that (this was a few years back, can't remember details) which was utterly impossible with the I2C controller I was using. The display also ACKed every package, but it did not mean it actually accepted the command (=was not busy executing something else). Annoying display.