Why don't you post the complete sketch?  Without the rest of the code we can't really see what's happening.  For example, we don't know what you've initialized dataPin and clockPin to.  We don't know what type of data Variable_a_[] and Variable_b_[] are.

Additonally I don't see you setting dataPin and clockPin as outputs.

Remove the Serial.begin and Serial.print from your code and try it.  You're probably running into "flow-control" because you're writing serial output and nothing is there to receive it.

Very strange.  I just downloaded Arduino-0013 onto an Intel-based MacPro (10.5.6) and I'm getting this error when I launch it:

Code:

java.lang.UnsatisfiedLinkError: /Applications/arduino-0013/Arduino 13.app/Contents/Resources/Java/librxtxSerial.jnilib:
thrown while loading gnu.io.RXTXCommDriver

Arduino-0012 runs just fine on the same machine.  Just in case something got corrupted in the download I tried again and same result.  I'm able to run 0013 on my other machines with no problems (dual G5 and G4 Powerbook).  In fact I've never had a problem running any version before (all the way back to 0007).

Any ideas?

Not at the time. I was in a hurry to get things working the last time it happened so I just did the reboot (it was about a 1.5 weeks ago).  Next time it happens I'll check the log.

I've had this happen a few times on OSX (10.4.11) with 0012.  The symptom is that the Arduino icon bounces in the dock forever and the app never starts.  The only solution I've found so far is a reboot.

I had always assumed that it had something to do with the USB serial port and the application having trouble opening the port.  I tend to do a lot of connects and disconnects of the USB cable while prototyping.  While I always shut down the IDE before connecting/disconnecting, sometimes the serial port doesn't show up in the list and I have to unplug and reset my USB hub.

Well then I'm guessing that OSX avr-gcc interrupt bug is not what's causing your problem.

Since you already said that the 0011 Wire library works for you, I pretty sure that building it under 0011 on OSX will likely work.  Have you compared the Wire.cpp source between 0011 and 0012 (or 0013) to see what's changed?

When you "switch out the library" are you copying over the entire Wire folder under hardware/libraries?  If so, then you're also bringing along the Wire.o object file that was compiled under an older avr-gcc version that didn't have the bug.

Try this: Use the library from 0011 in 0012 (or 0013) and be sure to delete the Wire.o file.  This will force it to be rebuilt with the later avr-gcc compiler.  If the interrupt bug is the root of your problem, then the library from 0011 will now also have the lockups.

However I have only been able to tweak Wire 0011 library to be a reliable I2C Master<>Slave network. Wire 0012 and 0013 works for about 100 byes then freezes.  I have spent several hours trying to determine why, but have yet to find a tweak that will make I2C reliable.

Are you using the OSX version the IDE?  If so then there's a "known" bug with the avr-gcc compiler (4.3) that's included with Arduino 0012 and 0013.  The compiler generated bad interrupt handling code which causes crashes and lockups.  The Wire library relies on interrupts so your freezes match how this bug manifests.

The Windows version of avr-gcc doesn't have the bug.  I don't know about the vaious linux variants.

You simply have a bug in your sketch. The IDE couldn't determine the program size because the compilation failed and no "program" was generated. This is not the same issue.

You're apparently missing the setup() function definition.

Arduino-0012
Mac OSX 10.4.11 PPC

About 1 time in 10 I randomly get the following error while Verifying a sketch:

Code:

Couldn't determine program size:    text         data          bss          dec          hex      filename

[/color]

Verifying again immediately after the error will work without any problems so it doesn't seem to be a critical bug.  It's only annoying.  :-/

See here:

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1238640832

These enhancements are planned to be rolled into the next Arduino IDE version.

Providing contact information and ongoing support would be the responsibility of the author. If you feel you're not getting the support you need from said author, then simply don't use their (free) library.

Alternately you could work on finding a solution and contributing that to the community so that others can benefit.

And yes, the solutions to your compilation problem can be found be examining the header files referenced in my original post and adjusting for the differences between the 168 and 328 chips.

I'm okay with an "unsupported" patch version as long as it's "supported" by the IDE. In other words the Arduino core could conditionally include this enhancement to the standard AVR-GCC code if the target was the 328. The enhanced 328 header definitions would be part of the Arduino core distribution, not the AVR-GCC includes.

This would allow the existing code to seamlessly compile without forcing people to track down a relatively esoteric fix.

I've run across a number of problems with existing code and libraries when compiling for the ATmega328. What I've found is that the included AVR header file for the chip has a significant number of define names changed for no apparent reason. When existing code is compiled for the 328 either it fails to compile because of a missing define, or in the case of changed interrupt vectors builds code that locks up.

The header used for the ATmega8/168 is:
/hardware/tools/avr/avr/include/avr/iomx8.h

The header used for the ATmega328 is:
/hardware/tools/avr/avr/include/avr/iom328p.h

Some examples of changes that have caused problems:

PORTB references

ATmega8/168 (iomx8.h):

Code:

#define PORTB   _SFR_IO8 (0x05)
/* PORTB */
#define PB7     7
#define PB6     6
#define PB5     5
#define PB4     4
#define PB3     3
#define PB2     2
#define PB1     1
#define PB0     0

ATmega328 (iom328p.h):

Code:

#define PORTB _SFR_IO8(0x05)
#define PORTB0 0
#define PORTB1 1
#define PORTB2 2
#define PORTB3 3
#define PORTB4 4
#define PORTB5 5
#define PORTB6 6
#define PORTB7 7

There's a lot of code that references PB0 - PB7 and this all breaks because the definitions are changed to PORTB0 - PORTB7. PORTC and PORTD have the same problems.


Interrupt Vectors

ATmega8/168 (iomx8.h):

Code:

#define INT0_vect                  _VECTOR(1)
#define SIG_INTERRUPT0                  _VECTOR(1)

/* External Interrupt Request 1 */
#define INT1_vect                  _VECTOR(2)
#define SIG_INTERRUPT1                  _VECTOR(2)

/* Pin Change Interrupt Request 0 */
#define PCINT0_vect                  _VECTOR(3)
#define SIG_PIN_CHANGE0                  _VECTOR(3)

/* Pin Change Interrupt Request 0 */
#define PCINT1_vect                  _VECTOR(4)
#define SIG_PIN_CHANGE1                  _VECTOR(4)

ATmega328 (iom328p.h):

Code:

#define INT0_vect         _VECTOR(1)   /* External Interrupt Request 0 */
#define INT1_vect         _VECTOR(2)   /* External Interrupt Request 1 */
#define PCINT0_vect       _VECTOR(3)   /* Pin Change Interrupt Request 0 */
#define PCINT1_vect       _VECTOR(4)   /* Pin Change Interrupt Request 0 */

It looks like the "old" names for all of the interrupt vectors have been left out. While I understand that the old names like "SIG_PIN_CHANGE0" are deprecated and should be changed to "PCINT0_vect", there's a large base of existing libraries that reference the old interrupt vector names. I don't see any reason to break all of that code by removing the old names when they don't hurt anything to be there.

I wouldn't be so bad if the code failed to compile, but it doesn't. There's only a warning about a possibly misspelled signal handler. Invalid code still gets built that crashes the chip whenever the interrupt is triggered.

There are probably more differences in the support for 328's but this is what I've come across so far.

It seams like this would be much more valuable if the options could be added at the sketch level rather than in the general preferences. This way you could add additional options only when you need them for a particular sketch/library/etc.

Maybe a pseudo compiler directive that is interpreted by the IDE's pre-processor?