[beagleboard] Is BoneScript more trouble than its worth?

[Wally Bkg]

I've been playing with BBB and BBG at the "top level" that I'd expect a 
beginner to start with -- plug it in the USB port and use the Cloud9 IDE 
stuff.  My BBB is an old A5A revision and it seems to have some issues, so 
lets ignore it for now,

Seems most of the BoneScript stuff either throws apparently "harmless" 
errors (disconcerting to a newbie, and all I can do is wave my hands and 
say "it doesn't matter") or they throw apparently severe errors and just 
don't work.

I've setup a virgin BBG and did apt-get update and apt-get upgrade to get 
the "latest" into the 4GB eMMC.  Is this not enough?   

I find it somewhat disconcerting that the page
http://192.168.7.2/bone101/Support/BoneScript/updates/
Is still talking about Angstrom, and apparently hasn't been updated since 
the original BBW.  Is this the root of my BoneScript problems?

My BBG BoneScript is not totally FUBAR as the three "Run" buttons to turn 
on, off, and restore the usr leds seems to work:
http://192.168.7.2/bone101/Support/BoneScript/
But the link to analogWrite() is where things go wrong.


My system:
cat /etc/dogtag
BeagleBoard.org Debian Image 2015-03-01

lsb_release -a
No LSB modules are available.
Distributor ID:Debian
Description:Debian GNU/Linux 7.9 (wheezy)
Release:7.9
Codename:wheezy

uname -a
Linux beaglebone 3.8.13-bone71.1 #1 SMP Wed May 20 20:13:27 PDT 2015 armv7l 
GNU/Linux


In the webpage:
http://192.168.7.2/bone101/Support/BoneScript/analogWrite/

I get the expected message:
Your board is connected!
BeagleBone Green S/N BBG115091153 running BoneScript 0.2.4 at 192.168.7.2

Is this a "bad" version of Bone-script?

I was most interested in the analogWrite() bonescript because the node-red 
doesn't offer access to the PWM yet, and I wanted to do an Arduino-like 
cyclic LED dimming demo.

When I click the "Run" button I get:
Bonescript: connected
Bonescript: initialized
x.value = true
x.err = undefined

And the voltage at J9_P14 stays 0V, instead of the expected ~2.2V for the 
0.7 width output.


So then  I opened up Cloud9 IDE and in the Workspace go to 
Cloud9->examples->Grove_BBG->blinkled.js
when I run it I get:
debugger listening on port 15454
error: Failed to find devicetree fragment: bspm_P9_14_f
info:  0: 54:PF--- 
 1: 55:PF--- 
 2: 56:PF--- 
 3: 57:PF--- 
 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
 5: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART2


/usr/local/lib/node_modules/bonescript/my.js:57
if(slot[0]) {
   ^
TypeError: Cannot read property '0' of null
at Object.exports.load_dt 
(/usr/local/lib/node_modules/bonescript/my.js:57:20)
at exports.create_dt.handler 
(/usr/local/lib/node_modules/bonescript/my.js:93:21)
at ChildProcess.exithandler (child_process.js:656:7)
at ChildProcess.emit (events.js:98:17)
at maybeClose (child_process.js:766:16)
at Socket.ChildProcess.spawn.stdin (child_process.js:979:11)
at Socket.emit (events.js:95:17)
at Pipe.Socket._destroy._handle.onread [as close] (net.js:466:12)


I did set-up node-red again and it was uneventful,  I see the BBB 
installation instructions have been updated from the last time I did it.  
Worked better since it now mentions mkdir -p ~/.node-red before doing npm 
install of the node-red-node-beaglebone.  Node-red has a few rough edges 
(most notably saving & loading "nodes" that you've wired up, and no easy 
way to stop or "undeploy" a buggy one), but its easy to show a newbie how 
to get started and do basic stuff.

 

-- 
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.

[beagleboard] Unexpected failure

[Fred Patrick]

I just got a new BeagleBone Black and have flashed Debian 7.9 successfully. 
I was connected with USB to a Mac running OSX 10.10.5 Yosemite. I was using 
a 5v 2A power adapter and a TP-Link TL-WN722N wifi adapter. I used both 
with another BBB for about a year with no problems. I was in the process of 
adding the Adafruit wifi-reset script to the startup services when the 
BeagleBone died. Nothing else was connected. 

Now whenever I try to boot the system, there is a single momentary flash of 
of the power light and thats it. 

Is this likely just bad luck on my part? Is anyone else having this problem?

Thank you
Fred Patrick

-- 
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] Debian: re-partition 2Gb eMMC for a little more space?

