Learning to create libraries

Can anyone recommend a reference to learn how to create libraries?

I have the data sheet for the ili9488 chipset, and I don't like any of the various libraries I have tried in my effort to get my mcufriend 3.5" TFT LCD working ( nothing but a white screen ).

I also have the 'Beginning Arduino Programming' by Brian Evans, but it seems to be a repeat of the reference area available from Arduino.cc .

I know the .h file is the header file, and the .cpp file contains the 'meat and potatoes' of the usable commands referenced in the .h file.

My current question is: how do I correlate the .h and .cpp files with what is in the data sheet, so that I may properly write and implement a library ( using the data sheet as a reference )?

Thanks!

Attached are the notes I have so far, and a copy of the data sheet ( which seems to be too large to be postable here, 9.3 MB. Here is the link for a copy I put on Google Drive ).

https://drive.google.com/open?id=0B6te0J--JjLXQWVDMGl0NU84V0k

How to write a library for arduino tutorial.pdf (169 KB)

I haven't written any code yet.

I'm just trying to get a good start on planning things, so that problems down the road will be minimized.

I think that I can start by getting basic commands from Section 5 of the data sheet.

I just haven't figured out the proper way to code the .h and .cpp files to use them.

I want to start small and work my way up, as I realize that I have a big task ahead of me and don't want to bite off more than I can chew at one time.

Attached are .pdf's for the basic and extended command set.

The data sheet I posted on Google Drive will need to be referenced for the descriptions, as the file is too big to post here, even when zipped.

ILI9488_Preliminary_DS_V090_Command_Basic.pdf (134 KB)

ILI9488_Preliminary_DS_V090_Command_Extended.pdf (145 KB)

cw8jwh:
I haven't written any code yet.

Why not just start with the libraries you were unhappy with?

Creating an interface with a complex piece of hardware is not trivial.

The bare mechanics of class design are easy enough to pick up in a few hours, along with what sorts of things go in a header file (declarations) and what goes in a source file (definitions). There are numerous references and tutorials about C++ classes (those are your Google keywords). I don't know which ones are best since I learned this stuff a decade ago.

Designing a class is orders of magnitude harder, especially for a device like this.

The basic structure will require a multi-level hierarchy of functions. At the low level will be driver functions that just execute one of the commands. Higher level functions would combine multiple commands to perform a more complex task, like initializing the display or drawing a simple shape (like a line).

BulldogLowell:
Why not just start with the libraries you were unhappy with?

My guess is because he's not happy with them. Necessity may be the mother of invention, but dissatisfaction is its stepfather or something.

Jiggy-Ninja:
My guess is because he's not happy with them. Necessity may be the mother of invention, but dissatisfaction is its stepfather or something.

They may be a harbinger of the difficulties to come. If was widely adapted and there were good libraries, someone with the talent to build a lib would may have done it! Still, the fundamental methods may be there... albeit not perfected for the OP's use. Why would you toss the wheel if you thought you may have something better?

To me, graphics programming is amongst the most difficult to understand and develop... only the most intrepid of those (who may not even how to build a C++ class?) would undertake that task!

I like an honest challenge for one, as it helps me keep my mind sharp.

And, please trust me, I am under NO illusions about magnitude or potential difficulties.

I could very well start with what I don't like,

But what I think I'd initially like to learn is how the .h relates to the .cpp and how the .cpp relates to the datasheet of whatever chipset.

I realize that a lot of the libraries have been built with multiple chipsets in mind, but what I want to do is start small ( relatively, of course ) and work with one chipset until I get a handle on things.

Then, once I am proficient and comfortable enough, branch out from basic command sets for a single chipset, to the extended set, and then on to adding different chipsets. But that last part is predicated on future interest.

For now, I only want to do one chipset, which is the ili9488; because I have an mcufriend 3.5" TFT LCD, and the silk screen on the board says it is for the Mega 2560.

And I will be using the Due as my board because I like it more than I do the Mega, and I don't happen to have any Mega boards.

Besides all of that, I am seriously considering starting classes this fall at the local community college so I can work towards my eventual B.S. degree. A few C++ classes should help with an eventual engineering degree.

mcufriend3point5inch-tft_ili9488_rear.zip (878 KB)

cw8jwh:
For now, I only want to do one chipset, which is the ili9488; because I have an mcufriend 3.5" TFT LCD, and the silk screen on the board says it is for the Mega 2560.

So it is designed for 5V systems (like the Mega).

cw8jwh:
And I will be using the Due as my board because I like it more than I do the Mega, and I don't happen to have any Mega boards.

The Due is a 3.3V system and will probably not work with the shield, the shield could even damage the Due.

Whandall:
So it is designed for 5V system (like the Mega).

The Due is a 3.3V system and will probably not work with the shield, the shield could even damage the Due.

I see your point, so I will look for a couple of Mega boards to use with the screen.

But this doesn't affect the subject of this thread.

Thanks!

I would say: forget about a library for now. Start with an empty sketch with setup() and loop().

Next think what must happen. You probably want/need a function to initiialise the display.

Next you probably need a function to draw a pixel. Think wat it needs; e.g. position and color.

So now you have the basis to implement. You probably want to initialise the display from setup(). The drawing of pixels can be done anywhere, below it's done in setup.

void setup()
  // init display
  initDisplay();
  // draw a diagonal line
  for(int cnt =0;cnt<10;cnt++)
  {
    drawPixel(cnt, cnt, 128, 00, 255);
  }
}

void loop()
{
}

/*
initialise display
*/
void initDisplay()
{
  for you to implement
}

/*
draw a pixel
in:
  x position
  y position
  color
*/
void drawPixel(int x, int y, int red, int green,int blue)
{
  for you to implement
}

Exact details obviously depend on the display. The display might have built-in functionality to draw a line or circle and to draw text but not one to draw a pixel (drawing a pixel would be drawing a line with a length of 1 in that case). Write functions that give easy access to those functionalities.

Its all about modeling your thinking.

Look at the manual and write down the steps you would do to achieve the different things you want to achieve. A good starting point is to create "tools" first. These become the building blocks (foundation) to your library. Maybe start with setPixel(x,y,color) then you use this later to draw a line, then fill a rectangle, grab bitmaps from a file etc. etc. Its like lego blocks. Make up the base toolset and build from there.

Now, in the wonderful world of c++ you could just grab some else's base tool set that has the tools you need are set out but non functional, inherit this and build a class from the handbook that makes them work with your screen.

Good luck, your kinda' like the kid thinking the Air-force has got it all wrong and trying to build your own fighter jet. But actually, many of us started there.

My first job out of college, I was led to an inert NC milling machine prototype handed a data sheet on the servo motors they installed and told to write the software to make it go.

-jim lee

As a starting point, I decided to follow a prior suggestion and pick a library to work with,

so I chose the MCUFRIEND_kbv library.

Attached is a cross-rerence sheet I made to help me understand the library files ( .h and .cpp ) inter-relationships better.

Anyone mind glancing at it, to see if I have everything pegged correctly?

Thanks!

cross_reference_between_dot_h_and_dot_cpp_files_in_C_plusplus_for_Arduino.pdf (63.5 KB)