I'm currently working on an I2C Quad DAC for our lighting control on the ROV
and when I run my code (or sometimes inadvertently ground a pin) I get the
mbed flashing it's leds in a 2-out 2-in pattern. What does it mean
(processor fault? self-destruct meltdown? the destruction of civilization as
we know it?).?

Hi Gary,

I'm currently working on an I2C Quad DAC for our lighting control on the ROV and when I run my code (or sometimes inadvertently ground a pin) I get the mbed flashing it's leds in a 2-out 2-in pattern. What does it mean (processor fault? self-destruct meltdown? the destruction of civilization as we know it?).?

Ah, those are what I like to call "Siren Lights", or even better, "Blue Lights of Death". Whenever you see this, the mbed libraries have knowingly thrown a fatal error. It should look a little like /handbook/DebuggingGettingStarted

If you have a terminal program on your PC listening to the mbed USB serial (see /handbook/SerialPC), you will often get it trying to squeal a last word before dying, which can often give you a clue as to what is wrong.

As you are playing with I2C, as mentioned in other threads, the beta I2C library is pretty paranoid at the moment. It just implements the minimal I2C transactions, and bails out if something goes wrong. This could well be what you are seeing.

Have an experiment and see if it is trying to tell you anything.

Simon

While we are on the subject of LEDs, are LEDs1-4 independent of the PWMOUTs or do I "burn" a PWMOUT when I program an LED to be used?

Hi,

While we are on the subject of LEDs, are LEDs1-4 independent of the PWMOUTs or do I "burn" a PWMOUT when I program an LED to be used?

You only burn a PwmOut if you are using a LED as a PwmOut. If you are using it as a DigitalOut, no impact.

Details:

There are 6 physical PWM blocks on the mbed, so you can have up to 6 PwmOut objects. Whilst these will generally be routed out to pins 21-26, 4 can alternatively be routed to the LEDs. Here are the mappings:

p21 = P2_5 = PWM_6
p22 = P2_4 = PWM_5
p23 = P2_3 = PWM_4
p24 = P2_2 = PWM_3
p25 = P2_1 = PWM_2
p26 = P2_0 = PWM_1

LED1 = P1_18 = PWM_1
LED2 = P1_20 = PWM_2
LED3 = P1_21 = PWM_3
LED4 = P1_23 = PWM_4

So you can see, LED1 and p26 share the same physical PWM hardware channel, so you can use either LED1 or p26 as a PwmOut (using PWM_1 hardware), but obviously not both at the same time.

Simon

The I2C problem relates to the I2C Master (mbed module) not receieving an Acknowledge back from the I2C Slave device. this happens if the device is not present, the bus is shorted, or the wrong I2C address is used for example. either way the software detects a problem and goes into the error flashing state. I have requested the I2C library be changed so it retruns a NACK/ACK signal so we know the status of the communication.

There is a General Call instruction supported by the I2C bus protocol, slave address 0, which some I2C devices respond to and other do not. Some devices are designed intentionally not to respond, but still accept it as a reset command. If you use this address 0 and the device is not designed to respond with an ACK signal then the mbed software will hang.

Hi Gary,

Can you let us know the part number of the Quad DAC you are using?

Thanks

Chris

Hi Chris,

The Quad DAC is the MAX5842. It is described by Digikey as a DAC 12BIIT QUAD 2WIRE 10-UMAX.

Gary