Go Down

Topic: Another Compiler (Read 2338 times) previous topic - next topic

DavidHL

Hi,

Not sure which section this should be in - anyway, if you have an open mind this may be of interest:
www.rhombus-tek.com/BC4Arduino.html

It is a free no time limit demo, adapted for the Arduino hardware and includes the equivalents of DigitalRead/Write etc.. Has extensive libraries for LCDs(Char&Graphic)/KeyPads/I2C/SPI/RC5/1-Wire/SWUARTS and more.

David


Cheater

I cant see anyone giving up GCC. ;)

By the way if anyone is curious about why the Arduino code compiles bigger than the Bascom code, its because the Arduino does the pin number conversion at run time while the library for Bascom does it at run time.
I believe GCC compiles somewhat smaller than Bascom.

mem

#2
Feb 23, 2008, 11:41 pm Last Edit: Feb 23, 2008, 11:42 pm by mem Reason: 1
That looks interesting, particularly for those more comfortable with Basic than with C.

I do think the statement on the page you linked saying "when controlling I/O Pins runs 25 times faster than 'C'." is a little misleading. That speed improvement is over the Arduino digitalWrite function. But if maximum performance is required you can get more than a 25 times speed improvement with Arduino C code using direct port manipulation as documented here: http://www.arduino.cc/en/Reference/PortManipulation

DavidHL

Hi mem,
Thanks, you are absolutely right - it did say 'Arduino C' at one time - now it does again - just corrected. :)

Hi Cheater,
Quote 'By the way if anyone is curious about why the Arduino code compiles bigger than the Bascom code, its because the Arduino does the pin number conversion at run time while the library for Bascom does it at run(compile) time.'

I agree - so why not use the same Set/Reset P0-P13 in C and let it also run at assembler speed ?
Thanks for input.  :)

DavidHL

Hi mem - I failed to respond to >25 - BASCOM is right at the assembler limit using SBI/CBI so 125nS each at 16MHz.

Cheater

Quote
I agree - so why not use the same Set/Reset P0-P13 in C and let it also run at assembler speed ?

Its done at runtime to prevent newbie mistakes. Your library doesnt stop them.
For experts its just overhead but we know how to do it fast anyway if we need to.

DavidHL

Hi Cheater,

I know very little about C, and am genuinely interested in the fastest & most simple C code for:
Set Out13
Reset Out13

Thanks

Cheater

Ok pin 13 would be pin 5 on port B on the actual chip.

Fastest way to turn it on is sbi(PORTB, 5) and to turn it of its cbi(PORTB, 5).
Just like assembly. :)

Those two are defined in wiring_private.h and are pretty simple.
Code: [Select]
#ifndef cbi
#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))
#endif
#ifndef sbi
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))
#endif

DavidHL

Hi Cheater,
Thanks, that achieves the same speed - but there is the loss of P0-P13 clarity.

I also want to give feedback on your
Quote
By the way if anyone is curious about why the Arduino code compiles bigger than the Bascom code, its because the Arduino does the pin number conversion at run time while the library for Bascom does it at run time.

I substituted sbi(PORTB,5) etc in Blink, so that Arduino would also benefit from the compile-time conversion, but it made little difference.

I even went one stage further and removed 2 redundant likes of code from Blink, so total is now:
sbi(PINB,5);
delay(500);
but still 1085 bytes - so will not waste any more time on it - but thanks.

Cheater

Quote
Thanks, that achieves the same speed - but there is the loss of P0-P13 clarity.

It is possible to do what you've done and just make them 'aliases' and convert them to the proper names before compiling.
I consider that a really ugly thing to do however.

Quote
I even went one stage further and removed 2 redundant likes of code from Blink, so total is now:
sbi(PINB,5);
delay(500);
but still 1085 bytes - so will not waste any more time on it - but thanks.

Thats because your compiling against the Arduino libraries. They are always included.
If you compile it separately (with a Makefile) then there is no overhead.

blalor

Quote

Thats because your compiling against the Arduino libraries. They are always included.
If you compile it separately (with a Makefile) then there is no overhead.

Is that a difference in "cc -o whatever pins_arduino.o HardwareSerial.o ..." vs "cc -o whatever -larduino" (where libarduino.a is the output of "ar <er, something...> pins_arduino.o HardwareSerial.o ...")?

Cheater

Quote
Quote
Is that a difference in "cc -o whatever pins_arduino.o HardwareSerial.o ..." vs "cc -o whatever -larduino" (where libarduino.a is the output of "ar <er, something...> pins_arduino.o HardwareSerial.o ...")?

I think there is a difference but I'm not sure.

kg4wsv

Quote
Is that a difference in "cc -o whatever pins_arduino.o HardwareSerial.o ..." vs "cc -o whatever -larduino" (where libarduino.a is the output of "ar <er, something...> pins_arduino.o HardwareSerial.o ...")?


Yes.  Linking against all the .o files crams them all together, just like you ask.  Making a library and linking against -larduino extracts the code for the functions you use (not the whole thing) and merges only the needed code with the executable.

-j


AVRman

I love the Arduino environment.

Go Up