Not sure if there is a better way, but you could do a readTextFile, store the
data in a string, append your data to the string, then writeTextFile the data
to a file. This would work well until your text files start getting large,
after which things will start getting slow and memory-intensive.
2 Ideas:
- Create a log file which you output your debug info to using file.write(). You
can use the tail Linux command to see the latest data.
-Have the program output using print as usual. At boot up, you have your
program set as a background job. Whenever you want to monitor the program, you
That looks like an inconvenient, non-standard protocol to interpret. Since
there is no clock line, you can't rely on edges to signal the start of each
bit(other than the start of the datagram). However the timing of the packet
is consistent, so I would approach it based on timing. The data
Since the ADC reference voltage is 1.8V, the 1800 refers to the voltage
range of ADC in millivolts. You should see a resolution of 1800mV/4096 =
0.4394mV.
I guess it depends on your perspective whether or not raw means the
actual 12-bit ADC register value or the ADC voltage itself.
On
It's correct. The ~ in root@beaglebone:~# indicates that you are in the
home directory, which starts out empty. if you do cd .., ls then you
will see the standard directories.
On Friday, September 19, 2014 7:51:46 PM UTC-7, jackson...@gmail.com wrote:
All,
I'm using the beagle bone to get
I believe that PRUSpeak(https://github.com/deepakkarki/pruspeak/) makes use
of remoteproc. I haven't made the transition yet, but I'm definitely
curious about it. The complexity of implementing remoteproc seems much,
much greater than using UIO or /dev/mem mapping. What is the benefit of
using
There are more than a few comparison articles online. Some I've bookmarked
in my journey are:
http://makezine.com/magazine/how-to-choose-the-right-platform-raspberry-pi-or-beaglebone-black/
http://www.doctormonk.com/2013/07/raspberry-pi-vs-beaglebone-black.html
Mixing digitalWrite and analogWrite could be the problem. Try disabling the
buzzer by setting the PWM duty cycle to 0:
if(data =='stop'){
b.analogWrite(S_13,0,3);
console.log('stop buzz');
};
On Wednesday, September 3, 2014 12:14:31 PM UTC-7, keo@gmail.com wrote:
I
If you have an editor-of-choice(eg Sublime Text), there's a handy trick for
using it remotely without needing to constantly save-upload your files.
This works on Windows using WinSCP:
1) Open WinSCP and connect to the BBB
2) Create the empty source file on the BBB(main.c for example)
3) Right
I think Miguel's logging idea is the best way to know exactly what's going
on. Some additional thoughts:
Based on code, if your program stops receiving data but still runs then it
is probably infinitely blocking at arduino.readline(). The fact that you
don't see output from print(line) or
, 2014 10:29:12 PM UTC-7, Michael M wrote:
I think Miguel's logging idea is the best way to know exactly what's going
on. Some additional thoughts:
Based on code, if your program stops receiving data but still runs then it
is probably infinitely blocking at arduino.readline(). The fact
John, that's an even better trick.. thanks! I'll try it out for my next
project.
On Tuesday, September 2, 2014 9:04:16 PM UTC-7, john3909 wrote:
From: Michael M mmcda...@gmail.com javascript:
Reply-To: beagl...@googlegroups.com javascript:
beagl...@googlegroups.com javascript:
Date
I think there are too many unknowns, and a lack of benchmarks on the BBB,
to give you a yes or no answer.
My suggestion would be to get a BBB. (Or if you only have one chance, get
the fastest embedded system you have budget for). Then you develop your
algorithm until it works. If it's slow,
Yes, this sounds like a perfect use case for the BeagleBone Black, a
webcam, and OpenCV. Take a look at
this:
http://derekmolloy.ie/beaglebone/beaglebone-video-capture-and-image-processing-on-embedded-linux-using-opencv/
A few things to consider:
-Depending on the duration and resolution of
You'll have two separate programs for the BBB(socket server) and the
computer(socket client). In your case, the BBB will program will infinitely
loop, waiting for messages. The computer will be event-driven, only sending
messages when a gesture has been detected. You should google C++ sockets
If you can, maybe avoid the file on harddisk and talk directly to the BBB.
The simplest way might be to create a socket connection over WIFI... you
could have the BBB host the socket server and connect to it from the host
computer using the exposed IP and port. You can then send data through
3:06:15 PM UTC-7, William Hermans wrote:
Looks good so far Michael. I was considering doing something similar, but
with Nodejs. For the learning experience, and still may.
On Wed, Aug 20, 2014 at 11:36 AM, Michael M mmcda...@gmail.com
javascript: wrote:
Hi all,
I made a browser-based
Hi all,
I made a browser-based app or writing and debugging PRU assembly programs.
It's designed to be more user-friendly compared to the current PRU
debuggers available.
More Details and installation instructions are on Github:
https://github.com/mmcdan/visualpru
It's still in the early
via SSH I'm not sure
if I can do this via Terminal in the OS desktop
El jueves, 7 de agosto de 2014 18:04:39 UTC-5, Michael M escribió:
I want to know first, beacause I've never worked with python on beagle
bone black, if I can make a small Human Machine Interface, that runs in the
beagle
I want to know first, beacause I've never worked with python on beagle
bone black, if I can make a small Human Machine Interface, that runs in the
beagle bone, and also which operative system is the adequate to work with
this.
-Yes you can. Anything you can do on a linux desktop/laptop, you can
Since you have a working driver, you can:
1)Identify the events begin emitted from your input device using: cat
/proc/bus/input/devices
2)Capture the data from the input device using: ls /dev/input to find
your device's event output then cat the appropriate file for the actual
data.
You may
without data loss. If you keep this in mind when
coding you'll be safe.
The assembler is rather simple in parsing the input. It probably just
compares the parsed 32-bit result with the allowed range (0-255).
-- Bas
On 1-7-2014 1:02, Michael M wrote:
Hi Bas,
You are right
Hello,
I've written a PRU program which manipulates bits in one of the registers.
The program does not compile with PASM when I use the ~ operator.
Setting multiple bits works:
or r3.b0, r3.b0, 13// Set bit 3
but clearing multiple bits does not:
and r3.b0, r3.b0, ~(13)//
Thanks for the info Serge!
I did some more tests, and it looks like applying the DTO will set some
parameters of the pin, but not others. You always need to manually set the
state using the files in order to get a guaranteed state. For example,
let's say that I set a pin to be an Input w/ a
The changes I make to the pinmux in the Device Tree Overlay are not
reflected when I read the files in /sys/class/gpio or probe the physical
pin itself. However, the change IS reflected when I read
/sys/kernel/debug/pinctrl/44e10800.pinmux/pins. The OS is the Rev C Debian
build.
Setting the
25 matches
Mail list logo