[William Hermans]

Ah darn it forgot to mention that in addition to apt-get clean, if you run
apt-get autoremove you *may* also gain some space from removing packages
that were installed as prerequisite for other packages, that may no longer
be needed.

On Wed, Jan 6, 2016 at 2:00 PM, William Hermans  wrote:

> I concur with Robert. If you're just logging temperature, use a console
> image, and in fact, if you strip them down, you can get down to just above
> 100M with a reasonable amount of tools installed as well. ~160M including
> Nodejs, and express.
>
> On Wed, Jan 6, 2016 at 12:56 PM, Robert Nelson 
> wrote:
>
>> On Wed, Jan 6, 2016 at 1:04 PM,   wrote:
>> > Hello,
>> > I have an old A5C board that I'm bringing up for a temperature logger.
>> I
>> > flashed 4.1.13-ti-r38 last night, did the usual "apt-get update",
>> installed
>> > the Atheros firmware, configured the WiFi, and now I'm out of space. I
>> can't
>> > even use "apt-get remove" at this point.  I'd like to keep the MMC as a
>> > removable device so I can grab the data once in a while, so putting the
>> boot
>> > image is less desirable.
>> >
>> > Is there anyway to re-partition the eMMC card so I can have some
>> breathing
>> > room to remove some of the unneeded packages?
>>
>>
>> sudo apt-get clean
>>
>> Otherwise, the A5C has only 2GB on the eMMC..
>>
>> If your only doing a temperature logger, just grab the smaller
>> "console" image: (around 300MB-ish installed)
>>
>>
>> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> https://rcn-ee.com/
>>
>> --
>> 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] Debian: re-partition 2Gb eMMC for a little more space?

[William Hermans]

I concur with Robert. If you're just logging temperature, use a console
image, and in fact, if you strip them down, you can get down to just above
100M with a reasonable amount of tools installed as well. ~160M including
Nodejs, and express.

On Wed, Jan 6, 2016 at 12:56 PM, Robert Nelson 
wrote:

> On Wed, Jan 6, 2016 at 1:04 PM,   wrote:
> > Hello,
> > I have an old A5C board that I'm bringing up for a temperature logger.  I
> > flashed 4.1.13-ti-r38 last night, did the usual "apt-get update",
> installed
> > the Atheros firmware, configured the WiFi, and now I'm out of space. I
> can't
> > even use "apt-get remove" at this point.  I'd like to keep the MMC as a
> > removable device so I can grab the data once in a while, so putting the
> boot
> > image is less desirable.
> >
> > Is there anyway to re-partition the eMMC card so I can have some
> breathing
> > room to remove some of the unneeded packages?
>
>
> sudo apt-get clean
>
> Otherwise, the A5C has only 2GB on the eMMC..
>
> If your only doing a temperature logger, just grab the smaller
> "console" image: (around 300MB-ish installed)
>
>
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> 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] Debian: re-partition 2Gb eMMC for a little more space?

[Robert Nelson]

On Wed, Jan 6, 2016 at 1:04 PM,   wrote:
> Hello,
> I have an old A5C board that I'm bringing up for a temperature logger.  I
> flashed 4.1.13-ti-r38 last night, did the usual "apt-get update", installed
> the Atheros firmware, configured the WiFi, and now I'm out of space. I can't
> even use "apt-get remove" at this point.  I'd like to keep the MMC as a
> removable device so I can grab the data once in a while, so putting the boot
> image is less desirable.
>
> Is there anyway to re-partition the eMMC card so I can have some breathing
> room to remove some of the unneeded packages?


sudo apt-get clean

Otherwise, the A5C has only 2GB on the eMMC..

If your only doing a temperature logger, just grab the smaller
"console" image: (around 300MB-ish installed)

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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.

[beagleboard] Re: MT7601 WiFi adapter troubles in Debian Jessie

[sandradkenny]

script I generated for Debian Wheezy based on Ubuntu forums to be run at 
the command line:

echo << EOF >> script.sh
#!/usr/bin/env bash
sudo apt-get install linux-headers-amd64 build-essential git
git clone https://github.com/porjo/mt7601.git
sudo mkdir -p /etc/Wireless/RT2870STA/
cd ./mt7601/src && make && sudo make install && sudo cp RT2870STA.dat 
/etc/Wireless/RT2870STA/
sudo modprobe mt7601Usta
EOF

chmod 700 script.sh
./script.sh

You might need slightly different for linux headers. Absolutely class 
because I bought the dongle from hong kong for about €2.56 including 
delivery but only worked for me on Windows up to today.

