This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Writing onto the PCD8544 LCD

For writing onto the LCD screen by TM4C123GH6PM microcontroller, is it important to use the Peripheral Devices API's for GPIO, SSI and Clock or can I just  configure the GPIO, clock and SSI and write the values to the SSIDR and the values would be sent automatically to the DDRAM of Nokia5110 LCD?

  • Akash Kothari said:
    or can I just  configure the GPIO, clock and SSI and write the values to the SSIDR

    Akash,

    This depends on the APIs you are referencing. What is it that they are doing? Are they formatting or providing control words to send the data to specific registers or commands to the display to do specific tasks? This is really a very open ended question which is highly dependent on the Peripheril Devices APIs. In general, I would usually recommend using the provided APIs unless you full understand what they are doing and can recreate it with direct use of the TM4C TivaWare driver lib APIs.

    In regard to this point:

    Akash Kothari said:
    or can I just  configure the GPIO, clock and SSI and write the values to the SSIDR

    I would not recommend that you do this. Make use of the TivaWare DriverLib to implement the necessary SSI functions. The code for the setup and use of this peripheral is already proven and validated so why wouldn't you take advantage of it? Also, I would recommend you have a look at any applicable examples and re-use as much of these as you can as well.

  • Dear Sir,

    I want to write down functions that enable a program to be able to write different characters of desired sizes to the LCD. The APIs that I was thinking of using were that of GPIO, clock and SSI. Also, I want to write a code that controls the flow of data instead of using the APIs that are so easy to use. I was just wondering that the aforementioned latter idea was possible to carry out and if yes, then what things will I really need to focus on to get the goal accomplished.

    Thanks.

  • Hello Akash,

    So my understanding from your post is you want to write your own APIs; correct? Of course this is possible. There are no hidden features or secrets that the provided APIs make use of. To write your own APIs you would need to study and understand all of the relevant TM4C documentation. This would include the related chapters of the datasheet/user guide and any relevant errata/work arounds within the errata document as well any application specific needs such as the interface to your targeted peripheral device (in this case the display) and it's required formats and data flow. In addition, if you want to display characters on the display there might be a need to study how to generate the images to be sent to the display if it does not have some sort of built in mechanism to automatically display the characters on screen when provided an ASCII code. For displaying different size characters, you may even have to build graphic files for each character which means building your own font.

    As you may surmise by now, this process is no trivial task which is why we provide the APIs and discourage the extensive use of direct register manipulation (DRM as called by others on this forum). If you want to learn more about the uC architecture and registers, I would suggest you start with much simpler tasks such as simple GPIO manipulation then add some timer outputs/PWMs. Perhaps next try setting up SSI to communicate between two Launchpads while toggling some GPIO to indicate message receipt.. While doing all this, use the TIvaWare API's as reference to see the flow and order of initialization of registers even if you don't keep the same APIs.

    The general idea is to start small and build your expertise with the device before adding in another device externally such as the display. As another poster on this forum often professes keep it simple to start with then layer on complexity as you build a solid foundation.

  • As one (past) actively engaged in the electronic display biz I (generally) agree w/Chuck's writing.

    Yet one key/critical point has been missed! And that's your (chosen) display - a (likely) "no longer produced, small, Nokia. Does such a display have, "Much of a future?" Is it noted for its key display metrics: Contrast, Viewing Angle, Backlight brightness, Color Saturation?

    Most likely you've acquired this at discount - I'd counsel that your, "Launch of any significant effort - targeting this "less than pristine" display" (may) deserve a, "re-think."

    Due to today's prominence of cell-phones & tablets - client users "expect" much from a display. The old, very basic, display you reference will not fare well when viewed/compared.

    If a display w/SPI (or I2C) interface is sought - ARM M0 MCUs (< 1 USD @ Q=100) may serve as "front-end" for a more modern, capable display (usually parallel data bus based) and convert SPI from your MCU to the display's parallel data expectation...  In addition - displays are now arriving w/SPI interfaces - although most always these are (notably) far slower in "screen paint" than their parallel data equivalents...