GOAT logo

Join the conversation! The forum activity is now at GOATeach.org!  We are working to cross pollinate our conversations. Document and share tools at farm hack and talk at GOAT!  Also join GOAT riot and introduce yourself and your projects!

[Solved] Running out of Pins

Topic Type: 
Problem

I'm very close to having the initial prototype functional - that is to say, a product that is not reprogrammable on the fly and that exists without an LCD and keypad. However, I realize now that I'm running very low on pins and that I have two possible solutions available:

1) shift the cell phone communication over to the Arduino RX/TX pins: this is the easiest way to do this but reduces flexibility quite a bit. There will be NO remaining open pins (ie: no room for other sensors or motors) and development/debugging with a computer will be greatly hindered since those pins are usually what is used.

2) build an additional shield to manage lcd AND keypad: this is more elegant and leaves room for expansion. Basically, we can build something very similar to this by using the same chip. We can attach an LCD exactly the same way Adafruit did, so that we can piggyback on their library, except just add in a keypad instead of 5 buttons.

Right now, I'm going with number 1 and once we have a working prototype that's being tested, I will implement number 2 and see if it's as slick as I think it will be.

Conclusion

We've decided to drop the dependency on a keypad and lcd screen in favor of interfacing with Fido using a separate cellphone. See the comment that inspired this and check out our new conversation: Program your Fido by sending it text messages .

R.J. Steinert's picture

The Adafruit RGB LCD Shield Kit is pretty cool in that it reduces your pins needed on the microcontroller to just 2 (6 are required on the LCD unit right?). As a last resort, what do you think of dropping the LCD display and incorporating an RGB LED like the Public Labs folk did with the Thermal Flashlight? In the interrupt routine a blinking green light would indicate it's ready for input of the phone number, a blinking red light would indicate it's ready for input for the upper bound, and a blinking blue light would indicate it's ready for input for the lower bound. When the unit is told to display the temperature, it would take the upper and lower bounds and display it somewhere between red-green-blue depending on where the current reading is in the upper and lower bounds. Am I missing anything else the LCD could be used for? The advantage here is that one RGB LED ($1.95 at the high end) is cheaper than an LCD screen but the drawback is user friendliness. My "advantage" is definitely in the spirit of "How cheap can we get this?" but the cost/benefit analysis may not hold up on this suggestion.

Louis's picture

The RGB LCD Shield Kit not only reduces pins to the two I2C pins, which is the exact same as the I2C backpack we're currently using, but it also has buttons! The port expander used on the RGB shield seems like it could handle our keypad just as easily as it could handle those 5 buttons, plus it's not a surface mount device (SMD) so it's big enough for a hobbyist to wire up easily. It would probably end up costing the same if we build on our shield since we could then drop the I2C backpack since our shield will handle that too; downside is that it will be more difficult to make.

LEDs would work to let you know that the device is running and in alarm mode or not, but I think that it basically reduces the "reprogrammable on the fly" feature of our product to none since how can you input a temperature or a phone number using just an LED for feedback? It would require teaching users some kind of color code for numbers and that doesn't sound user friendly at all. Plus, how do they know if they're reprogramming the bounds or the phone number or something else? Stripping down the device to no LCD and no keypad is definitely a cheaper alternative though.

R.J. Steinert's picture

Aaaaah buttons nice.

The 4 directional buttons plus select button allows basic control...

Keypads take up a lot of pins (which one were you thinking about using?), so with buttons on an RGB LCD Shield Kit and some (a lot?) programming, we might be able to drop the keypad altogether. In the interrupt mode the left and right buttons would move across the LCD and the up and down button would change the value of the number.

Anyways, cool ideas but the most important thing right now I think is getting a minimum viable product built whichever way is easiest. We can iterate later to improve things like cost, usability, and ... "buildability". So with that in mind, the reasons I suggest an RGB LED are as follows. 1) The RGB LED helps out with the pin issue. 2) The RGB LED + Keypad combo might be easier to program than the LCD + Keypad combo.

how do they know if they're reprogramming the bounds or the phone number or something else?

Inspired by decades of crappy electronics with one singular red light blinking out a primitive version of Morse code, we could deploy a similar technique with an RGB LED. The directions might go like something as follows.

To set the Phone number

  1. Hold # until the LED blinks green.
  2. Enter the phone number you would like to be sent text messages.
  3. Hold # again and the LED will stop blinking green. Fido will now send you a confirmation text message.

To set the upper bounds

  1. Hold * until the LED blinks red.
  2. Enter the temperature you would like to be the upper bounds.
  3. Hold * again and the LED will stop blinking.

To set the lower bounds

  1. Hold 0 until the LED blinks blue.
  2. Enter the temperature you would like to be the lower bounds.
  3. Hold 0 again and the LED will stop blinking.

To see the current temperature

  1. Hold 1 until the LED turns on. If you defined your upper bound as 95 degrees and your lower bounds as 75 degrees, you will see corresponding colors across the RGB spectrum for the following temperatures.

Red (95) - Orange (90) - Yellow (85) - Green (80) - Blue (75)

If implementing something like what I've just proposed sounds more difficult than what you had in mind, then don't worry about it. I'm not familiar with programming LCDs and using them in combination with keypads to do input so it's tough for me to estimate which way is more difficult. Maybe we'll come back to this idea at some later date if the cost/benefit of this starts to seem appealing.

Louis's picture

Took me all day to cook this idea up apparently:

What else has an LCD and a keypad that we already interface with Fido? A cell phone!

I think that the first run should be programmable via cell phone with an optional LCD display so that you can check temp without texting when you're physically near the device. The cell phone that initially texts Fido will become the "owner" and will need to confirm reprograms from different phone with an option of relinquishing ownership. A hard reset will also allow Fido to get a new owner.

A shield with keypad and LCD can be a later elaboration on Fido v1. Sound reasonable?

R.J. Steinert's picture

It looks like we've settled on this issue for now. I've found it's best practice to summarize the status of an issue in it's original post when it has reached a good stopping point. @Louis You could write something like...

Conclusion

We've decided to drop the dependency on a keypad and lcd screen in favor of interfacing with Fido using a separate cellphone. See the comment that inspired this and check out our new conversation Program your Fido by sending it text messages .