next topic »

[Reply #30 on:]

Why do that?

I believe it is an attempt to make the core more portable.  The idea is to have the pins defined in a header file that is located and included when a sketch is built. 

But I don't know why main.cpp was used to pull in the pin definitions.

In fact why not change main.cpp from ... Then it compiles on its own without any header files, and will only be used if the user doesn't supply their own main function.

I almost agree.  There is some safety in using a common header file for function prototypes.  Well, with overloading, maybe there isn't.  Let me check ... never mind.  I must be thinking of ObjectPascal.

I agree.  The second version is a good alternative.

[Reply #31 on:]

I believe it is an attempt to make the core more portable.  The idea is to have the pins defined in a header file that is located and included when a sketch is built. 

Since the developers control what the IDE does when it compiles, why not just have it copy the pins file anyway? I mean, if they are going to copy main.cpp, why not copy pins_arduino.h as well? This seems a convoluted way of doing it.

[Reply #32 on:]

I have no idea why it was done the way it was.

[Reply #33 on:]

I believe the idea was to allow 3rd party boards to use the standard Arduino core more easily.  All the pinout-specific stuff is supposed to go into a single header file, and boards.txt can specify the directory.  So in theory, a board which only needs to customize pins could just add a directory and its own copy of pins_arduino.h, and not need to modify any files, except perhaps boards.txt.

Compiling the code into main.cpp was probably just an oversight?  It very likely belongs in either wiring_digital.c (where it's actually used), or in its own dedicated .c file (as it was in prior to 1.0).

If you delete the ARDUINO_MAIN line from main.cpp, and add it into wiring_digital.c like this:

Code:

#define ARDUINO_MAIN
#include "wiring_private.h"
#include "pins_arduino.h"

I believe that solves this problem.

[Reply #34 on:]

We can certainly move the pins_arduino.h include from main.cpp to some other file, if it helps.  Just submit a issue / patch to the Google Code list: http://code.google.com/p/arduino/issues/list

[Reply #35 on:]

Done, issue #691, including a patch! 

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

[Reply #36 on:]

Bump.

This patch became part of 1.0-rc2.  Anyone who really cares about main() might want to give 1.0-rc2 a try before 1.0 officially releases?

http://code.google.com/p/arduino/wiki/Arduino1

[Reply #37 on:]

This example compiles and works:

Code:

int main(void) {
  init();
  Serial.begin(9600);
  pinMode(2, INPUT);
  while(1) {
    int sensorValue = digitalRead(2);
    Serial.println(sensorValue);
  }
}

I see that all compiler warnings have been turned on, probably only for testing.

Some observations:

Code:

avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega168 -DF_CPU=16000000L -DARDUINO=100 -I/***/arduino-1.0-rc2/hardware/arduino/cores/arduino -I/***/arduino-1.0-rc2/hardware/arduino/variants/standard /***/arduino-1.0-rc2/hardware/arduino/cores/arduino/IPAddress.cpp -o/tmp/build4743758903281560802.tmp/IPAddress.cpp.o
In file included from /***/arduino-1.0-rc2/hardware/arduino/cores/arduino/IPAddress.cpp:3:
/***/arduino-1.0-rc2/hardware/arduino/cores/arduino/IPAddress.h: In member function 'IPAddress::operator uint32_t()':
/***/arduino-1.0-rc2/hardware/arduino/cores/arduino/IPAddress.h:51: warning: dereferencing type-punned pointer will break strict-aliasing rules
/***/arduino-1.0-rc2/hardware/arduino/cores/arduino/IPAddress.h: In member function 'bool IPAddress::operator==(const IPAddress&)':
/***/arduino-1.0-rc2/hardware/arduino/cores/arduino/IPAddress.h:52: warning: dereferencing type-punned pointer will break strict-aliasing rules
/***/arduino-1.0-rc2/hardware/arduino/cores/arduino/IPAddress.h:52: warning: dereferencing type-punned pointer will break strict-aliasing rules

Code:

avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega168 -DF_CPU=16000000L -DARDUINO=100 -I/***/arduino-1.0-rc2/hardware/arduino/cores/arduino -I/***/arduino-1.0-rc2/hardware/arduino/variants/standard /***/arduino-1.0-rc2/hardware/arduino/cores/arduino/Tone.cpp -o/tmp/build4743758903281560802.tmp/Tone.cpp.o
/***/arduino-1.0-rc2/hardware/arduino/cores/arduino/Tone.cpp:108: warning: only initialized variables can be placed into program memory area

The last one can be silenced by using 'const prog_uint8_t var_name' instead of 'const uint8_t PROGMEM var_name'.

See: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=57011

I'm using:

* avr-gcc (GCC) 4.4.3
* avr-libc 1.7.1

Thanks for making it work.

[Reply #38 on:]

The PROGMEM issue seems identical to

http://code.google.com/p/arduino/issues/attachmentText?id=688&aid=6880000003&name=0004-Avoid-spurious-pgmspace-warnings.-See-http-gcc.gnu.o.patch&token=9f0e77f0e7d48a831b326a901e2ed403