Forums

Surely Dave Wilson will jump in - provide expert content - here's quick summary content:

a) developing multiple size fonts is always a welcome design feature - yet fairly complex task - great bulk "done" for you under the Gra Lib

b) Lines, rectangles always helpful - again much ground-work "done" for you

c) Icons, images (primarily bmp) - again substantially "done" for you w/in Gra Lib

Keep in mind that while you reference the 320x240 TFT display - much of the code strategy and implementation can be adapted to smaller screens.  You may also find code efficiencies by careful review of the multiple, mono display examples w/in StellarisWare.

While you mention a 128x64 "mono" display - you don't state whether this is Lcd, Oled or other.  Most of the Lcd mono versions operate on an 8 pixel per byte transfer method.  The 320x240 TFT - by comparison - utilizes 2 bytes (16 bits of data) to fully define a single pixel.  You should be able to strip away vast amounts of the color decoding yet retain the essence of the native image to pixel (or byte) requirements of your target, mono display.

By staying with a mono display - programs such as PC Paintbrush (& similar) can be much more easily harnessed to vastly automate the image to data harvest & ordering process.  Should you not require a "full font set" - you can create and save key text headings strictly w/in Paintbrush.  (beware though - any change at all demands that you modify and re-save that specific bit-map)

While color is often appealing - too often color is used as a poor substitute for effective, thoughtful Screen Design.  Proper planning and modeling can lead to mono displays which are as compelling as color - yet are simpler & faster to design, implement & maintain...

Thanks for your thoughts Cb1_m

I'm working on the ST7565 driver which is a graphics driver with a byte of data for 8 pixels. I would love to use the gra lib for smaller displays, but this depends on the work involved in porting it for the same.

My pleasure to share mon ami.  Few further comments:

a) Should you elect the ease/efficiency of existing Windows "Paint" programs - best to devise both full screen (128x64 in your case) and multiple, reduced size, pixel harvesting operations.  This will enable you to "guide the eye" via headline size text - intermixed with the more utilized 5x7 font.  We solved this by creating a variety of "bmp templates" - so that we can "tune" the image size to best meet our target screen and/or pixel area of interest.

b) Long knock on Character Displays - lack of accustomed lower-case descenders - will likely continue in your application.  (Chars: g,j,p,q,y) descend - look strange when forced to unnaturally rise due to vertically limited pixel field.  You can solve this w/ your graphic display - but at the cost of 2 character rows - most likely.  (assume 5x7 font - 1 blank pixel between rows - then 64/(7+1) yields 8 character rows.  If you allow 2 pixels for descenders - your character row height "balloons" to 9 + blank - 64/10 yields 6 rows)  Without doubt the descended characters look better - but demand additional programming time/effort and reduce the amount of text one can display/screen.

c) Have long/serious history w/displays - believe your choice of 128x64 most wise.  Very popular, multi-sourced, available in wide range of size, polarizations and bus-based control ICs.  (our overseas display partners advise against choice of far less popular (usually orphaned) 132x65 or near similar - false economy to design/develop for an item which may not be available long-term - that is why industry has settled on classic standards...)  Caveat however - the only standard as regards displays is that there is NO Standard!   (pardon, my dear HD44780/clones)

Certainly a review of the various Stellaris Development Kits will reveal mono display use.  This may be more fruitful for your initial efforts than the dissection of "full color" - 16bpp as previously mentioned...  (when all else fails - K.I.S.S. seems to work)

I guess cb1_mobile was right... :-)

You can certainly use the Stellaris Graphics Library with a monochrome display since you can write a display driver for any display as long as it is capable of setting a single pixel to a given color or brightness. Take a look at this app note for more information on developing a display driver that will allow grlib to talk to your display hardware.

Often with low resolution/low color-depth displays, the trick when using the library is producing fonts and images that look good in that format. Jagged edges and strangely skewed characters are normal if you pick poorly. As far as fonts go, assuming you are working in English, the "g_sFontFixed6x8" font we provide looks great on small screens. It only includes ASCII characters, though (hence my English note), so you would have to find an alternative if you need accented characters or other alphabets.

