I/O:
In the early days there were input ports and output ports. Now there are grouped ports for a given purpose on the controllers. For example on some micro controllers, a group of ports can be defined as a rotary encoder or an a/d converter. The software to implement speed/direction/position is internal to the chip.
Pins need real estate and real estate costs money, so there is a tendency to want to reduce pin count. Real estate is the PCB or the IC die. when building something, a large amount of the total cost goes into the case and power supply.
Using I2C and the appropriate I/O device would relieve you of switch debouncing and polling.
Every mechanical switch bounces, so pushing it once could mean 10 closures the the micro sees.
So, if you let the I2C chip detect a change in state and then notify the processor via an interrupt, your programming become much easier.
I'm temporarily trying to avoid learning concepts of debouncing and matrix scanning of inputs. I'm trading that for the I2C bus (Native) and interrupts.
Your output seg, could be hard coded or maybe even hard coded into groups. e.g. Pass a few variables like a,b,c,d,e and each pair is an out/delay. So passing 5,10,5,10,0,0
is ring for 5 sec, off for 10, ring for 5, off for 10 or you could just plain hard code it (pseudocode) such as out 1,0; Wait 5, out 1, 0; wait 10 etc.; Return
If you like C, we can find that too.
Another platform I have never seen discussed here is the mbed.
https://mbed.org/platforms/
Here, the entire development process is done via a webpage in C for various processors.
Now, don't read it, but here is an 841 page manual for the LPC1768 used in one of the mbed modules:
https://www.google.com/url?sa=t&rct...pOYQQCnRgxetOEDSvLaCiWw&bvm=bv.58187178,d.cWc
These two concepts are not the mainstay of what's out there.