7 days later

giuliomoro I just realised that I didnt really understand what you meant by "thresholding the analog inputs in the software" in order to use them as digital ones for my switches.... 🙂

what I mean is that you start by connecting the switch as usual:

3.3V
 |
 Z  R1 10k
 Z
 |
 |
 +----------------To Analog or digital Input
 /  switch
 |
Gnd

then if you connect it to the digital input, you will get only readings of 1 when it's not pressed and 0 when it's pressed. If instead you connect it to an analog input, you will read values around 0.8 when it's open and around 0 when it's closed. What I mean by thresholding is that you'd consider the reading a "digital 1" if it's above 0.5 and a "digital 0" if it's below 0.5. Something like:

analogValue = multiplexerAnalogRead(context, input, muxChannel);
digitalValue = analogValue > 0.5.

See, here and here for more info on the multiplexerAnalogRead() function

Does it make more sense now?

    3 years later

    Hi, as far as I'm concerned, there's currently no way to expand the number of analog inputs on Bela Mini - am I right, or am I (hopefully) missing something? Currently I'm using an external microcontroler (Teensy 3.2) connected to Bela Mini as a midi controller in order to get those extra analog inputs that I need, but it's rather clumsy and otherwise not ideal...

    How many extra inputs do you need? There are 8 more available on BelaMini, though one is one the same pin as one LED (so it has limited range) and one is on the same pin as a digital I/O (so only one of the two functions can be enabled). Most of these have a strict 0V:1.8V range, and they are all slower to read than the Bela analogs, but it seems that they can work nicely in your case. If you only need 7 or 8 extra channels, these may work, but if you need more, you could look at building a little breakout board with a multiplexer on board which works similarly to the Multiplexer cape for the bigger Bela.

      giuliomoro !!!OH that would be great!!! I only need 3 or 4 additional analog ins, so that sounds perfect! Could you specify how to access these inputs and whether they're available from Pure Data?

      to access those one needs to read the files /sys/bus/iio/devices/iio:device0/in_voltage0_raw, /sys/bus/iio/devices/iio:device0/in_voltage1_raw etc , where the number corresponds to the ADC number in this pinout. Not sure this can be done straight from Pd without causing mode switches and dropouts, so one may have to write a bit of C++ code to wrap those. What would you use in Pd to read a file on disk? We can give that a try first.

      Does the file "...in_voltage0_raw" have some extension? Just making sure I'm getting it right - the file gets automatically updated every now and then and holds a latest value of a given pin?

      Regarding reading files in PD I've tried something among these lines:

      alt text

      with the [textfile] object, but it's unfortunately for text files exclusively. There's gotta be some other way, I'll look into it.

        krzysztofcybulski Does the file "...in_voltage0_raw" have some extension? Just making sure I'm getting it right - the file gets automatically updated every now and then and holds a latest value of a given pin?

        that's correct. It's a virtual text file (without a newline at the end). The value you read is a string containing values between 0 nad 4095. Every time you read it, it goes and takes a measurement of the ADC and returns that value. So it's not real-time safe at all. As it's a virtual file, it seems that Pd is having trouble to read it. We'll have to make a C++ workaround I guess.

        OK I have something working: drop this render.cpp file in your Pd project and use something like this with [unpack] or similar:

        [r bela_lowResAnalogIn]
        |
        [print]

        It reads every 50 ms more or less, not sure how much faster than that it can go.

        As mentioned before, use the pinout here and triple check that you do not send more than 1.8V to each of the 1.8V inputs. You can use P1.18 "REF+ AIN 1.8V" as a 1.8V voltage reference to drive your potentiometers/sensors. I am not 100% sure whether this is properly buffered. Wire up a few pots/sensors and see if you are getting any crosstalk between them, as that would be an indication that you need a buffer on that voltage reference.

          giuliomoro You must forgive me, but I'm totally dub when it comes to Linux, command line etc.
          By "drop this file" you mean dropping it by using the Bela IDE? I've done it and the file is visible, yet, when I try to run the project on Bela, I get the following:

          Makefile:483: recipe for target '/root/Bela/projects/test_czytania_pliku_analog_in_dodatkowe/build/render.o' failed

          and:
          'libraries/libpd/libpd.h' file not found column: 10, line: 33

          Not sure how to deal with it.
          Apologies again, cuz it's probably bread and butter for anyone familiar with Linux coding...

          a month later

          giuliomoro Just a short postscript: I tested the solution (using the "hidden", original PocketBeagle analog inputs within Pure Data) and it works great - everything's ok and the readings are stable, the only thing that is less than satisfactory (altohough exactly just like you've described it) is the frequency of the readings - between 19 and 20 per second). I was just wondering if there is a possibility of a simple tradeoff - i.e. if I would only like to read 3 out of 8 inputs, would the readings be faster? Or it doesn't matter and it would be still the same frequency?

          The reading loop in the code is:

          	while(!Bela_stopRequested())
          	{
          		for(size_t n = 0; n < gLowResAnalogIn.size(); ++n)
          		{
          			path[x] = '0' + n; // int to char
          			std::string ret = IoUtils::readTextFile(path);
          			gLowResAnalogIn[n] = std::atoi(ret.c_str()) / 4096.f;
          		}
          		usleep(kLowResAnalogInSleepUs);
          	}

          and the kLowResAnalogInSleepUs constant is defined as:

          static constexpr size_t kLowResAnalogInSleepUs = 50000;

          which is what's driving your sampling period. Change it to, e.g.: 10000µs to get about 100Hz.