I can understand that it is not encouraged to write your own interrupt handlers on day one. That's why we have wrappers like attachInterrupt() - I don't use them either, but I'm perfectly fine with them. But hiding main() ... come one! Thats less than 10 lines of perfectly understandable code. The most intellectual part of it is the for-loop. No pointers, no object oriented code, no if statement, no boolean operators... how simple can it get?
If you really think that hiding main() is necessary, then I don't want to know how simple-minded the user-base is thought to be. Every beginner should instantly feel offended by that. That's outrageous!
@madworm,
I was thinking more along the '328 lines. That's a good point about the smaller parts - I imagine you are not using any bootloader on those then? Just download sketches via the ICSP interface?
At least for the bigger chips I use custom 'boards.txt' entries, but I suppose it'll be the same thing for the tiny ones. And I don't use the IDE for the tiny ones...
From what I've seen of 1.0, switching between bootloader and a real programmer will be much easier (menu based, which is great). The fuse settings don't change though, one doesn't regain any flash space that way.
off-topic:
The next big step would be to use one of the bigger ATmegaXX-U chips on the arduino boards with enough flash space to hold both the serial port emulation AND and ISP emulation at the same time. This should once an for all kill this damn "can't upload" issue. Pololu has a programming adapter that does just that, but it doesn't seem to be 'open' and requires winblows tools to change settings.
But I guess the inclusion of avrdude 5.11 (which itself can resets the target board now using '-c arduino') will be a big increase for upload reliability.
To you it is simple... for someone that just started in programming and embedded devices (which is probably the majority of Arduino users) main() makes a lot less sense than setup() and loop().
I can understand you. I only use the board and the bootloader from Arduino, but I also see why Arduino is made the way it is now. But the good thing is that it allows people to evolve and try different ways of using the hardware and software according to their own personal knowledge.
##############################################################
#
# to activate this board, select it and use:
#
# 'Burn Bootloader' - 'w/ USBtinyISP' just once
# this makes sure the correct FUSE settings are used
#
8x8RGBLedMatrix1.name=8x8 RGB LED Matrix - ATmega168 / 16MHz Quartz / USBtiny
8x8RGBLedMatrix1.upload.maximum_size=16384
8x8RGBLedMatrix1.upload.speed=115200
8x8RGBLedMatrix1.upload.using=arduino:usbtinyisp
8x8RGBLedMatrix1.bootloader.low_fuses=0xFF
8x8RGBLedMatrix1.bootloader.high_fuses=0xDD
8x8RGBLedMatrix1.bootloader.extended_fuses=0x05
## just so the IDE doesn't throw an error
## it will be overwritten, but we need the correct FUSE settings
8x8RGBLedMatrix1.bootloader.path=optiboot
8x8RGBLedMatrix1.bootloader.file=optiboot_diecimila.hex
##
8x8RGBLedMatrix1.bootloader.unlock_bits=0x3F
8x8RGBLedMatrix1.bootloader.lock_bits=0x3F
8x8RGBLedMatrix1.build.mcu=atmega168
8x8RGBLedMatrix1.build.f_cpu=16000000L
8x8RGBLedMatrix1.build.core=arduino
#
#
#
##############################################################
If I want to do without a bootloader, I change the fuse settings, lockbits and the available flash size to respect that fact. Uploading works as usual.
Uploading is currently slower with an usbtiny than with optiboot. There is a trivial 'patch' for that, but it was not accepted... it involves adding the bitclock parameter '-B 1' to the programmers.txt and a tiny modification in the java code that deals with uploading. This would increase upload speed at least 10x.
O.O I had no idea you could do that and this is 100% awesome. I just shaved 132 bytes off my sketch and now have enough space to implement a URL decode function (94 bytes) to fix that bug that's been annoying me for months.
CapnBry:
O.O I had no idea you could do that and this is 100% awesome. I just shaved 132 bytes off my sketch and now have enough space to implement a URL decode function (94 bytes) to fix that bug that's been annoying me for months.
Glad that helped. Better not upgrade to version 1.0 though, unless they fix that .
You CAN use main() instead of setup() and loop(). Really, yes, you can.
void setup() { Serial.begin(9600); Serial.println("setup does not run");
}
void loop() { Serial.println("loop does not run");
}
int main() {
init(); Serial.begin(9600);
while (1) { Serial.println("My main is running");
delay(1000);
}
}
This works because main() is inside the core, which gets compiled to a ".a" library archive. If you use any function with the same name, the linker will put your copy into the final output, rather than the one from the library.
So go ahead and use main(). The ability to do so has been there all along. Just make sure you call init() to initialize the hardware, so things like millis() and delay() will work properly.
void setup() {
Serial.begin(9600);
Serial.println("setup does not run");
}
void loop() {
Serial.println("loop does not run");
pinMode(13,OUTPUT);
}
int main() {
init();
Serial.begin(9600);
while (1) {
Serial.println("My main is running");
delay(1000);
}
}
compiles on 0022 and not on 1.0-rc1.
I've had a quick look on the compiler/linker parameters, but can't find a difference.
Error on 1.0-rc1:
avr-gcc -Os -Wl,--gc-sections -mmcu=atmega168 -o /tmp/build792419732568248348.tmp/sketch_oct16a.cpp.elf /tmp/build792419732568248348.tmp/sketch_oct16a.cpp.o /tmp/build792419732568248348.tmp/core.a -L/tmp/build792419732568248348.tmp -lm
core.a(main.cpp.o): In function `main':
/XXX/arduino-1.0-rc1/hardware/arduino/cores/arduino/main.cpp:6: multiple definition of `main'
sketch_oct16a.cpp.o:sketch_oct16a.cpp:16: first defined here
This error vanishes when adding the 'weak' attribute as pointed out before.
I feel that if this compiles (works?) on 0022, it should do the same on 1.0