Guide Make your own USB LCD controller!

Steve, you're just too clever! That's actually genius. Thanks!

 

Great work, thanks!
I tried to build something like this a while ago. Used a 4450 and LCDSmartie, never solved my problem with the display showing each char twice. Would be nice to see the code!?

I've built a simple testing device, a 2550, a display and nothing more. Works great with LCDSmartie. My goal now is to use it in Linux, I've found a patch to make a Matrix Orbital USB-display work with LCDProc, so I hope it will be easy.

 

I finaly got around to getting a prototype board built, which is the same one that I had posted earlier (the eagle board layout). I've been playing with it for about a week and was getting really frustrated that all I got to display was extremely corrupted data. I checked the board layout thoroughly and even started taking off parts to try and figure out what went wrong. I even burned a new chip to see if that would help. Turns out that my cable going from the PCB to the display was too long, although I couldn't even imagine this as a problem since it was only about 30cm in length. So, in the picture you'll notice that I have just about 5cm wires to the LCD. Works great now. If you needed longer cabling, you might be able to run the data/control outputs through a schmidt trigger to help. Pay no attention to my xtal caps....all I had were SMD ones at the time

 

If you need longer wires between the display and PIC, you need to slow down the data rate and make sure you observe the correct set up and hold times.

 

Have we any updates on and eagle file, for the layout i can download? and any updats on drivers and things, ive got my lcd sitting waiting!

 

I tried slowing down the data rate all the way to 4800 baud. I'm currently running at 56K. I didn't think set up and hold times were something that could be controlled externaly....?

 

Incase there was confusion - I'm not talking about USB, I'm talking about the LCD timings.

Having not seen the code, I can't see how exactly your controlling your LCD, but the firmware must make sure that all the timings are met. The USB protocol does not guarantee any data rates due to the nature of the bus. It's quite likely that you'll get as many frames as possible sent in the window before polling the next device on the bus regardless of the "baud rate". If you are simply controlling the LCD directly with no data processing, it's possible that you're right at the limit of the timing specifications of the LCD resulting in cable length problems.

I would guess that the data is getting garbled as a result of setup and hold times rather than the data rate.

edit: sorry, I just realised you're One~Zero not ch424 Replace you/your etc in the above paragraphs with ch424!!

 

The firmware couldn't make less effort to get the setup times right. You're right about the baud rate Steve. The PIC core is running at 48MHz (so dividing that by 4 goes to 12MIPS), so there's a good chance it's running too quick for the LCD. I may well be playing with the source today, so I'll have a go then. It shouldn't be too hard to just add some "Nop()"s at the right places in the LCD routines.

That's great to hear PHermansson! Do post your success with LCDProc, I couldn't get it to work very well when I tried.

ch424

 

Hi ch424

Would you please send me the code for reference? I have got several pieces 16x4 LCD. I want to modify it myself. Thanks
email computermonster(at)gmail.com

Robbin

 

I can't get it to work, and im pretty sure it's the programmingbits that won't get right, could you export it with the config-bits (mplab: file->export->check square with config bits)?

 

Thanks for that jensah! I can't believe noone else knew you could do that! Amazing, thanks! Try this. Could you say if it works?

Thanks

ch424

 

Yep that worked alot better
b.t.w. what baudrate is it?

 

Brilliant! Baudrate doesn't matter - 128k or less.

Remember to post pics!

 

ahh now it's working. And i managed to get it working in vista even. If anyone have problems with installing it under vista drop a msg or pm me and ill post the slightly modified .inf


Fixed this
(B.t.w. i cant figure out how to use GPO/BL controls in LCDsmartie a short example file for that would be great )
Backlight is backlight (duh)
RA0 (Pin2) is GP(5)
Hope it helps

And one new thing i only got a 3 pin rotary encoder that does 10 00 01 11 is it compatible?

 

Hey jensah, glad it's working! I've sent you a PM...

If you look at my first post, all the commands are listed. You can use them with the $Chr() command in LCDSmartie. e.g. $Chr(254)$Chr(102)$Chr(1)$Chr(75) would set GPO1 to 75:25 mark:space ratio. You can adjust the backlight using the "Matrix Orbital Settings" button in LCDSmartie, as well as the built in Backlight(0|1), BacklightToggle and BLFlash(n) commands in the Actions tab.

Edit: The GPOs 1 to 4 are RA2 to RA5 (pins 4 to 7) respectively, then GPO5 is RA0 (pin 2).

That encoder should work, yes.

Thanks
ch424

 

Ahh, i was messing around on the GPO5 a.k.a. buzzer one. So now it the GPO:s work.
try this INF if you got truble installing under Vista

My encoder looks like this, and i'm starting to doubt that it's compatibe.

And it's pulsing it at each change not holding it, so A=0 B=0 then A=1 B=0 and when at next notch A=B=0, and after some wiki:ing i think the're called "quadrature encoder"

 

Have you tried wiring it up!? I'm pretty sure it does exactly what mine does... mine's a quadrature encoder too.

Thanks for the .inf, I'll have a go later. I tried editing it as suggested on that MSDN page, but no luck. Yours looks different though, so hopefully I'll have some success with it! I'm using the 64-bit version and I thought maybe that was stopping it...

ch424

 

ahh, it had some silly wiring byt after some dismantling of the encoder i managed to figure it all out, A was A B was C and C was B
The enc does 2 steps per notch though

I've tried the inf on Vista Business 32bit, and 64bit can be a pain sometimes since not everything is supported.

 

Well I've got it working with LCDProc, wasn't that hard. I'm using the display right now on my Thin Client motherbord, it's using a 2,5" harddrive and Slackware 11 is installed. What I did was this:

The module to use is cdc-acm, "USB Modem (CDC ACM) support" in kernel config. This creates a device called "/dev/ttyACM0".
To load the module:

modprobe cdc-acm

dmesg says:
usbcore: registered new interface driver cdc_acm
drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters
usb 1-1: new full speed USB device using uhci_hcd and address 6
usb 1-1: configuration #1 chosen from 1 choice
drivers/usb/class/cdc-acm.c: This device cannot do calls on its own. It is no modem.
cdc_acm 1-1:1.0: ttyACM0: USB ACM device

All seems well. Next, LCDProc:

Download source, unpack and run:
./configure --enable-drivers=MtxOrb
make
make install

LCDProc is nearly ready to go, just configure it first:

vi LCDd.conf
Driver=MtxOrb
...
## Matrix Orbital driver ##
[MtxOrb]
Device=/dev/ttyACM0
Size=20x4

After this the server is started:
LCDd -r 4 -f -c LCDd.conf

"-r 4" gives more info, "-f" makes LCDd stay in front, useful for debugging.

Then the client:

lcdproc -f

"-f", same as for LCDd.

It works good, although I see signs of the timing issues you were discussing. Lcdproc has a little heartbeat symbol thats supposed to flash regularly, in this setup it's cleary unstable. But that doesn't matter...
Next thing now is to try some other client, this setup is ment to be a small musicplayer. Would be nice controlling it by the lcd and the rotary encoder I plan to add.

Some pictures of the current setup. The display looks good in reality,,,