Closed hoffmanjon closed 8 years ago
post your output when running with DEBUG=bone
ie run from command prompt like so
sudo DEBUG=bone node tempSensor.js
@hoffmanjon any update here? Or should we close this?
I have the same issue:
This is my code:
var b = require('octalbonescript'); //load the library
var pin = 'P9_33'; //the pin to operate on
b.analogRead(pin, function (err, value) {
if (err) {
console.error(err.message);
return;
}
console.log(value); // value is floating point number between 0 and 1.
});
When I run it using DEBUG=true
mode I get:
bone Using Universal Cape interface +0ms
bone Checking for Universal Cape interface... prevent with AUTO_LOAD_CAPE=0 +72ms
bone Slots returned 0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
4: P-O-L- 1 Override Board Name,00A0,Override Manuf,cape-universaln
5: P-O-L- 0 Override Board Name,00A0,Override Manuf,BB-ADC
+19ms
bone found Universial at slot 4 +8ms
bone Found Universial using ",cape-univ" or ",univ-" as filter +3ms
bone Universal Cape interface already loaded ... +2ms
bone index.js loaded +3ms
bone getpin(P9_33) +7s
bone find_sysfsFile(ocp:P9_33_pinmux,/sys/devices/platform/ocp,ocp:P9_33_pinmux) +4ms
bone Pin Path :null +8ms
bone analogRead(P9_33); +3ms
bone read Analog input P9_33 +3ms
analogRead error: ENOENT, open '4_raw'
I can see the code I added to detect if the universal cap is already loaded and it is detecting the universal cape, and preventing the universal cape from loading again which was an issue we fixes with the last code update.
I also see the BB-ADC slot is loaded which is claiming exclusive-use of P9_33 ([https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-ADC-00A0.dts]) and I assume preventing us from setting the P9_33 pin mode.
We can test this theory by manual unloading the cape by folling @RobertCNelson instructions located at [https://github.com/RobertCNelson/bb.org-overlays]
Assuming "cat /sys/devices/platform/bone_capemgr/slots" show
" 5: P-O-L- 0 Override Board Name,00A0,Override Manuf,BB-ADC"
the bb-adc is at slot 5 we should be able to temp unload it using
"sudo sh -c "echo '-5' > /sys/devices/platform/bone_capemgr/slots"
Then run our node.js project again and see if we can use "P9_33". IF we can then we need to add some more logic to octalbone script to detect capes that have already claimed exclusive use of the pin and if that exclusive pin is already in teh mode we want maybe just try accessing the pin rather then trying to set its mode. Just speculating here as I haven't really looked at what the analogRead code is doing at the lower level.
Can you describe your setup so I can try to reproduce and troubleshoot?
What beagle-bone are you using and what capes do you have plugged in as an epprom can load a slots file and claim the pins which is why I ssupect the BB-ADC slot is already loaded.
Have you forced an overlay to load by editing the /boot/uEnv.txt file? see https://github.com/RobertCNelson/bb.org-overlays readme for help on how to force overlays and diable them etc.
Looks like https://github.com/theoctal/octalbonescript/blob/master/lib/analog.js is loading BB-ADC
but in your output I do not see the debug from line 15 "debug('analog enable. Path = ' + ainPrefix);" which makes me think "/sys/devices/platform/ocp', '44e0d000.tscadc' is not there. Could be with this kernel its in a different location. Certainly need to add some debug to the enable function so the file is missing we spit out some debug saying so.
Honestly have never used the analog read with octalbonescript so would need to do some playing to get you a real answer. Send me your setup and I can give it a whirl?
Andy
Looking at latest from @jadonk looks like analog locations have changed to "var ainPrefix = "/sys/bus/iio/devices/iio:device0";" https://github.com/jadonk/bonescript/blob/master/src/hw_mainline.js line 16
But then looking at https://github.com/jadonk/bonescript/blob/master/src/my.js
I see found = exports.find_sysfsFile('ocp', '/sys/devices/platform', 'ocp', callback);
jadonk added support to bonescript for older and newer kernals so hard to follow which code is executing without a beaglebone in front of me. When I get back to the house with some Bone hardware I can see if I can replicate your issue.
Andy
@Andrewiski, thanks for your help. I have actually figured out the problem.
If I using the following code it initialise OBS, it works:
process.env.AUTO_LOAD_CAPE = 0;
var obs = require('octalbonescript');
obs.loadCape('cape-universaln');
obs.loadCape('BB-ADC');
Thanks, Simon
fixed this issue of BB-ADC not getting loaded. Some PR in past messed it. Check with latest version and let me know if it works fine.
Thanks,
Probably should add some debug to make it easier to debug slots not being loaded. ie add an else to if(helper){ ... }else{ debug('BB-ADC is not loaded'); }
enable: function(callback) { bone.load_dt_sync('BB-ADC'); var helper = bone.find_sysfsFile('helper', '/sys/devices/platform/ocp', '44e0d000.tscadc'); if (helper) { ainPrefix = helper + '/TI-am335x-adc/iio:device0/in_voltage'; debug('analog enable. Path = ' + ainPrefix); } if (typeof callback == 'function') callback(null, { 'path': helper });
},
Whats weird there is in his debug above I see BB-ADC is in fact loaded, are you sure you don't have a race condition meaning you not waiting on the callback for the pin to be enabled which loaded BB-ADC to complete before you try to read it?
I really don't think that is right place to put debug. Race condition is real.
I am trying to use a temperature sensor. My code looks like this:
var b = require('octalbonescript'); var tempPin = 'P9_39'; b.analogRead(tempPin, function(err, aRead) { if (err) { console.error(err.message); return; } console.log("Getting Temp"); var x = (aRead * 1800/2014); console.log("aRead: " + aRead); console.log("x: " + x);
});
When I run it with node tempSensor.js, I get the following error:
I am using the standard 4.1.15-ti-rt-r43 kernel that comes with Debian 8.3 however I have also tried the 4.4.6-bone6 kernel.