For images (icons, logos, etc), I would recommend developing your images in Photoshop or a similar high quality image editor and converting to 1bpp there (so that you can preview the results). Don't expect to take a photograph, save it as a 1bpp image and have it look good on your monochrome display! You will likely have to do some manual touch-up at the pixel level to end up with a good looking logo or other image when you don't have anything other than black and white pixels to play with.

Thanks guys. Looks like I'll have to stay with string and image dumps rather than use the full St. gra library. It would be more work trying to get widgets/canvases etc running for the monochrome display. I already used the porting guide to develop a low level driver. And it is working well with the qs_ek example(which uses string and image dumps to a frame buffer)

I guess I didn't get my point across. If you write a display driver (which will take you about a day or less assuming you already have some sample code that is capable of initializing your display controller and setting a single pixel at a given location on the screen), you can then use any graphics library API and draw lines, circles, rectangles, text, etc. You can also use the widget library too but the only complication there is that most of the example applications for it assume you have a touchscreen. If you want to see how to use that library with navigation buttons instead, look at the qs-logger application shipped with the ek-lm4f232 release of StellarisWare (whose display driver, incidentally, supports a 96x64 color display - even lower resolution than yours).

You don't mention which EK you are using but I suspect you have a ek-lm3s1968, ek-lm3s6965 or ek-lm3s8962. The only reason these boards' examples don't use graphics library is that all their example software was written well in advance of us developing grlib. We have, however, modified their drivers to work with grlib but not included this in the release. That work took about 2 hours. If you search the forum, I'm sure you can find several people who have posted drivers that allow grlib to work on those EKs too. These drivers continue to use the SRAM-based frame buffer and make use of the driver's Flush() API to force frame buffer changes onto the physical display.

So, the message to take away from this is that, if you want to get a display up and running, the effort required to develop a display driver for grlib is way less than the effort required to come up with a full-blown grlib substitute that works only on that display. Grlib drivers are really easy to develop since the library does all the graphics heavy lifting for you.

@Dave Wilson - merci (guess that course in predictive correlation was not all for naught)

Dave Wilson

photograph...often will NOT look good...on mono display

SO true - even Sports Illustrated girlz - scanned @ processed into 1bpp format - resemble @ best "Big-Foot"  (and he/she/it on notorious "bad-hair" day)

Photos are thus disasters - what does work are mono images/icons/drawings - specifically created for 1bpp format.  Our group's found scientific/engineering drawings which were specifically created for non-grayscale, mono applications.  Many such can be found w/in older (i.e. late 1970s, 1980s release) graphic programs/drawing packages.

Extracting the image essence from a color/gray-scale rich image is not for the faint of heart - thus best avoided... This extreme lack of suitable/processable source images greatly enhances the appeal of small, color displays...

Thanks Dave/Cb1

I'm using the 9b92 Ek which does not have any kind of display. I just hooked the spi lines to an ST7565 driver which controls a 128*64 display. To point it out politely, it does not matter what ek is being used.

I'll look at the logger example you mentioned. Unfortunately, I missed that example.

Ah - fair enough. I figured you were looking at one of the older EK boards with a display and assuming that, because its display drivers were not grlib compatible, that it was not possible to support that kind of display via the graphics library. I've been keen to include grlib support for those boards too for quite some time but it's just another of those jobs that hasn't bubbled to the top of the priority list yet.

Holy crap.. That is exactly what I wanted to do(except that it is not an oled, which is fine). Thanks for your help guys.

We aim to please :-) Let us know if you have any problems when you start delving into the driver.

Big-Foot - lost in this fray of activity (09:52) 5-6 up - patiently/quietly awaiting, "atta boy."

I sometimes find it hard to understand what you are saying, cb1. Are you talking in HAM?

73

@Q-

Dave (perhaps I a bit) have got you on your way.  And that's good.   Ham long ago (WA2RTL, DL4IJ - left to join the network)

Attempted to flag the caution against using photos w/in 1bpp environment - provided alternatives.

(doubt you'd have any "understanding" difficulty w/09:52 post, above)

Hello guys,

Is there any way to accomodate the way my lcd driver(ST7565) works for offscreen buffers. The offscreen buffers are designed for 1/4/8Bytes per pixel, which is entirely different from the way my lcd works - where a byte equals to 8 pixels.