searching for LCD controller with vertical font drawing

[josip]

Hello
I'm searching for a suitable graphical monochromatic LCD module that can be verticaly mounted.

For example, I can send rotated graphics to Toshiba
T6963, but fonts can only be drawn horizontaly. While T6963 can drive LCD with resolution such as 128x160, almost all LCD module manufactures connect the LCD to work as 160x128. That's why I'm searching for a controller that can drive LCDs in rotated mode.

Does anyone know which LCD controllers support verticaly oriented LCDs? Is there another way to solve this problem?

Thanks
Josip

Crystalfontz LCD Blog

Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.

 

[CF Support2]

Any of our graphics modules can be operated in a vertical format. It is a matter of writing your code so that you are addressing the screen differently. Instead of the 0,0 position being in the upper left, it will be in the upper right and you will need to create your graphics accordingly. The controller / module is indifferent as to it's orientation.

For the CGROM (character generator) you will not be able to use properly as it's orientation is set for landscape orientation. For characters, you would need to create your own character set with the proper orientation.

You may encounter a viewing issue as the orientation of the polarizer will change from 6 o'clock to a 9 o'clock. Viewing from straight on should be fine and with a few degrees in any direction.

 

[josip]

Your solution has following shortcommings:
- the whole table of custom characters occupies memory on processor (not possible in my case)
- character size is limited to 8x8 (I normaly use 6x8)
- my usual functions for outputting text don't work (text gets written top-down, not left-right)

If there's any controller that supports drawing rotated text, it would make a much better solution in my case.
Thanks for your answer.

 

[CF Tech]

All the controllers that I know of that support built-in fonts do so in a quite limited way. There is typically only one font to choose from, and its character spacing and orientation are fixed. The controllers are doing the font in hardware, and the flexibility is quite limited.

I have usually ended up rendering fonts in software. An 8x8 font that contains 128 characters takes only 1KB of space. The you can define your font size to be any subset of 8x8, simply mask the extra pixels and do not set them on the screen.

I have some code that puts an 8x8 font to a frame buffer (which you might not have room for) but it could be modified to write directly to the display. There is one version for "horizontal bytes" and one for "vertical bytes". The letters are positioned at pixel boundaries (not byte). It is written in C for an AVR. Please write support@crystalfontz.com if it might be helpful to you.

A suggestion:

You might consider moving to a larger processor. It is possible to spend a whole lot of time staying in the constraints of an old, small, slow processor. Talking to a graphics display does take a significant bit of processing and resources. Keeping a frame buffer of the graphic display in the processor's memory significantly reduces the complexity of the code, but it does take a chunk of RAM.

The new processors are cheap, fast, and have lots of flash and RAM. They allow you to write at a higher level, which gets the project done more quickly. You can also add software features that enhance the value of your product.

A new processor would also allow you to use a library like RamTeX or easyGUI, which would handle all this low level mucking around with pixels, and allow you to concentrate on building your product rather than spending time reinventing the graphics library. This approach also opens up ANY graphic display for your consideration, instead of the tiny few (perhaps zero?) that have the controller you want, the font you want and the orientation you want.

 

[josip]

Thank you for a very informative and helpful answer.
I will look into upgrading to a more powerful processor (we use PIC family), and I will definitely check the libraries you mentioned.
Thanks again for the information provided.