On Sunday, December 28, 2014 at 2:25:34 AM UTC, Mark Copper wrote:
>
> I updated the "m7601Usta" module following Robert Nelson's procedure in 
> the beagleboard  "Jessie Snapshot content" thread of October 28.
>
> Module installation appears to be successful:
> # lsmod | grep mt
> mt7601Usta757197  0
>
> The adapter is plugged into hub (the Ralink)
> # lsusb
> Bus 001 Device 004: ID 0d8c:000c C-Media Electronics, Inc. Audio Adapter
> Bus 001 Device 003: ID 148f:7601 Ralink Technology, Corp. 
> Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> But the device does not appear under "ifconfig -a" or "iw dev" or "ip a"  
> (just to be sure)
>
> I'm running Debian Jessie on the BBB:
> # uname -a
> Linux beaglebone 3.14.26-ti-r43 #1 SMP PREEMPT Tue Dec 23 20:10:13 UTC 
> 2014 armv7l GNU/Linux
>
> Am I missing anything obvious?
>
> 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.

[beagleboard] Debian: re-partition 2Gb eMMC for a little more space?

[tim . limon]

Hello,
I have an old A5C board that I'm bringing up for a temperature logger.  I 
flashed 4.1.13-ti-r38 last night, did the usual "apt-get update", installed 
the Atheros firmware, configured the WiFi, and now I'm out of space. I 
can't even use "apt-get remove" at this point.  I'd like to keep the MMC as 
a removable device so I can grab the data once in a while, so putting the 
boot image is less desirable.

Is there anyway to re-partition the eMMC card so I can have some breathing 
room to remove some of the unneeded packages?

Here's the stats:

root@beaglebone:~# *df -h*
Filesystem  Size  Used Avail Use% Mounted on
udev 10M 0   10M   0% /dev
tmpfs98M  4.4M   94M   5% /run
/dev/mmcblk1p1  1.8G  1.8G 0 100% /
tmpfs   245M 0  245M   0% /dev/shm
tmpfs   5.0M 0  5.0M   0% /run/lock
tmpfs   245M 0  245M   0% /sys/fs/cgroup
/dev/mmcblk0p1   15G   24K   15G   1% /media/card
root@beaglebone:~#
root@beaglebone:~# *fdisk -l*

Disk /dev/mmcblk0: 14.9 GiB, 15931539456 bytes, 31116288 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xfb28685a

Device Boot Start  End  Sectors  Size Id Type
/dev/mmcblk0p1   2048 31115263 31113216 14.9G  c W95 FAT32 (LBA)

Disk /dev/mmcblk1: 1.8 GiB, 1920991232 bytes, 3751936 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x

Device Boot Start End Sectors  Size Id Type
/dev/mmcblk1p1 * 2048 3751935 3749888  1.8G 83 Linux

Disk /dev/mmcblk1boot1: 1 MiB, 1048576 bytes, 2048 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mmcblk1boot0: 1 MiB, 1048576 bytes, 2048 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
root@beaglebone:~#
root@beaglebone:~#


Thank you fo the help,
--Tim

-- 
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.

[beagleboard] Re: Can get DCAN0 going but not DCAN1

[prototive]

thank you so much for clarifiation m8!
been trying to get my BB Green to communicate CAN for too long now, 
actually ERROR- passive vs. active led me to right track here!

