Pages: 1 2 3 [4]   Go Down
Author Topic: Arduino 0012 available.  (Read 4552 times)
0 Members and 1 Guest are viewing this topic.
The Netherlands
Offline Offline
Newbie
*
Karma: 0
Posts: 6
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Well it seems that replacing the code with your two lines of code did the trick! The entire program now runs like a charm again! This makes me wonder though why the interrupts are disabled (and restored to their previous state) by the millis() function. In the wiring.c file I found the following reason: "disable interrupts while we read timer0_millis or we might get an inconsistent value (e.g. in the middle of the timer0_millis++)" but I'm not sure whether this will affect my code too. Thanks a lot anyway Mikal!

regards,
Dr. D.

P.S. I looked at the implementation of the delay() function, and now it seems to me that this statement in the Arduino reference isn't true anymore:

"Certain things do go on while the delay() function is controlling the Atmega chip however, because the delay function does not disable interrupts. Serial communication that appears at the RX pin is recorded, PWM (analogWrite) values and pin states are maintained, and interrupts will work as they should." (source: http://arduino.cc/en/Reference/Delay)

Since delay() calls millis(), and millis() disables and restores the interrupts, this means that during a delay() the interrupts are regularly switched off and on. I wonder if interrupts still keep "working as they should".
« Last Edit: October 16, 2008, 08:54:06 am by drdistortion » Logged

Austin, TX USA
Offline Offline
God Member
*****
Karma: 4
Posts: 997
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Dr. D--

The reason given for the disabling of interrupts in millis() is indeed correct.  Release 0011 did not disable interrupts in millis(), and I experimentally determined that about 1 in 800K calls returned an incorrect value as a result.  The problem will never affect your code, though, because in your ISR, interrupts are already disabled!  (Your only problem now is dependence on an internal implementation detail.  You may find, for example, that timer0_millis doesn't exist when you try to migrate to 0013.)

I am troubled by the fact that rapid interrupts with embedded calls to millis() crash things.

Your observation about delay()'s documentation is thought provoking.  Since delay repeatedly calls millis(), it is obviously no longer correct to say that delay() does not disable interrupts.  However, there are brief windows where interrupts are still enabled in between calls to millis().  I wonder whether this would allow for serial communication.  I'll experiment.

Thanks for the feedback, and I'm glad your code is working!

EDIT: delay() and serial communication seem to be still compatible.

Mikal

« Last Edit: October 16, 2008, 11:43:25 am by mikalhart » Logged

0
Offline Offline
Newbie
*
Karma: 0
Posts: 49
Freediving, spearfishing, alt energy, motion control, christian
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

[size=14]timer0_overflow_count[/size]

I've been using timer0_overflow_count to drive a stepper motor but I gather that on v12 it's not longer available.

What can I do?  

Thanks

Marcel
<novice>
Logged

Vienna, Austria
Offline Offline
Newbie
*
Karma: 0
Posts: 2
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I've tried to declare a function pointer (for a function returning an int) with 0012 on linux (it shows "0012 Alpha")

Code (minimal stripped-down version that reproduces problem):
Code:
int (*statefun)();

void loop ()
    {int a = 1;}

void setup ()
    {int b = 2;}
This produces the error message (already shown by others):
error: expected unqualified-id before 'int'

When I declare the function pointer as follows:
Code:
typedef int zoppel;
zoppel (*statefun)();
the sketch compiles fine.

What black magic are you guys doing to the builtin type int?
Is there any compile-time switch to turn off that black magic -- I'd gladly do without function-style casting for my projects.
Logged

London
Offline Offline
Tesla Member
***
Karma: 10
Posts: 6255
Have fun!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi runtux,

Some misguided soul  smiley-wink created some macros like these for casting :
#define int(x)     ((int)(x))

These are in wiring.h and you can either comment them out, or you can put your function prototype in a separate header file and #include in the sketch file, it should be ok as long as its not part of the physical pde file.
« Last Edit: November 26, 2008, 11:01:03 am by mem » Logged

Forum Administrator
Cambridge, MA
Offline Offline
Faraday Member
*****
Karma: 12
Posts: 3538
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

You should also just be able to:

#undef int
Logged

London
Offline Offline
Tesla Member
***
Karma: 10
Posts: 6255
Have fun!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

David, not sure why, but that didn't work when I tried:

Code:
#undef int

int (*statefun)();
void loop ()
    {int a = 1;}

void setup ()
    {int b = 2;}
Logged

Vienna, Austria
Offline Offline
Newbie
*
Karma: 0
Posts: 2
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

mellis writes:
Quote
You should also just be able to:

#undef int
and mem notes:
Quote
David, not sure why, but that didn't work...

sorry for not reporting this: Yes I also tried to #undef int without success after having read other posts concerning this bug  smiley-wink in 0011

I'd vote for removing this #define or at least allow to turn it off via a #define (or #undef if somebody finds out how).

Just did some more testing: The #undef works if there is some other statement before it. So
Code:
typedef int zoppel;
#undef int
int (*statefun)();

works, while removing the typedef line doesn't. Weird. Maybe this is related to the following fix in the announcement:
Quote
* Moved insertion of #include <WProgram.h> to after any comments and #include statements in the main sketch file.  This means that an #include <stdlib.h> now works.

So it looks as if the #include is moved *after* the #undef rendering it useless if the #undef isn't preceded by a statement.
Logged

Pages: 1 2 3 [4]   Go Up
Jump to: