Main Site Documentation

Mountaineer - Socket 4 and Socket 7 - Unusable Behavior

#1

I have a Mountaineer ETH board and find that I am unable to use Sockets 4 and 7 for just about anything.

On Socket 4 (P Y) I have tried the character display module and the IO60P module. The former displays garbage characters on the screen, the latter causes a runtime error as the Software I2C cannot be initialized.

On Socket 7 (X U) I have tried to connect a RS-232 module, but the program completely freezes when initializing the serial port.

Perhaps this is due to other pins on these ports, but in the case of Socket 7, there only pins 4 and 5 are needed for the UART.

What can I check or do to make these sockets usable as labelled on the board? I have already populated all the other sockets so moving them to another location is not an option.

Other Sockets:
[ol]Socket 1: Reserved for CAN in the future
Socket 2: RS232
Socket 3: RS232
Socket 4: IO60P DIO (not working)
Socket 5: Character Display
Socket 6: Joystick
Socket 7: RS232 (not working)[/ol]

#2

The character display module driver is being updated. It needed a small delay in some boards

#3

I was also unable to get an rs232 module working on socket 7. The board freezes so bad it needs to be cleared with mfdeploy

#4

There was a bug in the software implementation of I2C in Microsoft’s Gadgeteer libraries, affecting IO60P and similar modules. They have found and corrected the problem. It should be fixed in the new Gadgeteer release. A quick fix courtesy from Jan Kucera for the old Gadgeteer core is given below.

Cuno

PS
We regularly use RS232 on socket 7, strange that this does not work with your board…

Just download the Main/GadgeteerCore/Libraries/Core/DaisyLink42 project at http://gadgeteer.codeplex.com/ and reference it in the project instead of the standard daisy link assembly. Open the SoftwareI2C.cs file and in the Gadgeteer.Interfaces.SoftwareI2C.DoManagedWriteRead method just above the timeout exception, there is a stop pulse code:


sclPort.Active = false;                    // Allow clock pin to float high
while (!sclPort.Read() && !timeout) ;      // Wait for the clock pin to go high
sdaPort.Active = false;                    // Allow data pin to float high

Just wrap it in a test condition and offer a repeated start as well:


if (readLength == 0 || numWritten != writeLength)
{
    // send stop pulse if not reading, or if write failed
    sclPort.Active = false;                    // Allow clock pin to float high
    while (!sclPort.Read() && !timeout) ;      // Wait for the clock pin to go high
    sdaPort.Active = false;                    // Allow data pin to float high
}
else
{
    // set up for repeated start condition;
    sdaPort.Active = false;
    while (!sdaPort.Read() && !timeout) ;
    sclPort.Active = false;
}
#5

I also had a character display attached to port 5. I wonder if that is the common factor