Re: [beagleboard] 3.12-rc4: kernel testing time...

2013-10-17 Thread George Lu
Hi Robert,

I too had missed it earlier. I would be glad to do the quick "test-me.sh"
script.

George


On Thu, Oct 17, 2013 at 2:53 PM, William Hermans  wrote:

> Robert, I completely missed this on your first post.
>
> "Other thoughts...
> Some users will build/install these from src, however anyone
> interested in a quick "test-me.sh*" script which will install the new
> kernel on a daily/weekly basis?
> "
>
>  Yes please ! Does one exist yet ? I'll test every new version that comes
> out when I am made aware of it if such a script exists. I've noticed that
> rc5 is here already which partially has me balking at using a lot of
> internet bandwidth to pull tons of sources in.
>
> Also if you have a specific list of things you'd like tested I may be able
> to do this. Also what would be a good load test ? I've written my own very
> simple load test ( timed while(0){i++;} sort of deal, but yeah. Also I will
> be testing Nodejs following previously used steps( by me personally) to get
> the latest Nodejs sources compiled and running on 3.8.x.
>
> I should be more active in this mater after this weekend . . .
>
>
> On Wed, Oct 16, 2013 at 11:01 AM, Jason Kridner 
> wrote:
>
>> I've booted it on Buildroot. Was going to try taking the same kernel
>> and booting it on Angstrom as well, but haven't gotten there yet.
>>
>> Build output:
>> https://s3.amazonaws.com/beagle/buildroot/2013-10-13-21%3A15%3A27/index.html
>>
>> Source:
>> https://github.com/jadonk/buildroot/commit/5bcbc31f31a9f0b6941c522a3a50877326cb96d2
>>
>> Planning on automating this as I have time.
>>
>>
>> On Wed, Oct 16, 2013 at 11:40 AM, David Lambert  wrote:
>> > Has anyone managed to get this kernel to work on the BBB?
>> >
>> > Regards,
>> >
>> > Dave.
>> >
>> >
>> > On 13-10-12 07:43 PM, David Lambert wrote:
>> >>
>> >> I forgot to use earlyprintk :-[ Here is the screenlog with it enabled.
>> >>
>> >> On 13-10-12 04:21 PM, David Lambert wrote:
>> >>>
>> >>> On 13-10-11 02:51 PM, Robert Nelson wrote:
>> 
>> 
>>  ah... okay because uImage gets interesting in v3.12
>> 
>>  make ARCH=arm LOADADDR=0x80008000 uImage
>> 
>>  Regards,
>> 
>> >>> OK I got the kernel, modules and firmware to buid eventually (forgot
>> >>> uboot-mkimage).
>> >>> Commands used were:
>> >>>
>> >>> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LOADADDR=0x80008000
>> >>> uImage dtbs
>> >>> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LOADADDR=0x80008000
>> >>> modules
>> >>> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
>> >>> INSTALL_MOD_PATH=./tempmod LOADADDR=0x80008000 modules_install
>> >>>
>> >>> Now I am stuck at boot, see screenlog attached.
>> >>>
>> >>>
>> >>>
>> >>> Any ideas?
>> >>>
>> >>> Regards,
>> >>>
>> >>> Dave.
>> >>>
>> >>>
>> >>
>> >
>> > --
>> > For more options, visit http://beagleboard.org/discuss
>> > --- You received this message because you are subscribed to the Google
>> > Groups "BeagleBoard" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to beagleboard+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [beagleboard] 3.12-rc4: kernel testing time...

2013-10-18 Thread George Lu
On Fri, Oct 18, 2013 at 10:15 AM, Robert Nelson wrote:

> wget http://rcn-ee.homeip.net:81/dl/jenkins/beagleboard.org/test-me.sh
>  chmod +x test-me.sh
>
> run via: ./test-me.sh
>
> (it does an abi check with the server, so if I ever change anything,
> it'll tell you what to do to update test-me.sh..)
>
> So far it's only been tested against Angstrom (2013-06-20) from here:
> http://beagleboard.org/Getting%20Started#update via the eMMC..  So
> microSD should work fine too..
>
> PS: remember no "external" capes work.. For the BBB, hdmi, ethernet,
> usb, etc is tested..
>
>
On  a BB white that was on debian 7.1, it booted into 3.12.0-rc5-bone6 #1
as expected. I noticed immediately that my byobu status bar says the CPU
speed is now "infGHz". :)
debian@arm:~$ uname -a
Linux arm 3.12.0-rc5-bone6 #1 SMP Mon Oct 14 10:57:12 UTC 2013 armv7l
GNU/Linux
debian@arm:~$ cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpuf...@vger.kernel.org, please.
analyzing CPU 0:
  no or unknown cpufreq driver is active on this CPU
  maximum transition latency: 0.00 ms.


On BBB that was on debian 7.1, kernel 3.8.13-bone28, after I ran test.sh
and rebooted I still have 3.8.13-bone28. There is a 3.8.13-bone28.bak
directory, and there are newly written *.dtb files in /boot but there are
no files from 3.12.x. This BBB is booting off uSD, Could that be the issue?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [beagleboard] 3.12-rc4: kernel testing time...

2013-10-18 Thread George Lu
>  > On BBB that was on debian 7.1, kernel 3.8.13-bone28, after I ran
> test.sh and
> > rebooted I still have 3.8.13-bone28. There is a 3.8.13-bone28.bak
> directory,
> > and there are newly written *.dtb files in /boot but there are no files
> from
> > 3.12.x. This BBB is booting off uSD, Could that be the issue?
>
> Laughs! It figures the first "bug" in the test-me.sh script would be a
> user trying to update an debian/ubuntu system...  Which I haven't
> written support for yet... For now just use the install-me.sh and my
> linux-dev build scripts.. ;)
>
>
Understand. I have this BBB updated using wget
http://rcn-ee.net/deb/wheezy-armhf/v3.12.0-rc5-bone6/install-me.sh.



> So here's the deal, we no longer have an "active" Angstrom kernel
> maintainer for the beagleboard.org, so i'm filling in till that
> changes.


Appreciate your filling in this role.


> Right now the goal/testing should be limited to usb and
> video output and if we are missing any config's from the 3.8 kernel.
> For capes, well that's going to take a little bit of work from you
> guys too. ;)
>
>
My ar9271 based wifi dongle seems to work fine.

