opengauge development: gunio technical considerations

[dcb]

doing digital reads in an interrupt seems kind of frowned on so I made ISR( PCINT1_vect ) as small as I could in this version. It does exactly the same thing as the previous post, just takes a litle more effort to move the pins around.

int lbuttonPin = 17; // Left Button, on analog 3,  
int mbuttonPin = 18; // Middle Button, on analog 4 
int rbuttonPin = 19; // Right Button, on analog 5 

int lbuttonBit = 8; //  pin17 is a bitmask 8 on port C  
int mbuttonBit = 16; // pin18 is a bitmask 16 on port C  
int rbuttonBit = 32; // pin19 is a bitmask 32 on port C  

//pretend we start with upressed buttons
int buttonpins = lbuttonBit + mbuttonBit + rbuttonBit;

//attach the interrupt 
ISR( PCINT1_vect ){ 
  buttonpins &= PINC;//bypassing digitalRead for interrupt performance
} 
 
void setup() { 
  Serial.begin(9600);

  pinMode( lbuttonPin, INPUT ); 
  pinMode( mbuttonPin, INPUT ); 
  pinMode( rbuttonPin, INPUT ); 

//"turn on" the internal pullup resistors
  digitalWrite( lbuttonPin, HIGH); 
  digitalWrite( mbuttonPin, HIGH); 
  digitalWrite( rbuttonPin, HIGH); 

//low level interrupt enable stuff
  PCICR |= (1 << PCIE1); 
  PCMSK1 |= (1 << PCINT11); 
  PCMSK1 |= (1 << PCINT12); 
  PCMSK1 |= (1 << PCINT13);   
  
} 
 
void loop() {    

  //print out what buttons have been pressed
  if(!(buttonpins&lbuttonBit)) Serial.print("lbutton");
  Serial.print(",");
  if(!(buttonpins&mbuttonBit)) Serial.print("mbutton");
  Serial.print(",");
  if(!(buttonpins&rbuttonBit)) Serial.print("rbutton");
  Serial.println("");
  
  //reset the buttons
  buttonpins = lbuttonBit + mbuttonBit + rbuttonBit;

  delay(1000);
}

[MetroMPG]

Man, I'm falling behind (still haven't hooked up my LCD). But happy to see some code (buttons) that I can read at a glance. :P Thanks for commenting it nicely - I've collaborated on other projects before and people never seem to want to comment their stuff properly ("considerately" may be a better word).

[dcb]

update, the display has a 5x8 character box. It looks like there is 8 (not 16)user defined characters.

[JohnnyGrey]

One thing about non-tactile buttons...

In a car, they get old FAST. Touch screens and the like were cool when they first came out, but they're devoid of any tactile feedback. When I'm driving my car, I want to know that my input was received without having to look at whatever device I'm using. The car itself demands enough of my attention.

Another thing is that I may want to have my finger on the button without actually activating it. For example, on a CD player, if I am scanning through tracks, I want my finger to remain in the same place, but I want to hear a song for a few seconds before I skip it. With touch button, I have to withdraw my finger, then who knows where it's going to float off to with the motion in the car, vibration, etc. Plus holding your arm up in space isn't exactly comfortable. For my scangauge, I might want to reset my trip MPG as I pass a sign post. This requires that I know where my finger is and that I can activate the button at a precise moment, without having to look at it.

GPS devices have a good reason to use touch input. Stereos and MPG gauges do not.

/rant

[dcb]

Agreed about the buttons, especially if you want to have your finger on the button for doing some testing/calibration (i.e. hit it right when we pass this mile marker, etc).

[larrydag]

I'm not getting a warm fuzzy from my freeduino device and LCD. I tried firing it up again and it took several resets before I got it working again. Is this going to be typical after being off?

[dcb]

I've been trying to figure that one out, certainly don't want to leave it like that if it is possible to fix it, but it needs some research/trial and error. I *think* if we put the LCD power (and LED backlight) on a transistor and control the power up so that it is after the duino is up to speed that it might help, don't know for sure. The LCD stuff needs work. I want it to be solid, but there are probably a few folks besides me who could research it.

[JohnnyGrey]

Got a capacitor on your 5v line? Regulators can only do so much to quiet the noise.

Simplify things...

LCD circuits use very little current. I've got mine powered off an AVR signal pin. With the right RC circuit, you can delay power to the LCD until your micro can stabilize its outputs.

[dcb]

The pin power for the LCD (not the LED!!) was a good idea, but no dice, not even with delays, and turning the LCD on and off.

I tried disconnecting the LED power while it booted up, no luck

It seems to boot up better if you hold down the reset button for two seconds, but hell if I'm certain about that or even know why.

The good news (or the bad news) is that it is reproduceable on seperate machines.

[larrydag]

This could be a good reference.

http://www.uchobby.com/index.php/200...facing-part-1/

[JohnnyGrey]

Do you have a debouncer on the reset line?

[dcb]

