I am a C# programmer and am used to work with classes and Object Orientation (OO).
So I created some simple classes to encapsulate some essentials.
I've attached a .zip file called Libraries. Unzip it in your Arduino folder in My Documents. It contains 3 mini libs: AnalogInput, DigitalInput and DigitalOutput.
Please read the header files for more information on the specific classes.
It is a work in progress. I build what I need but make sure I can extend later.
BTW: there is a method enableInternalPullup on the DigitalInput class
I've created these classes as an exercise (in Arduino dependency management ) and because I don't like all the static and sequential stuff that seems to be the norm. I understand that it is convenient for beginners, but I am an OO programmer 8) and like it when I don't have to keep all the low level details in my head XD I truly believe that you get better code if you use OO responsibly. But I also understand that it is not the only variable on a platform like the Arduino. That is why I want to learn a bit more on code optimization first, before getting too far ahead of myself.
Also being a beginner in experimenting with the Arduino (although I had previous experience with other types of MCU's) I quickly found that I was repeating myself (in code). To me, that is always a sign 'something needs to be done'. This is my first pass at it.
I hope more people will see its value and find these classes useful.
robtillaart:
Not necessary the norm but sometimes the only way to get the functionality needed packed in the memory available.
Can you elaborate on that? I have no idea (yet) on how efficient the compiler packs down the code and how smart it is in optimizing.
What I saw was staticly defined class instances just so the MyLib.someFunction (like SPI.write or whatever) syntax can be used. Is the compiler smart enough not to package up unused code? Otherwise if you don't use those statics (because you need more than one instance?) they will only take up memory space.
This brings me to a question I had in my mind since I first posted SimpleTimer on the Playground... what's the best place to share some Arduino code ? Playground seems a bit too "official" sometimes, while libraries posted here in the forum are quickly buried to oblivion due to the sheer amount of activity going on.... The github idea is good IMHO, but it seems the staff doesn't have enough time to bring it forward.
I think some improvement is needed in this area.
I apologize with the OP for hijacking his thread I'll have a look at the libraries ASAP.
obiwanjacobi:
Is the compiler smart enough not to package up unused code?
I think unreferenced code is stripped by the linker. Therefore you get into the final .hex file only the code that is actually called (to be precise, that appears to be called at compile time - there's no run-time analysis of dead codepaths, of course).
mromani:
I think unreferenced code is stripped by the linker. Therefore you get into the final .hex file only the code that is actually called (to be precise, that appears to be called at compile time - there's no run-time analysis of dead codepaths, of course).
At the "How the linker works" section it describes how the linker uses complete object files to decide what to include and what not. So only if you write each function in a separate file, it cannot get optimized even when it is not in use. There goes the class file =(
Attached is a 'port' of the MIDI library 3.2 by Francois Best where I've split up the Midi class into a MidiInPort and a MidiOutPort. I haven't included the midi thru functionality but the rest is as much copy-paste as possible.
The MidiOutPort takes a Stream in the constructor thus allowing a much broader range of output devices (not tied to Hardware Serial anymore). The MidiInPort still uses the USE_SERIAL_PORT macro (because there is no virtual serial device base class I couldn't get rid of the call to Serial.begin(MIDI_BAUDRATE)).
Now I can receive midi on the hardware serial and send midi on the software serial and to multiple outputs.
I once had the idea to make a "midi -> arduino -> switch my keyboard light" sketch, with this lib it becomes easy.
Thanx! And I haven't even shown you all the code. It seems I am slowly building up a new template library ... XD
Not entirely sure what you mean by 'switch my keyboard light' but I've found that even if you use the standard MIDI library on Hardware serial and only use the input, you're still able to output text to the COM port on the PC calling the normal Serial.Xxxx methods.
obiwanjacobi:
I dont get why an empty program -with just an empty setup and loop method- is still 466 bytes long!?
Here's the linker map of an empty program. Much of it are the interrupt vectors. Also, even an empty program still calls main() and init() which set a few things up, and so those are always linked.
obiwanjacobi:
[...]
(because there is no virtual serial device base class I couldn't get rid of the call to Serial.begin(MIDI_BAUDRATE)).
[...]
You can use the magic of OOP and have an overloaded constructor which takes a HardwareSerial*, so that the usage could be either this:
MidiOutPort midiOut(&softSerial);
or this:
MidiOutPort midiOut(&Serial);
completely transparent to the user. In the library implementation, the easiest way to do this is to encapsulate the write() function, forex:
void write(uint8_t b) {
if (m_hws != NULL) { // set to null in the softwareserial constructor
m_hws->write(b);
} else { // not using hardware serial
m_ss->write(b);
}
}