I don't see UART listed among Status items. Is that categorized under
Capes? There is only /dev/ttyO0 at the moment. Besides telling you
something does not work, how do we help?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [beagleboard] Re: 3.12-rc4: kernel testing time...

2013-10-29 Thread George Lu
I also tried 3.12.0-rc7-bone8 on debian:

After applying overlay for UART1, /dev/ttyO2 appeared.
# echo BB-UART1 > /sys/devices/bone_capemgr.6/slots

After applying overlay for UART2, /dev/ttyO3 appeared.
# echo BB-UART2 > /sys/devices/bone_capemgr.6/slots

# cat /sys/devices/bone_capemgr.6/slots
 0: 54:PF---
 1: 55:PF---
 2: 56:PF---
 3: 57:PF---
 4: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART1
 5: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART2
# ls /dev/ttyO?
/dev/ttyO0  /dev/ttyO2  /dev/ttyO3

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [beagleboard] Re: node.js SerialPort Erro

2014-01-15 Thread George Lu
Hi Rob,

I have serialPort installed and working with both node v0.8 and v0.10 on
two BBB.

On the first BBB, making v0.8 from source took a bit over half-an-hour, as
I recall. Below were my steps:


# apt-get install build-essential

Fetch and Build node.js


root@arm:~# wget
http://nodejs.org/dist/v0.8.22/node-v0.8.22.tar.gzroot@arm:~# tar xvf
node-v0.8.22.tar.gz
root@arm:~# cd node-v0.8.22
root@arm:~/node-v0.8.22# ./configure --without-snapshot
root@arm:~/node-v0.8.22# make

I had used the same steps to build node v0.10.x too. I ended up switching
back to 0.8 because BoneScript still needs 0.8 at the moment. npm install
serialport or npm install -g serialport works fine after that. I have
serialport 1.1.3 on this BBB.

On the second BBB, I have Robert's bone-debian-7.3-2014-01-10 test image
running. This test image already has node v0.10.24 preinstalled. npm
install serialport was smooth. I see that I have the latest serialport
v1.2.5 installed here.

George


On Wed, Jan 15, 2014 at 8:17 AM,  wrote:

> I am having issues with installing node-serialport because of its 0.10+
> dependency. I have attempted to compile node.js latest to the board but
> that is a very slow and painful process (first attempt ran for ~4 hours
> then power cut... I was not impressed)
>
> Anyone have this package successfully working with node 0.8 ??
>
> On Thursday, May 9, 2013 8:12:45 PM UTC-4, johnamon wrote:
>>
>> Apologies if this is a double post, my previous post hasn't seemed to
>> have appeared on the boards.
>>
>> I have tried to install the node.js extension SerialPort via the command
>> "npm install serialport" but I receive the following error:
>>
>> "Error: Python executable "python" is v2.7.3, which is not supported by
>> gyp"
>>
>> Does anyone know how to fix this?  I've tried upgrading python, which
>> didn't work.
>>
>> Thank you
>>
>> John
>>
>  --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [beagleboard] Using 3G Data card with Beaglebone black.

2014-09-15 Thread George Lu
Hi Sanjay,

I had gotten Huawei E353 to work with beaglebone in a remote monitoring
application. It was not straight forward to get it working.

I had used sakis3g to do the mode switching and get the BB manual
connected. sakis3g does not offer a way to auto-reconnect if the connection
is hung up for any reason. wvdial will keep a connection up. Google around
and you might be able to find examples specific to your service provider.
For example: http://www.yantrr.com/wiki/Sample_wvdial.conf_file. Remember
you need to do mode switching before starting wvdial.

There is a USB reliability issue that is fixed in kernel after around 3.12.
Back when I was running 3.2 kernel on the Beaglebone, it would eventually
unable to reconnect after a few weeks (at least the data continue to get
logged). On 3.8 kernel, there would be kernel panic after just a few days
and system stayed in hung state until someone could reset it. System
stability improved big time since we switched to 3.15 kernel a few months
ago. I might switch to the 3.14-ti kernel the next time I get to work on
it. Depending on what else you do on your BB or BBB, you may also need to
customize am335x-bone.dtb or am335x-boneblack.dtb to get the pin
configuration you need on >3.8 kernel. See
http://elinux.org/Beagleboard:Capes_3.8_to_3.14#Custom_dtb.




On Mon, Sep 15, 2014 at 6:05 AM, Jerônimo Lopes 
wrote:

> Hi Sanjay,
>
> It is possible, in many ways.
>
> First of all, you'll need usb-modeswitch, so the card can be recognized as
> serial ports.
>
> Second you need a software that can configure your ethernet interface, for
> that you can use one of these:
>  - sakis3g: if you google "3g + BBB", it will lead to it, it's an script
> 'lost' out there, through its interactive interface, you can configure the
> connection.
>  - wvdial: it auto creates scripts for pppd. it seams to have some bugs
> for the arm arch, people say it works, I never get it work correctly.
>  - ofono + connman: very badly documented, but it works. I find it not
> very stable.
>  - modemmanager + networkmanager: default of most linux distros, its last
> version has a nice cli to create connections. I would try that.
>
> I had many headaches trying to do that, feel free to ask and share.
>
> 2014-09-14 15:09 GMT-03:00 sanjay ahuja :
>
> Is it possible to use huawei E3131 Bs-1 3G Data Card with beagle bone
>> black to access internet.
>>
>> Can somebody please point to any steps or tutorials for configuring it?
>>
>> Details of data card:
>>
>>  --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Wireless mesh networking

2014-09-28 Thread George Lu
Hi Brian,

I had evaluated babel, OLSR, and Batman-adv two years ago on a test network
of 5 beaglebones to demonstrate wifi mesh networking. I concluded
Batman-adv was the one to explore further. I was using Robert Nelson's
ubuntu (3.2 kernel) on beaglebone white then. I had tried three different
long range wifi dongles from Alpha. The black one (http://www.amazon.com/
Alfa-AWUS036NHA-Wireless-Adaptor-Compatible/dp/B004Y6MIXS) has Atheros
ar9271 chipset and has the best kernel support on Beaglebone. The more
common model is based on realtek rtl8192cu chipset. Back then rtl8192cu
driver on arm was not anywhere near ready. I would still strongly prefer
AR9271 based wifi dongle today. I had to use a USB Y-cable to make sure
there is sufficient current during boot time to power up the wifi dongle.
BB only has a USB host port, so this was a bit inconvenient. I resorted to
tie the 5V and GND lines of the USB to a 5V supply to ensure smooth boot.

With a 14" omnidirectional antenna and tx-power cranked up full, I was able
to sustain decent connectivity at ~300 meter per hop during field
demonstration.

For batman-adv, I configured every node's bat0 interface on 192.168.50.x
subnet. (wlan0 has its own static address assignment in
/etc/network/interfaces)