Originally Posted by larrydag

This could be a good reference.

http://www.uchobby.com/index.php/200...facing-part-1/

Thanks Larry! That helped I've booted it 20 different ways now and am batting 1000. There was a reference to 'the “new” datasheet' there, I messed with the initialization routine after looking at it and things are looking much more solid. Need to clean it up first but will update the workspace maybe tonight.

[larrydag]

I was really wondering if it was the controller chip. I just happened to be googling different information concerning the LCD and Arduino and that link came up. That's great it worked.

[larrydag]

Here's a way to power up your *duino with nothing but solar power. This is for the hardcore eco-minded (EV maybe) folks out there.

http://www.instructables.com/id/Self...Arduino-Board/

[IHateMayonnaise]

As a lurker I have a few questions regarding the MPGuino project. First, I understand that the project is not yet "complete," but I was wondering as to what extent it is functional. To my understanding there is some working code (on page 1 of this thread), so to implement it all we should need to do is get a FreeDuino Arduino Diecimila kit as well as a 16x2 (or possibly 16x4) LCD display from the same site. Together with basic soldering skills and the know-how to implement the 4-bit Arduino LCD library as well as the accompanying code, the vast majority of this project seems to be complete (forgetting about buttons for the time being).

But how will it connect to the car? I assume not through the OBD2 port, since my understanding is that this project is geared towards people who would like to have a scanguage but do not have an OBD2 port. So how will it connect? I have an OBD2 port (and an OBD2 reader) but do not have the money for a ScanGuage. I am confident that my time and money invested in this project will pay me back after I taylor my driving habits with the instant feedback of a fuel economy guage.

Anyway, I am looking for somewhere to start. Any thoughts?

[larrydag]

IHateMayonnaise, the goal of this project is two fold: 1) Have an open source and low cost hardware fuel economy gauge 2) provide a fuel economy gauge for car owners that do not have OBDII capability (but still have fuel injection or OBD1, etc.)

The Opengauge is still not ready for primetime. Hardware is just finally getting wrapped up or so we think. There is still quite a bit of debugging to do with getting it to read electronic data from the car. Yet the cost of entry and getting involved is pretty low. We would love to have another Opengauge debugger to help with this project. The more people interfacing with different types of cars is only going to make this project better.

[IHateMayonnaise]

Originally Posted by larrydag

IHateMayonnaise, the goal of this project is two fold: 1) Have an open source and low cost hardware fuel economy gauge 2) provide a fuel economy gauge for car owners that do not have OBDII capability (but still have fuel injection or OBD1, etc.)

The Opengauge is still not ready for primetime. Hardware is just finally getting wrapped up or so we think. There is still quite a bit of debugging to do with getting it to read electronic data from the car. Yet the cost of entry and getting involved is pretty low. We would love to have another Opengauge debugger to help with this project. The more people interfacing with different types of cars is only going to make this project better.

I would love to get involved, all I should need is that protoboard and a LCD right? And how is it planned that this will connect to the car?

[larrydag]

The minimal hardware you'll need is a freeduino/arduino, LCD, and some electronic components. dcb has done a great job listing most of the hardware that will be needed. Take a look at the "realease one workplace" thread. There you will find all the information you'll need.

I'm planning to connect to my car via the ECU. As diesel_john pointed out you can connect directly to the VSS and Injector. I don't know which procedure would work better because I haven't tried either yet.

[larrydag]

I quickly mocked up a possible pcb mock up for an arduino shield to combine all of the components needed to interface with the LCD, buttons, and VSS/Injector cables. This was a quick run so it needs to be debugged. I figured I would post it and get any feedback.

My thought is that header pins could be soldered into this shield so it would just plug right into the *duino. This design I don't believe is capable using Radioshack type supplies because the traces are a little too compact. But I bet you could use Radioshack supplies if you took out some traces and replaced it with jumper wire.

I did the layout in Visio 2003

[dcb]

Originally Posted by IHateMayonnaise

so to implement it all we should need to...

We are currently calling the lcd from nkcelectronics.com the "official" lcd of the mpguino version 1 project, because we need to know the pinout and chipset to be effective in supporting it. For boards we are mainly using the the less expensive serial kit or the usb kit from nkc, depending on needs. I've just swapped in the serial board in my prototype, mainly because I want to claim the lower out of pocket cost when promoting the project, but some folks will need/want the usb board.

You do not need a LCD library, the code on the workspace has it's own LCD class that is up to date. Just download the arduino IDE from http://arduino.cc , paste the code in, hit verify, then hit "upload to board" (assuming you have built/bought a freeduino).

Connecting to the car will require the following connections (solder, tap, cut and twist, stick a pin in it, whatever you are comfortable with)
1. Ground
2. Battery +
3. an Injector lead
4. a VSS (Vehicle Speed Sensor) lead.

In the picture a few posts down, I will be using a blue terminal block for the other ends of the injector and vss leads and the power jack for the battery/ground.