Im trying very hard to build a overly complicated bike-controller in order to teach myself programming.
Ive now at a stage where my very messy code is becoming a serious problem to debug, so ive figured its time to learn how to write a library, to externalize some of the code functions, where they can each be troubleshooted separately.
Now, since im very self-taught, i have some severe gaps in my programming knowledge, so im hoping for some forum guidance here, simply put; how to structuralize a "big project" code.
So could anyone please explain in a way so i can understand, what to put into the different files (.h/.cpp), and how that code must differ from whats used in a sketch?
Im currently very confused about how to reference between the different files, or if the referencing is all done in the "main" sketch (.ino)..
To setup some concrete examples;
I have a function to read my buttons, that is to readGPIO from a number of mcp23008 pin extenders, sort out the output pins and trunkate the rest into a binary state byte array (10101110 for example, if button "A" is on, its 1, else 0).
I then have another function to check the pressed-duration, to sort out long or short clicks, with a similar array containing each buttons last button-press-type as a value 0 (unpressed), 1 (pressed), 2 (shortclicked), or 3 ( longclicked).
I am then using a separate function to keep a record of the last button press type and the last button read time, so i dont have to keep the i2c bus busy with constant read requests.
Meaning, if i would poll a button state from my main loop once each loop, it would reply last state without polling for a new one between each button-check interval.
The idea is to have the code respond to each button change by resetting the last button-press-type to 0, to only respond to each new buttonpress once.
So how would i put thease functions into a library, or a external .h/.cpp file and keep the function usage "as is" in the rest of the code?
..I have NO clue about constructors and such "fancy" words, more than i know i should know them before calling myself a "programmer"...