- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
has anyone got an original HD44780 display (4x20) on a PSoC4 up and running with the Cypress provided character LCD component? It seems that the initialisation is done, the LCD is blank after LCD_Char_Start(), so the bars in line 1 & 3 which are visible after power-up are removed. However, calling LCD_Char_PrintString() doesn't show anything, even with setting the display position explicitely to (0,0) by calling LCD_Char_Position().
Currently I'm digging into it by using a logic analyzer, but it would be nice to know if anyone has been able to get an HD44780 on PSoC4 working.
Regards,
Ralf
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a pioneer board running a generic 44780 2 X 16 display with kees library. The display is
an arduino pinned out display. Kees library allows you to span more than one port with library
for the interface. A 4 x XX display should work as well.
You might post your project for forum to look at code base.
http://www.cypress.com/?app=forum&id=2492&rID=75707
“File”
“Create Workspace Bundle”
Use Firefox or IE, not chrome to post.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Make sure you are using the latest version of kees' multi-port-LCD library. It increased some delays, since some displays need higher ones.
Maybe you can attach a logic analyzer and look what gets transmitted.
Try to enable the blinking cursor, and see whether it moves when sending text.
Check the R/S line - if its stuck only commands get transmitted, but no character data...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
btw: I too had success with connecting an LCD. See e.g. my blog: blog.hendriklipka.de/archives/2013/10/psoc_frequency_counter_1.html and blog.hendriklipka.de/archives/2013/10/psoc_frequency_counter_2.html
There was already another thread regarding similar problems, maybe it can can help you: www.cypress.com/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Where did you find that? Is this in the standard component (v1.90) from Creator, or the multi-port one?
Btw: when looking for problem, start with the assumption that the components are fine (see http://blog.codinghorror.com/the-first-rule-of-programming-its-always-your-fault/ ). Yes, there are bugs sometimes in the PSoC components, but they are rare... Most likely something else is wrong.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
PSOC 4 has some a fair number of pins dedicated to fixed use, so
by using the standard component, where you are forced to use a whole port
except MSB, thats might be conflicting with dedicated pin. Maybe thats a
possible issue ?
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm not familiar with the one Chris wrote for the kees library, but I have been using the one I wrote for some time now, you might give it a try. It only uses 6 pins and make sure you connect the RW pin on the display to Vss. You can find the latest one here.
http://www.cypress.com/?docID=44039
Mark
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@hli:
Yes, the Cypress provided component for a character LCD v1.90. I make this 'assumption' because the 8th pin in the corresponding port is connected to a LED, and the LED is activated when LCD_Char_Start() is called. I still have to verify if it's the component which influences this bit.
@Dana:
The port I used is port 2, bits 7-1. The LED mentioned above is connected active-low to P2.0. According to datasheet P2 is used for ADC muxer only, but I don't use any analog features. I created a empty project with only the LCD, nothing else. After calling LCD_Char_Start(), the LED is active, which shouldn't be the case.
@meh:
I have to read from the LCD to check if the connection is well. I'll use the 6-pin components if there's no other way.
Regards,
Ralf
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Since you don't use P2[0], does it matter that it gets set to 0? It should not affect the operation of the LCD in your case. Looking at the code of the component (_WrDatNib / _WrCtrlNib), it looks OK to me. Are the port settings OK in the design wide resources?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Hli,
of course it matters. The end design will use P2.0 (that's why I connected a LED to it). And a component shouldn't influence pins that are not relevant for its function.
Currently I'm digging deeper into what happens, if my logic analyser doesn't lie to me it seems that LCD_Char_1_WriteControl() writes garbage to the LCD. The first command after switching to 4-bit mode is CURSOR_AUTO_INCR_ON -> 0x06, but according to the LA the LCD receives 0x8E. I assume that something's wrong with my hardware. I'll report back.
Regards,
Ralf
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hmmm... the LA seems to lie. I modified the LCD_Char_WrCntrlNib() function to transmit the pin state register to UART prior to disabling the E signal - the first 4-bit command CURSOR_AUTO_INCR_ON seems to be ok, but after that the garbage begins. Strange...
Regards,
Ralf
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- you can set the font size manually ( _WriteControl(0x28))
- a proper HD44780 display should be able to handle both sizes properly
- but maybe in your case, the 5x10 font ROM is not populated, and so you get empty characters (test thjis with a blinking cursor)
- according to my HD44780 data sheet, the controller uses internally already ASCII codes for the characters. At least I have never encountered a display where I could not use PutString() with ASCII characters...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Regarding P2[0]: I meant it should not matter for your test, since its not connected. APart from that, looking at the source code suggests that it will not be touched (all operations mask the proper bits).
Thats why I was asking about the proper pin configuration for your project...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Hli,
Yes, setting up the font size manually would work. I'll test it with a blinking cursor.
Regarding the PrintString functions, I'm sorry, I confused the behaviour with a different LCD driver, so #3 can be deleted.
#1 and #2 are still pending...
Regards,
Ralf
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
One 44780 to another are not all identical. Look at part suffix, it calls
out ASCII character set mask programmed into it.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Dana,
yes, the character set is the right one. As I said above, I mixed up two different controller types.
Regards,
Ralf
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
UPDATE: I managed to break it down to the LCD_Char_1_IsReady() function - replacing it with CyDelay(50) seems to work.
Now, I'll dig deeper into that function. PSoC4 support comes with V1.90 of the character LCD component, so it might be that the busy flag query isn't stable yet for my display.
Regards,
Ralf
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think I found the bug:
LCD_Char_1_IsReady() function switches the port configuration between high impedance digital input and strong output. However, if someone uses the the upper bits of the corresponding port (as I do), the shift for the configuration bits is not performed - that's also the reason why the LED got 'confused'.
I'll raise a ticket on it.
Regards,
Ralf