New Features for MPGuino?

[FalconFour]

Ah, it does look like it's hardwired to 4 and 5. That'd work fine if MPGuino just went "straight down the lines" and went 0-1-2-3 for VSS-L-Center-R inputs... I swear, none of the pin mapping on MPGuino makes any sense at all (look at the jungle in the LCD wiring).

I think the button inputs are read once per 500ms cycle, so if you interrupt the cycle with your own function, digitalWrite() the EEPROM power line high (it uses far less power than the max of the ATMega chip, so you can power it directly I'd imagine, and digital pins 10/11 are free), perform your interactions, then digitalWrite() it low again, that would still work for pins 4 and 5, I think...

[mluckham]

Originally Posted by FalconFour

I think the button inputs are read once per 500ms cycle, so if you interrupt the cycle with your own function, digitalWrite() the EEPROM power line high (it uses far less power than the max of the ATMega chip, so you can power it directly I'd imagine, and digital pins 10/11 are free), perform your interactions, then digitalWrite() it low again, that would still work for pins 4 and 5, I think...

I'm looking at interfacing to two I2C devices ... the MPGuino would be I2C Master to the EEPROM, and I2C Slave to the external, intelligent LCD module. In the latter case the slave (MPGuino) registers for

Wire.onReceive(receiveI2CEvent)

, the code need only check for legitimate I2C signalling or error conditions (if one of the buttons is pressed).

So do you think the buttons and the I2C signals can safely be wired together? Or will be I burning out my LCD protection diode again if I try?

[mluckham]

Or just rewire the darned buttons to ANA1 and ANA2, and free up ANA4 and 5 for the I2C !!

[FalconFour]

^ That could probably work too. I haven't dug into the code yet, but I don't see any reason why the buttons would be hardwired to those pins, other than that's how it's best laid out on the MPGuino device PCB (I'm having to make some of those odd trace-influenced design/code decisions on my own project ATM).

Curious though. How do you think you could blow out a diode by wiring signals together? o.O Seems very strange. Only way I could think of blowing out a diode is by hammering it with a high reverse-polarity voltage, or putting too much power through it...

[mluckham]

Originally Posted by FalconFour

Curious though. How do you think you could blow out a diode by wiring signals together? o.O Seems very strange. Only way I could think of blowing out a diode is by hammering it with a high reverse-polarity voltage, or putting too much power through it...

I have no idea what happened to blow the diode, just the timing of when it happened brings the above to mind.

I'll find out when/if it happens again ... I bought 2 replacement diodes, fortunately! so there is one spare ...

[mluckham]

Originally Posted by FalconFour

^ That could probably work too. I haven't dug into the code yet, but I don't see any reason why the buttons would be hardwired to those pins, other than that's how it's best laid out on the MPGuino device PCB (I'm having to make some of those odd trace-influenced design/code decisions on my own project ATM).

If and when my LCD interface is working, the buttons won't be needed for that version - just some little adaptor/buffer circuits tying the vehicle's signals to the Arduino.

[bobski]

Originally Posted by FalconFour

Ah, it does look like it's hardwired to 4 and 5. That'd work fine if MPGuino just went "straight down the lines" and went 0-1-2-3 for VSS-L-Center-R inputs... I swear, none of the pin mapping on MPGuino makes any sense at all (look at the jungle in the LCD wiring).

Well, the significance of the injector signal location is that pins 2 and 3 can have interrupt routines assigned to them. For those not familiar with them, an interrupt routine is a piece of code that gets called and executed when some signal is triggered, no matter what the normal running loop says should be happening at that point in time. The triggering signal can be internal to the microcontroller such as a timer that triggers at regular intervals, or can come from an external source in the case of pins 2 and 3. Interrupts are key to time-sensitive tasks such as measuring the pulse width of the injector signal. What doesn't make sense about the assignment is that pins 2 and 3 can be assigned to two different interrupt routines... There's no reason to use both of them for the single injector signal.
The button signals are obviously digital in nature, so it would make sense to put them on digital inputs. Unfortunately, there's only one free digital input that doesn't have some special function. We really just need more digital ports.
Here's two birds with one stone: The $1.71 PCA9554 8-bit I2C I/O port in a 16-pin DIP package (it comes in others, but DIP is solder-friendly). Move the button signals over to the PCA9554, and use the two Arduino pins it frees up to run the I2C bus.
I2C is like USB in that you can communicate with many devices which share a single 2-wire bus. Each device has a unique address on the bus (generally selected by a jumper or combination of resistors on a pin of the particular device), so selecting which device you want to communicate with is just a matter of using its address when you start a particular bit of serial communication.
So tacking on that sub-$2 part would let us set up an I2C bus (with the substantial expansion options it provides), free up one analog I/O pin and provide 5 new digital I/O pins.
I'm kind of curious if the LCD could be driven off one of these expanders as well.

Originally Posted by mluckham

I'm looking at interfacing to two I2C devices ... the MPGuino would be I2C Master to the EEPROM, and I2C Slave to the external, intelligent LCD module.

Unfortunately, I don't think I2C has provisions for a hierarchy like that. There's one master and all the other devices on the bus are slaves. I guess you could get around that by using two busses, but the Arduino uses specific pins for I2C because of hardware provisions in the ATmega controller. There's only hardware for one bus.

[dcb]

Originally Posted by bobski

...There's no reason to use both of them for the single injector signal...

There is actually a reason. Those pins can be set up to trigger an interrupt on a rising signal or a falling signal, but not both at the same time (and still be able to tell the firmware if it was rising or falling). We need to be able to reliably detect the rising signal from the falling signal, with minimal processing overhead. That is how the injector pulse width is determined.

[mluckham]

Originally Posted by bobski

Unfortunately, I don't think I2C has provisions for a hierarchy like that. There's one master and all the other devices on the bus are slaves. I guess you could get around that by using two busses, but the Arduino uses specific pins for I2C because of hardware provisions in the ATmega controller. There's only hardware for one bus.

I think there can be one Master "at a time", but it doesn't mean that only device can be the master on the bus, period. Certainly, it would need to be coordinated.

I could re-think the heirarchy and treat the uLCD as a slave device, but I'm sort of visualizing the touch-screen LCD as a general-purpose "control panel" for multiple I2C slave devices - which is more suitable to it being the master.

The port expander is an interesting idea. Another would be to change the method of detecting buttons to use only one pin, but such method would need to retain the feature of detecting multiple concurrent button presses. The simplest solution - in software, anyway - would simply be to move the button signals to ANA1 and ANA2, and free up ANA4-5 for I2C.

My personal goal is to work with the current MPGuino design and adapt it - if another MPGuino were to be laid out, that's another matter entirely ... it would be nice to accept more input signals, for example, and expand the functionality of the device. Without making it way more expensive - I think it is the price point that makes people want to get one and experiment

[bobski]

Originally Posted by dcb

Those pins can be set up to trigger an interrupt on a rising signal or a falling signal, but not both at the same time (and still be able to tell the firmware if it was rising or falling).

Huh. Is that a limitation of the older 011 IDE, or just obsessive optimization? I wrote a pulse width analysis (frequency, duty cycle, on time) program a little less than a year ago that has 4 microsecond resolution, is accurate down to about 8 microseconds (verified with an oscilloscope), only uses 1 input and is fully compatible with the current IDE. Cumulative on time would add one more line to the off half of the interrupt routine.
http://dl.dropbox.com/u/9882625/inte...reAnalyzer.pde