Bonescript on BBB | digitalWrite does not change pin voltage

GoogleGroups
1

I just received my BBB in the mail and am trying to do some basic (very, very basic) tests. I will be using the BBB to (eventually) run my home brewery, and decided to use it over the RasPi because of bonescript.

Back to my issue: I have an SSR which will be controlled from pin P8_46. For my basic test, all I am trying to do is turn it on. I have tried digitalWrite and analogWrite, but neither seem to work. Currently I have a volt meter hooked up to the pin to test the output, it never changes.

Here is my code:

`

var b = require(“bonescript”),
pin = “P8_46”;
b.pinMode(pin, b.OUTPUT);
b.getPinMode(pin,logger);
b.digitalWrite(pin, 1, logger);
b.digitalRead(pin,logger);
//b.analogWrite(pin, 1);
//b.analogRead(pin,logger);

function logger(x){
console.log(x);
}

`

The output I get is:

null
{ value: 1 }
{ pin: ‘P8_46’,
name: ‘GPIO2_7’,
options:
[ ‘lcd_data1’,
‘gpmc_a1’,
‘pr1_mii0_txen’,
‘ehrpwm2B’,
‘NA’,
‘pr1_pru1_pru_r30_1’,
‘pr1_pru1_pru_r31_1’,
‘gpio2_7’ ],
mux: 0,
slew: ‘fast’,
rx: ‘disabled’,
pullup: ‘disabled’ }

So the digitalRead is showing that the pin is on, but the voltage output of the pin on the meter never changes.

When I use analogWrite, I get the following error:

fs.js:429
return binding.write(fd, buffer, offset, length, position);
^
Error: EEXIST, file already exists
at Object.fs.writeSync (fs.js:429:18)
at Object.fs.writeFileSync (fs.js:764:21)
at load_dt (/usr/lib/node_modules/bonescript/index.js:59:12)
at Object.f.analogWrite (/usr/lib/node_modules/bonescript/index.js:519:37)
at Object. (/var/lib/cloud9/brewbone/index.js:21:3)
at Module._compile (module.js:449:26)
at Object.Module._extensions…js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.runMain (module.js:492:10)

Eventually, I would like to use analogWrite to be able to control the output with PWM.

Any help would be greatly appreciated. I am sure I am doing something stupid and basic, but I cannot figure it out.

Thanks,

Josh

2

It appears you have not set the pinmux to GPIO mode (it is in lcd_data1 mode).The GPIO value will never make it from the processor core to the outside world without the proper pinmux setting.

Setting the pinmux depends on which Kernel version you are running.
Kernel < 3.8: sysfs
Kernel >= 3.8 device tree overlay

Another option is to switch to a different pin that has its default mux set to mode 7 on bootup.
Louis

3

Louis is right, you can either switch to a different pin or set a device tree overlay. The mux is set to 0, which means its ‘lcd_data1.’ You can follow this example (http://beagleboard.org/support/BoneScript/ServoMotor/) to figure out how to get your PWM to work.

4

Thanks! I would have never figured that out! I appreciate the help.

5

I’ve just made a patch to BoneScript to try to address the pinmuxing. It is still in the staging tree looking for testers. I’ll publish news when the release version is updated.

6

Thanks for the link!

7

Thanks! I would like to help, but am pretty sure I am useless to you :slight_smile:

8

Do you guys know of any good tutorials on how to use the device tree overlay to set the correct mux? I have found other pins which work, but I would like to figure this out for future reference. Thanks!

9

This would be a good read if you need to understand device tree (https://docs.google.com/document/d/17P54kZkZO_-JtTjrFuVz-Cp_RMMg7GB_8W9JK9sLKfA/pub)

And you can also check out this video titled, "

Beaglebone: Introduction to GPIOs - Using Device Tree Overlays under Linux 3.8+" (https://www.youtube.com/watch?v=wui_wU1AeQc)

10

Wonderful. Thank you for helping out a newbie!

  • Josh Peltier
11

Does the create_dt funxtion at https://github.com/jadonk/bonescript/blob/master/node_modules/bonescript/my.js help?

12

Hmmm…that looks nice :slight_smile:

Thinking out loud here…
Since that goes through the trouble of creating a dtbo for one pin, I wonder if it could be used as a stepping stone to create a function to read a cape EEPROM starting at address 0x100, which just so happens to contain a plain-text dts source. Now your cape driver could be created on-the-fly upon first insertion. Of course it wouldn’t do this every boot, just if a dtbo file is not found in /lib/firmware.

I guess I will have to poke around in the capemgr source that reads the EEPROM (to figure out which dtbo file to overlay) on boot. I’m assuming it is done in capemgr…
Louis

13

Hmmm....that looks nice :slight_smile:

Thinking out loud here....
Since that goes through the trouble of creating a dtbo for one pin, I
wonder if it could be used as a stepping stone to create a function to read
a cape EEPROM starting at address 0x100, which just so happens to contain a
plain-text dts source. Now your cape driver could be created on-the-fly
upon first insertion. Of course it wouldn't do this every boot, just if a
dtbo file is not found in /lib/firmware.

I guess I will have to poke around in the capemgr source that reads the
EEPROM (to figure out which dtbo file to overlay) on boot. I'm assuming it
is done in capemgr.....

I think modifying the EEPROM format to provide a flag and a .dtbo (not
.dts) is a good idea. The version of the .dtbo would need to be included
such that newer versions in /lib/firmware would get loaded to fix any bugs
in the EEPROM.

Using the create_dt function to help generate those .dtbo files makes some
sense to me, but I think the change to capemgr is the pressing issue.

Updating the .dtbo in the EEPROM to reflect user settings is risky, but can
be imagined. There would need to be some super-easy tools with error
checking and a way to quickly back it out. I wouldn't start anything in
this direction without a well spelled out vision of how everything would
work.