Go Down

Topic: My newest development in interfacing arduino with input hardware (Read 4 times) previous topic - next topic


Thanks! I spent a hour or so extracting the format from the avr lib doc:


This is for library with no class definitions. I'm still thinking about how to better describe classes with this format.


I swear I heard this before but here it is, maybe one of the best and free program/library documentation software: Doxygen


I'm going to study it a bit and I highly recommend (from what I just read through) other library developers to use it to save time on documentation.


I uploaded a beta version of the library with sample code on every class, buttons, keypads, rotary encoder, analog button arrays (yes! you can use more than one analog pins and each pin hooks up to several buttons but all pins have to have identical resistor networks).

Here it is, with library, example code and an auto-doc. I'm writing an overview for beginners at the moment. Someone is already testing the code :)


With this library, you can arbitrarily change your interface without changing code. Say you start with matrix keypads and then decide go with 6 single buttons and two rotary encoders for the look. You don't have to change you code. Say you start with no buttons (too scared to hook up buttons and then decide to go with keypads?!), and you can use serial port to type in characters. The library has an object to streamline serial inputs into button outputs for your code so your code thinks it has a keypad. Then later you find out you only need like 4 buttons for everything you programmed and actually hooked up 4 buttons and change one line in the code (instantiate a phi_button_arrays object instead of phi_serials object), you're done!


  I don't know when I will have time to try it out but, I downloaded it. Sounds really good, thanks!
Good links: Eagle tutorial= http://www.youtube.com/playlist?list=PLDE1858BD83D19C70
General Arduion tutorials = http://tronixstuff.wordpress.com


  I don't know when I will have time to try it out but, I downloaded it. Sounds really good, thanks!

Great! I'll get the overview doc done with a couple more example codes for the formal release soon.


Thanks for all your responses. I've released the library 1.0 version. It's compatible with arduino 1.0 and 0022. Here is a link to exhibition post:


I think I've done something more than I was planning for. A united front for input devices with options to have local and several remote control over any project.

I'll be making some project with it soon.


Are there any more grey codes?

There will be, I haven't looked at them for years but IIRC there are versions with a lot more codes than you have there, a grey code after all is just a code where only a single bit changes for every new value.

Grey codes are normally used for absolute encoders I thought, a relative encoder should have no need for such things.


No - Gray codes are used for relative encoders, Allows you to get your information in 2 bits and keep track of position in software. Absolute encoders have either a whole bunch of wires or use some serial/parallel protocol to give position.

I have seen 2, 3, & 4 bit grey codes. 2 bit is most common, with a Z bit thrown in that goes true for exactly one sequence of the code in every revolution of the shaft.


You are confusing the code with it's implementation. A grey code can, as you say be any number of bits, but does give an absolute reference in itself. If it is a genuine grey code there is no need for an indexing bit. This is only needed for incremental encoders - which are much cheaper. These are more commonly used for speed rather than position recognition.

I deal with absolute encoders on a daily basis, most frequently 14 and 24 bit ones. The ones I use are grey code, but the implementation I prefer is ssi (simple serial interface), in fact I actually posted reference code for this some time ago somewhere on the forums.


Grey codes:

A grey code is just a implementation of parallel data of any width (2...N bits wide) just like ordinary parallel data buses. The difference is in the individual sequence of values as one increments up or down the sequence. We normally use a simple 0,1,2,3,4.... sequence, but with grey coding you rearrange the numbering sequence such that only one bit changes with each increment or decrement of the sequence in a 0,1,3,4,5... sequence. The advantage is that one doesn't have to be concerned about bit skew timing between the bits of a given value as the value sequence changes as only one bit will be changing value with each increment or decrement in the steps, and that makes timing/decoding of the sampling the data on the receiving end of the bus more reliable and error free. You see it mostly in machine control where the parallel data encoder may be some distance from the receiver electronics and/or high level electrical noise environment.



I added an analog joystick object that acts as an 8-directional digital keypad. Will release this addition soon. Meanwhile, any other input devices anyone wants to add to the library?



I was wondering if anyone has had the time or opportunity to add/modify Phi_prompt library and example to use a I2C LCD and a I2C 4*4 matrix keypad.

I have the requirement to use I2C keypad and LCD with a menu system for my current and few upcoming projects, I currently have everything working nicely with my own menu but it's a rather unhappy looking system of crapola and I would like to use this great menu system.  I require that this menu recognizes <LiquidCrystal_I2C.h> and key presses from the <Keypad_I2C.h> libraries.
The keypad lib uses standard keypad.getKey(); keypad.getState() etc.. I'm just not sure how to proceed to make phi_prompt work with this in a timely manner that wont take me forever to figure out but I'm sure some one on here could do this in 5 minutes
¸,ø¤º°`°º¤ø,¸ ???????? ¸,ø¤º°`°º¤ø,¸

24x7 Arduino Every TIme All The Time



The phi_prompt library sits on top of these two libraries:
LiquidCrystal: displays on character LCD of course.
phi_interfaces: senses all sorts of directly connected inputs, such as keypads, buttons, rotary encoders, analog joysticks, some of my specialty keypads etc.

To make the phi_prompt work on your lcd, the easiest way would be to use an I2C lcd library that inherits from LiquidCrystal library. This way you just pass the lcd object to phi_prompt as if it were LiquidCrystal. I believe adafruit has such an I2C lcd library.

To make phi_prompt work on your keypad, you would need to create a new class in the phi_interfaces library to make use of the getKey method. This may be done by someone with some experience writing c++ classes AND WITH the actual keypad. I don't have your keypad though.

Go Up