LCD connected to AR-150 (Update)

jw1 · 2016-01-07T01:46:32.000Z

A small update to this project. Posted in the right forum section this time

Serial LCD hooked up to an AR-150.

I have LCDProc working now. It’s kinda cool…

JW

alzhao · 2016-01-07T10:03:26.000Z

Can you show more detailed info. It will be very helpful for a lot of users.

Hardware connection?

Software info?

jw1 · 2016-01-07T18:57:28.000Z

Some more info on this project.

The display I used here is one from Parallax Inc. (Parallax 2 x 16 Serial LCD with Piezo Speaker (Backlit) - Parallax) but any serial lcd should work just as well. Sparkfun and Matrix Orbital make very nice ones too.

Serial LCDs have an extra controller stacked on top of the otherwise parallel interface to most displays which makes them more expensive. The upside is that you can use the UART with only the single TX pin to control them. Otherwise you would have to sacrifice at least 6 GPIO pins or alternatively start bit-banging SPI or other protocols to be able to interface with the display.

The image shows how it is hooked up. GND, 5V and TX of the UART connected to RX on the backside of the LCD.

Once this is done it becomes incredibly simple to send any text to the display by just echoing to the appropriate port. (in this case /dev/ttyATH0)

Set appropriate baudrate first (in this case 19200)

stty -F /dev/ttyATH0 19200 raw -echo

Then just echo away…

echo -en "GL-iNet is awesome…" >/dev/ttyATH0

