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.
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.
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: Arduino Reference - Arduino Reference
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.
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.
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
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.
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.
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.
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 ...")?
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 ...")?
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.