Displays for 2019

geezer88

Senior Member
I've dusted off some of the i2c displays in my parts bin and have been playing with them. I've also looked around for 232 serial displays and they seem to be rare these days. Haven't seen anything to get me excited, yet. I'm talking character style displays.

The beauty of the RS232 displays is the single pin required to drive them, and the relatively little program space to use them.

The address ability of the i2c style is an advantage, but they bring along the baggage of the 4bit/8bit setup and use that gobbles lots of program space.

So, what are folks using for new projects? Do the new OLEDs have a lot of overhead to eat program space? What else? Cheap sources?

Oh, Oh, I know. How about servos with little flags to wave semaphore code?

tom
 

erco

Senior Member
How about servos with little flags to wave semaphore code?
I'm on it. The 14M2 prevails.

Mod Edited : The flame thrower part wasn't acceptable last time. Isn't now.
 
Last edited by a moderator:

hippy

Technical Support
Staff member
Do the new OLEDs have a lot of overhead to eat program space?
For text OLED's it's no more than normal LCD's and that is less than 180 bytes from the AXE133 firmware.

For graphic OLED's the overhead is about twice that, plus most of the EPROM and TABLE space will be taken up by font definitions.

The biggest overhead for the PICAXE using a display is the actual characters which are sent to the display using SEROUT. That of course becomes much greater if using I2C or parallel connected displays.
 

johnlong

Senior Member
Hi
Have a look at the nextion displays you can off load a lot of the picaxes program use to them
and they offer touch screen facility to a project. The older modles are resistive touch they have
just released a 7 and 10 inch capacitive touch versions that can play videos on them
via just simple serial in and out commands from the picaxe
 

AllyCat

Senior Member
Hi,
I've dusted off some of the i2c displays in my parts bin .....
The beauty of the RS232 displays is the single pin required to drive them, ..........
The address ability of the i2c style is an advantage, but they bring along the baggage of the 4bit/8bit setup ....
About 5 years ago I started an 08M2 project to convert "RS232 serial" to I2C commands to use as an "AXE133-compatible driver" for one of the "I2C expander backpacks" which are often fitted to the 2 x16 and 4 x 20 etc. LCD character displays. It implemented a (large) internal circular buffer with interrupt-driven HSERIN reception, which completely eliminates the need for the long inter-character spacing, or any critical timing of the AXE133 serial input (even with the implicit 4-bit control).

There were some "complications" (which I documented on the forum), but the real "killer" was that the 08M2 HSERIN kept throwing unexplained errors, even at quite modest baud rates. I did find a workaround and the prototype program performed very well, but I thought that the various "fixes" would be of limited general appeal, so I shelved the project.

However, a recent thread has confirmed that the HSERIN command in M2 chips appears to be fundamentally flawed and the "workaround" is a recommended solution. Further analysis suggests that fully concatonated (conscutive) ASCII characters at 9600_16 baud (and equivalents) are quite possible, so I decided to "blow the dust off" the project ..... but don't hold your breath! First, I will probably resurrect this thread which I started a few years ago to see what additional features for the AXE133 might be of interest to others:

The three "command" codes (253-255) will be expanded to eight and moved to the "unused" (duplicated) ASCII characters 8 - 15, (although the circular buffer allows any mapping to be decoded). Certainly to be added will be backlight dimming (using software PWM via the I2C expander) and the ability to program the embedded character strings"on the fly" via the serial input. Probably also a facility to change the baud rate and polarity by direct command, but I'm open to suggestions on what other features might be of value to others.

Cheers, Alan.

PS: I hadn't seen flenser's version before, but I see that his program also "avoids" the use of HSERIN. ;)
 

techElder

Well-known member
I've made several iterations of the 8x8 LED matrix modules with from 2 to 5 scrolling message modules. I don't know what the limit is, but I have one coming up with 8 modules. They allow me to have several displays going at once with different information on each. I've been asked to create a "scroll and stop" action to the large display. Hmmmmm ... :D

I believe the basic loop routine came from westaust55 (many thanks!), but I've massaged it considerably since then; as well as adjusting font characters and adding compile-time directives for module count and display characteristics. There are many ways to skin this "cat". I've chosen one.

LED Matrix 8x8 with 5 modules Normal scroll

PICAXE 20X2 with 2 to 5 (or more) 8x8 LED Modules (using the MAX7219 driver) built as a separated display module with commands (such as intensity/scroll speed), canned messages and i2c addressability (so there can be multiple addressable displays.) Compiling with program directives allow adding or removing matrix modules and whether displaying lowercase or all uppercase.