Den torsdag 8 augusti 2013 kl. 21:10:04 UTC+2 skrev drew@gmail.com:
>
> While I can't help solve the problem, maybe I can provide some more 
> information to help debug it, as it appears I'm seeing a similar problem.
>
> I am merely trying to get DCAN1 up and running, and have followed numerous 
> tutorials, etc (including the one Scott points out) to get the DCAN1 
> running, and I can't get it to send data.  I've not tried receiving, 
> because if I can't send then I don't care if I can't receive at this point. 
>  
>
> The interesting thing I notice is when I do cansend, I get data spewing 
> back and forth on the wire.  I've tried this with a CANBus controller as 
> well as just tying DCAN1_TX and DCAN1_RX together.  If I disconnect one of 
> the Tx/Rx lines, then the spewing stops.
>
> Here is what I do:
>
> *reboot*
>
> canconfig can0 ctrlmode bitrate 125000 triple-sampling on
> canconfig can0 start
> cansend can0 051#11.22.33.44.55.66.77.88
>
>
>
> This results in no Tx bytes as reported by ifconfig or ip -details 
> -statistics link show can0.  The ip link shows that the can state is 
> ERROR-PASSIVE which from my exhaustive research says that there is an 
> active error, and it will listen, but not transmit.  Previous to this, the 
> state as ERROR-ACTIVE (which is supposedly OK).
>
> I'd love to figure out what the problem we're running into is.
>
> My system details:
> Angstrom base image with 3.8.13 kernel image
> I've also built an image from the Ubuntu directions and tried that with no 
> difference (I've not built the whole image as I don't have a 4GB SD card 
> yet).
>
> Thanks in advance for any help that can be provided,
> Drew Hintz
>
> On Wednesday, August 7, 2013 9:42:05 PM UTC-4, Scott Heighway wrote:
>>
>>
>> I've been following the examples provided here ( 
>> http://www.aero-box.co.uk/beaglebone-black#TOC-CANbus ) and have managed 
>> to get both CAN modules to show up, but I can only get CAN0 to transmit and 
>> receive.  Nothing untoward shows up in dmesg, and I can bring up the 
>> devices; its only CAN1 that doesn't work.  Does anyone have any suggestions 
>> to figure out what could be wrong?
>>
>> I'm running Ubuntu 13.04 (07-22), and have the following modifications to 
>> my am335x-bone-common.dtsi file:
>>
>> *snip*
>> dcan0_pins: pinmux_dcan0_pins {
>> pinctrl-single,pins = <
>> 0x178 0x12  /* ic2c.sda_dcan0_rx, 
>> SLEWCTRL_FAST | INPUT_PULLUP | MODE2 */
>> 0x17C 0x32  /* ic2c_scl.dcan0_rx, 
>> SLEWCTRL_FAST | RECV_ENABLE | INPUT_PULLUP | MODE2 */
>>  >;
>> };
>>
>> dcan1_pins: pinmux_dcan1_pins {
>> pinctrl-single,pins = <
>> 0x180 0x12  /* uart1_rxd.d_can1_tx, 
>> SLEWCTRL_FAST | INPUT_PULLUP | MODE2 */
>> 0x184 0x32  /* uart1_txd.d_can1_rx, 
>> SLEWCTRL_FAST | RECV_ENABLE | INPUT_PULLUP | MODE2 */
>>  >;
>> };
>> *snip
>>
>> *snip*
>> uart2: serial@48022000 {
>> status = "disabled";
>> };
>>
>> dcan0: d_can@481cc000 {
>> status = "okay";  // Switch on DCAN0
>> pinctrl-names = "default"; // Apply default 
>> pinmuxing
>> pinctrl-0 = <&dcan0_pins>;
>> };
>>
>> dcan1: d_can@481d {
>> status = "okay";  // Switch on DCAN1
>> pinctrl-names = "default"; // Apply default 
>> pinmuxing
>> pinctrl-0 = <&dcan1_pins>;
>> };
>> *snip*
>>
>> *snip*
>> &i2c2 {
>> status = "disabled";
>> pinctrl-names = "default";
>> pinctrl-0 = <&i2c2_pins>;
>> *snip*
>>
>>
>> And my /proc/net/dev file:
>>
>> Inter-|   Receive| 
>>  Transmit
>>  face |bytespackets errs drop fifo frame compressed multicast|bytes   
>>  packets errs drop fifo colls carrier compressed
>> lo:   0   0000 0  0 0   
>>  0   0000 0   0  0
>>   eth0: 2351960   13013000 0  0 0   
>>  32410 388000 0   0  0
>>   usb0:  4742719333000 0  0 0 
>>  4156896   15720000 0   0  0
>>   can0:   0   0000 0  0 0   
>>  0   0000 0   0  0
>>   can1:   0   0000 0  0 0   
>>  0   0000 0   0  0
>>
>

Re: [beagleboard] Can we turn BeagleBone Black to an FM receiver ?

[Graham]

You will need a hardware tuner-downconverter in front of the BBB.
But these are available for less than $25.

Google: "SDR dongle" for a lot of hardware front end alternatives

Things like:
https://www.adafruit.com/products/1497

http://www.rtl-sdr.com/buy-rtl-sdr-dvb-t-dongles/


The things you find are usually intended for Windows computers used for the 
back end signal processing.
So you are then facing a port of the back end demodulation software onto 
the BBB.

If you Google "SDR dongle Linux" you will find some existing Ubuntu ports.

But a BBB that was not doing anything else could likely handle the 
processing load.  An X-15 could do it for sure, with the on-board DSP.

But the first guy to make it work on a BBB is going to have to do some real 
work.

--- Graham

==

On Wednesday, January 6, 2016 at 10:06:13 AM UTC-6, Charles Steinkuehler 
wrote:
>
> On 1/6/2016 7:19 AM, amul...@gmail.com  wrote: 
> > 
> > Now, the main question is, can we make BeagleBone Black as an FM 
> receiver 
> > using only software without using any external FM module ? 
>
> Only software?  No. 
>
> I've worked on very minimal radios using just a couple of (FPGA) I/O 
> pins and some discrete parts.  Basically, you use a differential input 
> of the FPGA as a comparator, build a delta-sigma ADC out of it, and 
> directly sample the radio signal.  This actually works OK for lower 
> frequencies, but there's no way you can do this with just software and 
> GPIO pins at ~100 MHz FM frequencies. 
>
> You might be able to do something similar with the timer hardware on 
> the BBB if you have an outboard down-converter.  You might even be 
> able to use another timer for the reference frequency output.  But 
> you're still going to need at least a handful of external discrete 
> parts to do filtering/mixing. 
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

-- 
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] Can we turn BeagleBone Black to an FM receiver ?

