Arduino 0016 Makefile location

Where is the Makefile for Arduino 16?

The 0015 Makefile doesn't work ( http://code.google.com/p/arduino/source/browse/tags/0016/hardware/cores/arduino/Makefile )

the 0015 Makefile references files that don't exist in 0016

Makefile:242: /Applications/arduino-0016/hardware/cores/arduino/pins_arduino.d: No such file or directory
Makefile:242: /Applications/arduino-0016/hardware/cores/arduino/wiring.d: No such file or directory
Makefile:242: /Applications/arduino-0016/hardware/cores/arduino/wiring_analog.d: No such file or directory
Makefile:242: /Applications/arduino-0016/hardware/cores/arduino/wiring_digital.d: No such file or directory
Makefile:242: /Applications/arduino-0016/hardware/cores/arduino/wiring_pulse.d: No such file or directory
Makefile:242: /Applications/arduino-0016/hardware/cores/arduino/wiring_serial.d: No such file or directory

I'm having the same problem.

What happened to wiring_serial.c? Has it been replaced/renamed? I can see methods still declared in wiring.h, e.g. serialWrite(..), but I can't find the definitions!

If anyone figures out how to compile code using a Makefile under 0016 then pls post details.

best regards,

/m

The old serial definitions were removed, they can't co-exist with the new HardwareSerial stuff that is now in the core. The ISR/interrupt functions can only be defined once. I'm no fan of the current HardwareSerial implementation.

Since posting this I've dug around and found that a Java program controls compilation for Processing... I just originally assumed there was a makefile hidden somewere. Keeping a makefile that would be in parity with the IDE would be a pain and prone to little issues. I don't think compiling outside the IDE is an important enough issue to get the level of effort it needs.

I'm starting to abandon the Arduino library/IDE in favor of simpler libraries and a VERY simple makefile.

The .d files are dependencies listings that are supposed to be automatically generated by the Makefile. This was added in a patch submitted by a user, but it seems it doesn't work very well.

@mellis: are you referring to arduino-0016/hardware/cores/arduino/Makefile?

This method still depends on SRC which no longer lists the correct files. Either that or the files have gone missing.

With the following cut-down SRC definition I now get through compilation:

SRC = $(ARDUINO)/pins_arduino.c $(ARDUINO)/wiring.c \
$(ARDUINO)/wiring_pulse.c \
$(ARDUINO)/wiring_shift.c $(ARDUINO)/WInterrupts.c

Of course then it fails on linking, because functions such as serialWrite() are undefined.

What puzzles me is that they don't seem to be defined anywhere in 0016.

So are the low-level serial access methods now deprecated?

The old serial functions are deprecated. The new "Serial" object(s) have a few ease-of-use advantages while the old functions were faster and smaller.

Pros of the new "Serial" object: - Can use "Serial.print()" to print any number or string - Supports all 4 ports on the Mega with Serial1, Serial2, Serial3 - object oriented style interface. I'm not sure if this is really a "pro", since it doesn't fit with the rest of the core functions.

Cons of the current "Serial" implementation:

  • The register's addresses for the serial ports are stored in variables. This means each address has to be pulled from SRAM instead of using immediates. This can make things much slower because even after the variables are looked up, they must be stored in registers. This forces functions to push/pop more registers.
  • Print functions are in the parent-class, so you don't directly call them. The addresses of the print functions are looked up from tables on every call. Printing at 9600 baud takes 16667 cycles per character, and this only adds another ~10 cycles to that. This is a bigger deal when using 2Mbaud which only uses 80 cycles per character or when using a modified version of "Serial" that allows async writes.
  • Print functions perform unnecessary casts and jumps. For example: "Serial.print(5);" will create a run-time executable that
  • stores 5 as a int16_t immediate in the executable
  • looks up the function for int16_t version of print() and calls it
  • cast 5 to a int32_t (because it's a signed number it takes a handful of operations to extend the sign bit)
  • calls the int32_t version of print
  • sees if the number is positive to possibly print a "-"
  • calls the printnumber function.
  • printnumber function repeatedly calls write() to print the number after looking up which write() it needs.

  • "Serial.begin()" is a really simplistic function when called with a constant... but since it's not inlined it gets included in-full, which can make the sketch several hundred bytes bigger. This makes the startup take longer, wastes space on the chip, and makes uploading the sketch take longer.

Thanks, that's really good info. I see why you are not a fan of the current version.

Ease of use is what makes Arduino great tho.

For me this means sticking with 0011 for now (that's right, I've not been able to build on any platform since!). Going forward I will either have to make my own low-level serial methods, copy the old ones, or perhaps migrate to a pure avr-lib environment.

To anyone involved in library maintenance/development: I think it would help if the deprecated function prototypes were also removed from the header files.

If GCC ever gets the “-fwhole-program --combine” option working for C++ and Processing’s build system is reworked to make use of it, then most of these issues would be resolved by the compiler.

Right now the “-fwhole-program --combine” definitely only works with gcc (g++ will barf on you). I have tried using just “–combine” with g++, which seems to work most of the time, but will sometimes do strange stuff…

It’s straight-C for me right now.