The PICAXE 20X2 has somewhat limited RAM (which this display uses) so there is about an 18 character limit per message, but the PICAXE 28X2 extends this limit considerably due to having more RAM available.
Video Available on YouTube
 

techElder

Well-known member
This code shows that there no 18 characters limit per message with a 20X2.
I was referring to a particular limit to my software the way I designed it. I wasn't implying that the 20X2 had any specific limits.

This isn't the appropriate place to discuss my design as the following is what the OP wanted this thread to be focused on.
So, what are folks using for new projects? Do the new OLEDs have a lot of overhead to eat program space? What else? Cheap sources?
 

geezer88

Senior Member
I don't think I made myself clear. Using the 8574 based iC2 expanders, the user is constrained to 4bit operation of the LCD. This means all the messages to the display have to include the routines needed for 4 bit operation. With the serial displays I've used, the display only needs the text or numbers as input, not all of the control stuff, too. Yeah, I know that the same routines can be used in every project, and they aren't huge, but I'm a lazy old fart, and would rather not be bothered. So, are there new, inexpensive character displays folks have found a source for? I do have a small Nexion display on order.

So, what the heck is this, above, about? "Mod Edited : The flame thrower part wasn't acceptable last time. Isn't now. "

tom
 

Buzby

Senior Member
So, what the heck is this, above, about? "Mod Edited : The flame thrower part wasn't acceptable last time. Isn't now. "

Erco built a very clever combination of semaphore flags and miniature flame throwers, all driven by PICAXE.

Not safe for minors, or those with limited intelligence.
 

BESQUEUT

Senior Member
I was referring to a particular limit to my software the way I designed it. I wasn't implying that the 20X2 had any specific limits.

This isn't the appropriate place to discuss my design as the following is what the OP wanted this thread to be focused on.
It's not necessary to use red ink...
I apologize if you think that I discuss your design.
I only said that a 20X2 can drive MAX719 displays with more than 18 characters texts, and less than 400 bytes code. IHMO the OP search for new projects with not to much overhead to eat program space...
 

lbenson

Senior Member
So, are there new, inexpensive character displays folks have found a source for? I do have a small Nexion display on order.
I like the Nextion displays, though on the pricey side for some minimal applications, and they do require some work on the Nextion side (though I found their IDE to be very good, including the ability to simulate on a PC with actual USB/serial modules in and out (or without them)--made me wish again for the ability of the PICAXE simulator to write to and read from a real serial port).

About a year ago I had a severely pin-constrained design and looked for an inexpensive serial-only LCD--never found one, so I would be interested to see if anyone else can point to one.
 

geezer88

Senior Member
Pretty funny about semaphores and flamethrowers. The semaphore idea just popped into my head as I was writing that post. I hadn't known about the past history. Been off the Picaxe trail for several years.

Looking at the shop section of this website, there are some serial displays. The axe133 does exactly what I want. I may just go that route. It isn't so much the size of code. As Hippy pointed out, 177 bytes isn't that bad, especially if I set up a few "starter files" with all the display stuff ready to go. Now that I think of it, I may already have some. Being old and out of it awhile, I think I may make a few more "re-discoveries".

I did order the small Nexion to play with. I'm not impressed with the editor, but this display is very complex, so the editor has a lot of stuff to be able to take care of. I've been reading the posts on it in this forum with great interest.

Thanks all for your comments and support.
tom
 

BESQUEUT

Senior Member
About a year ago I had a severely pin-constrained design and looked for an inexpensive serial-only LCD--never found one, so I would be interested to see if anyone else can point to one.
Not really inexpensive but...
http://www.warburtech.co.uk/products/displays/monochrome/devantech.lcd03.20x4.lcd.module/
https://www.lextronic.fr/module-de-pilotage-serie-pour-afficheurs-2494.html
https://www.lextronic.fr/afficheur-2-x-16-caracteres-nclcd162-blb-53.html
https://www.gotronic.fr/art-afficheur-serie-lcd05-16-17106.htm
 
Last edited:

lbenson

Senior Member
Not really inexpensive
True that. About the same as the far more capable Nextion 2.4" and 2.8" devices--and with a second line for two-way serial, those can be interactive with touch.

I'm not sure why it would take anything more than software (and the right backpack chip) to make a one-wire serial LCD module like these $5USD 4-line I2C modules from ebay.


(I like those I2C LCDs, but every once in a while you need that second pin.)
 

geezer88