[Charles Steinkuehler]

On 1/6/2016 7:19 AM, amulya...@gmail.com wrote:
> 
> Now, the main question is, can we make BeagleBone Black as an FM receiver 
> using only software without using any external FM module ?

Only software?  No.

I've worked on very minimal radios using just a couple of (FPGA) I/O
pins and some discrete parts.  Basically, you use a differential input
of the FPGA as a comparator, build a delta-sigma ADC out of it, and
directly sample the radio signal.  This actually works OK for lower
frequencies, but there's no way you can do this with just software and
GPIO pins at ~100 MHz FM frequencies.

You might be able to do something similar with the timer hardware on
the BBB if you have an outboard down-converter.  You might even be
able to use another timer for the reference frequency output.  But
you're still going to need at least a handful of external discrete
parts to do filtering/mixing.

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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] Can we turn BeagleBone Black to an FM receiver ?

[Przemek Klosowski]

On Wed, Jan 6, 2016 at 8:19 AM,   wrote:

> I was going through and article about Turning RPi into an FM transmitter .
> It consists of just putting a wire on the GPIO4 of Pi which works as an
> antenna and run the python script.
>
> The software uses the hardware of RPi which generates spread spectrum clock
> signals to create FM signals.

Right, and the way it works they use the spread spectrum feature to
programmatically modulate the frequency of the PWM signal away from
103.3 MHz.
Since FM modulation works by changing the base, aka carrier, frequency
in proportion to the amplitude of the audio signal you're sending,
this happens to behave like a FM modulated signal that is decoded by a
FM radio.
It's a neat hack---the spread spectrum feature works fast enough to
change the frequency of the PWM signal at audio (kHz) rates---it'd be
impossible to change it fast enough by twiddling the PWM frequency
through its configuration registers.

As far as I know, there's no similar spread-spectrum feature on BBB,
so this won't work on BBB---although I wonder if something clever
could be done on a PRU.

>
> I dug out more on http://elinux.org/RPi_BCM2835_GPIOs and found out that
> GPIO4 's alternate functions include ARM_TDI and GPIO_GCLK.
>
> I want to know what does the ARM_TDI and GCLK mean.

You are looking at IO multiplexing. RPi and Beaglebone both can
connect multiple internal peripherals to output pins.
The FM feature uses a specific peripheral. It doesn't matter what
other peripherals are on alternate functions.

>
> Now, the main question is, can we make BeagleBone Black as an FM receiver
> using only software without using any external FM module ?

So now you're talking about FM receiver; neither BBB nor RPi has
hardware to receive FM. In theory, with fast enough ADC one could do
direct decoding but a) you'd probably need an antenna amplifier and b)
the available ADCs are nowhere near fast enough to digitize 100 MHz.
You could decode FM signals at carrier frequency 100KHz, probably :)

-- 
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] Enabling BBB PRUSS in dtb-rebuilder 3.14?

[Robert Nelson]

On Wed, Jan 6, 2016 at 9:39 AM,   wrote:
> Hi,
>
> I am getting exactly same issue. Did you find solution to this problem? How
> should I enable PRU?

Instead of randomly replying to an ancient message, why don't you
actually state your "error" and what you are trying to do..

hint...

This is fixed in 4.1.x/etc..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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] Enabling BBB PRUSS in dtb-rebuilder 3.14?

[anujamutalik]

Hi,

I am getting exactly same issue. Did you find solution to this problem? How 
should I enable PRU?

-Anuja

