need service on Digix boards

[rholt]

I have two Digix boards that I'm quite sure I've blown the i2C ports out of.
while programs like "Blink" are working, whenever I try to run a known good program that incorporates i2c, (even with all pins disconnected) just as the program finishes the compile, the COM ports disappear (from Device Manager on Windows) of both boards.
I have an UNO board that is working just fine with this setup.
So... i'd like to return the 2 boards for repair - i will pay for their repair.
thanks...
also... i just received a NEW (third) Digix board. oddly, the anti-static bag it was shipped in was NOT SEALED but rather it had scotch tape over the open end of the bag. While the lights come on when i hook it up, there is no COM port showing up under my Windows (win 8.1). i would like to exchange this for a new one.
Please let me know how to go about these returns and repair.

thanks,
Russ Holt.

[gogol]

I have two Digix boards that I'm quite sure I've blown the i2C ports out of.
while programs like "Blink" are working, whenever I try to run a known good program that incorporates i2c, (even with all pins disconnected) just as the program finishes the compile, the COM ports disappear (from Device Manager on Windows) of both boards.

That is impossible!  The DigiX does not know, that you are compiling!  The first possibility causing this, is when the DigiX restarts after the download of a program has finished.

Post one of those programs and tell us, which board setting (and which Arduino IDE revision) you are using.

[rholt]

gogol,
Obviously, "compile" was NOT the term that I should have used, and I apologize. I'm very new to all of this and don't yet have the hang of the terminology.
Attached is an example ino that works with my Arduino Mega 2560 board, but not (anymore) with my Digix board.
Usually, when I power up my Digix board, it many times comes attached to a different COM port, ie COM 4 or COM 5, but then when  load the program, the COM 4 (or 5) will disappear from my Device Manager (in Windows) and reappear as COM 10 and the program will run.

But now, the Program loads and says at the end "Set boot flash true. CPU reset." but when i click on the Serial Monitor, I immediately get the "Board at COM5 (or 4) is not available." error message. The same thing happens with both Digix boards. (see attachment)

Russ

[rholt]

I forgot to add that I'm using the Arduino 1.5.6-r2 IDE with the DigiStump DigiX (standard) board.

[gogol]

I think, that your boards are not necessarily broken, when looking in your code.
When I load your code in one of my boards (original DUE and DigiX) they stuck as well.
Next point for checking is, that I just extended the Blink-Example with the acceleration library.
(I assume, that you are using: https://code.google.com/p/mma-7455-arduino-library/)

Code: [Select]

#include <Wire.h> //Include the Wire library
#include <MMA_7455.h> //Include the MMA_7455 library

int led = 13;
// Once the following line is enabled, the sketch hangs and no USB enumeration will take place
//MMA_7455 mySensor = MMA_7455();   //Make an instance of MMA_7455

void setup() {
  pinMode(led, OUTPUT);
}

// the loop routine runs over and over again forever:
void loop() {
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);               // wait for a second
}
Here comes the point, where you need to dig deeper into the sketch, and why it is hanging!

The point is, that the board is first recognized, when the USB init code can be called.  If that can't be called, you will see no device!

If your sketch does not behave like you thought, try to reduce it to a bare minimum.

[rholt]

gogol,
I see what you're saying, and, as i recall (because of your statements) , when I was first troubleshooting the program, I remembered that the code did not hang when I commented out the creation of the instance of "MMA_7455 mySensor = MMA_745"

I'll do some experimenting when I get home today - thanks for the suggestion.

Russ

[rholt]

gogol (and everyone)...
So, I'm home now - I hooked up my board to my new Gyro board which uses i2c and I have Data!
I will assume there is work to be done with the Accelerometer code.
Thank you VERY much for your direction in this!