LCDProc is a nice little addon (http://lcdproc.omnipotent.net) that actually turns your box + display into a stats server for multiple other networked devices (including itself) to report their status to.

The output of it can be seen here: (HD version on G-Drive)

The package is available in the standard openwrt repository under packages/utils/lcdproc

opkg install lcdproc

Bear in mind though that it comes with a ton of drivers for various flavours of displays. In my case my particalar Parallax display wasn’t supported out of the box.

I have been able to patch the lcdproc codebase with a driver for the Parallax written by Markus Dolze but that was quite a fiddly process.

~~Please let me know if anybody is interested in this and I will publish the patched codebase to a Github repo (which I will do anyway as soon as I have a moment)~~ I have put a repo of lcdproc with Parallax drivers patched into the codebase on https://github.com/jay2u/lcdproc

Also, ~~I have attached an IPK~~ (which you can download to your device and install with “opkg install”) straight from the package without the need for compiling anything. Get it here: https://github.com/jay2u/lcdproc/releases/download/v1.0/lcdproc_0.5.7-1_ar71xx.ipk

There is a downside to hooking up a serial display to the UART. The U-Boot boot process sends quite a constant stream of data over the serial port during boot. This is done at a rate 115200 baud by default which makes the display garble up during boot time as it is set at 19200 baud max.

After the boot process completes everything’s fine but it isn’t very elegant. The only way around that I guess would be patching u-boot to disable its serial console (not a good idea!) or going for a board with multiple UARTs.

Addendum: I have now found it is possible to compile U-Boot to be silent on normal boots and to only write to the serial console when booting with the reset button pressed. More on that later…

JW

jw1 · 2016-01-09T22:47:41.000Z

There is another way of doing this, I just found, which would involve talking to a display via an i2c interface.

This can apparently be done by using 2 GPIO pins. The pins would however need to be modified with 10k pull-up resistors connecting them to 3v3.

The upside of this is that i2c display arrangements are typically a lot cheaper (around $7 instead of $25) and it would eliminate the clashing problem with u-boot mentioned above.

Still, if you want to keep your soldering down to a bare minimum and want a “no hassle” solution for hooking up a display, you could decide to shell out the extra cash and go for the more simple solution above.

I will be trying this next in the coming weeks, time allowing of course.

Will keep you posted on progress…

alzhao · 2016-01-13T08:48:44.000Z

wonderful.

Seems I2C solution is better. Don’t want to touch the serial output in in such project, cost can be much lower.

jw1 · 2016-01-13T09:41:04.000Z

Agree Just grabbed hold of a couple of backlit I2C LCDs for $5 a piece. Hacking away at it right now.

More to follow when I get them going…

jw1 · 2016-01-28T05:54:01.000Z

Continuing the I2C LCD connection experiment.

I soldered in the separate I2C interface to the hd44780 LCD. That combination only cost me around $7 instead of over $25. 好吧!

Next. Soldered all the header pins to the GPIOs and 5V.

Now all that is left to do is grabbing hold of some 4k7 or 10k resistors to use as pull-ups for the GPIO lines.

If bridging the gap between 5V and 3.3V doesn’t want to play nice I might have to add some level shifters along the way.

This is work in progress I will post full documentation once I get it working.

jw1 · 2016-02-01T06:06:36.000Z

I have a new display ($7 total component parts) running over 2 GPIO pins bit-banging I2C on an AR-150, finally! Click here for HD Video link

The process, however, was quite involved and I ended up having to build a couple of level shifters out of MOSFETs and a bunch of resistors for the data channels, hence the clutter of wiring going on on the breadboard in the background.

That mainly has to do with the fact that the GPIOs are on a 3.3V circuit and the display runs on 5V. The GPIO pins actually only output around 2.7V when “high” which is too low for the other circuit to pick up (not to mention the hazards of bi-directional I2C talking back to the Atheros) which is why they need a boost from the transistors.

I will post full details on the process as soon as I have time, so stay tuned, but do let me know your thoughts in the meantime.

alzhao · 2016-02-01T10:46:59.000Z

Is it possible to drill a big hole on the top of the case so that you fix the screen on the case?

jw1 · 2016-02-01T20:03:01.000Z

Sure, I was thinking the same thing.

But the screen is too big for the smaller box. It will fit an AR-300.

I will look for smaller screens or build the whole thing into a different enclosure.

alzhao · 2016-02-03T12:09:37.000Z

Yes. Seems it is too big. We will have a bigger case (twice big as AR150) so that you can play with. The case will come in April.

jw1 · 2016-02-04T01:22:44.000Z

Nice!

beamzer · 2016-02-06T19:27:39.000Z

Might be fun to look at one of these OLED displays

http://www.aliexpress.com/wholesale?catId=0&initiative_id=AS_20160206032306&SearchText=oled+128x64

they are so small, you might be able to fit them in the standard case, and it’s color and full graphics.

jw1 · 2016-02-07T01:22:54.000Z

Thanks! You read my mind and I already have 2 of them lying about to play with.

They are indeed the perfect size (just under 1 inch)

Unfortunately there are no lcdproc drivers for it (I already had to modify existing HD44780 drivers to get this going) so I will have to create my own driver, which will be the new project henceforth

b3106833trbvn-com · 2016-04-04T20:01:39.000Z

Any update on this project? I’d like to be able to add a small square display to the existing case.

asanori3 · 2016-04-23T22:25:50.000Z

I was connected to the i2c LCD of 3.3v to GL-MT300N.

SWITCH-SCIENCE

I2C small LCD board (3.3V) - SWITCH-SCIENCE

Breadboard friendly, 2.54mm pitch, I2C controlled 8x2 characters LCD board for 3.3V microcontroller. It has the pull-up resistors for I2C bus in it.

Price: 8.61 USD

However , there was no i2c-tools in it .

Download from here .

http://dl.eko.one.pl/chaos_calmer/ramips/packages/i2c-tools_3.1.2-1_ramips_24kec.ipk

opkg install kmod-i2c-gpio-custom kmod-i2c-core bash perl

opkg install ./i2c-tools_3.1.2-1_ramips_24kec.ipk

#insmod i2c-gpio-custom bus0=0,2,44

and run small script.

http://netlog.jpn.org/r271-635/2013/01/raspberry_pi_i2c_lcd.html

./i2c_lcd.sh -i " GLMT300"

alzhao · 2016-04-25T12:36:29.000Z

@KOJI, thanks for sharing.

j-maathuis · 2018-09-02T11:25:18.700Z

I have still a AR150 lying around. Back in the days I bought it I spend a lot of time with @frietpan on this forum trying to modify it. Now all these years and a lot of knowledge (based on Raspberry Pi’s) later I wanted to give it a try to connect an OLED 128x32 to a GL.iNet router.

Since my brandnew AR750S has dedicated I2C pins but can’t be opened due loss of warranty I did have a look on the AR150 and discovered this model doesn’t have dedicated I2C pins. Now I found this topic that I2C is possible on the AR150 I’m wondering how to configure I2C for the GPIO pins of the AR150.

I thought the OLED it self may be driven with Adafruit drivers in Python but while writing this post the Adafruit drivers are appearantly designed for Raspberry Pi’s and Beaglebone Black’s: GitHub - adafruit/Adafruit_Python_SSD1306: Python library to use SSD1306-based 128x64 or 128x32 pixel OLED displays with a Raspberry Pi or Beaglebone Black.

Does anyone have new thoughts on driving a screen with the AR150?

alzhao · 2018-09-03T10:26:21.962Z

It is using GPIO for I2C so you can use two GPIO in AR150 to try. Just as @asanori3 have done.

j-maathuis · 2018-09-03T15:27:43.808Z

I managed it to get I2C working on the GL-AR150.
i2c-tools_3.1.2-1_ramips_24kec.ipk failed to install but a long time later you now can install it with opkg install i2c-tools.
i2cdetect -y 0 did detect my OLED SSD1306 screen on location 0x3c.

Now I’m struggling to get something shown on the display. Since I used Adafruit library’s on my Raspberry Pi for this screen which are not designed for other devices than the Raspberry Pi and Beaglebone Black I don’t know how to get something shown on my display.

I just discovered the page GitHub - mkschreder/hack-ssd1306-openwrt: Tutorial on how to connect an ssd1306 oled display to OpenWRT over a usb to i2c dongle (ch341) which seems interesting. Diving into it further at a later time.