On Wednesday, 31 December 2014 01:27:59 UTC+1, Rick M wrote:
>
>
> > On Dec 30, 2014, at 16:13 , Robert Nelson  > wrote: 
> > 
> > They are actually enabled: 
> > 
> > 
> https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am33xx.dtsi#L761
>  
>
> Oh, I didn't see a status="okay" line, so I thought maybe they were 
> disabled. The problem I'm having is that /dev/uioX doesn't exist, and the 
> libprussdrv library I'm using is failing to open it (the host interrupt). 
>
> Instructions I've seen tell me to: 
>
> # modprobe uio_pruss 
> FATAL: Module uio_pruss not found. 
>
> But you can see, that's not found. What am I missing? Is that module not 
> in the distro by default? 
>
> Finally, it seems to fail to load the firmware: 
>
> > dmesg | grep remote 
>
> [2.780145]  remoteproc0: 4a334000.pru0 is available 
> [2.780159]  remoteproc0: Note: remoteproc is still under development 
> and considered experimental. 
> [2.780168]  remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and 
> backward compatibility isn't yet guaranteed. 
> [2.780439]  remoteproc0: failed to load rproc-pru0-fw 
> [2.788152]  remoteproc0: powering up 4a334000.pru0 
> [2.788228]  remoteproc0: request_firmware failed: -2 
> [2.799717]  remoteproc1: 4a338000.pru1 is available 
> [2.799731]  remoteproc1: Note: remoteproc is still under development 
> and considered experimental. 
> [2.799740]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and 
> backward compatibility isn't yet guaranteed. 
> [2.799968]  remoteproc1: failed to load rproc-pru1-fw 
> [2.805679]  remoteproc1: powering up 4a338000.pru1 
> [2.805751]  remoteproc1: request_firmware failed: -2 
> [2.879535]  remoteproc2: wkup_m3 is available 
> [2.879554]  remoteproc2: Note: remoteproc is still under development 
> and considered experimental. 
> [2.879563]  remoteproc2: THE BINARY FORMAT IS NOT YET FINALIZED, and 
> backward compatibility isn't yet guaranteed. 
> [2.880691]  remoteproc2: powering up wkup_m3 
> [2.883576]  remoteproc2: Booting fw image am335x-pm-firmware.elf, size 
> 219827 
> [2.884295]  remoteproc2: remote processor wkup_m3 is now up 
>
>
> -- 
> Rick Mann 
> rm...@latencyzero.com  
>
>
>

-- 
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] Using SPI in a kernel module

[John Syne]

> On Jan 5, 2016, at 5:19 PM, William Hermans  wrote:
> 
> OK, you have several options on how to implement this. First, look in 
> drivers/iio or drivers/staging/iio for example drivers that use SPI. If you 
> use the RT kernel, you will see latency of less than 1mS, but if this isn’t 
> good enough, then I recommend using the PRU to program the McSPI. For 
> examples of how to program the McSPI natively, look at Starterware for 
> example code. If you look on Github, the Starterware examples have been 
> ported to the PRU. 
> Regards,
> John
> 
> I'd actually recommend using the PRUs *OR* /dev/mem/ + mmap() if you need 
> anything better than 100-200ms. The RT kernels are pretty good at reducing 
> latency from what I've seen, but they still are not "perfect”.
/dev/mem/ + mmap() is always going to have more latency than kernel module 
because kernel code is executed at a higher priority that user space app. 

Regards,
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/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.

[beagleboard] Re: Where are the serial ttyO1,2,3,4?

[vamshi . gajjela]

Hi Folks,

I have added the following 

uart1_pins: pinmux_uart1_pins { 
pinctrl-single,pins = < 
0x170 0x30 /* (E15) uart0_rxd.uart0_rxd, PIN_INPUT | 
MUX_MODE0 */ 
0x174 0x00 /* (E16) uart0_txd.uart0_txd, PIN_OUTPUT | 
MUX_MODE0 */ 
>; 
};

uart2_pins: pinmux_uart2_pins { 
pinctrl-single,pins = < 
0x180 0x30 /* (D16) uart1_rxd.uart1_rxd, PIN_INPUT | 
MUX_MODE0 */ 
0x184 0x00 /* (D15) uart1_txd.uart1_txd, PIN_OUTPUT | 
MUX_MODE0 */ 
>; 
};

This worked for me


uart1: serial@44e09000 {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&uart1_pins>;
};

uart2: serial@48022000 {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&uart2_pins>;
};



