So the good news is that I sort of got the encoder to work using the code above.
using the following:
Code: Select all
unsigned int microseconds;
wiringPiSetup () ;
/*using pins 23/24*/
struct encoder *encoder = setupencoder(4,5);
long l = encoder->value;
printf("value: %d\n", (void *)l);
value = l;
I can reliably get the output to either go up or down depending on the direction I turn the encoder. It doesn't increment or decrement by 1, but rather by 4, and only if I turn carefully. however, simply knowing if the value goes up or down should be "good enough" to rotate through the options menu. I haven't got the button press figured out, but that should be relatively easy in comparison. the big usleep was for a bit of debouncing (physical switches are noisy) the encoder as it rotated. I used values as low as 5000 and got similar results to the higher choices.
The code seems useful as it has been prepared to be a library added to other projects already. My snippet above uses it in this fashion. It does require the installation of wiringPi.
I did try to take a look at Ares code, but I don't know enough to integrate this code into his, and still have it compile after. He is a real coder, I am not.
The meta code for it would be something like this (I realize some of this is already in there for the keyboard input in raspivoicemain.cpp):
create options list
named mute, negative, zoom, blinders, edge detect, threshold, brightness, contrast, foveal mapping, restore defaults
with individual option states as appropriate
start at option 0
update encoder value
if encoder value > old_encoder_value then option = option + 1
if encoder value < old_encoder_value then option = option - 1
update button press
if button press = true then option.state = option.state + 1
if option.state > max option.state then option.state = 0
/* ex. for mute, 0 and 1 are possible, for zoom, 0,1,2,3 are possible representing none, 25, 50, and 75% */
run raspivoice with new option
If you are willing to work on this, I can send you the prototype stage hardware to get the encoder functional. I don't know how you feel about hardware, but what I would send would just plug onto the gpio header on the rpi board. No need for soldering.
While this continues, I would commence the work on the ultrasonic rangefinder and vibration motor feedback. I would make this a separate process programmed in python. I feel confident that I can take this from start to finish on my own in short order as I find python far more forgiving.