2

Recently, I have begun designing and writing code for microcontrollers in order to get a deeper understanding of how they work. The first major project I have undertaken involves writing a driver for the trusty Hitachi HD44780 LCD controller. In no time at all, I was able to implement a communication interface with the LCD and all the defined LCD commands. I am happy with the basic driver, I'm sure it follows convention. It uses a layered top-down approach such that there is a well defined public interface and the bottom layer contains the only functions to talk to the GPIO hardware.

However, I have started to implement advanced features such a vertical shifting/scrolling, animations etc. Implementation so far has been done within a single module which is good because it keeps all the functions together and the user of the driver can just call the functions provided to him/her. The downside of this is the driver is becoming more complex to maintain which tells me that I may need to break it up rather than pursue monolithic design.

I'm thinking of creating another module just for say vertical scrolling. The public interface will contain the data structure and functions required to perform scrolling which is all handled by main. Is this a valid approach or am I missing something completely?

When I say module, I am talking about a group of inter-related functions. My understanding is that a driver is a module for controlling a bit of hardware but module doesn't necessarily mean driver e.g. C string library.

  • 1
    What do you mean by a module? Is that a single source file, or are you thinking about putting the scrolling in a different driver? – Bart van Ingen Schenau Jun 1 '15 at 6:17
  • When I say module, I am talking about a group of inter-related functions. My understanding is that a driver is a module for controlling a bit of hardware but module doesn't necessarily mean driver e.g. C string library. – sulay Jun 1 '15 at 6:39
2

Drivers are frequently split into several layers. Something as "simple" as a mouse driver has separate modules for:

  • Different USB specifications: 1.0, 2.0, etc.
  • Specific USB controller chips.
  • HID devices.
  • USB mice.
  • All mice at kernel level.
  • Equivalent implementations of the above for PS/2 and serial mice.
  • Windowing system mouse driver (Xorg, etc.)
  • Graphical toolkit mouse API (GTK, QT, etc.)

It's certainly reasonable to split your driver based on level of abstraction, or what is likely to change together. Things like buffering, scrolling, formatting, wrapping, and animation can and should be split off and worked separately, using only the public API of the layers below.

  • Thank you for that answer Karl, that clarifies a lot :). – sulay Jun 2 '15 at 2:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.