On Tuesday, April 30, 2013 at 10:11:54 PM UTC+5:30, SKiAt wrote:
>
> Hi all
> today I received my first Black one revision A5A. 
>
> With my old Beaglebone A6A I was using 2 uart, so the first things I 
> checked out were the serial ports, and:
>
> - I didn't find the /dev/ttyOx nodes
> - I saw that there is no mode the pin muxing avaliable from 
> /sys/kernel/debug/omap_mux/...
>
> I have read about the auto muxing based on capes eeprom configuration and 
> stuff like this is it the only way? And if I don't need the display how can 
> I disable the hdmi drivers?
>
> Thanks 
> Luca
>

-- 
*The information contained in this communication is confidential and may be 
legally privileged.  It is intended solely for the use of the individual or 
entity to whom it is addressed and others authorized to receive it.  If you 
are not the intended recipient, you are hereby (a) notified that any 
disclosure, copying, distribution or taking any action with respect to the 
content of this information is strictly prohibited and may be unlawful, and 
(b) kindly requested to inform the sender immediately and delete any 
copies. *

-- 
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] Can we turn BeagleBone Black to an FM receiver ?

[Gerald Coley]

My suggestion is that read up on the processor. And there is no FM receiver
inputs on the processor.

http://www.ti.com/product/AM3358/technicaldocuments


Gerald

On Wed, Jan 6, 2016 at 7:19 AM,  wrote:

> Hello all,
>
> I was going through and article about Turning RPi into an FM transmitter
> 
>  .
> It consists of just putting a wire on the GPIO4 of Pi which works as an
> antenna and run the python script.
>
> The software uses the hardware of RPi which generates spread spectrum
> clock signals to create FM signals.
>
> I dug out more on http://elinux.org/RPi_BCM2835_GPIOs and found out that
> GPIO4 's alternate functions include ARM_TDI and GPIO_GCLK.
>
> I want to know what does the ARM_TDI and GCLK mean.
>
> Now, the main question is, can we make BeagleBone Black as an FM receiver
> using only software without using any external FM module ?
>
> Regards
>
> --
> 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.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/

-- 
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.

[beagleboard] Can we turn BeagleBone Black to an FM receiver ?

[amulya349]

Hello all, 

I was going through and article about Turning RPi into an FM transmitter 

 . 
It consists of just putting a wire on the GPIO4 of Pi which works as an 
antenna and run the python script. 

The software uses the hardware of RPi which generates spread spectrum clock 
signals to create FM signals. 

I dug out more on http://elinux.org/RPi_BCM2835_GPIOs and found out that 
GPIO4 's alternate functions include ARM_TDI and GPIO_GCLK. 

I want to know what does the ARM_TDI and GCLK mean. 

Now, the main question is, can we make BeagleBone Black as an FM receiver 
using only software without using any external FM module ?

Regards

-- 
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.

[beagleboard] Re: UART4 stopped working: did not get pins for uart4 error: -19

[gvk51]

To resolve the issue, I have added the proper pinctrl signals for the uart, 
I did this for uart0 & uart1

uart1_pins: pinmux_uart1_pins {
pinctrl-single,pins = <
0x170 0x30 /* (E15) uart0_rxd.uart0_rxd, PIN_INPUT | 
MUX_MODE0 */
0x174 0x00 /* (E16) uart0_txd.uart0_txd, PIN_OUTPUT | 
MUX_MODE0 */
>;
};

uart2_pins: pinmux_uart2_pins {
pinctrl-single,pins = <
0x180 0x30 /* (D16) uart1_rxd.uart1_rxd, PIN_INPUT | 
MUX_MODE0 */
0x184 0x00 /* (D15) uart1_txd.uart1_txd, PIN_OUTPUT | 
MUX_MODE0 */
>;
};

This worked for me

uart1: serial@44e09000 {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&uart1_pins>;
};

uart2: serial@48022000 {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&uart2_pins>;
};


