So I've been working on a project to create an IO API for Arduino. Something like the Java IO.
I was creating some libraries that deal with a sort of streams, like serial, eeprom and so on. And I felt that there is no library to deal with streams in general.
So I created one!
It's called ArduinoIO. I created a site with the documentation and the link to the github source code.
My wish is just share with you my library. Please feel free to comment, help, complain or just use!
That looks ... rather heavyweight for a microcontoller with 32kbytes of memory. How big is a sketch that uses your library for serial IO, compared to the normal Arduino serial/"print" driver?
Of course, Arduino has only a few bytes of program memory. But my point is: In some projects, it's important to have some "contracts" about what kind of streams we are using.
For ex, I was creating a font format to write in a GLCD module; the "writer" (a driver to print chars on GLCD) needs to read the font bytes from somewhere and use it to print the char to the GLCD module. But the font bytes could be anywhere, like eeprom, external eeprom, memory, etc; so how can the "writer", generically, read it without care the source of the stream?
The IO library solved my problem, I just wrote different input streams, one for each source. And the driver must only know that it will read from a InputStream.
I spent some extra bytes but I won a lot in generality.
A few months ago I was working with a GLCD module.
Originally, I was using PIC microcontroller, cross-compiling with SDCC compiler.
Unfortunately it generates a huge final code.
So I decide to do it with Arduino. I created a little driver to draw
bitmap images and text on that GLCD module.
As you know, there are a lot of bitmap fonts and drivers out there. But
everyone has it's own way to organize such bitmaps, and it's own way to
read it. Usually they store the bitmap in the program memory.
A bitmap font usually is an array of bytes, such bytes are grouped to
represent a charactere in the GLCD display (glyph). Usually the groups
are sequentially stored, corresponding the ASCII table.
Considering this, I thought that my driver could be more generic. So I could
create a font format that works similar to the above approach, but doesn't
require to have all glyphs. The font could has only the used glyphs,
saving some memory.
