LCD controller ST7290, apart of having a kind of MODE 3 SPI - which is rare -
has also a strange limitation on the CS control line which (apart of being
active high, which is also rare) does not inhibit its internal shift register
from latching data on the bus.
In case others SPI devices are connected to the same SPI bus, even controlling
correctly the CS lane as u8glib is doing and avoiding conflicts, the controller
catches everything is passing on the bus, ending up with some trash on the
display.
This limitation prevents the usage of other SPI devices connected to the same
bus and thus is limiting the flexibility of the system.
Micro-controllers in the ATMEL AtMEGA48/88/168/328 family have the capability
of using the built-in USART in SPI mode (only for master mode).
This additional resource can be used to control a ST7920 LCD and free the main
SPI module for other usages.
For this purpose, I developed a new u8g device that I called
"u8g_dev_st7920_128x64_hw_usart_spi" and which is based on the existing
"u8g_dev_st7920_128x64_hw_spi".
I added also the x4 versions.
I just added a new file ("u8g_com_atmega_st7920_hw_usart_spi.c"), modified
"u8g_dev_st7920_128x64.c" and "u8g.h" to the original u8glib v1.14 package for
atmel (not for ARDUINO).
Initialization is done using the standard u8glib way for HW SPI:
u8g_InitHWSPI(&u8g, &u8g_dev_st7920_128x64_4x_hw_usart_spi, PN(1, 1),
U8G_PIN_NONE, U8G_PIN_NONE);
I'm sharing it with the community.
Oliver, please do a formal check if my code follows your library guidelines,
coding style and philosophy.
I'm currently using it so it has been tested a lot on my application board, but
it's worth to test it with another HW.
Hope it helps.
Nicola
PS: porting this device to Arduino should be very easy and trivial, but
personally I won't do it as I don't use Arduino.
Original issue reported on code.google.com by Nicola.Z...@gmail.com on 28 Nov 2013 at 5:09
Original issue reported on code.google.com by
Nicola.Z...@gmail.com
on 28 Nov 2013 at 5:09Attachments: