Couldn't wait for my Pyra, so I bought a OMAP5432 devboard

[Djoga'Ro]

Hmm... Maybe. Might be odd if values jump from near min to 0. The output value could also be scaled between min and max, but then you loose what real mV it was

As it is, you easily disable the possibility to reach 0. I couldn't find a line in your repository, that'd pull down the value at some later point. Or is that to be done in the executable called?

 

[Risca]

As it is, you easily disable the possibility to reach 0. I couldn't find a line in your repository, that'd pull down the value at some later point. Or is that to be done in the executable called?

Yeah, that's the idea. My application only forwards the mV and sets some requirements on threshold values. I think that's a sane approach

 

[Djoga'Ro]

Then you shouldn't test against min, when deciding if you disable the threshold. Otherwise you'll rarely report 0 mV - less often then it's actually dialed in that is.

 

[Risca]

Some updates!

I re-soldered my volume wheel to my board and added some hot glue to keep it in place this time.

I used makesd --debug -vk latest omap5432evm to get the latest Letux-6.1-rc4 kernel and Debian rootfs. Then I copied over my latest changes to the board and did some development and testing on the board itself. Looks like it's all working rather fine

I did 3 changes:

• only disable lower threshold if it's below or equal to 0 or the lower threshold value. This works fine in reporting absolute 0 to the given executable and doesn't cause any interrupt storms
• clamp the output value to --min and --max. It is up to the called executable to scale the value appropriately.
• Call EXECUTABLE with arguments <value> <min> <max>.

Latest changes pushed to the main branch here: https://github.com/Risca/pyra_vol_mon

This is the current help text:

root@letux:~/pyra_vol_mon# ./pyra_vol_mon --channel 1 --step 10 --help                
Usage: pyra_vol_mon [OPTION]... EXECUTABLE

Monitor palmas_gpadc ADC channel and run EXECUTABLE when input changes.

  -c, --channel     ADC channel to monitor. The Pyra volume wheel is
                    connected to ADC channel 2.
                    Defaults to 2.
  -l, --min         Lower limit to monitor. ADC values below this limit will
                    only trigger executable once, until the ADC channel goes
                    above the limit again.
                    Defaults to 0.
  -u, --max         Upper limit to monitor. ADC values above this limit will
                    only trigger executable once, until the ADC cannel goes
                    below the limit again.
                    Defaults to 0x7FF.
  -s, --step        How much the ADC input value is allowed to change before
                    calling the executable again.
                    Defaults to 25.
  -h, --help        Show this help text and exit
  -v, --verbose     Be a bit more verbose.

EXECUTABLE will be called like this:

    EXECUTABLE <adc value>

Example output with echo as executable:

root@letux:~/pyra_vol_mon# ./pyra_vol_mon --channel 1 --step 10 --max 1200 echo
Found IIO device with name palmas-gpadc with device number 0
588 0 1200
559 0 1200
536 0 1200
509 0 1200
484 0 1200
461 0 1200
438 0 1200
409 0 1200
386 0 1200
357 0 1200
337 0 1200
305 0 1200
283 0 1200
256 0 1200
225 0 1200
204 0 1200
182 0 1200
158 0 1200
134 0 1200
109 0 1200
77 0 1200
38 0 1200
0 0 1200

(please note that the --channel argument is not needed on the Pyra - Pyra uses the default channel 2)

I also did some testing with the pyra_vol_ctl that @hns made. I had to change the sound card to match my devboard, but after that it just worked! I could see the volume sliders in alsamixer move up and down as I turned my volume knob. Great success!

I guess all that's left is to write a systemd service file and this little adventure is ready for release

 

[Risca]

One little fun thing I noticed with my volume wheel is that it is very capacitive (I think) so when I turn it quickly, the voltage reading overshoots I wonder if the little pyra wheel has the same issue?

 

[Git1]

I guess all that's left is to write a systemd service file and this little adventure is ready for release

Awesome work there, thanks!

 

[Magic Sam]

Awesome work indeed, thanks a lot !

Cheers, Magic Sam