opengauge development: gunio technical considerations

[MetroMPG]

Mine took over a week to arrive. The donkey train across the border into Canuckistan is facing swollen rivers & streams from the spring runoff, dontcha know.

EDIT: Whoops, whoops. I read your post and thought it was from fellow hoser Who. Thus you can ignore this post entirely.

[dcb]

Whoops, the occasional sampling of the injectors would be reasonably accurate, but then you need to add tight timing control around the code that would enable the timer interrupts and disable them. And then make an exception for the vss signal, because on my vehicle, it is more than a second between pulses at low speed and you wouldn't want to miss one of those.

I don't think it would make it more straightforward though, since it adds code, but it would be a good optimization, a strategy to consider if reacting to the button presses and displaying prove to be too time consuming. But I think we are ok and might even be able to shorten the 1 second display rate and keep microsecond accuracy.

if you wanted to plug into the serial processor as it stands today:
http://ecomodder.com/forum/showthrea...7979#post17979
Basically in the middle of loop, get rid of the serial calls and replace it with

updateTrips(tmpInjHiMS, tmpInjCount, tmpvssCount );//quick addition in the trip objects
updateDisplay()



updateTrips might look like:
void updateTrips(long injHiMS, injCount, vssCount ){
instant.reset();
instant.update(injHiMS,injCount,vssCount);
current.update(injHiMS,injCount,vssCount);
tank.update(injHiMS,injCount,vssCount);
trip1.update(injHiMS,injCount,vssCount);
trip2.update(injHiMS,injCount,vssCount);
}

and the trips themselves would provide functions like:
current.mpg(), instant.kph(), instant.mph(), tank.dte(), trip1.lper100km()

now updateDisplay() is tricky, as well as keeping track of the button interrupts and deciding the next screen. Might want to look at how coyote did his for starters.

[larrydag]

Originally Posted by MetroMPG

So, are you still thinking the 16x2 LCD mentioned in post #2 is the one to get? If so, I'll order one too. I'm a bit out of my depth, but I can at least be beta testing along side you guys.

Also, the Guino is boring with only a blinking LED to program.

I'm with you MetroMPG in that this is a little out of my league. But there is hope for us. I strongly suggest checking out the Arduino code library and tutorials

http://www.arduino.cc/playground/Mai...ralCodeLibrary

This should help to understand a lot of the nuances in coding the *duino.

As a project to learn coding I'm trying to figure out how to wire up a Battlestar Galactica Cylon scanning eye. I know its a cheesy LED thing but it should be a good first step to learn about *duino's.

[dcb]

Whoops, one more note, there was a caution about the lcd and interrupts at: http://www.arduino.cc/cgi-bin/yabb2/...m=1173553276/3

it is summarized as follows:
1.) Never use a delay or any library which introduces a delay while in an interrupt (like the Wire library or LCD libraries). Serial communication, or any communication requiring a clock will also fail.
2.) Use an external pull-up on the interrupt line.

re: 1. not a problem if updateDisplay is called directly in loop() as I'm suggesting.
re: 2. This is an external hookup issue.

Also I did some scratching and I think worst case scenario (i.e. a v8 with tbi doing 150mph at 8000RPM), there should be about 10 milliseconds of overhead for all the interrupts, which leaves .99 seconds to figure out what to display and display it.

P.S the 2x16 showed up today, I still can't tell if it is the one with less built in characters but more user definable characters or not.

[dcb]

Sorry, I couldn't resist playing with the lcd. The library didn't work for me, wound up poking at it in arduino ide till I got somewhere. All those somewhat arbitrary hokey delays need to be replaced with a status check on the lcd (i.e. LCD? are you ready for another command or piece of data?) I also moved the pins all around to keep the timer1 and 2 pwm pins open (and the serial ports open).



I call this configuration the boreduino

[MetroMPG]

Awesome! I love it! Can't wait for mine to come too.

I also love that you're not not blowing the project budget on mounting hardware/shields.

(Correct me if I'm wrong, but a "shield" is Arduino-speak for separate circuit boards that you mount additional electronics on and then connect to the 'duino, right?)

[dcb]

Originally Posted by MetroMPG

I also love that you're not not blowing the project budget on mounting hardware/shields.

Thanks I like this setup because the LCD is secure, the pins are still easy to get to, and it is low profile when sitting on the dash. Also it would be simple enough to add sides and a top after things become less experimental, and stain or paint it if desired. But hot glue and bits of wire and a chunk of balsa are good enough for me. Just need to sort out the buttons.

FYI, radio shack had a bag of 4 little buttons for $2. I'll probably mount them flush with the LCD face on the sides with some long leads for now. Or maby along the top right where it would be easier. Yah, I like easy, that looks like a plan.

Edit: easiest mounting turns out to be to jam them in under the LCD. Now how many? 2, 3 ,4? Each button takes a pin

4 buttons should be easier to navigate. I.e. a select, 2 scrolls and a back.

3 buttons isn't too bad either, I e a scroll in either direction (so you don't have to cycle through all the options if you pass it) plus a select button, but "go back" becomes a thing you have to select.

2 buttons is the easiest to hook up and simplifies the design choices. Harder on the users as there's lots more clicking, but not a big deal.


Ok Pin check: We don't have any sensors plugged in yet or buttons (or a piezo speaker), but after the LCD we have:

4 pwm pins
2 "serial" pins 0,1, I think we can give up 0, but TX might be useful for debugging.
6 analog/digital read pins
(yep, sorry blinky fans, I took pin 13 for the LCD)

So that leaves us 11 pins without buttons or car signals.

we need 3 digital read pins to talk to the car. vss,inj,ign power.
and each button will need a pin, so maybe 4 there.
piezo speaker for another 1, would be good for the "your mpg is dropping" alert.

[MetroMPG]

Can we combine 2 buttons simultaneously pressed for some fuction, such as "home"? That could let us get away with 3 buttons with 4 button functionality (assuming just one "combo" button). Might not be the best usability though. Just a thought.

[dcb]

I think the answer to the number of buttons happens to be 3 And they will be in the upper right corner.

I sat it in the car, it is the same height as a scangauge but about two inches narrower, and fits. I pretended to use the buttons, and am of the conclusion that a small cluster of them is better than spreading them around.

upper right corner was the easiest place I could get to them and still see the screen.

3 because that is what fits in the upper right with sufficient space between the buttons, with sitting flush with the lcd and not increasing the profile.

So just need to glue down a block there of the right thickness, solder up the switch leads, with a common ground and three signals, and glue them to the block.

edit: re chording buttons. I was actually looking at those earlier today, that is weird. I think the only chord that people might intuitively know is the soft reset, where you mash everything down.

[MetroMPG]

Agreed about combining buttons. Probably not the best (intuitive) idea.

I also agree that a cluster is best - as Trebuchet pointed out earlier, you'll learn which ones you need to press and eventually will be able to do it without looking. Cluster = useful tactile feedback for selecting the right one.