When starting a mesh node, a startbatman.sh is called that has the
following:
modprobe batman-adv
ifconfig wlan0 mtu 1528
batctl if add wlan0
ifconfig bat0 192.168.50.218 up
batctl gw client
ip route del default
ip route add default via 192.168.50.1

On the node serving as gateway through its eth0, I had the additional lines
for Network Address Translation.
sysctl net.ipv4.ip_forward=1
iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables --append FORWARD --in-interface bat0 -j ACCEPT

You could add an @reboot line in /etc/crontab that calls your startbatman.sh
on reboot every time.

I have not updated this since the switch to 3.8 kernel, but I am pretty
sure it would work on the current Debian image. I would recommend you use
the 3.14 kernel to benefit from the more reliable USB.

George

On Fri, Sep 26, 2014 at 2:30 PM, Brian Anderson  wrote:

> Hi all,
>
> I am interested in setting up a wireless mesh network using a collection
> of BBBs (and possibly other devices).  Does anyone have experience setting
> up a wireless mesh network using BBB?
>
> I am not really interested in a so-called "wireless distribution system"
> that is used to extend an SSID across a wide area using wireless mesh
> networking.  I am much more interested in setting up a network of
> cooperating nodes that talk with each other (and to the internet via a
> gateway/mesh portal connected simultaneously to the internet and the mesh).
>
> In particular, I'm interested in:
>
>   * What distro and kernel are you using?
>   * Ideally this would be with one of RCNs Debian images, but if not,
> I'm interested in what you might have used.
>   * If you have done something with a Linux based system other than a
> BBB, I'd like to know about that too.
>   * What mesh routing protocol was used?  Batman, Babel/AHCP, HWMP, OLSR,
> ...
>   * Steps to configure the mesh network and gateway.
>   * Did you use 802.11s?  If so, presumably using the 802.11s support in
> the kernel?
>   * WiFi chipset that was used (presumably supporting mesh mode).  SOFTMAC
> or HARDMAC?
>
> I have researched the topic fairly extensively and can probably set
> something up via trial and error myself.  Prior to diving into that, I
> wanted to see if anyone has already done some work with wireless mesh
> networking and BBB (or something else) and would be willing to share their
> experience and knowledge!
>
> Thanks in advance.
>
> Cheers,
>
> ba
>
>  --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Send Raw or hex data out the serial port using bonescript

2014-11-19 Thread George Lu
On Wed, Nov 19, 2014 at 3:26 PM, John Mladenik 
wrote:

> I need to be able to send raw data out of the serial port using Bonescript
> command b.serialWrite.I set up an HTML Bonescript to send data and then
> looked on the logic analyzer to see what bit pattern is sent out.  The
> pattern is always the ASCII value of the character whether the variable is
> a text or number.
>
> Does anyone know how to pass to b.serialWrite a value so that the UART
> outputs that value?
>
> so I want to have
>
> var port = '/dev/ttyO2'; // set UART port
> var data = 0x55 ;
> b.serialWrite(port, data );
>
> and for the bit pattern coming out of the UART to be  01010101
>
> I tried using String.fromCharCode(data);  but this only works for values
> up to 127 (0x7F) since that is all ASCII goes to.   This must not support
> extended ASCII?
>
> here is my html/javascript to test this functionality
>
> 
> 
>
> Uart Byte:
> 
> SEND
>
> 
> 
> 
> 
> function uartWr() {
> var b = require('bonescript');
> var port = '/dev/ttyO2'; // set UART port
> var data = document.getElementById('value').value;
> // set baud rate and buffer size
> var options = {
> baudrate: 9600
> };
>
> b.serialWrite(port, data );
>
> }
> 
>
> 
> 
>

