Go Down

Topic: High performance device driver library Arduino Mega 2560 - Beta release (Read 2918 times) previous topic - next topic

pert

Unless my memory fails me, the Arduino sketch compiles to about 1.7 KB for a Moteino Mega.
Robin2's code on Arduino IDE 1.8.2/Arduino AVR Boards 1.6.18 compiles to:
Quote
Sketch uses 1750 bytes (0%) of program storage space. Maximum is 253952 bytes.
Global variables use 192 bytes (2%) of dynamic memory, leaving 8000 bytes for local variables. Maximum is 8192 bytes.
So that's about what you remember. However:
The Ddr-ArdMeg version compiles to 342 bytes.
With the changes I mentioned above, HelloWorld compiles in the Arduino IDE to:
Quote
Sketch uses 1678 bytes (0%) of program storage space. Maximum is 253952 bytes.
Global variables use 338 bytes (4%) of dynamic memory, leaving 7854 bytes for local variables. Maximum is 8192 bytes.
I suspect the difference may be that the Arduino IDE automatically adds the line:
Code: [Select]
#include <Arduino.h>
to HelloWorld.ino.

Regarding the confusion over the term "device driver library": I think in the Arduino world we would call this a core. For example, here is the one used by Arduino AVR Boards:
https://github.com/arduino/Arduino/tree/master/hardware/arduino/avr/cores/arduino
Though some of the files in DdrArdMeg are analogs of the libraries included with Arduino hardware packages. So basically we have replacements in DdrArdMeg of the Arduino files/libraries:
Analog.h - hardware/arduino/avr/cores/arduino/wiring_analog.c
Binary.h - hardware/arduino/avr/cores/arduino/binary.h
Eeprom.h - hardware/arduino/avr/libraries/EEPROM/src/EEPROM.h
ExtIrq.h - hardware/arduino/avr/libraries/EEPROM/src/WInterrupts.c
Mcu.h - hardware/arduino/avr/libraries/EEPROM/src/wiring_digital.c
Pin.h - hardware/arduino/avr/libraries/EEPROM/src/wiring_digital.c
Port.h - hardware/arduino/avr/libraries/EEPROM/src/wiring_digital.c
Serial.h, etc. - hardware/arduino/avr/libraries/EEPROM/src/HardwareSerial.h, etc.
Spi.h - hardware/arduino/avr/libraries/SPI/src/SPI.h, etc.
They all seem to differ from the standard Arduino API.

If compatibility with the Arduino IDE was a goal you might consider creating a hardware package, as Cosa has done. This would allow you to define your own Arduino.h and pins_arduino.h files and thus likely cut out the extra overhead seen when using DdrArdMeg as a library with Arduino AVR Boards. There is more information on this here:
https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification

Robin2

I suppose I could have been clearer about that.
Still not too late to do that.

Many a good product has disappeared without trace due to poor marketing.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

Robin2

Is there some technical reason why the examples do not use the standard Arduino style with setup() and loop()?

If they did I think it would make the whole thing more accessible to Arduino users?

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

lonfield

Is there some technical reason why the examples do not use the standard Arduino style with setup() and loop()?

If they did I think it would make the whole thing more accessible to Arduino users?

...R
No technical reason. I just felt that it wouldn't add the example per se. It's also trivial to add a setup() and a loop() to the main() in the example in the same way as it is done in Arduino's main.cpp.

/Nils

lonfield

pert,

Yes, Arduino.h is a major contributor to the sketch size, though not the only one.

Compatibility with the Arduino was not one of my design goals (sorry  :( ). The goal, relative Arduino, is to have a similar level of abstraction so that it wouldn't be too difficult to alter between the two. From a technical view point it's also not really feasible to make Ddr-ArdMeg compatible with the Arduino API. For example, Ddr-ArdMeg has a more stringent approach regarding type safety. The main reason being to reduce the probability for bugs. This won't translate well to the Arduino API, which in many cases  uses regular, unscoped integers.

Regarding hardware package, I've limited the support to the line of MCUs having the same architecture as ATMega 2560. However, the Configure.h file you mentioned earlier adds support for defining various pin naming schemes as well as taylorization of specific peripherals (quantities, buffer sizes and some) based on the specific needs and/or the MCU used.

/Nils

Robin2

No technical reason. I just felt that it wouldn't add the example per se. It's also trivial to add a setup() and a loop() to the main() in the example in the same way as it is done in Arduino's main.cpp.
Just as with your product description I think you need to consider carefully how you present your examples to the market you are aiming at.

Stick with the Arduino programming style. Don't make it hard for people.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

Go Up