Go Down

Topic: Arduino 0012 available. (Read 5395 times) previous topic - next topic

gradbert

What all would I need to do to put the build together?  I got a linux box and a spare afternoon

mungbean

Great stuff... interested to see the Ethernet library in there, but can't find any information about which shield it's actually for?

cheers


chris

mem

Quote
interested to see the Ethernet library in there, but can't find any information about which shield it's actually for?
I think its the wiznet w5100 http://www.flickr.com/photos/mbiddulph/2489332318/

mungbean

yeah the code mentions w5100, but the flickr pic is an Arduino board with built-in ethernet, aka Netduino, whereas the release notes for 0012 specifically mention a shield...

"Added an Ethernet library for use with the Arduino Ethernet Shield."


is this a typo?

hfoster

This sounds like a very nice update!

How do I make use of the "per-board specification of the upload.using preference" feature?  

I am guessing that the format of the specification is something like:
diecimila.upload.using=bootloader
orangutan.upload.using=avrispv2 (where avrispv2 is defined in programmers.txt)

In which file would I put the upload.using specifications, boards.txt or preferences.txt?

Thanks again; this will be a very helpful feature for those who use different boards!
H.

mellis


Hey Guys,

is there any reason this code doesn't work in 0012 but it does in previous releases:

extern volatile unsigned long timer0_overflow_count;

void resetMillis()
{
cli();  // disable interrupts
timer0_overflow_count = 0;
sei();  // enable interrupts
}

gives me this error when i compile

C:\Users\Rob\AppData\Local\Temp\build42789.tmp/Temporary_4215_2571.cpp:27: undefined reference to `timer0_overflow_count'


C:\Users\Rob\AppData\Local\Temp\build42789.tmp/Temporary_4215_2571.cpp:27: undefined reference to `timer0_overflow_count'


C:\Users\Rob\AppData\Local\Temp\build42789.tmp/Temporary_4215_2571.cpp:27: undefined reference to `timer0_overflow_count'


C:\Users\Rob\AppData\Local\Temp\build42789.tmp/Temporary_4215_2571.cpp:27: undefined reference to `timer0_overflow_count'


C:\Users\Rob\AppData\Local\Temp\build42789.tmp/Temporary_4215_2571.cpp:27: undefined reference to `timer0_overflow_count'

Thanks Rob.

mikalhart

#22
Sep 23, 2008, 03:01 am Last Edit: Sep 23, 2008, 03:02 am by mikalhart Reason: 1
There sure is!  There isn't a "timer0_overflow_count" in Arduino 0012 anymore.  

But you should be able to reset the millis count using this:

extern volatile unsigned long timer0_millis;
void resetMillis()
{
 cli();  // disable interrupts
 timer0_millis = 0;
 sei();  // enable interrupts
}


Mikal

Hey Mikal,

where is the emoticon for a guy bowing down  :D

my sketch now complies!

Cheers Rob.

phineus

#24
Sep 28, 2008, 05:33 pm Last Edit: Sep 28, 2008, 05:36 pm by phineus Reason: 1
I am having similar issues - I am jumping from 0010 to 0012 to get some of the new functions - but now my old code won't compile anymore.  Is there a general explanation of the likely issue like a quick explain of the include order thing mentioned above and anything else I might need to know?  Do I need to recompile all the libraries I'm using, for instance?  Which functions are now deprecated, and what do I do to get them back?  Sorry if these seem like naive questions but I think we're all learning here.  Do I need to post the specific errors?  They seem to change as I import more libraries, but since I don't know exactly what function is from which library...  For instance, why is it saying "Serial" is undeclared?

Here's an example of the kind of error I'm seeing:

Code: [Select]

/Applications/arduino-0012/hardware/libraries/Stribe/Stribe.h: In member function 'void Stribe::InitStribe()':

/Applications/arduino-0012/hardware/libraries/Stribe/Stribe.h:37: error: 'Serial' was not declared in this scope

/Applications/arduino-0012/hardware/libraries/Stribe/Stribe.h: In member function 'void Stribe::spiInit()':

/Applications/arduino-0012/hardware/libraries/Stribe/Stribe.h:88: error: 'memset' was not declared in this scope

In file included from /Applications/arduino-0012/hardware/cores/arduino/WProgram.h:4,

mem

Mellis, are some of the problems being reported here due to conflicts with the casting macros ?
[font=Courier New]     #define int(x)     ((int)(x))[/font] etc

If so, I wonder if it would help if those macros were moved from wiring.h to a separate file so that libraries could access everything else it needs from wiring.h (primarily the constants and typedefs) without conflicting with stdio.h etc.

Perhaps the casting macros could be included only by pde files. Is it necessary to support java style casts in library source code?

The_Bongmaster

i have been having problems burning the lilypad bootloader to an atmega168 chip, it was ok in 11 but wont work in either now :(

not sure why.
B-dui in creation.

ladyada

since the '328 is available now it would be really nice if the IDE was adapted for it. the arduino codebase has a lot of #defines that need modifying. i tried hacking it all myself to start but honestly did not get it all working in the end (for reasons i cant quite discern :( ) it compiles and uploads code but then the arduino 'freezes'
maybe spiffed knows the secret to getting the new rev up & running? hes figured it out before! (plzplzplzplzplz) ;)

mikalhart

#28
Sep 29, 2008, 05:19 am Last Edit: Sep 29, 2008, 05:21 am by mikalhart Reason: 1
I agree with mem about the advisability of removing what he calls the "casting macros", although I'll go one step further and suggest that they be completely discarded.  I don't see that they have any use, since they are already natively available in C++ (not just Java!).

In C++, the "C-style" cast expression

Code: [Select]
x = (int)y;
is exactly the equivalent of what is known as a "function-style" cast:

Code: [Select]
x  = int(y);
Therefore, most of the little series of #defines at the top of wiring.h:

Code: [Select]
#define int(x)     ((int)(x))
#define char(x)    ((char)(x))
#define long(x)    ((long)(x))
#define byte(x)    ((uint8_t)(x))
#define float(x)   ((float)(x))
#define boolean(x) ((uint8_t)((x)==0?0:1))


are redundant at best and possibly problematic at worst.  The last of these, boolean, is obviously a little different, but I also question its usefulness, since C++ has the perfectly usable native type bool, which performs exactly the same function.  If it were up to me, I would delete all the #defines and perhaps typedef bool boolean (but only for backwards compatibility) in 0013.

Here's a little sketch that demonstrates some of what I have been talking about:

Code: [Select]
#undef int // remove the wiring.h definition
void setup()
{
 long lng = 142L;
 int i = int(lng);
 bool b = i > 140;
}

void loop(){}


For a better read on "function-style" casting, you can read http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlcpp8a.doc/language/ref/cplr188.htm

Best regards,

Mikal

mem

Mikal, good to have your voice supporting the dropping of the pesky casting macros.

As you say, boolean is another issue. boolean is an arduino defined data type (probably for compatibility with Processing) so is required in wiring.h. The macro may be preferred to a typedef bool for compatibility reasons. I am not sure that the avr gcc bool does exactly the same as the boolean macro in wiring.h.

Lets see what the official Arduino word is on these macros.

Go Up