need service on Digix boards

[rholt]

kd7eir & gogol,
I get your point and they're well taken - I just figured that the newer library would have made itself compatible with all arduinos, including the DUE. I must learn to trust NO ONE!!1 .
I will now start looking into what general things have to be looked @ when converting Libs over from AVR to ARM. I'm not sure how much help i can be right now, but I'm sure willing to start learning.
thanks again for you comments on this.

gogol,
Thanks for clearing up the "disabling the COM port" issue. Whenever i click the Download button (and simultaneously watching the Windows Device Manager) I see that it's up, and the DL seems to go through 2 iterations. after the 1st iteration, the COM port will usually switch from the Bossa to the Digix port on Device Manager. Then, after the 2nd iteration, it disappears from Device Manager. I think what you're saying is that after the 1st iteration, the Digix connects to the (correct) COM port, but while running the 2nd iteration, because of software issues, is unable to connect to the COM port and therefore it is NOT SHOWN on Device Manager rather then BEING disabled. If that is so - thank you for the clarification.

Russ from Coral Springs, Fl.

[rholt]

I think I may have found at least a possible cause to my problem when reading through that "Digix Pinout Documentation" thread. In it MichaelMeissner mentions in his Jan 9, 2014 @ 10:45am post:

"In looking at photos of the Due, Mega, Leonardo, and DigiX, it answers a question I've had in looking at various library code.  I've seen various library code that does I2C that uses the 2nd I2C port instead of the first i2C port.  It looks like yet another case of the Arduino team changing their mind as new boards come up.

In the Uno R2, they used A4/A5 as the I2C pins.  Then when the Uno R3 they come out with the new shield layout, and add 2 pins next to AREF for the I2C pins, and wire A4/A5 to use it.

Then the Mega comes out, and it has SDA/SCL relocated to pins 20/21, but I believe it still uses the 'common' I2C pins next to AREF."

If I have time @ work today, I'll look deeper into that MMA_7455 Library to see if THIS MIGHT BE WHY the program is working on my Mega board and not the Digix -> because it may be looking to run off the 2nd I2C ports which are at pins 70 & 71 up by AREF (?).

If I don't have time during work, I will check it out when i get home. I'll also keep looking.

Russ from Coral Springs, Fl.

[gogol]

Thanks for clearing up the "disabling the COM port" issue. Whenever i click the Download button (and simultaneously watching the Windows Device Manager) I see that it's up, and the DL seems to go through 2 iterations. after the 1st iteration, the COM port will usually switch from the Bossa to the Digix port on Device Manager. Then, after the 2nd iteration, it disappears from Device Manager. I think what you're saying is that after the 1st iteration, the Digix connects to the (correct) COM port, but while running the 2nd iteration, because of software issues, is unable to connect to the COM port and therefore it is NOT SHOWN on Device Manager rather then BEING disabled. If that is so - thank you for the clarification.

Yes, that is in short what is happening. You can read it in the Wiki in longer: http://digistump.com/wiki/digix/tutorials/programming
When a program is loaded and running on the DigiX, that program initializes the USB port. In case of the DigiX, that is done in some core board depended code, which is part of every program.  It is not possible to upload code to the DigiX/DUE, when a standard program is running. Therefore the board needs first to be reset into BOSSA-mode, which makes programming possible.  So you see normally three states:  The state where the board identifies itself as DigiX/DUE and is running a program. Than it gets reset ino BOSSA-mode, the DigiX/Due COM-port disappears and the BOSSA-port appears.  After the code is uploaded, the board gets a reset command again (after the NVRAM is configured to boot from flash) and that makes the program running again in DUE/DigiX mode.

When -and that is your case- the program hangs during initialization, the COM-port becomes not visible. You need to erase the program manually, which brings the board again in BOSSA-mode.

[rholt]

Thanks, gogol,
I'll be reading that link, today.
I'm also going to walk myself through the MMA_7455.h (accelerometer) Library, and the Wire.h Library, in order to begin my journey to find out why my program hangs when I try to create an instance of the MMA7455 in the program. I'm so not up to speed on this, but I have to tell ya, at the same time, I'm having a GREAT time going through the processes of learning. Certainly appreciate all the help I'm getting, and hope to pay it forward someday.

Russ from Coral Springs, Fl