Was wondering how many of the GPIO I can use for analog reading. I have many sensors that output only in analog; so I was wondering if that may work, since the BBB has only 7 Analog IO, while the rest are all digital.
If I can’t plug more than 7 analog IO, how could I plug in more? Thanks.
Maybe you need more ADC chips .
I dont know how to use gpio as as analog reading , As I understand , GPIO only get 2 level input 1 or 0 , and if your analog signal over 2 levels ,how to measure ?
Another idea is
use TDM switcher , maybe you can find some chip can do switch several ADC input and 1 or more digital output . I dont know if there is this kind of chip ,maybe
DOH
You make a good point…I thought that the GPIO were configurable between analog and digital.
as ADC I’ve found this: not sure if it is right for me thou. I need these sensors to shoot data concurrently, while I think this board, allow only one signal at time, unless you switch input
The system is capable of reading the ADC inputs rapidly in round-robin fashion. It depends on having kernel support for this. The changes went into the mainline kernel last fall:
http://beagleboard-gsoc13.blogspot.com/
This patch is for ADC touch screen , generally resistive touch screen will have 4 lines for ADC X+ X- Y+ Y-
so , this will cost 2 ADC
for my understand , this round robin is just between this 2 ADC , instead of two sensors in one ADC converter.
From top thread , if you want to use over 10 sensors for ADC , you need external ADC chip . and do some communication work with am3358
If you want to have some flexable and no much than 10 sensors ,
what about add a stm32 ?
If your requirements are pretty relaxed (like running a touch screen), then you could use four GPIO outputs as address inputs for a 16-to-1 analog MUX chip. Your program would select the input you want to measure (of 16 possible), which would connect that input to an ADC pin.
If you really need 10 perfectly synchronized samples, then I suggest you build a board with 10 individual ADCs all connected to one common “sample & convert” signal. The Beaglebone can drive that signal using one GPIO output, wait for the maximum A-to-D conversion time, and then read all of the ADCs using an SPI or I2C chain. (Each ADC output connected to the next ADC input.)
Of course, if you need those samples to be perfectly periodic (like for an FFT), then you will have to drive that “sample & convert” output using one of the PRUs or a hardware timer. There is too much going on in a Linux system to make anything happen in software at a precise time. The sampling jitter would be many milliseconds, and still too large for any kind of signal processing even with the realtime patches in the kernel. This is the kind of application TI had in mind when they included the PRUs: Each is a 200 MHz processor with 5 nsec instructions and no interrupts or tasks to make their responses non-deterministic. They are yours to command, and they can talk directly to all the hardware registers without needing drivers, kernel execution state, virtual addresses, etc.
Thanks for the suggestions;
The issue is that these sensor may need to communicate with the board at the same time; imagine a sort of mocap device for a quadruped: if they walk, they are in fact using all 4 legs at the same time, so I need a way to capture these values at the same time. From what I understand, if I use an ADC, I am forced to tell it to switch to a specific input, so it works more like a radio selector (multiple station, but you can get only one at time), than a electric strip (many plugs can take electricity independently at the same time).
The solution that you mentioned (the one with the device that send all the data at once), seems functional to my case. I don’t need instantaneous reactivity by the device, since it is more used to capture data on movements, convert it to something that the main computer can digest (done on the BBB), and then sent to the computer, that will grab the data and apply it to a mesh. Each of these steps will take time, so I am aiming at something usable with a small lag; that’s why Analog seem the quickest way to get the data out.
I am basically clueless about what could I potentially buy, to achieve what I want; and can’t really find any reference online…if there is one is either well hidden or people don’t like to talk about it.