But of course there's a new problem - and it is with the data I'm getting from the code from my Gyro L3G4200D.
My sketch is creating the x value, by reading 2 bytes at Register Addresses "0x29" and "0x28" then combining them:
x = ((xMSB << | xLSB);
When I run the code on both the Arduino Mega2560, the BINARY readings are correct, and when I Serial.print in Decimal, the Mega shows the correct signed Int's (giving both positive & negative values), but the Digix shows unsigned giving VERY skewed values.

Russ

[MichaelMeissner]

The int data type on ARM systems is 32-bits, while it is 16 bits on AVR systems.  So what you want to do is use a 16-bit cast to short, which will sign extend the 16 bit item:

Code: [Select]

unsigned char low, high;
int combo;

high = get_high_byte ();
low = get_low_byte ();
combo = (short)((high << 8) | low);


[rholt]

MichaelMeissner,
Thanks so much - works like a charm! (I have so much to learn!)
I really appreciate the help on this forum.

Russ from Coral Springs, Fl.

[MichaelMeissner]

MichaelMeissner,
Thanks so much - works like a charm! (I have so much to learn!)
I really appreciate the help on this forum.

Russ from Coral Springs, Fl.

Well in this case, it comes up fairly frequently as people migrate from AVR based Arduinos/Digisparks/etc. to ARM based systems.  Three other compatibility things that bite people include:

• char without a signed or unsigned modifier, is unsigned on ARM systems, and signed on AVR systems;
• The AVR compiler makes double the same size and representation as the 32-bit float type, while under the ARM compiler, double is 64-bits, and float is 32-bits;
• The ARM does not need the PROGMEM decorations (in theory, the defaults in the Arm headers should allow code to work fine).

[gogol]

Don't forget in your enumeration:

• using libraries developed for AVR and never tested/adapted to ARM. 

[MichaelMeissner]

Don't forget in your enumeration:

• using libraries developed for AVR and never tested/adapted to ARM. 

Yep, particularly libraries that access hardware directly.  I was just listing the compiler specific gotchas that I knew about.

Another thing that I forgot to mention is AVR is stuck back on GCC 4.3.2, and ARM platforms tend to use 4.7 (and hopefully moving to at least 4.8, since 4.7 is now frozen), and the C++ language implementation has changed.  However, I typically see complaints about code developed on ARM, and trying to be back ported to AVR.

Another compatibility issue is at the library issue.  I hate having to have separate programs for Digispark/Trinket/Gemma from Arduino/Teensy, due to the former using TinyWireS.h/TinyWireM.h and the later using Wire.h.  I seem to recall there are other 'Tiny' issues between ATtiny85 and other platforms.

[rholt]

back to an older subject, i'm afraid -
the MMA_7455.h library (i've downloaded the newer one)...
and while the small program i have runs on the Arduino Mega2560, when i start the download on the Digix board (after resetting the board to Digix) it has the effect of disabling the COM port. (see the 2 screenshots of the instance before i Upload the program and after i upload the program. on the 1st screenshot, i've commented out the creation of the instance of the "MMA_7455 mySensor = MMA_7455();" and the program runs on the Digix. but (see the 2nd screenshot) - when i uncomment out that line, it loads (or seems to load) and then drops the COM Port. disappears from my Device Manager.
why is it ok on the Mega, but not on the Digix? (i should start a new thread?)
Russ from Coral Springs

[kd7eir]

back to an older subject, i'm afraid -
the MMA_7455.h library (i've downloaded the newer one)...
and while the small program i have runs on the Arduino Mega2560, when i start the download on the Digix board (after resetting the board to Digix) it has the effect of disabling the COM port. (see the 2 screenshots of the instance before i Upload the program and after i upload the program. on the 1st screenshot, i've commented out the creation of the instance of the "MMA_7455 mySensor = MMA_7455();" and the program runs on the Digix. but (see the 2nd screenshot) - when i uncomment out that line, it loads (or seems to load) and then drops the COM Port. disappears from my Device Manager.
why is it ok on the Mega, but not on the Digix? (i should start a new thread?)
Russ from Coral Springs

The answer, simply, is that the library is not compatible with the Digix/SAM3X8E as it is currently written. I have no interest in this library, so I cannot invest the time to tell you what, exactly, needs to be changed. Until the library is modified for the Digix/SAM3X8E it will never work.

[gogol]

and while the small program i have runs on the Arduino Mega2560, when i start the download on the Digix board (after resetting the board to Digix) it has the effect of disabling the COM port.

First: It is NOT DISABLING the COM-port!  It is never enabling the COM-port. Which makes a big difference.  When the DigiX starts your program there is some initialization done. If that initialization hangs, because of malfunctioning libraries, the COM-port will never be enabled!  This understanding is necessary, as there might be other errors, when a initialized COM port gets disabled during run-time of your sketch.

Second: That is, why I mentioned the use of libraries, which are never tested for the Arduino DUE / DigiX!
As the AVR family of microcontrollers is totally different from the ARM architecture, most libraries (which are not only on the abstract Arduino Layer) need adaption!

For that reason, there is the topmost sticky thread in the Arduino-DUE Forum, that one, talking about which libraries are tested and working!

You can start digging into that yourself, or ask the maintainer of that specific library!