I recall BoneScript uses https://github.com/voodootikigod/node-serialport
for serial port interface.
You should be able to send raw binary with b.serialWrite(port, [0x55]);
Data should be a buffer (http://nodejs.org/api/buffer.html).

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Send Raw or hex data out the serial port using bonescript

2014-11-24 Thread George Lu
On Sat, Nov 22, 2014 at 7:49 PM, John Mladenik 
wrote:

> So it worked but once I let the board sit not being powered overnight it
> stopped working.   Do you or anyone know how to get the UART2 working and
> stay working once powered down and then turned back on?
>

Once power cycled, you would need to start up the program again so that the
serial port could be properly opened for writing. I would have the
bonescript code in, say, /home/debian/doSerial.js, and run that
automatically on every reboot. There are a number of ways to do this. One
quick way is try to add a line in /etc/crontab to run this command on
@reboot:

@reboot rootcd /home/debian &&
NODE_PATH=/usr/local/lib/node_modules && export NODE_PATH && doSerial.js

Assuming you are using debian image, /dev/ttyO1 and /dev/ttyO2 have
"rw-rw---" as their permission. So you either need to run it as root or add
your desired user to the dialout group to be able to write to these serial
interfaces.

If doSerial.js crashes for any reason, you could use a process monitor to
restart it. Supervisord <http://supervisord.org/>, forever
<https://github.com/nodejitsu/forever>, pm2 <https://github.com/Unitech/pm2>,
are some options to explore.


>
> On Wednesday, November 19, 2014 3:44:26 PM UTC-8, George Lu wrote:
>>
>> On Wed, Nov 19, 2014 at 3:26 PM, John Mladenik 
>> wrote:
>>
>>> I need to be able to send raw data out of the serial port using
>>> Bonescript command b.serialWrite.I set up an HTML Bonescript to send
>>> data and then looked on the logic analyzer to see what bit pattern is sent
>>> out.  The pattern is always the ASCII value of the character whether the
>>> variable is a text or number.
>>>
>>> Does anyone know how to pass to b.serialWrite a value so that the UART
>>> outputs that value?
>>>
>>> so I want to have
>>>
>>> var port = '/dev/ttyO2'; // set UART port
>>> var data = 0x55 ;
>>> b.serialWrite(port, data );
>>>
>>> and for the bit pattern coming out of the UART to be  01010101
>>>
>>> I tried using String.fromCharCode(data);  but this only works for
>>> values up to 127 (0x7F) since that is all ASCII goes to.   This must not
>>> support extended ASCII?
>>>
>>> here is my html/javascript to test this functionality
>>>
>>> 
>>> 
>>>
>>> Uart Byte:
>>> 
>>> SEND
>>>
>>> 
>>> 
>>> 
>>> 
>>> function uartWr() {
>>> var b = require('bonescript');
>>> var port = '/dev/ttyO2'; // set UART port
>>> var data = document.getElementById('value').value;
>>> // set baud rate and buffer size
>>> var options = {
>>> baudrate: 9600
>>> };
>>>
>>> b.serialWrite(port, data );
>>>
>>> }
>>> 
>>>
>>> 
>>> 
>>>
>>
>> I recall BoneScript uses https://github.com/voodootikigod/node-serialport
>> for serial port interface.
>> You should be able to send raw binary with b.serialWrite(port, [0x55]);
>> Data should be a buffer (http://nodejs.org/api/buffer.html).
>>
>  --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] How to keep Python pgm running if putty disconnects ???

2014-07-17 Thread George Lu
On Thu, Jul 17, 2014 at 8:49 AM,  wrote:

> I'm using a BBB Debian (2014-03-27) and I monitor temps with a Python
> prrogram.
> Currently, while developing, I access the BBB from a local PC via Putty.
> Various things happen which disconnect my PC session - this morning a
> dialog box said "A software error cause the connection to unexpectedly
> close" (or something similar) and temps were not logged for about 4 hours.
> In the future, I plan to post some "keep alive" timestamp and check that
> from another machine which will alert me if the monitor box stops
> posting... but thats another issue.
>
> My question is:  How can I have a session that runs on the BBB --- that I
> can connect to if I want to see it's progress - AND will always be running
> regardless of a remote session?
> I'm sure I could launch the Python pgm at bootup, or crontab, but I don't
> know how I could see output from that session.
>
> It might be that I don't really need to see the output continually - as
> I've become accustomed to via the Putty window.  Thats just a comfort
> issue.
> If I wanted to see recent temps, I'm sure I could write another Python pgm
> to analyze the log file and show me recent data.
>
> Your ideas appreciated.
> thx
> jaymer...
>

You could run your program in a screen (http://www.gnu.org/software/screen/)
or byobu (http://byobu.co/) session, which will stay alive after your putty
got disconnected. Both could be easily apt-get installed on BBB debian. I
prefer byobu myself.

And if you start your python program @reboot from crontab, you could pipe
the output to a file (program >> outputfilename). You could use "tail -f
 outputfilename" to monitor the output when you connect with putty.

George

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Re: Availability - how come nobody has any BeagleBone Black to sell?

2014-01-29 Thread George Lu
http://www.adafruit.com/products/1278

FYI, I have received email notification that adafruit.com has BBB in stock
as of this morning.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [beagleboard] PPS Support from GPIO

2014-01-31 Thread George Lu
Hi Lee and selsinork, I have gotten PPS working on a BBW A3 with 3.8.13
kernel following your guidance.

I am using the Adafruit Ultimate GPS
breakout.
I had used UART4 for serial connection to GPS and gpio1_31 (P8#20) for PPS.
This pin is actually not a good choice now (I think it conflicts with emmc
on BBB), but I had made the PCB this before BBB was released. Lee's choice
of 1_29 should be better.

The gpio1_31 should be coded as gpio2_31 in the overlay as selsinork
pointed out. Very confusing indeed.

I had removed assert-rising-edge after seeing
herethat the default is already
for rising edge. Below is my BB-PPSGPIO overlay
source:

/dts-v1/;

/plugin/;

/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";
part-number = "BB-PPSGPIO";
version = "00A0";


/* state the resources this cape uses */
exclusive-use =
/* the pin header uses */
"P8.20",/* gpio1_31   */
/* the hardware ip uses */
"gpio2_31";


fragment@0 {
target = <&am33xx_pinmux>;
__overlay__ {
gps_pps_pins: pinmux_gps_pps_pins {
pinctrl-single,pins = <
0x84 0x27 /* P8.20 gpio1_31 (63) */
 >;
};
};
};

fragment@2 {
 target = <&ocp>;
__overlay__ {
pps {
 compatible = "pps-gpio";
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&gps_pps_pins>;
gpios = <&gpio2 31 0 >;
};
};
};
};


root@beaglebone:/home/debian# cat /sys/devices/bone_capemgr.8/slots
 0: 54:PF---
 1: 55:PF---
 2: 56:PF---
 3: 57:PF---
 4: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4
 6: ff:P-O-L Override Board Name,00A0,Override Manuf,cape-bone-proto
root@beaglebone:/home/debian# echo BB-PPSGPIO >
/sys/devices/bone_capemgr.8/slots
root@beaglebone:/home/debian# cat /sys/devices/bone_capemgr.8/slots
 0: 54:PF---
 1: 55:PF---
 2: 56:PF---
 3: 57:PF---
 4: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4
 6: ff:P-O-L Override Board Name,00A0,Override Manuf,cape-bone-proto
 7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-PPSGPIO

dmsg shows:
[ 1270.098465] bone-capemgr bone_capemgr.8: part_number 'BB-PPSGPIO',
version 'N/A'
[ 1270.098571] bone-capemgr bone_capemgr.8: slot #7: generic override
[ 1270.098596] bone-capemgr bone_capemgr.8: bone: Using override eeprom
data at slot 7
[ 1270.098619] bone-capemgr bone_capemgr.8: slot #7: 'Override Board
Name,00A0,Override Manuf,BB-PPSGPIO'
[ 1270.098760] bone-capemgr bone_capemgr.8: slot #7: Requesting part
number/version based 'BB-PPSGPIO-00A0.dtbo
[ 1270.098784] bone-capemgr bone_capemgr.8: slot #7: Requesting firmware
'BB-PPSGPIO-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[ 1270.113904] bone-capemgr bone_capemgr.8: slot #7: dtbo
'BB-PPSGPIO-00A0.dtbo' loaded; converting to live tree
[ 1270.114270] bone-capemgr bone_capemgr.8: slot #7: #2 overlays
[ 1270.115369] of_get_named_gpio_flags exited with status 63
[ 1270.118823] pps pps0: new PPS source pps.14.-1
[ 1270.118993] pps pps0: Registered IRQ 207 as PPS source
[ 1270.119105] bone-capemgr bone_capemgr.8: slot #7: Applied #2 overlays.

And now we have the captured PPS assert events, showing the count changes
by one every second:

debian@beaglebone:~$ date; cat /sys/class/pps/pps0/assert
Fri Jan 31 18:31:40 UTC 2014
1391193100.002460136#133
debian@beaglebone:~$ date; cat /sys/class/pps/pps0/assert
Fri Jan 31 18:31:41 UTC 2014
1391193101.002453270#134
debian@beaglebone:~$ date; cat /sys/class/pps/pps0/assert
Fri Jan 31 18:31:42 UTC 2014
1391193102.002467910#135

Robert Nelson's 3.8.13 kernels in the recent test images already have
pps-gpio client enabled. It works just fine with this overlay. I could not
read the NMEA sentences on UART4 using BB-UART4 overlay though. I will try
Lee's overlay for UART4.

Thanks!

George



On Fri, Jan 31, 2014 at 6:57 AM, Lee Armstrong  wrote:

> You were right the first time, thank you!
>
> It is very confusing isn't it!
>
>
>
> On 30 January 2014 at 14:34:07, selsin...@gmail.com 
> (selsin...@gmail.com)
> wrote:
>
> On 29/01/14 21:29, Lee Armstrong wrote:
> > However isn't it actually pin 31?
> >
> > pin 31 (44e1087c) 0027 pinctrl-single
>
> that's pin 31 in the pinmux table, it's not a simple relationship from
> pinmux number to gpio number
>
> on my kernel there's 141 items in that list, but there are only 118 gpios.
> gpios0,1&2 have 32 pins, gpio 3 only has 22... according to the datasheet
> anyway...
>
> If you look in the kernel source.. arch/arm/mach-omap2/mux34xx.c seems to
> contain the mapping, although I can't say I understand how to read it
>
> > I'm still not getting a PPS input there but am wondering now if the GPS
> needs a fix before it even outputs one at all.
>
> Probably, most gps modules I've encountered only output pps after you get
> a fix, the EM406A I'm using is like that. Depends on the module, but yo

Re: [beagleboard] How to write attachInterrupt in BoneScript in details.

2014-03-05 Thread George Lu
You could use button.watch() in onoff in place of attachInterrrupt.  See
https://www.npmjs.org/package/onoff.


On Wed, Mar 5, 2014 at 2:00 PM,  wrote:

> Hi, forks!!
>
> I have some questions about attachInterrupt.
>
> I saw the topic
> attachInterrupt contents called on startup and stop without event triggered
> https://groups.google.com/forum/#!topic/beagleboard/bhacfUnNJYM
>
> Q1:
> I think one of solution is check actual button has pushed or not.
>
>  b.attachInterrupt(inputPin, true, b.FALLING, interruptCallback);
>  function interruptCallback() {
> if (b.digitalRead(inputPin)===1) return; // Is the real button pushed?
> or not?
>  
>
> But in this case, the function interruptCallback tightly depend on
> hardware ,so I can't reuse it call from another functions (for example WEB
> interrupt logic).
> It seems not good solution.
>
> Is there any solution more smart?
>
>
> Q2:
> http://beagleboard.org/Support/BoneScript/attachInterrupt/
>
> I guess the result of handler can determine to interruptCallback  execute
> or not.
> But when my function my*handler  *always return true,  interruptCallback  
> never
> called...
>
>  b.attachInterrupt(inputPin, myhandler, b.FALLING, interruptCallback);
>  function myhandler(){
>   return true;
>  }
>
> Could you tell me what is wrong, Please!
>
> Thanks.
>
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [beagleboard] Starting processes (via bash script?) automatically at boot?

2015-02-06 Thread George Lu
You could use crontab to run your program on startup. Let's say your
executable program (or shell script that calls your program) is
/home/debian/helloworld. In /etc/crontab, add this line to
run /home/debian/helloworld as user 'root' after startup :

@reboot  root   /home/debian/helloworld


On Fri, Feb 6, 2015 at 5:07 PM, Teiresias  wrote:

> I'm extremely new to linux programming (as a matter of fact to any OS
> programming, I'm more used to to-the-metal Atmel, etc. programming). A few
> of my other posts probably indicate this, haha.
>
> Luckily, the application I'm trying to develop doesn't look like it will
> require changing pin muxing any longer (which I still can't quite wrap my
> head around) and instead I'll just use the available i2c and UART1 and
> UART2 (which I know how to enable easily by editing uEnv.txt).
>
> However, my system needs to start and then just automatically run some
> processes when the system boots.  These are all compiled c-code.  I need to
> run an initialization program that sets up some shared memory locations,
> and then start a number of processes that run concurrently using these
> shared memory resources and interface with the i2c and UART interfaces.
>
> I've got the code figured out to do most of this, but I'm still a bit
> unclear on how to actually get this to run automatically at boot.  Is there
> some way to just get a bash script to execute at boot where I can simply
> call my process names from there?
>
> Any help would be greatly appreciated.  Thanks.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.