On Wednesday, April 9, 2014 at 1:09:03 AM UTC+5:30, polloc...@gmail.com 
wrote:
>
> Hi,
> On my BBB I have a Serial RS-232 BeagleBone Cape (BB_BONE_SERL-03 Rev A1) 
> that I have jumpered for UART4. It works under Angstrom and was recently 
> working under Ubuntu 12.04 LTS. Now it is not working under Ubuntu. There 
> seems to be pin error which may be preventing it from loading.  I don't 
> know if this was caused by some configuration changes or not.  I haven't 
> been able to figure out what is causing the conflict. 
>
> How can I find and fix this problem? 
>
> Thanks for your help.
>
> Phil
>
> 
> Background Information:
>
> 1. This is not a hardware problem. I have tested the same cape board under 
> Angstrom and it works (a remote putty serial session receives the 
> transmission); however, nothing is received from Ubuntu:
>
> root@ubuntu-armhf:/home/ubuntu# echo hello > /dev/ttyO4
>
>
> Note: I also tested UART4 using another micro-cape board that was working 
> earlier - it also failed.
>
> 2. Some time ago I replaced /boot/dtbs/am335x-boneblack.dtb (decompiled, 
> modified, recompiled .dts) to enable UART4 (/dev/ttyO4):
>
> ...
> serial@481a8000 {
> compatible = "ti,omap3-uart";
> ti,hwmods = "uart5";
> clock-frequency = <0x2dc6c00>;
> reg = <0x481a8000 0x2000>;
> interrupts = <0x2d>;
> status = "okay";
> linux,phandle = <0x1b>;
> phandle = <0x1b>;
> };
> ...
> This was working under Angstrom and Ubuntu. 
>
> 3.  I tried restoring the original /boot/dtbs/am335x-boneblack.dtb and 
> used a .dtbo overlay for UART 4 - it still didn't work.
>
> 4. I scanned dmesg for config errors:
>
> ubuntu@ubuntu-armhf:~$ dmesg | grep -iE "uart|tty|error:"
>  
> [ 0.00] Kernel command line: console=ttyO0,115200n8 fixrtc 
> root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait
> [ 0.507160] omap_uart 44e09000.serial: did not get pins for uart0 error: 
> -19
> [ 0.507505] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP 
> UART0
> [ 1.218231] console [ttyO0] enabled
> [ 1.222660] omap_uart 481a8000.serial: did not get pins for uart4 error: 
> -19
> [ 1.230408] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 61) is a OMAP 
> UART4
>
> ubuntu@ubuntu-armhf:~$ dmesg | grep capemgr
>
> [ 1.314500] bone-capemgr bone_capemgr.9: Baseboard: 
> 'A335BNLT,0A5C,2513BBBK0965'
> [ 1.322289] bone-capemgr bone_capemgr.9: 
> compatible-baseboard=ti,beaglebone-black
> [ 1.354316] bone-capemgr bone_capemgr.9: slot #0: 'BeagleBone RS232 
> CAPE,00A1,Beagleboardtoys,BB-BONE-SERL-03'
> [ 1.392362] bone-capemgr bone_capemgr.9: slot #1: No cape found
> [ 1.429467] bone-capemgr bone_capemgr.9: slot #2: No cape found
> [ 1.466577] bone-capemgr bone_capemgr.9: slot #3: No cape found
> [ 1.472829] bone-capemgr bone_capemgr.9: slot #4: specific override
> [ 1.479431] bone-capemgr bone_capemgr.9: bone: Using override eeprom data 
> at slot 4
> [ 1.487466] bone-capemgr bone_capemgr.9: slot #4: 
> 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'
> [ 1.497595] bone-capemgr bone_capemgr.9: slot #5: specific override
> [ 1.504197] bone-capemgr bone_capemgr.9: bone: Using override eeprom data 
> at slot 5
> [ 1.512234] bone-capemgr bone_capemgr.9: slot #5: 
> 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
> [ 1.522697] bone-capemgr bone_capemgr.9: loader: before slot-0 
> BB-BONE-SERL-03:00A1 (prio 0)
> [ 1.531582] bone-capemgr bone_capemgr.9: loader: check slot-0 
> BB-BONE-SERL-03:00A1 (prio 0)
> [ 1.540465] bone-capemgr bone_capemgr.9: loader: before slot-4 
> BB-BONE-EMMC-2G:00A0 (prio 1)
> [ 1.549338] bone-capemgr bone_capemgr.9: loader: check slot-4 
> BB-BONE-EMMC-2G:00A0 (prio 1)
> [ 1.558137] bone-capemgr bone_capemgr.9: initialized OK.
> [ 1.563745] bone-capemgr bone_capemgr.9: loader: before slot-5 
> BB-BONELT-HDMI:00A0 (prio 1)
> [ 1.572511] bone-capemgr bone_capemgr.9: loader: check slot-5 
> BB-BONELT-HDMI:00A0 (prio 1)
> [ 1.594787] bone-cap

Re: [beagleboard] Re: Should I bitbang i2c ?

[Elaman Nazarkulov]

Hi again Mr. Christopher Hopwood ,i have changed your code,but i have some 
misunderstandings.How you assigned address,register,value.You have used 
0xbb format,but i need 0x,is it possible in PRU?

-- 
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.