Write custom versions of arduino functions?

[dhiltonp]

Arduino's pinMode, (digital/analog)(Read/Write) take up 850 bytes all together.

Writing non-generalized versions for our library could reduce our flash footprint. Investigate costs/benefits.

[dhiltonp]

Maybe we can pull in this patch:

http://code.google.com/p/arduino/issues/detail?id=140

[dhiltonp]

I've pulled in this library, which is the implementation discussed here.

pinMode -> pinModeFast digitalWrite -> digitalWriteFast analogWrite -> analogWriteFast

This saves around 250 bytes, and reduces execution time.

[dhiltonp]

arduino-lite seems to be poorly maintained, but it should have a macro for analogWrite, which could be useful. No such optimization seems to exist for analogRead.

[dhiltonp]

http://maxembedded.com/2011/06/20/the-adc-of-the-avr/

This link demonstrates how to convert analog to digital on the avr. We currently use similar code in read_avr_voltage.

[dhiltonp]

adc reading implemented in read_adc.

[joshgoebel]

If we have those functions now isn't this completed?

[dhiltonp]

I've not verified that all arduino functions are replaced (doable by compiling the library directly in avr-gcc)

[joshgoebel]

Well, it's only a replacement if all the pins and values written are constants as determined by the compiler and therefor the dynamic code paths can be optimized out. So I assume you mean confirm that that is the case with the default compile of hexbright.h?

How were you planning to confirm that? Dissassembly?

[dhiltonp]

Part of the desire was to make this library usable outside of the arduino environment, compiling via avr-gcc while including/linking no arduino code.

At this point, I believe most of the inefficiencies of the arduino libraries have been resolved (interesting catch on the linked ram, by the way), so this is much less of a priority than before.