Senior Member
I bought one of those, too. It works fine, but beside needing the care and feeding of a nibble interface, it seems to interfere with the i2c altimeter I'm wanting it for. The display works fine by itself, and the altimeter works fine with a serial display, but the two itc devices won't play nicely together. Each time I use one or the other, I use hi2csetup, appropriate to the device, but no joy. I'll post again if I figure out what's up.
tom
 
weeeeeellll.......

Being a railway modeller, I am currently designing a servo operated semaphore system - semaphore railway signals that is! :LOL:

I've come across a rather neat LED matrix driver which I'm now using wherever I can - the HT1632C. There is a thread on here somewhere which contains code for driving it with a PICAXE which I hacked to pieces and got to work, but the simple fact is with some clever coding techniques you could really do almost anything with it.

In my case, I'm using them to drive approximately 24 8x24 dot matrix displays (two per driver, electrically arranged into a "single" 16x24 display). By separating the storage of characters from the display processing, I've found sufficient RAM in a 28X2 to store what each display is displaying (simply storing the ASCII characters - 4 bytes per display, 8 per driver chip).

The best thing about the HT1632C? They cost a grand total of 62p each, dropping to 46p as soon as you go over 10 (LCSC online shop) - which is the reason I'm now using them everywhere, even for individual LEDs (which needs more RAM, granted...).

Note - I'm not affiliated with anyone involved with the 1632C - I'm just a hobbyist that found them and has fallen in love with them!
 

AllyCat

Senior Member
Hi Tom,
it seems to interfere with the i2c altimeter........ the two itc devices won't play nicely together.
Assuming the two devices don't have a conflicting I2C address (usually the LCD backpacks can be changed with a pads link), I'd guess there might be too many pull-up resistors on the bus (i.e. each device has pull-ups fitted, but normally only one pair is required) and/or the bus cable might be too long. Of course there can be several more complex reasons for a bus conflict, but best to start with the easy things first. BTW which PICaxe are you using (they're not all created equal)? ;)

Cheers, Alan.
 

Hemi345

Senior Member
I have a little Digole color LCD display that can be used in UART mode. It uses very little PICAXE program space to use. You can find them on Ebay.
 

geezer88

Senior Member
I think Alan has the answer to my problem above: two many pullups on the i2c bus. But, for now, my original question has been answered by the Nextion display. I have just received the small, advanced one and in spite of the learning curve on my 70 year old brain, it has a lot to offer. The integration of touch input with the display's easy graphics means I don't have the mechanical problem of fitting little switches, knobs, and labels on a project..

So, thanks to all for your replies. I will be making my future questions and comments on the Nextion display in that section of the forum.

tom
 

lbenson

Senior Member
Lots of Nextion information in : this thread

The Nextion can send a lot of data which is both hard to capture and hard to decode. My advice is make each touched object respond on "touch up" with a 2-byte command sequence (e.g., !0 through !9 or !A though !Z, etc.) and ignore everything else. There might be situations where that could get you into trouble, but it has worked for me, using the M2's 2-byte background serial receive.
 

johnlong

Senior Member
I agree with Ibenson if you design your own communication code with ascii it makes things
much easier to debug later on.
The other thing to deside is which you want to be the master and slave
I always use the picaxe as the master and the nextion as the slave but with an interupt function with hsersetup %001 background recieve
and capture 2 bytes
that way you can see what and record what you have reset the picaxe to do
I also find that hotspots are more flexable to use than the button function of the nextion which can be limited in their outcomes
so simply to increase a picaxe variable create hotspot on screen in the touch write ie print "A+" on the picaxe side 1st var b0 "A" 2nd var b1 "+"
symbol qt="
hserin [60000,leave],0,2 'variable settings and operation selection
if hserflag <>0 then : if hserptr < 2 then: pause 10 : endif : get 0,b0:get 1,b1:endif
select case b0
case "A" if b1="+" then
inc b10
hserout 0, c.1, t9600,("t1.txt=",qt,#b10,$ff,$ff,$ff)

endif
end select
 

Hemi345

Senior Member
I've made several iterations of the 8x8 LED matrix modules with from 2 to 5 scrolling message modules. I don't know what the limit is, but I have one coming up with 8 modules. They allow me to have several displays going at once with different information on each. I've been asked to create a "scroll and stop" action to the large display. Hmmmmm ... :D

I believe the basic loop routine came from westaust55 (many thanks!), but I've massaged it considerably since then; as well as adjusting font characters and adding compile-time directives for module count and display characteristics. There are many ways to skin this "cat". I've chosen one.
Video Available on YouTube
Hey Tex, would you mind sharing your code for those 8x8 LED matrix modules?
 
Top