Re: [beagleboard] I am getting "undefined reference" error while running cross-compiled Qt program in Beaglebone Black

[Przemek Klosowski]

On Sat, May 19, 2018 at 2:56 AM, Gunjan Vora  wrote:
> I have done cross-compilation to run Qt programs in Beaglebone Black. I am
> able to run widgets general programs but graphics related programs are
> getting errors as
>
> /mnt/bbb-rootfs/usr/local/bbb/include/QtGui/qcolor.h:290: error: undefined
> reference to `QColor::setNamedColor(QLatin1String)'

I think you're getting link-time errors during croscompilation---I
don't see any evidence that you were able to run anything.
Does this code compile in a native (non-cross) environment?
On my system qcolor.h seems to be provided by qt5-qtbase so you need
to have that in the cross-compilation environment.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgFRZXZ3cy3nGf%3D6m%2Bzs5BcxCH78u3e%2Bz6Lcv-MBDE9Z3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: How to Autorun application at the start up in BeagleBone

[Przemek Klosowski]

On Fri, Apr 13, 2018 at 9:07 AM,   wrote:
>
> /etc/rc.local directory not available
It's a file, not a directory. Just try it:

echo touch /tmp/testRClocal > /etc/rc.local

and reboot the system. You should see the newly created file
/tmp/testRClocal when you login into the running system.


> also write script file in rc5d ,rc3.d directory but not working.
What did you write into those files? which OS version are you running?
Need more detail to help you.
Most new systems use systemd rather than the old SysV /etc/rc* files,
so this may not work (but /etc/rc.local is actually emulated by
systemd so that should be OK).

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgEPWy9Nd%2BffMy%2BMr5917de%3DrYgRdR2%3D8LYRzcnY%2BP%2BUSQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB PRUs to emulate the ROM of Ford's Intel 8061/5 Microcontrollers

[Przemek Klosowski]

On Fri, Mar 16, 2018 at 9:28 AM, Grey, Chris UTC CCS <
chris.g...@automatedlogic.com> wrote:

>  Anyway, what I'm wanting to do is harness the power of the PRUs to speak
> to the onboard processor, a Ford-specific derivative of the 16-bit Intel
> 8096, called Intel 8061 (single bank) and 8065 (4-bank capable). They range
> from 12MHz to 24MHz clock cycles, where the 8-bit memory-bus runs as 1/3rd
> the processor clock. I want to, on the fly, emulate the PROM by sending the
> processor opcodes and operands that basically marshal data to/from the
> Cortex A8 and the EEC's processor's I/O thus relocating all the engine
> management logic to code running in the Cortex A8 and turning the EEC's
> processor into a slave co-processor that does nothing more than read the
> inputs, write to outputs, and inform of events (i.e. interrupts). The
> details of how that can be done, I think I have a good handle on.
>
I can't really help you (don't own a Ford and have no experience tuning
EECs) but this sounds pretty interesting. As I was thinking about it, I had
some questions.

 As far as I understand, the original EEC effectively runs a simple RTOS,
and probably can be thougt of as a bunch of coroutines that each serve some
engine management function: one might be receiving the crank angle sensor,
another would calculate the timing sequence for current external conditions
(temperature, RPM, etc), and yet another would activate external devices
such as the fuel injector and spark coil, based on this timing. To replace
the OEM EEC you'd need to know the details of all the components. After
all, if you exceed their design limits, you could damage the engine (e.g.
if you consistently pre-ignite and knock the engine to death).

You seem to suggest fooling the EEC by giving it synthetic data and
instructions; I think you are trying to use the pieces of code in the EEC
that are presumably correctly written for the engine by its manufacturer.
This is clever: you treat the EEC as a library interfacing to specific
low-level engine hardware. Another advantage is that you don't have to
replicate the weird analog electronic interfaces to various sensors and
actuators, but rather use the ones already present in the EEC.

Is my understanding correct so far?

How are you going to deal with the following issues:

   - I believe you still need to disassemble and reverse-engineer enough of
   the EEC code to identify those individual services, so that you can call
   them out
   - the individual services are probably inter-related, and may depend on
   each other rather than decomposing cleanly---e.g. the spark routine may
   depend on being called within 1ms of the fuel injector activation.
   - the OEM EEC code probably contains some integrity checks like
   watchdogs and inter-coroutine checks, so you will need to fake them 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgHX55EjZCs8LG4ykgzNvJMKP_GAi9e4xEe8KT8ayPfC1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Can BBB Wireless update image in a bare metal device like ARM M0+(has a bootloader)

[Przemek Klosowski]

On Mon, Mar 5, 2018 at 2:29 PM,  wrote:
>
>   I have a FRDM-KV11Z (dev board for NXP ARM M0+ MCU) and a Beaglebone
> black Wireless (ARM Cortex A8). I am trying to get a bootloader up and
> running in FRDM-KV11Z device so that we could program it using
> Beaglebone(BBB). The connection between BBB and KV11Z is using a RJ45
> cable. The communication protocol used is UART with RTS-only.
>
> My idea is to get the KV11Z device change its application whenever BBB
> gets a updated version of app code( from the cloud). Can you guide me
> through the development process I will need to follow to get this working?
> I appreciate if you could share any document related to this.
>
It's not clear what level of help you're asking for. Do you know how to
update firmware on your Freedom board from your desktop computer? I don't
remember the NXP bootloader details myself, but I don't think it's very
complicated, and probably uses a USB port, right? Basically, you'd do the
same thing from the BBB as you are doing when working on your desktop. The
BBB has USB host ports so you should be able to talk to FRDM's bootloader
as well as serial emulation over this USB.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgEY1_y4XdFF_Zus0W7VMsqiqqC%3DiFis1YHm3H4-Gqmdvw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Scheduling Latency of a Blocking UART Read.

[Przemek Klosowski]

On Mon, Jan 22, 2018 at 4:58 PM, Kenny Koller 
wrote:

>
>  the difference between when the serial port packet is transmitted and
> when the read call returns
>
Are you measuring the time to return to Python, or return from the read()
syscall?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgES9ep-pBDmLZHtvMF%2BbGDZE0TotWQ6N6pkk%2Bmz%3DA%2B9kQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] can the pru be executed when the beaglebone is off?

[Przemek Klosowski]

On Thu, Jan 18, 2018 at 10:11 AM, diego  wrote:

>
> I want to implement a low-cost energy process that is independent of the
> main CPU and runs when the Beaglebone is powered off. can  PRU the beagle
> to run alone even if it does not have the operating system.
>
> The PRU is conjoined with the main CPU, so  it won't run if you power the
beaglebone off, of course. You could probably put CPU to sleep but keep PRU
going, but I am not sure how much power will it save--you'd still have to
power memory and all the peripheral chips (PMIC etc).

In general, beaglebone is not exactly a low power platform.  If you want
long-running power efficient operation, you probably should use one of the
low-end microcontrollers like CortexM, or MSP430 to do the low energy part,
and maybe power up the Beaglebone to do the high-power stuff if you need it.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgHmc28VLKBpRgX2hFLYOXGMo4jj6jREboOx8kPMn%2BT_HQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Connection to Android tablet

[Przemek Klosowski]

On Tue, Jan 16, 2018 at 3:10 PM, M Pitman  wrote:

> I am collecting data from an ADC chip and saving the data to a file on the
> Beaglebone Black.  Currently the commands are sent through PuTTY on a PC
> using ssh and then sftp sends the file back which is manually loaded and
> displayed in a Qt program.  My desire is to be able to send a command to
> the Beaglebone directly from the Qt program on an Android tablet and have
> the Beaglebone send the resulting file back to the tablet.
>
> I ran Xserver on the tablet and did a remote display from the beaglebone
over the USB networking. The same USB network connection can remotely mount
file shares.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgF28Bwb0nRWoT30vfhK7rD%3D08FYkt63xeG0PL6g80bSuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Are these motors suitable?

[Przemek Klosowski]

Sorry, I didn't read your email carefully---you were talking about Blue,
which as Mark points out has power drivers that can drive motors, so forget
what I said below.

On Fri, Dec 1, 2017 at 3:00 PM, Przemek Klosowski <
przemek.klosow...@gmail.com> wrote:

> Beaglebone can source few dozen mA at 3.3V so you do need to put some
> controller to drive those motors.
>

> On Fri, Dec 1, 2017 at 2:47 PM, <renglun...@gmail.com> wrote:
>
>> Hi. I'm looking at a tank-track chassis that comes with motors included.
>> Are they suitable for being controlled by a Blue or should I use an
>> external motor controller? For what it's worth, I'm looking at powering the
>> Blue with a 1600mAh LiPo battery.
>>
>> Here are the details of the motors:
>>   Operating Voltage Range: 3~7.5V
>>   Rated Voltage: 6V
>>   Max. No-load Current(3V): 140 mA
>> <https://maps.google.com/?q=3V):+140+mA=gmail=g>
>>   Max. No-load Current(6V): 170 mA
>>   Max. Stall Current: 2.8 A
>>
>> Thank you. My apologies if this query is miscategorised.
>>
>>
>>
>> --
>> 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.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/beagleboard/5b983893-2918-4af7-8de4-333c839d2677%40googlegroups.com
>> <https://groups.google.com/d/msgid/beagleboard/5b983893-2918-4af7-8de4-333c839d2677%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgHXikpr9D2RrTkMKTq_cmj5GTTx5b1p%2BtHGP6i5wBi0uQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Are these motors suitable?

[Przemek Klosowski]

Beaglebone can source few dozen mA at 3.3V so you do need to put some
controller to drive those motors.

On Fri, Dec 1, 2017 at 2:47 PM,  wrote:

> Hi. I'm looking at a tank-track chassis that comes with motors included.
> Are they suitable for being controlled by a Blue or should I use an
> external motor controller? For what it's worth, I'm looking at powering the
> Blue with a 1600mAh LiPo battery.
>
> Here are the details of the motors:
>   Operating Voltage Range: 3~7.5V
>   Rated Voltage: 6V
>   Max. No-load Current(3V): 140 mA
> 
>   Max. No-load Current(6V): 170 mA
>   Max. Stall Current: 2.8 A
>
> Thank you. My apologies if this query is miscategorised.
>
>
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/5b983893-2918-4af7-8de4-333c839d2677%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgG8AN%3DTu2xD-NvFRooBC23Hx6ZMs1V1fX79uktrmsV22g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Rotary quadrature encoder

[Przemek Klosowski]

On Fri, Dec 1, 2017 at 1:53 PM,  wrote:

> Hi all
>
> I am developing on a beaglebone black and want to include a rotary knob to
> Control cursors on my display in user space etc.
>
> The selected quadrature encoder is here : http://www.mouser.com/ds/2/54/
> EL12T-777462.pdf
>
> I need to convert the pulses into a direction and count up or down
> accordingly so I plan on using an external low cost micro controller to
> count up or down and send the value out onto the bus.
>

Beaglebone has a hardware quadrature decoder called eQEP.
http://beagleboard.org/project/eqep_rotary_encoder.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgEUTizXm8Y%2BHpmbP_QhqwQCp6y6VOT2GOFGQBeNZYU-Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Possible for Beaglebone Blue to support a non-wireless Ethernet connection?

[Przemek Klosowski]

On Thu, Nov 16, 2017 at 1:02 PM, n feehan  wrote:
>
> However, my application streams this encoder data as fast as possible over
> UDP as an OSC message - when I use a wireless connection anywhere in my OSC
> path, I see the data rate reduce drastically, to the point where it's not
> suitable for my application.
>
> My questions are:
> * Does the Beaglebone Green support four quadrature encoder channels?
>
What resolution and speed do you need? I think you are asking about the
available QIP(?) pins but you can do quadrature decoding in software,
perhaps on PRUs, so you have three choices, ordered in decreasing
performance: hardware decoder, PRU-based software decoder, ARM-based GPIO
software decoder.


>
>
* Is there a way to get wired Ethernet (ie, cat5 cable) out of the
> Beaglebone Blue?
>
You can use USB ethernet dongles---will be slower than built-in but
probably less latency and jitter than wireless

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgHRQPXH--aZdg%3Dxj%3DWxksKy0XYON5WaZjr8QfTmztCu6Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] IOError: [Errno 13] Permission denied

[Przemek Klosowski]

It looks like your software is trying to write to
/opt/scripts/device/bone/capes/DLPDLCR2000/0524/tmp_header_Video Play
Test__Tue__Nov_14_2017__11_19_37__.xls
but you don't have permissions to that location. Can you confirm that, and
do you know how to address that problem? I'm asking because I don't know
how much do you know, so I'm not sure what advice to give.

On Wed, Nov 15, 2017 at 12:04 PM,  wrote:

> Hello,
>
> I am trying to play video using Beaglebone black and DLPDLCR2000EVM
>  projector.
>
> I can play video manually but when I try to play videos using python
> script I am getting an error like this
>
> debian@beaglebone:/opt/scripts/device/bone/capes/DLPDLCR2000$ python
> MplayerTest.py
>
> Traceback (most recent call last):
> File "MplayerTest.py", line 89, in 
> main()
> File "MplayerTest.py", line 59, in main
> datalog = DataLog(LogDir, Test_name)
> File "build/bdist.linux-armv7l/egg/dlp_lightcrafter/datalog.py", line 77,
> in __init__
> IOError: [Errno 13] Permission denied: '0524/tmp_header_Video Play
> Test__Tue__Nov_14_2017__11_19_37__.xls'
>
>
> the system isn't being allowed to write to the datalog file.
>
> any one please help me to fix this problem.
>
> thank you.
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/9681b811-a796-4c62-af23-492c8e26ae84%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgH4LahivKLOOKROmJ%3DDZ5vC_bV4kQ%3DwtN19SGT_uNx%2B9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Connecting two Beaglebone Blacks

[Przemek Klosowski]

On Sat, Nov 11, 2017 at 10:33 AM, Adam Saenz  wrote:

>
> 2) (Simple, not least expensive) Connect the two with a cheap ethernet
> switch.  This allows you to use built in command line functions to control
> and copy files (ssh, scp).  You can get a pretty inexpensive 5 port switch,
> which will maintain the ability to communicate to both BBBs.  TP-Link
> 5-Port Fast Ethernet Unmanaged Switch | Plug and Play | Desktop (TL-SF1005D)
> 
>  or Brash Networks 5-Port 10/100 Mbps Full Duplex Desktop Unmanaged Fast
> Ethernet Switch BN-FE105
> 
>  are
> a couple of ethernet switches that are under $10.  You could remove the
> boards from their enclosure if it makes it easier to repackage.  While not
> the least expensive it's really not that expensive either.
>
> 3) (Simple, not expensive) You could also connect both with an ethernet
> crossover cable. This would eliminate the need of a switch at the expense
> of losing the ability to connect to them externally via ethernet.  You do
> have the USB ports to connect to them I suppose.  This would allow you to
> use ssh/scp while eliminating the cost of the switch; simple to connect,
> inexpensive to implement. Buhbo 1 ft CAT5e Crossover Cable UTP, Gray Wire
> with Green Boot
> 
>


> I think Beaglebone Ethernet ports are MDI-X capable and have it turned on
> by default, so it should work to just connect two ports with any cable---if
> it's a strahght-through it should still negotiate the crossover. I don't
> have two beaglebones up currently to test that---can anyone confirm?
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgEF%3D0dEo%2BEHbpxSiirbfXqknB4uGbSmS2udiZVrmH_iNg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Best way for events between PRU and processor?

[Przemek Klosowski]

On Mon, Nov 6, 2017 at 9:09 PM, Ken Shirriff  wrote:


>
> My application, in case it's relevant: I'm building a network gateway with
> the PRU bit-banging a 3 megabit/second Ethernet.
>

Oh, I've seen that on your blog---the bridge from  bitbanged Alto 3Mbps to
a 10/100 ethernet---great work!

I've seen stuff about Remoteproc - is that the cool new technology? Its
mailboxes seem like a good model. However, I'd rather stick with the UIO
model instead of moving to a new kernel and rewriting everything if
possible.

Yeah, many people on this forum like UIO but it seems that Remoteproc is
the wave of the future: it's the default in newer kernels, etc.  UIO is of
course supported too, though.
I don't  know the answer to your question about synchronization, sorry; TJF
might know.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgE9deSJ6KqgN1pdZ5FAJgUYXZGtdo4M-JjUjqrVU%3Dv92A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Number of cycles when using C with PRU

[Przemek Klosowski]

On Mon, Nov 6, 2017 at 7:31 AM, Alek Mabry  wrote:

> Is there a particular way I am supposed to type out commands in asm(); ?
>
> asm() is not part of the C language definition, so the syntax depends on
the compiler you're using. I know GCC asm() better, but I assume you're
using TI clpru. I don't know of a good explanation of clpur asm(); there
are examples in texane's pru_sdk, so
 git clone https://github.com/texane/pru_sdk
and look in e.g. example/pruss_c/pru_hal.c

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgFY5OUmnMKpGmH8EXW12kDH%2BV7%2B_D1JOkh8%2Bvq22LhnNw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Number of cycles when using C with PRU

[Przemek Klosowski]

On Sun, Nov 5, 2017 at 10:07 AM, Alek Mabry  wrote:

>
>
> However in the C code, I have no idea what it's actually doing in assembly.
>
> Take a function for example, if I make a void function, will the assembler
> have a command that jumps to that part of the code, and then jumps back
> (adding two cycles or so), or will it just insert that code into wherever
> the function is called?
>
Well, the C compiler is just essentially generating machine code, just
lilke assembler---it's just that in assembler you specify the instructions,
so there's a simple 1:1 correspondence. You can force the compiler to list
the generated assembly and count instructions. You can also inject assembly
into your function using asm() compiler extensions; typically, you would
insert such assembly in the middle of a function. You can also call your C
functions from such assembly but it's a little tricky because you have to
observe the compiler ABI for register saving, stack operations and
parameter passing.

>
> Is there any way to force the C program to do something in a specified
> number of cycles, figure out how many cycles the C code is taking, or just
> write assembly for time-critical parts directly into the C code itself?
>
You can inspect the generated code, and count instructions to get the
cycles. You obviously can't force the compiler to use less cycles than it
already uses in an optimized compile, but you can in principle pad with
NOPs to artificially increase the cycle count.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgE6st78w%3DWSqc%3DviFEvdWvJ%2BPFP9oEWXjHxQ13cjMkq%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Is it a bug? control flow instruction of PRU does not make right comparison with negative number

[Przemek Klosowski]

On Monday, October 30, 2017 at 6:22:20 PM UTC-4, Lingwei Zhan wrote:
>
> I am trying to use QBLT to compare two numbers and found out when one 
> number is negative, the QBLT logic does not seem make right comparison. In 
> the following code, before QBLT, r3 =1-4 = -3, and r2 = 10, so r3 < r2, 
> then the code should execute MOV r3, -1. However, when I run this macro, r3 
> is set to 1. 
>
Anyone notices this issue? Any idea how to fix it?
>
 
I looked at the description and couldn't  find the specification, but 
perhaps the comparison treats the numbers as unsigned; the bit pattern of 
negative 2-complement number, interpreted as unsigned results in large 
numbers, so the comparison would come out the way you observe.

>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/07af40f3-a838-4f78-abab-cd07553a7687%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: ADC.setup() Prevents Python Program from Running at Autostart

[Przemek Klosowski]

On Tue, Sep 12, 2017 at 2:15 PM, Dennis Lee Bieber 
wrote:

>
> I'd be concerned about that print statement... Where is stdout
> going for a cron job?
>

Cron jobs aren't supposed to have output. If they do, it's mailed to the
owner of the job, presumably because they contain error messages for
debugging.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgFm2oC-Km10xVG4ZE__2kupaM_M-X1pNMoCvVBtLX4beQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: UART PWM Interference

[Przemek Klosowski]

Could you post a picture or drawing of your physical layout? I think the
evidence points to interference from the PWM circuit into the XBee. HOw
close physically are they?

On Fri, Sep 1, 2017 at 9:18 PM, <ojc...@gmail.com> wrote:

> Just tried adding the 1uF decoupling capacitor in parallel with the
> existing 0.1uF capacitor - it didn't decrease the high error rate.
>
> On Saturday, September 2, 2017 at 12:08:00 PM UTC+12, ojc...@gmail.com
> wrote:
>>
>> So tested all of that - see table below
>> The servo power supply is a QM12V5A
>> <https://hobbyking.com/en_us/quanum-12v-5a-7-2-25-2v-dual-output-ubec.html?___store=en_us>
>>  but
>> as seen below - even when this is not active, there is still a high error
>> rate.
>> Also, I am not opening and closing the serial port now - it stays open
>> throughout each test. I sent 100 messages for each test. Error rates are an
>> approximate guess.
>>
>> PWM running  Servo & Servo Power Supply Active Message Mode
>>Error Rate
>> Yes  Yes
>>RX-TX on loopback   0% - all good
>> Yes  No
>>   RX-TX on loopback   0% - all good
>> No   No
>>   RX-TX on loopback   0% - all good
>> Yes  Yes
>>BBB to PC via xbee  10 - 50% - no good
>> Yes  No
>>   BBB to PC via xbee  10 - 50% - no good
>> No   No
>>   BBB to PC via xbee   0% - all good
>>
>> I don't really know what to make of it except that the problem seems to
>> be somewhere either in the xbee?
>> The xbee is connected with a 0.1uF decoupling capacitor between +3.3V and
>> GND close to the xbee (~25mm length from xbee GND pin thru 0.1uF Cap to
>> xbee +3.3V pin)
>>
>> I see some people recommend a 1uF decoupling capacitor on the xbee -
>> maybe I'll try adding one of those in parallel with the 0.1uF cap.
>>
>>
>> On Friday, September 1, 2017 at 9:22:31 AM UTC+12, Przemek Klosowski
>> wrote:
>>>
>>>
>>>
>>> On Thu, Aug 31, 2017 at 3:13 PM, <ojc...@gmail.com> wrote:
>>>
>>>> Errors : yes garbage characters on the receiver side
>>>>
>>>> Cross-talk : so I have had a servo motor (powered from it's own ubec)
>>>> plugged in, however I thought that the ubec noise might be interfering, so
>>>> I tried running the PWM signal without any device attached (no servo ubec
>>>> running) and no pwm wire plugged into the beaglebone. But still had the
>>>> same issue.
>>>>
>>> OK--so now can you test by losing the open/close ,disconnecting the XBee
>>> and jumpering TX and RX and writing some simple text out and checking that
>>> you receive it back correctly, while running PWM. If you see errors, then
>>> maybe beaglebone is sensitive to crosstalk; if you don't then the crosstalk
>>> must be in the XBee. BTW, suppying the  servo from a separate power supply
>>> might not fully prevent interference--it could be kickback from driving the
>>> servo.
>>>
>>>>
>>>> --
>>>> 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...@googlegroups.com.
>>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>>> gid/beagleboard/eabc977d-e1ea-4c07-abf3-6193fe8c2518%40googlegroups.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.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/a13bf443-af43-4b66-9e7f-6610cb12d95a%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/a13bf443-af43-4b66-9e7f-6610cb12d95a%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgEjJvREmupAU54bHxOXeWKy5pRFCyDgFdjyVGettmiKjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: UART PWM Interference

[Przemek Klosowski]

On Thu, Aug 31, 2017 at 3:13 PM,  wrote:

> Errors : yes garbage characters on the receiver side
>
> Cross-talk : so I have had a servo motor (powered from it's own ubec)
> plugged in, however I thought that the ubec noise might be interfering, so
> I tried running the PWM signal without any device attached (no servo ubec
> running) and no pwm wire plugged into the beaglebone. But still had the
> same issue.
>
OK--so now can you test by losing the open/close ,disconnecting the XBee
and jumpering TX and RX and writing some simple text out and checking that
you receive it back correctly, while running PWM. If you see errors, then
maybe beaglebone is sensitive to crosstalk; if you don't then the crosstalk
must be in the XBee. BTW, suppying the  servo from a separate power supply
might not fully prevent interference--it could be kickback from driving the
servo.

>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/eabc977d-e1ea-4c07-abf3-6193fe8c2518%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgH35Dwx1e%3DdvTkWoABceNwZyRNPUte8noF8kfkMeidwNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] UART PWM Interference

[Przemek Klosowski]

On Thu, Aug 31, 2017 at 8:55 AM,  wrote:

> I'm generating a high rate of errors 10-20% when sending messages out via
> xbee connected to UART but only when I use PWM at the same time. I'm using
> UART2 and I've tested this behavior using all of the other available PWM
> pins. Below is a piece of simplified code that has a high error rate. When
> I comment out the section that turns the PWM signal on, the UART/xbee sends
> messages pretty much faultlessly.
>
> What is the fix to eliminate the high error rate?
>
> Whate are the errors? is it failures to ser.open() or failures in
ser.write()? I don't think you should be opening and closing the serial
port every time you want to write to it---is there a reason to do it that I
fail to see?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGpf5%2BvRcADwYxpTC%2B9H4Ozmsjt6-3yxhBK%3DzEsQYpKWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Can't login into my PC linux to develop my software

[Przemek Klosowski]

On Thu, Aug 17, 2017 at 4:53 AM, edgargrimme via BeagleBoard <
beagleboard@googlegroups.com> wrote:

I installed the kernal projekt for the BBB boar at my PC in the virtual
> Linux. The build of the kernal was canceled because the virtual Memory of
> 20GB was too small. After log out of the Linux, I stards the Oracle and the
> Linux again. But After send Password I see the Login window again. But I
> know that the build of the kernal fills the whole virtual disk.
>
It seems that you have a Windows box with a Linux VM. I think what happened
is that you filled out the disk image you created too small (not the
virtual memory, which is a different thing). While there are ways to  fix
that, I think you should start from scratch, delete the existing Linux VM
and create a new one giving it a larger disk.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGfxWeTJwue7Nka2TnGDFjitGWMShuJOpXjtaOZ1g0Lbg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] "no display name and no $display environment variable"

[Przemek Klosowski]

On Mon, Aug 14, 2017 at 6:23 AM, Harke Smits  wrote:

> Thank you very much, I keep on learning. My application now runs fine
> manually from XTerminal. Now I want  to run the application on boot. I
> figured out a systemd service is problably the way to go. I managed to
> define that (ac.service) and run it on boot up. I wrote:
> [Unit]
> After = grafical.target
> [Service]
> Type = idle
> ExecStart = /home/debian/eme {*etc to run Python script and make log
> file}*
> [Install]
> WantedBy=multi-user.target
>
> This sort of works but the application does not start: the log file gives
> the famous $DISPLAY error. I try to start my application last, so after the
> X server has been started. Maybe the "WantedBy" statement is wrong?
>
> The default setup in systemd starts the graphical target (btw, graphical
not grafical), and runs the login manager which then runs graphical desktop
manager which allows you to run your app.
The simplest way to handle it is to use the 'autostart' feature of the
display manager.
You can replace the whole setup in systemd by doing what you are doing, but
you have to take out the display/login manager.
You will also need to add
Environment="DISPLAY=:0"
and maybe XAUTHORITY to the [Service} section

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgHE3pQKSpH4gq1V2N_PJWiZVoZMFtgT0FjOUdGP_GtebQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] "no display name and no $display environment variable"

[Przemek Klosowski]

On Sat, Aug 12, 2017 at 6:13 AM, Harke Smits  wrote:

>  I have a stand alone Beagleboard system, keyboard/mouse connected via usb
> dongle. The system starts up normally, in grafics mode, I can invoke
> internet, no problem, LAN connected. Going to XTerm I get the linux prompt,
> still in grafics mode. A simple TKInter test program works.
>

OK, this is normal

Going to linux (XTRL/ALT/F1) I can invoke startx that brings me back were I
> came from: the grafics environment (LXDE).
>

Now, this is not needed---you already have X running, and you should run
all your GUI programs from the Xterm like your TKInter test above. There's
no need to 'go to linux' again. Perhaps you are mislead by the fact that
after you run a graphical program from the shell prompt in XTerm you don't
get the prompt back---but that's easily fixed by running the command in the
background by adding the ampersand to the end of the command:
tesst &

When you go to the text console and do startx again, you have dueling X
servers, and I am not sure what is the expected result of that. Don't do
that---use the original X by either running in background with &, or
creating a new xterm, or arranging for your app icon to be visible so that
you can run it by doubleclicking the icon.

Starting the TKInter test program from the Linux prompt gives me the famous
> error message in the title. In Xterminal "echo $DISPLAY" renders :1, in
> plain linux: a blank line.  Starting my application in XTerm gives a fully
> blank screen.
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgH_1i-X_bGVYUE9vEv2uBO%3DMZ3dzV08wU2ix%3D36c8_s0A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] "no display name and no $display environment variable"

[Przemek Klosowski]

On Fri, Aug 11, 2017 at 6:33 AM, Harke Smits  wrote:

> Hello Learned group,
>
> I have a BBB with Debian version 2017-03-19, the latest release as far as
> I know, with a 4D systems display. I have made a Python script using
> TkInter, running fine on another BBB system with an older Debian version.
>
OK, so you are interacting with your BBB directly, not from another
computer via SSH or serial, right?


> I made a simple testscript using TkInter as well. Running the testscript
> form XTerm or UXTerm (what is the difference?) works: a simple window pops
> up.
> Running the same from Debian bash directly displays the well known error
> above. I googled a lot but no answer found yet.
>
What do you mean by 'from the debian bash'? Normally, you're sitting in
front of a graphical desktop (i.e. running the X server or Wayland)
displaying a terminal emulator (e.g. XTerm) that runs a shell (e.g. bash).
The shell command (e.g. xclock) starts the process that issues X11 commands
that go to the current $DISPLAY and show up as windows.
If you're not running the X server, i.e. sitting at the raw text terminal
console (all black screen with white text), you cannot and will  not see
graphics.

The older system with similar software runs fine from autostart. Maybe I
> need to do here as well? I can not find autostart in the lastest Debian
> version: it must be in a different directory that I know of.
> Finally: if I run the original script (running fine on the older system) I
> just get a blank screen and system halts.
>
If you want to use your system in graphics mode you should autostart X.
Usually it is done by asking it to go to the graphical run state (5 in the
old sysV init scripts, graphical.target in systemd)
For debugging, you can type 'startx' to start X manually.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgEwLf4sHO_iA%2BwGg3-8YCNjy%3DJL5OZxv4prH5bPLn0Y9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: OpenGL support for Beaglebone Black

[Przemek Klosowski]

On Mon, Aug 7, 2017 at 12:21 AM, sajeevan k  wrote:

> Hi all,
>
> Please provide help on using OpenGL with Beaglebone Black.
>

OpenGL has both hardware-supported and software implementations. If you're
planning to do something ambitious with your graphics, you need the
hardware drivers, which are proprietary and a little tricky (depend on
particular kernel version, etc). What are you trying to accomplish, what
did you try so far and what was the result of your attempts?

>
>
> Thanks & Regards,
> Sajeevan.K
>
> On Thursday, August 3, 2017 at 10:19:45 AM UTC+5:30, sajeevan k wrote:
>>
>>
>> Hi all,
>>
>> I have been using Linaro Tool chain and sysroot for cross compiling and
>> building my Qt applications for Beaglebone Black Rev C with debian image
>>
>> Cross Compile Tool chain used - 
>> gcc-linaro-4.9.4-2017.01-x86_64_arm-linux-gnueabihf
>>
>> Sysroot used - sysroot-eglibc-linaro-2017.01-arm-linux-gnueabihf.
>>
>> Does this arrangement support OpenGL?
>>
>> Is there any sysroot available for Beaglebone Black with installed OpenGL
>> ES packages ?
>>
>>
>> Thanks & Regards,
>> Sajeevan.K
>>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/658d1bf1-6d97-4d3d-a51c-840691301374%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGwE-O_ZDB7sRwd%3Di--9pUNA7jz%2B0%3DPQXzTLystbrEY-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Running bbb without emmc memory chip (physically, unsoldered)

[Przemek Klosowski]

are you aware that the eMMC chip is a ball-grid package? It's possible to
unsolder it, of course, with skill and hot-air repair station. I am not
sure if the boot sequence stops on failing to detect the eMMC presence ; I
suspect it's possible to force the SD boot using the usual keypresses that
work with eMMC present.

On Mon, Aug 7, 2017 at 4:03 PM,  wrote:

> Hello,
>
> Is there any way to physically extract the emmc memory chip and boot
> successfully the Angstrom linux distribution just/only from microSD card ?
>
> Do you have any advice for this problem ?
>
> Thank you in advance.
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/113c5509-d42a-477f-9d63-788a84bad3bf%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgFP3e541TC7aB9OZko5G1dqi3yR%2BQ3FVjO9pphe5TsshQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Touch on LCD Chipsee (BBB-EXP-C) stopped respond

[Przemek Klosowski]

It's possible that your palm deposits water or body oils and confuses the
resistive sensors. Can you try wiping the display with a paper
towel,perhaps sligtly moist with alcohol?

On Tue, Aug 8, 2017 at 5:04 AM, Radovan Chovan  wrote:

> So, now I have figured I can reproduce same problem with rezistive display
> from 4D Systems (BBB revC and Debian Wheezy(not Jessie)), when I touch
> display with my palm.
>
> But command
> sudo /etc/init.d/lightdm restart
>
> doesn't help at all. Display reboot with java application autostart lasted
> 20 seconds, but touch didn't still respond. When I touched this resistive
> display, I cannot still accomplish to start touch again after many tries
> with palm and finger touches.
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/d8d8d1a8-5d77-4854-9f90-dc683212%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgFiB%3DCpv441TGCdMLqpuw%3D5SF%3DMdo0%3DgEysqxmnfjseBQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] C66x resource scheduling

[Przemek Klosowski]

On Mon, Jun 26, 2017 at 7:16 AM, MDX  wrote:

> By firmware you mean C program code?
>
I don't know what I can assume about the context of your question, so
please forgive me if guess wrongly and explain things that are obvious to
you or, conversely, talk over your head---please clarify in response.
You asked about coordination and partitioning of DSP coprocessors, which to
me implies  a unified system that manages both the main CPU and the
coprocessors on a similar plane. This is not how Linux sees the
coprocessors: while the CPU cores are indeed managed as an ensemble by the
kernel, the coprocessors are seen as peripheral resources. Linux kernel may
help loading them with their binary firmware, and starting and stopping
them, but you need to write all the synchronization primitives yourself.
The DSPs (and PRUs, etc) will be running their own code but will not have
the usual set of Linux system calls (unless you somehow implement them
yourself in your firmware). You can write the DSP/PRU code in their
respective assembler, or in the C variant understood by the DSP/PRU C
compiler, which is different than the C compiler used by the main CPU.
The newer kernels provide more functionality via the RemoteProc subsystem,
but it's just a way of managing high-level stuff like firmware loading,
starting/stopping, and communication with the coprocessors. You still can't
manage the computational tasks homogenously, e.g. moving them forth and
back between the CPU and coprocessors---instead, you need to split up
processing tasks between the CPU and coprocessors, write the code, deploy
and start the binaries, and communicate and synchronize their operation.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgHNub4EUOPnsSbVdTKQZqfEbJDh5ztKPwD5EjWPQXHn0Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BB Blue with single pulse encoder input

[Przemek Klosowski]

On Fri, Jun 23, 2017 at 10:05 AM, Clark Sann  wrote:

> Since you don’t care about direction, for now, you might try hooking the
> encoder to just the A channel.


If the decoder is in quadrature mode, this probably won't work---it needs
the B channel signalling to disambiguate the direction, so I think the
counter will not change. This is just my guess based on general knowledge,
so I may be wrong---check it for yourself.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgF8b1KVXTRh%2B3qw_Gg1RjQHhtV74TK1r_fXGizWruBs5Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Time sync PRU with ARM

[Przemek Klosowski]

probably the simplest thing would be to provide a hardware signal to a GPIO
pin that all PRUs are busy-looping on; this should provide a 5ns resolution.

On Fri, Jun 9, 2017 at 1:23 PM,  wrote:

>
> I am trying to time sync a couple of beaglebone black PRUs to each other.
>
> I have ptp running on my boards and so I have time synced my Linux user
> spaces but cannot figure out a way to time sync the user space with the PRU.
>
> I want to do this so i can turn the "real time" hardware constraints that
> PRU supplies into actually real time.
>
> Trying to control the Fast I/O pins in synchrony.
>
>
>
> Any thoughts or suggestions?
>
> 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.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/50568dbc-e5e2-4c21-8acf-e33fa80bf4e2%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgEAqE1zuig1URQBRdLUA%2BY2MwuSig9Pebdx%3Dt8vu0848Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] smartctl and sdcard

[Przemek Klosowski]

On Tue, May 30, 2017 at 10:49 AM, Micka <mickamus...@gmail.com> wrote:

> I'm able with the PC to use the command smartctl to get info on my SDCard
> with the protocol SMART.
>
OK, it looks like I missed something. What context are you seeing this in?
USB smart card reader, I suppose?
Like I said, the USB-to-whatever bridge you're using has to support SMART
protocol; there are even some USB-ATA bridges  that fail to do so, so maybe
the USB-SD/MMC bridge on BBB doesn't do that either.
I only used high-level tools like skdump/smartctl---never wrote
SMART-reading code like your example below. Does this code work on a
standard x86 platform where, as you say, smartcll talks to your SD card?


> I found a lot of subject on this topic, and I'm working on this piece of
> code for the moment:
>
> int ret = 0;
> struct mmc_ioc_cmd idata;
> memset(, 0, sizeof(idata));
> memset(ext_csd, 0, sizeof(__u8) * 512);
> idata.write_flag = 0;
> idata.opcode = MMC_SEND_EXT_CSD;
> idata.arg = 0;
> idata.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_ADTC;
> idata.blksz = 512;
> idata.blocks = 1;
> mmc_ioc_cmd_set_data(idata, ext_csd);
>
> But no result for the moment!
>
>
> Le mar. 30 mai 2017 à 15:49, Przemek Klosowski <
> przemek.klosow...@gmail.com> a écrit :
>
>> SMART protocol is defined for ATA interface, and it is translated over
>> USB interface by most but not all USB-ATA bridges. I have never seen it
>> implemented for SD cards. Historically, it makes sense: SD card firmware is
>> just a tiny block management layer, although of course there's no
>> fundamental reason why it  couldn't be expanded to provide some of the
>> internal information via SMART---but it has never been done AFAIK.
>>
>> On Tue, May 30, 2017 at 8:17 AM, Micka <mickamus...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I wanted to know if someone successfully used the command smartctl with
>>> the sd card ?
>>>
>>>
>>> It could be so usefull to know the state of the sdcard, the remaining
>>> life, etc !
>>>
>>> --
>>> 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.
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/beagleboard/CAF%2BMRtnD2qk7RHc6rxzuX9DRT0kNE30
>>> -kO1vKRBAzw%3D%2B-FZ6yw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtnD2qk7RHc6rxzuX9DRT0kNE30-kO1vKRBAzw%3D%2B-FZ6yw%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>> 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.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/beagleboard/CAC%3D1GgHV050he1CYE2mJ%3D3KHgyPpLez8-Z%3Dn_
>> TFgD8xVR4KK6w%40mail.gmail.com
>> <https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgHV050he1CYE2mJ%3D3KHgyPpLez8-Z%3Dn_TFgD8xVR4KK6w%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>> 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.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/CAF%2BMRtm7eBZTajzhdFcT_32h7r%2Bq9kEYKehk23gcCs8HB5PsEg%
> 40mail.gmail.com
> <https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtm7eBZTajzhdFcT_32h7r%2Bq9kEYKehk23gcCs8HB5PsEg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgHVgCXYm6Z3vCeh5RA4aOUwysJR0TdJp1xv5drLx7V_PQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Help with Cross Compile of first HelloWorld App

[Przemek Klosowski]

On Wed, May 31, 2017 at 6:23 AM, ee14mtech11049 via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> here what does dec 221812 hex 36274 represents?
>
>
>   text   databssdechex filename
 211304   2732   7776 221812  36274 HelloBeagle.elf

text segment size ( 211304) plus data segment size (2732) plus BSS/zeroed
segment size (7776) equals the total program size 221812, which written as
a hex number is 0x36274


On Thursday, April 10, 2014 at 4:50:47 AM UTC+5:30, RV9Flyer wrote:
>>
>> I'm a newbie and this is my first post.
>>
>> I just got started with building my first HelloWorld style app to test
>> the cross-compile capabilities of Eclipse/CDT, The app compiles
>> successfully and generate the expected HelloBeagle.elf executable. However,
>> when I transfer it to my beagle and attempt to run, I get an "Illegal
>> instruction" error.
>>
>> I've watched every video I could find (Thanks Derek Malloy) and I still
>> can't find the reason for the error. Obviously it's not generating the
>> right code base, but the build output does show that it it aimed for the
>> cortex-a8 processor which I believe is correct for the beaglebone black.
>>
>> I would appreciate any suggestions or ideas!!
>>
>> Thanks
>>
>> *Here is my environment info and build output:*
>>
>> *Build Environment:*
>> Windows 7
>> Eclipse Kepler SR2
>> CDT
>> GNU ARM Eclipse Plug-in
>> MinGW
>>
>> *Beaglebone Black:* (Angstrom Distro)
>> Linux beaglebone 3.8.13 #1 SMP Wed Sep 4 09:09:32 CEST 2013 armv7l
>> GNU/Linux
>>
>> *Build output:*
>> 16:11:12  Build of configuration Debug for project HelloBeagle 
>> make pre-build main-build
>> arm-none-eabi-gcc --version
>> arm-none-eabi-gcc.exe (GNU Tools for ARM Embedded Processors) 4.8.3
>> 20140228 (release) [ARM/embedded-4_8-branch revision 208322]
>> Copyright (C) 2013 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>> PURPOSE.
>>
>>
>> Building file: ../src/HelloBeagle.cpp
>> Invoking: Cross ARM C++ Compiler
>> arm-none-eabi-g++ -mcpu=cortex-a8 -O0 -fmessage-length=0 -fsigned-char
>> -ffunction-sections -fdata-sections -Wall  -g3 -MMD -MP
>> -MF"src/HelloBeagle.d" -MT"src/HelloBeagle.d" -c -o "src/HelloBeagle.o"
>> "../src/HelloBeagle.cpp"
>> Finished building: ../src/HelloBeagle.cpp
>>
>> Building target: HelloBeagle.elf
>> Invoking: Cross ARM C++ Linker
>> arm-none-eabi-g++ -mcpu=cortex-a8 -O0 -fmessage-length=0 -fsigned-char
>> -ffunction-sections -fdata-sections -Wall  -g3 -Xlinker --gc-sections
>> -Wl,-Map,"HelloBeagle.map" --specs=rdimon.specs -Wl,--start-group -lgcc -lc
>> -lc -lm -lrdimon -Wl,--end-group -o "HelloBeagle.elf"  ./src/HelloBeagle.o
>>
>> Finished building target: HelloBeagle.elf
>>
>> Invoking: Cross ARM GNU Create Flash Image
>> arm-none-eabi-objcopy -O ihex "HelloBeagle.elf"  "HelloBeagle.hex"
>> Finished building: HelloBeagle.hex
>>
>> Invoking: Cross ARM GNU Print Size
>> arm-none-eabi-size --format=berkeley "HelloBeagle.elf"
>>text   databssdechex filename
>>  211304   2732   7776 221812  36274 HelloBeagle.elf
>> Finished building: HelloBeagle.siz
>>
>>
>> 16:11:28 Build Finished (took 16s.236ms)
>>
>>
>> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/7fd10f76-e2e1-4e3b-a928-1baa94a6c5a6%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgEhxVaAMfP3t0PNUwaVPBem6Q6G4ozQzjwmJz0OeZYN-A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] smartctl and sdcard

[Przemek Klosowski]

SMART protocol is defined for ATA interface, and it is translated over USB
interface by most but not all USB-ATA bridges. I have never seen it
implemented for SD cards. Historically, it makes sense: SD card firmware is
just a tiny block management layer, although of course there's no
fundamental reason why it  couldn't be expanded to provide some of the
internal information via SMART---but it has never been done AFAIK.

On Tue, May 30, 2017 at 8:17 AM, Micka  wrote:

> Hi,
>
> I wanted to know if someone successfully used the command smartctl with
> the sd card ?
>
>
> It could be so usefull to know the state of the sdcard, the remaining
> life, etc !
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/CAF%2BMRtnD2qk7RHc6rxzuX9DRT0kNE30
> -kO1vKRBAzw%3D%2B-FZ6yw%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgHV050he1CYE2mJ%3D3KHgyPpLez8-Z%3Dn_TFgD8xVR4KK6w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Depauperate Beagle Board Green

[Przemek Klosowski]

On Fri, Apr 28, 2017 at 4:57 AM, Andrea Rondini  wrote:

> My problem is i've to midfy this board, not add an adpter.


Perhaps you could explain what exactly do you want to do. From what you
said so far, it appears that you want to use the beagleboard as a
controller in some sort of musical instrument---but I am just guessing
based on snippets of information from several of your posts. It would be
simpler if you wrote down your requirements and plans---then people on this
group could give you advice based on their own experiences implementing
their own Beaglebone-based builds.
It's quite possible that there are easier ways of accomplishing what you
want, but nobody will be able to help unless they know what's on your mind.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGjgq-bwRTp_H%2BkBCgwQBtKBvTGXcFFUF58bx61bv_TgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Repeatable bug where beaglebone black loses bytes from it's serial connection.

[Przemek Klosowski]

It looks like the serial output buffer overflow. I think you're using the
USB serial port, so it's probably not lost in the USB link, but on the
Windows side the USB serial driver is presumably overwriting the output
buffer.  Would you have a Linux system somewhere to cross-check it by using
a different OS/serial driver combination?
Can you change the settings in the Windows serial port, asking for hardware
flow control?

On Fri, Apr 21, 2017 at 12:26 PM, David Howlett 
wrote:

> I should mention I am using:
> - Windows 10
> - Drivers from about 2 weeks ago
> - A beaglebone image from about 2 weeks ago
>
>
> On Friday, April 21, 2017 at 5:18:37 PM UTC+1, David Howlett wrote:
>>
>> I have spent about two days tracking down an issue in one of my machines.
>> I am streaming pressure readings from an i2c pressure sensor to a PC at
>> high speed. I have reduced the problem to a small test case. To replicate
>> the fault I connect the beaglebone black to a PC, connect to it with serial
>> over the micro USB port, login and launch a command that streams data fast.
>> On the PC run a program that collects the streamed data more slowly than it
>> is being created.
>>
>> import serial
>>
>> x = serial.Serial('COM15')
>> to_send = b'\x03yes HelloWorld\n'
>> x.write(to_send)
>> while True:
>> received = x.readline()
>> if received != b'HelloWorld\r\n':
>> print(received)
>>
>>
>> The python program above prints lines like:
>>
>> b'ld\r\n'
>> b'HelloWoroWorld\r\n'
>> b'HelloWorldorld\r\n'
>> b'HelloWorldorld\r\n'
>> b'ld\r\n'
>> b'ld\r\n'
>> b'ld\r\n'
>> b'ld\r\n'
>> b'ld\r\n'
>> b'ld\r\n'
>> b'HelloWoroWorld\r\n'
>> b'ld\r\n'
>> b'HelloWlloWorld\r\n'
>> b'ld\r\n'
>> b'HelloWorldorld\r\n'
>>
>> At about 4 lines per second. If I set the program on the beagle bone to
>> stream slowly then this issue goes away. It appears to be an issue with a
>> buffer filling up somewhere between the output of the yes command and
>> reading bytes from the windows API. The correct behaviour is that the yes
>> command should be stopped when the buffer is full to prevent the loss of
>> data, then allowed to continue when there is space in the buffer again. I
>> observe that the streaming command (in this case yes) is stopped but there
>> is still data loss happening somewhere.
>>
>> I wrote this in python because it is the language I am most comfortable
>> in but if you needed me to I could rewrite the example in some other
>> language. To run the program shown above you will need pyserial and you
>> will need to change 'COM15' to be whatever the port is called on your
>> computer.
>>
>>
>> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/f4c86058-1fee-41fb-bc6f-d41f8eccb3b6%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgHaO3GQCnKpVa3ATJ9p1VfEMkYOGvtBdEeMGb2nacR13w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] rc_ files

[Przemek Klosowski]

If you are having problems with https, try http

git clone http://github.com/StrawsonDesign/Robotics_Cape_Installer.git


On Thu, Apr 13, 2017 at 6:02 PM, chris Bruner  wrote:

> Huh, apparently I can ping and traceroute anywhere, but wget times out
> (both http and https) so It's a networking 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.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/7603adb2-a32f-4abf-a330-006cd3fe676e%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgEppLKv8%3Dhw78%3D6_ZYTx03q5vc%3DvbVnuMRQJqO4Fd%3DZRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB can't connect over eth0

[Przemek Klosowski]

the 'nonfunctioning' BB does seem to be sending and receiving some packets.
When you test them, do you use the same physical network connection or a
different one?  If different, perhaps there's something wrong with the
cable or switch port you're using?

On Fri, Mar 31, 2017 at 8:35 PM,  wrote:

>
> I have two beaglebone blacks. One is working fine, the other isn't; as far
> as I can tell, they are nigh on identical (both Rev C--not sure what else
> to look at; I did get the nonfunctional one more recently and possibly from
> a different vendor).
>
> I've tried both BBB's booted off of the same microSD card and even then I
> have issues with one and not the other.
>
> When I boot and configure the eth0 interface on one BBB, I can not ping or
> ssh or perform any sort of actual interactions with anything else on the
> network.
>
> For instance, when I connect to a router which is running a DHCP server, I
> get the following from "ifconfig eth0" on the functioning BBB:
> eth0  Link encap:Ethernet  HWaddr 04:a3:16:ac:00:c4
>   inet addr:192.168.0.23  Bcast:192.168.0.255  Mask:255.255.255.0
>   inet6 addr: fe80::6a3:16ff:feac:c4/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST DYNAMIC  MTU:1500  Metric:1
>   RX packets:400 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:272 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:92719 (90.5 KiB)  TX bytes:88918 (86.8 KiB)
>   Interrupt:175
>
> but on the nonfunctional BBB (using the same SD card to boot) I get:
> eth0  Link encap:Ethernet  HWaddr 04:a3:16:b2:89:b1
>   inet addr:169.254.91.61  Bcast:169.254.255.255  Mask:255.255.0.0
>   inet6 addr: fe80::6a3:16ff:feb2:89b1/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST DYNAMIC  MTU:1500  Metric:1
>   RX packets:8 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:104 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:1622 (1.5 KiB)  TX bytes:25334 (24.7 KiB)
>   Interrupt:175
>
> The DHCP server on the router does see and give out a lease to the
> functioning one but does not seem to notice the non-functioning one.
> If I ssh over USB into into the nonfunctioning one, running "dhclient
> eth0" does not appear to help anything.
> If I configure a static ip address on the nonfunctioning one:
> $ sudo ifconfig eth0 192.168.0.23
> $ ifconfig eth0
> eth0  Link encap:Ethernet  HWaddr 04:a3:16:b2:89:b1
>   inet addr:192.168.0.23  Bcast:192.168.0.255  Mask:255.255.255.0
>   inet6 addr: fe80::6a3:16ff:feb2:89b1/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST DYNAMIC  MTU:1500  Metric:1
>   RX packets:8 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:121 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:1622 (1.5 KiB)  TX bytes:32811 (32.0 KiB)
>   Interrupt:175
> $ ping 192.168.0.50 # Attempt to ping the router
> PING 192.168.0.50 (192.168.0.50) 56(84) bytes of data.
> From 192.168.0.23 icmp_seq=1 Destination Host Unreachable
> From 192.168.0.23 icmp_seq=2 Destination Host Unreachable
> From 192.168.0.23 icmp_seq=3 Destination Host Unreachable
> From 192.168.0.23 icmp_seq=4 Destination Host Unreachable
> From 192.168.0.23 icmp_seq=5 Destination Host Unreachable
> From 192.168.0.23 icmp_seq=6 Destination Host Unreachable
> ^C
> --- 192.168.0.50 ping statistics ---
> 7 packets transmitted, 0 received, +6 errors, 100% packet loss, time 6031ms
>
> I get the same error attempting to ping the BBB from my computer, and the
> same issues if I attempt to connect the BBB directly to my computer's
> ethernet port.
>
> Performing exactly the same procedures, I have no issues with my other
> BBB. I've also attempted these running on the internal memory rather than
> the microSD card, and the issues persist.
>
> For what it's worth, the lights on ethernet port for the BBB are blinking.
>
> I'm having trouble imagining what issue I could be having without it
> simply being a hardware issue or some subtle difference between , and I
> don't really know what the hardware issue could *be*.
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/4bdae1c0-0656-4361-9cef-8ec496f2e14e%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You 

Re: [beagleboard] How to reliably push data from ARM host to PRU (shared) memory with predictable (low) latency?

[Przemek Klosowski]

On Fri, Mar 24, 2017 at 1:03 PM, William Hermans  wrote:
> I've honestly no idea how you're implementing what I suggested, so I can't
> really comment on what's going on. sleep() won't work though, and I'm not
> sure how usleep() is implemented for your particular OS( Debian Linux ), but
> usleep() on micro-controllers( bare metal ) is usually less than 10 lines of
> code. I want to say less than 6 lines of code, but it's been a while since
> I've looked through an implementation.

On a bare-metal microcontroller, sleep() is a busy loop but in Linux
sleep/usleep/nanosleep() results in a system call, which explains the
latency differences. BTW, a busy loop on Linux could still be
interrupted and result in latency.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgEXofGW8r2fLsaNPSCWHmiuqa6XoXtTKqeBr00xJsq_fQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: UAV Drone out of a BBBW

[Przemek Klosowski]

On Tue, Mar 21, 2017 at 4:44 PM, 'woody stanford' via BeagleBoard
 wrote:
> Ok so little angry now about the possibility of having to use 6 MOSFET's to
> control a single motor (how the HELL did someone come up with the idea of
> using a 3-phase motor for these toys...what was it some CAD/CAM guy...and
> what i the whole difficulty with brushes anyways?).
Brushes are unreliable, lossy and result in torque ripple. 3phase
motor torque is flat, and they're so efficient that practically all
high end motors are 3phase, and there's a trend to put 3phase in
smaller and smaller appliances, like dishwashers, washing machines and
refrigeratos. What is your issue with 6 mosfets? They cost less than
fancy carbon brushes :)
>
> How is this for an idea of how to use 3 MOSFET's to control one of these
> drone motors? I figure that its the voltage that the motor "sees", I can
> feed it a 50% PWM signal that my motors will think is zero volts (silly
> things). Then I can go down to 0% PWM for the negative voltage eliminating
> the need for the additional 3 MOSFETs. Run 100% for max positive voltage.
For 50% PWM to result in zero current through your motors you need to
reference it to a half-Vcc, so you'll need some sort of circuit
anyway. Just welcome your new 6-legged 3-phase overlords and be done.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgHbWpr0fOqE69QZLa2Y1w7-ac_XgczGi3jGWOjBy9Pmtg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Can a USB joystick directly control pwm voltage?

[Przemek Klosowski]

On Sun, Mar 19, 2017 at 2:33 AM, 'woody stanford' via BeagleBoard
 wrote:
> hook up your VCC to one end of your pot and then take the voltage as sunk
> through another fixed resistor to ground. Ask me if I'm still not explaining
> it right or just google voltage divider.

Right, but I don't even know where to get the old-style analog
joystick that could be wired this way---everything that's easily
available is USB and requires a host mode. For better or for worse,
full blown Linux makes it the easiest to use them,  because the USB
stack is already up and running, automagically producing the joystick
data stream. Without it, i.e. when using a small microcontroller with
USB host mode,  the software for this project would be dominated by
the USB handling code.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgG1ox266k-n9iKtrHWwfv4A9-eRqtxSXK%3D%2BQx5TLAMy-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Can a USB joystick directly control pwm voltage?

[Przemek Klosowski]

On Sat, Mar 18, 2017 at 1:49 AM,   wrote:
> I just want to know the possibilities here before buying a beaglebone black
> and starting a project. Im completely new here so perhaps there would be a
> better micro-controller out there. I just want to be able to use a generic
> usb joystick (or 2 rather simultaneously) to get user inputs that in turn
> control  pwm pins to vary the output voltage. From there i know the voltage
> can be amplified to get into my 24v needed range to proportionally control a
> hydraulic function. The key here is that i want to be able to make a system
> that if components get damaged they can be swapped out and i don't have to
> fabricate a new analog multi-axis joystick each time. I would need the
> possibility of 6 pwm's being controlled at the same time via 2 joysticks

Sounds like a cool project, and looks doable. In Linux joysticks show
up as input devices, typically in /dev/input/js0
That file appears automagically when you plug in the USB joystick, and
it contains the binary event stream from the joystick.
There's a input device test program jstest in the linuxconsoletools
package, which decodes that binary traffic, decoding that stream.

A typical game pad has two joysticks and a dozen or so buttons  (mine
has 4 front buttons, colored ABCD cross on the right, 4-way hat on the
left, 3 buttons in the middle and two center buttins in the joysticks.
Since each joystick provides X and Y analog position, each gamepad can
drive four PWM outputs, so you need two gamepads---I think that's what
ou mean by 'two joysticks'/

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGpiJJdP8XyfCZRxtrAeh4QA5SEqRMhWCzYvg_HvM3O8A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] xrandr Can't open display

[Przemek Klosowski]

On Wed, Mar 8, 2017 at 6:29 AM, sajeevan k  wrote:
> Video is displayed nicely. But there is one issue.
>
> A bottle with orange cap is appeared as one with blue cap. That means color
> displayed is not correct.
>
> This is true for Image capture also. An image which is displayed with
> original color in debian image viewer is displayed with wrong color, when I
> am displaying in this way.
>
> I don't think it is because of the programs that we used here. A frame which
> is captured with a program is showing correct color with debian image
> viewer, but with different color, when I am displaying with startx in BBB.

Sorry, I just don't know this area. In general, I'd try to isolate the
problem---I think you started doing this anyway, by moving the
captured images to an external host (I think that's what you mean by
viewing the image with 'debian image viewer'). This would mean that
the image is captured correctly, so the wrong display must happen when
you display it on BBB; does it happen only for the captured images, or
for all images? Keep trying to find the specific case for which you
have the problem. Sorry I can't be of more 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGr9g_rRtL5HJjExAVQTnLLxX0MQrpTL1KSx%3DD%2B4ypRUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] xrandr Can't open display

[Przemek Klosowski]

On Fri, Feb 24, 2017 at 2:49 AM, sajeevan k <sajeev...@laxven.com> wrote:
>
> After I enter startx in the command prompt of my desktop (ie
> root@beaglebone:~#) the following messages appearing in the display of my
> desktop.
>
>
> root@beaglebone:~# startx
>
>
> X.Org X Server 1.16.4

> (==) Using system config directory "/usr/share/X11/xorg.conf.d"
> xrandr: Failed to get size of gamma for output default
> Screen 0: minimum 1280 x 720, current 1280 x 720, maximum 1280 x 720
> default connected 1280x720+0+0 0mm x 0mm
>1280x720   0.00

So here you're running the xrandr command and getting output from it, right?

>
> Here the important point is that, now in my desktop terminal, I cannot enter
> the xrandr command, because there is no command prompt  ( ie # ) in the
> terminal.

OK, so the terminal program is not set up right. I see that you're
using openbox, which is a window manager.
I am not familiar with it, so I don't know what do you do in openbox
to start programs, but you need to start a terminal emulator and
arrange for a shell to be run within that emulator. This is normally
done automatically, but clearly in your case something is choking up.
I don't know what terminal emulators are available on your system, but
you need something like xterm, gtkterm or lxterm. Perhaps
https://bbs.archlinux.org/viewtopic.php?id=155127 has some advice that
you could use.

> Now as Przemek suggested, I included the command 'xrandr' in ~/.xinitrc,
> before ./simpleQt (name of my simple Qt application).
>
> But the execution of this command is observed in either desktop display or
> display connected to BBB.

See above---the execution of your xrandr outputs the information about
your screen.


>
> I am also giving the contents of .xinitrc file
>
> #!/bin/bash
> xrandr
> oclock -geometry +1450+920 -bg ivory -fg blue &
> ./q_msg_linux &
> exec openbox
>
> Please suggest a method, how I can run xrandr command in this situation.
>
>
> Thanks & Regards,
> Sajeevan.K
>
>
> On Sunday, February 19, 2017 at 6:39:08 AM UTC+5:30, Przemek Klosowski
> wrote:
>>
>> On Fri, Feb 17, 2017 at 6:45 AM, sajeevan k <saje...@laxven.com> wrote:
>>
>> > Now I am able to open a window as per a small qt progam in the LCD
>> > display.
>> >
>> > But still xrandr is not showing the outputs. It is showing no protocol
>> > specified.
>>
>> How are you running your qt program? Run xrandr in exactly the same
>> way; it should work.  If it doesn't, describe how you set up your
>> console, show exactly the commands you're typing and their output
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/755415f5-a880-499a-8da1-1792b164a827%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgFLoh%2BsP93WZM0Aok5Rz1YpzcmHhOYsx4GTLJnMR-owsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] USB Audio on BBGW/BBB using also and mpg321 : Distorted/clipped/too fast playback

[Przemek Klosowski]

On Thu, Feb 23, 2017 at 4:22 AM, 'Ian Watts' via BeagleBoard
 wrote:
> -2- I do not have Linux per se running on any other machine here - although
> I do have a spare / naughty Win7 (which I detest) PC, so I do have a
> potential candidate although where to start with that one?
You could download a bootable Ubuntu/Debian image to a USB stick and
boot from it in the 'live test' mode that doesn't overwrite your hard
disk. It basically has full functionality, and you even can download
and install additional packages if the original image lacks them.
Good luck--I think you're close to the solution, just have to find the
pesky glitch.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgE5VEcCxGFPsJ%2BjEHG8AkXjUj98fPiihWpUTqduca7iRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] xrandr Can't open display

[Przemek Klosowski]

On Fri, Feb 17, 2017 at 6:45 AM, sajeevan k  wrote:

> Now I am able to open a window as per a small qt progam in the LCD display.
>
> But still xrandr is not showing the outputs. It is showing no protocol 
> specified.

How are you running your qt program? Run xrandr in exactly the same
way; it should work.  If it doesn't, describe how you set up your
console, show exactly the commands you're typing and their output

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGpKN8nSMDqo8vJGuTw5ckCeE3EcaoM-kz5Gh9d54X%2BDg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] xrandr Can't open display

[Przemek Klosowski]

On Wed, Feb 15, 2017 at 12:23 AM, sajeevan k  wrote:
> I stated the X server with startx command.
> Also now a default display is coming in the LCD display(which may be the
> BBB's default display)
That's good. I don't know about the erorrs---it looks like the GL
software rendering is turned off but simple X should work now.

> Now I tried to run a simpleQt program, by opening another terminal. But it
> is only showing the following message in the terminal.
>
>  root@localhost:~# ./simpleQt
> QXcbConnection: Could not connect to display

Are you doing that from the same terminal as the one you ran startx
from? What is the value of the DISPLAY environment variable?

Try doing
DISPLAY=:0 ./simpleQt

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgFDcd%2B7Rbq1QYrdWKmCk00tAZSdPuodgqH19raPX-0ZHg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] xrandr Can't open display

[Przemek Klosowski]

i don't see that you started the X server---it needs to be running for
any of this to work.

On Tue, Feb 14, 2017 at 7:19 AM, Sajeev Krishnan  wrote:
> Hi,
>
>
> I am working with a Beaglebone Black with Debian Jessie.
>
> I am trying to interface with an LG 19M38H - B LCD display through its HDMI
> port.
>
> 1) When I am running the command
>
> sudo apt-get install read-edid xserver-xorg-video-fbdev
> xserver-xorg-video-modesetting x11-xserver-utils
>
> I am getting the following message
>
> root@localhost:~# sudo apt-get install read-edid xserver-xorg-video-fbdev
> xserver-xorg-video-modesetting x11-xserver-utils
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> read-edid is already the newest version.
> x11-xserver-utils is already the newest version.
> xserver-xorg-video-fbdev is already the newest version.
> xserver-xorg-video-modesetting is already the newest version.
> 0 upgraded, 0 newly installed, 0 to remove and 204 not upgraded.
>
> 2) Then I tried xrandr. It is giving the following message
>
> root@localhost:~# xrandr
> Can't open display
>
> 3) I did the following to solve the issue, after exploring in forums
>
> a)defining environment variable DISPLAY
>
> root@localhost:~# export DISPLAY=:0.0
> root@localhost:~# xrandr
> Can't open display :0.0
> root@localhost:~#
>
> b)defining environment variable XAUTHORITY
>
> root@localhost:~# export XAUTHORITY=/root/.Xauthority
> root@localhost:~# xrandr
> No protocol specified
> Can't open display :0.0
> root@localhost:~#
>
> c) used the command xhost local:root
>
> root@localhost:~# xhost local:root
> No protocol specified
> xhost:  unable to open display ":0.0"
> root@localhost:~# xrandr
> Can't open display :0.0
>
> d) used the command xhost +
>
> root@localhost:~# xhost +
> xhost:  unable to open display ":0.0"
> root@localhost:~# xrandr
> No protocol specified
> Can't open display :0.0
>
> e) Also  I changed the host name from beaglebone black to localhost to solve
> the issue.
>
> But nothing is working. Thanks in advance for the help.
>
> Thanks and Regards,
>
> Sajeevan.K
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/f50bcdd7-d36b-42cd-8bf3-5b323de97b28%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgFwb%3DFzcxZRwkUw%3DcCr%2BHvO4UgvE4cbu3s2evfM93RW4A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] USB Audio on BBGW/BBB using also and mpg321 : Distorted/clipped/too fast playback

[Przemek Klosowski]

On Fri, Feb 10, 2017 at 5:52 PM, 'Ian Watts' via BeagleBoard
 wrote:
> I also found a load of wav files, verified they played on the Mac,
> transferred them to the uSDCard and thence to the BBGW. All played fine on
> the Mac, all were 'broken' (as per last posts) on the BBGW.
>
> What I don't 'get' is that, after updating alsa.conf and re-initialising
> alsactl, the BBGW seems to play tracks correctly until it detects a change
> in sample rate (maybe ?) then nothing / no tracks play correctly - not even
> the ones that just played perfectly 


Maybe try your USB sound card on the Mac. Also, do you have access to
a Linux desktop running  a version of Debian comparable to what you
have on the BBB? Maybe try audio there, to compare 'ceteris paribus'.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgG56aHpyef-PbjJV%2B5yX%3DUjZ3jeJoUDsvdEaCTX73zK-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] USB Audio on BBGW/BBB using also and mpg321 : Distorted/clipped/too fast playback

[Przemek Klosowski]

On Fri, Feb 10, 2017 at 11:30 AM, 'Ian Watts' via BeagleBoard
 wrote:
> I tried your 'convert compressed mp3 to uncompressed 'wav' idea' with no
> luck, In fact the 'mp3' sound, although clipped and little too fast is
> comprehensible (one can hear it's Vienna/Ultravox or Mr. X/Genesis but no
> such luck with the 'wav' just horrible high pitched white noise...

This is maybe good news because the error is not subtle. Something is
wrong with the way you convert or play them; a .wav file should simply
play, period. Maybe get some .wav files  on the desktop (translate
some mp3 files, or find some .wav files already on your system), and
confirm that they play fine on the desktop, and then move them to BBB.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgG%2BsRda7STkbsbZ11_KfRu9MGd%3D1inrF%2BUMURzFHqwPAw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BES v0.8 does not recognize the USB Gamepad

[Przemek Klosowski]

it's been a while since I played with gamepads on Linux, but I seem to
remember that the gamepads show up as HID devices  with crazy number
of mouse buttons (MB 1,2,3,4,5,6,7,8,9). So, just write your app
to react to high-numbered mouse buttons. You can see what your gamepad
is generating by running the xev program from your text terminal;
it'll print event records to your screen.

Thu, Feb 9, 2017 at 2:06 PM,   wrote:
> Does anybody know how can I add the support for these USB gamepads?
>
> It would be great to have some help for doing this, even if someone could 
> explain how develop a new driver and compile It.
>
> I have everything ready but the USB gamepads.
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/9f60cb1f-d920-40f0-8dca-b9e9070b7662%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgH8CrO%2B_6CcmBbURN3HAkunhkdnzu3apNEMcNrYB7jBDQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] USB Audio on BBGW/BBB using also and mpg321 : Distorted/clipped/too fast playback

[Przemek Klosowski]

Sound is tricky because there are several layers that interact in
interesting ways: hardware, the USB layer, sound drivers, and the
transcoder software. I'd try to simplify: for instance, exclude the
transcoding layer by translating the files offline to a non-compressed
format, like .wav, and playing those. Now, the .wav files do have a
tradeoff: they don't require decoding, but they are larger, so they
may tax the mass storage bandwidth, so make sure to put them on the
fastest storage you have (presumably eMMC, or even a ramdisk). If the
.wav files play OK, then you'll know that the mpeg3 decode is to
blame. Othwerwise, it's down to examining other layers: e.g. trying a
different hardware sound card.

On Thu, Feb 9, 2017 at 9:55 AM, 'Ian Watts' via BeagleBoard
 wrote:
> Hi all,
>
> I'm still pretty new to my BBB / BBGW (I prefer the BBGW simply because of
> it's inbuilt wifi - real simple).
> So, I'm running on a SEED BeagleBone Green Wireless.
> with Debian / Linux 8 : 2016-06-14. The system is up to date - as of now.
> I'm running headless via wi-fi ssh on Terminal (Mac Sierra).
> and I'm trying to add sound playback of mp3 / wav files.
>
> So Far:
>
> I've installed / updated alsa and alsa-utils.
> I've plugged in a standard 10$ USB sound stick form EC Technology - some
> post suggest I get this one - I'm ambivalent as to the precise device but
> the smaller the better :
> https://www.amazon.co.uk/EC-Technology-Adapter-Window-above/dp/B012W70XH8/ref=sr_1_1?ie=UTF8=1486650199=8-1=EC-Technology+usb+sound+Adapter
> I'm also happy to switch to a new device if there is an even smaller /
> better / more readily hackable device available - but that's probably for
> another time - suggestions always welcome though !)
>
> I've used 'aplay -l' to confirm the USB device exists :
> card0:WILINK8_BT... device 0: WILIINK8 ...
>  Subdevices: 0/1
>  Subdevice #0: subdevice #0
> card1: Device [USB Audio Device], device 0: USB Audio [USB Audio]
>  Subdevices: 0/1
>  Subdevice #0: subdevice #0
>
> I have reconfigured the alsa device file (/usr/share/alsa/alsa.conf) to
> direct audio to the USB card (defaults.ctl.card 1and
> defaults.pcm.card 1) and not the BT module and I can hear pink noise
> (sound-test) from the connected USB Audio stick & speakers / headphones
> following an alsa restart / system reboot.
> I have installed mpg321 and, more recently, madplay.
> I have dumped some ripped mp3 music files into a 'Music' directory on
> uSDCard and can hear the output with :
> mpg321 -g 50 /media/uSDCard/Music/MyMusicTrack.mp3
>
> The sound that I hear appears to be 'clipped'. It is distorted and plays
> back too fast but with no increase in pitch etc. just like a broken / poor
> 'phone connection.
>
> Initially, I thought the problem may be with the track/file I had copied
> across & chosen to play, so selected another (no difference). Then I
> selected and left playing the whole folder (around 12 tracks) whilst I did
> some research.
> mpg321 -g 50 /media/uSDCard/Music/*
>
> Oddly enough, after a couple of tracks the sound was perfect and I listened
> to the rest of the selection (maybe 8 or 9 tracks in total) with some
> satisfaction. I also concluded (incorrectly) that the problem must have been
> with some of the files having been corrupted during the transfer process.
> However, when I decided to play the tracks again I note they are ALL
> suffering from the same clipped / broken / slightly too fast playback
> problem.
>
> I'm delighted to have gotten this far but... frustration... so near and yet
> so far...
>
> I have tried with powered speakers and with a simple headset... (no
> difference, remains distorted / clipped).
> I have tried with mpg321 and madplay... (no difference, remains distorted /
> clipped).
> Anyways, I'm now pretty sure this is a sampling mismatch / there will be
> some setting I've missed but, like my opening line said, I'm still pretty
> new to the BBB / BBGW and I'm unsure as to how to proceed - especially as
> I'm pretty nervous of taking too many retro-steps and 'playing' with far too
> little knowledge. I have googled and forum-ed this but find it confusing
> enough extracting relevant Wheezy / Jessie differences and trying to adapt
> Raspbian / Debian examples etc... anyways... I'm lost...
> Apologies for the length of this post but too much info is generally better
> than way too little... I hope...
> Thanks for reading, hope you can give me some pointers.
>
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/88a79ba0-5860-48ec-acbe-b1e1703b576b%40googlegroups.com.
> For more options, visit 

Re: [beagleboard] Phasors calculation using libpruio

[Przemek Klosowski]

On Thu, Jan 26, 2017 at 11:10 PM, Renzo Fabián  wrote:
> I have the following C code's parts that uses tables of sins and cosins

PRU uses 32-bit integer arithmetic, and only has unsigned add and
subtract. You'd have to recast your calculation into fixed point and
use software multiplication. What is the required accuracy? If it's
not too much, perhaps you could use table lookup, or combine table
lookup with linear interpolation?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgHnKV%3DOsLdbOKrvp338asMWzkjhdPYe%3Df3zw6t%2B2Y3FpQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Help with PIR demo

[Przemek Klosowski]

On Fri, Dec 16, 2016 at 10:33 PM, Chris Fink
 wrote:

> At first the LED light turned on right away, and I got a constant succession
> of "Motion Detected" messages. Then I realized that the code assumed an
> active-LOW output from the PIR, but my PIR is active-HIGH, so I changed the
> lines
>
> if(x.value === 0){
>  b.digitalWrite(led, 1);
> console.log("Motion Detected");
>
> to instead be
>
> if(x.value === 1){
>  b.digitalWrite(led, 1);
> console.log("Motion Detected");
>
> In this case the light does not come on, and I get a constant succession of
> "No Motion Detected" messages...and the PIR never detects motion, no matter
> how much I move, or how close I am. I even tried a different PIR (also
> active-HIGH), and got the exact same results. I also tried removing the
> pull-up resistor, which also did not work.

First of all, you have to watch for the voltages. BBB uses 3.3V,
whereas Arduino uses 5V. If you apply 5V to BBB, you could damage it,
but on the other hand, if you use 3.3V provided by BBB to power a 5V
sensor, it may simply be not enough for it to operate (although it
won't damage the BBB because it's unlikely to generate its own 5V).
The bottom line is you do need a 3.3V-compatible sensor.

If yours is 'active HIGH' then a pull-up resistor would probably just
peg it in a 'constantly active' state.

Just use a DVM to measure the voltage on the sensor when it's powered
by your BBB: if it shows 0V covered, and around 3V if you stick your
hand in front of it, it should work with the code above.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgHTGtN07X%3Dea4bCK7NUMMxO-0_coEfzjydwCe07mFg4WQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] wiring diagram

[Przemek Klosowski]

On Tue, Dec 13, 2016 at 9:36 PM, 'chris kearsley' via BeagleBoard
 wrote:
> im looking for a wiring diagram to attach a stepper driver to bbb to drive a
> stepper motor is there any information out there

BBB can generate digital sygnals that will drive current amplifiers
that the stepper motor requires. Is that what you have in mind?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgHLMpJW%3Dzy0JE7BWhge%3DMGgSV2QhHRj9_UzYKiNyqCPAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Ftdi driver issue

[Przemek Klosowski]

On Mon, Dec 12, 2016 at 12:15 PM, Sylvain  wrote:
> Hello,
>
> I try to plug more than one FTDI Usb Serial Adapter on a BeagleBone Black.
>
> I tried several adapters and all work fine if plugged directly on the USB
> Host port.
>
> But if I use an USB hub - I tried several - or a specific cape
> (http://www.titan.tw/product/USB_2COM_BB.html), the ftdi driver complains:
>
>> [ 1544.135039] ftdi_sio ttyUSB0: ftdi_set_termios FAILED to set
>> databits/stopbits/parity
>> [ 1545.143074] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set
>> baudrate
>> [ 1550.151247] ftdi_sio ttyUSB0: urb failed to clear flow control
>
>
>
> Here comes the different cases:
>
> BBB Usb Host > USB Cape > Ftdi Usb Serial Adapter 1
> > Ftdi Usb Serial Adapter 2
>
> BBB Usb Host > USB Hub > Ftdi Usb Serial Adapter 1
>> Ftdi Usb Serial Adapter 2
>
> BBB Usb Host > USB Hub > USB Cape > Ftdi Usb Serial Adapter 1
>   > Ftdi Usb Serial Adapter 2
>
> --> fails
>
>
>
> BBB Usb Host > Ftdi Usb Serial Adapter 1
> BBB Usb Host > USB Cape
>
> --> works

how are you powering the hub? and BBB? Is it possible that you're
running out of supply current? Try a powered hub---does it make a
difference?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgFy5_nM_5Z4D9qPEdSq34TMsyCzcDXdUGD6uuu-KXcoFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Embedded C - Function Declaration

[Przemek Klosowski]

On Thu, Nov 10, 2016 at 2:14 AM, Neil Jubinville
 wrote:

> Calling the write function from the main loop results in the LED turning on
> however the function does not fire.
>
> static void turnOn(){
>write_r30(0x);
> }
>
>
> static void turnOn(){
>write_r30(0x);
> }
>
>
> int main(void){
>
>turnOn();   // this does not work.
>

I think it's a simple typo---you have two turnOn() functions---it
looks to me that the second one should be called turnOff(). As it is,
I think you redefine the first turnOn with the second one, which
actually turns off the pin, so you see nothing. Does it make sense?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgEti53XjubcJ880hZ2OK32-5OVZzUpR%3DoMAqSbTwFh7Gg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] correct connection of an opto-coupler

[Przemek Klosowski]

On Tue, Nov 8, 2016 at 10:27 AM, mzimmers  wrote:
> I apologize for the confusion...after reading the instructions for the nth
> time, I have come to realize that I'm trying to use the wrong component for
> this exercise.
Right, Derek calls for an LDR aka Light-Dependent Resistor, aka
photoresistor, that looks like this:

https://www.amazon.com/PODOY-Photoresistor-GL5537-Resistors-Light-Dependent/dp/B016D737Y4

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgHvpuSwxYh%2BPmH9s-4YkWFVo-oS1eOav1mDhOE_Oa8uJg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] correct connection of an opto-coupler

[Przemek Klosowski]

On Tue, Nov 8, 2016 at 9:39 AM, mzimmers  wrote:
> Hi, all - I thought I posted something about this last week, but a search
> doesn't turn it up, so here goes again.
>
> I'm working through Molloy's book, and trying to build the opto-coupler
> circuit in chapter 6. I'm not a hardware guy, so I'm feeling my way along
> here. The diagram doesn't show specifically how to wire up the four
> connectors. I looked at the data sheet for the device, which was helpful,
> but still doesn't get me home.

OK, so what did you try? Which four connectors are you talking
about--the opto's?
As a device, opto is normally being driven by your computer (pins A
and C on your datasheet, connected to the LED) and the output
phototransistor serves as a control switch for your working circuit.
They both need current limiting, normally in the form of a series
resistor. For instance, the LED in your opto is limited to 60mA, and
probably should be driven at 10mA, so if you're driving it from 3.3V
output of your Beaglebone, you need a resistor of
R=U/I=(3.3-1.3)/.01=200 ohm. The output phototransistor is limited to
50mA, so it also should have a similar current limiting resistor
connected to it.
Of course the opto could also be used as an input circuit---the LED
driven by a voltage from the outside, and the phototransistor
connected to the input of your Beaglebone. Similar current-limiting
considerations apply.

>
> I could trial and error, but I've already fried one component, and they're
> not easy to come by in my area. Can anyone help clarify this configuration?
>
> This is the specific device: opto-coupler
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgE4LmvNaS0Zn_Ek-WmDx6jq7dKE6LCY62Yf2GcLdFUsGg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: LED won't go off (Chapter 6 exercise)

[Przemek Klosowski]

On Mon, Oct 24, 2016 at 11:16 PM, mzimmers  wrote:
> Yes, the gate voltage is 3.3V when the file "value" is 1, and 0V when the
> value is 0.

then, either the transistor is blown (they need to be protected from
static discharge which could damage them) or it's miswired.
This is the circuit which may or may not render well in ASCII.
o +5V
|
   |||  R
   |||  330ohm
|
 _V_  LED
|
|--+
GPIO -->--| |
|--+
  _|_  GND
 BTW, you didn't mention the LED current limiting resistor---you need
that because your transistor can pass multiple amps when GPIO is 3.3V
and the drain is at 5V-Vled, i.e. around 3.5V. Lack of the resistor
could have damaged the transistor as well, although it would have
damaged the LED as well I think.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGDLxE82rKhojxDSVQHUjP0o3hGge0h-ESeCJMGiMCX2A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: LED won't go off (Chapter 6 exercise)

[Przemek Klosowski]

On Mon, Oct 24, 2016 at 10:25 PM, mzimmers  wrote:
> Oh, now this is interesting: now that daylight has gone, and the room's a
> little darker, I can see that the LED is on brightly when the value is 1.
> When the value is 0, it's noticeably dimmer, but not completely off.

OK then, check the voltage for '0'---it has to be much lower than
Vgs(th) i.e. 2.5V. Perhaps some pullup doesn't let it go all the way
down? Again, measure it with the voltmeter.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgFYZV9FndXwVqbS4PH96piV3GBhYS_V3RB_OO_H-LyY8A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: LED won't go off (Chapter 6 exercise)

[Przemek Klosowski]

http://www.farnell.com/datasheets/2162038.pdf page 4 shows Ids vs Vgs
plot that conduction start well above 2.5V (listed as Vgs(th) in the
datasheet), so the the voltage put out by the GPIO pin, which should
be almost 3.3V,  should be enough. Do you have a multimeter to measure
the actual gate voltage?

On Mon, Oct 24, 2016 at 8:50 PM, mzimmers <mzimm...@gmail.com> wrote:
> Hi, Przemek -
>
> It's a Fairchild BS270:
>
> link on newark
>
> I (obviously) need to learn more about this...is the information you ask of
> in the data sheet? If so, I'll search for it.
>
> mz
>
> On Monday, October 24, 2016 at 6:44:59 PM UTC-6, Przemek Klosowski wrote:
>>
>> On Mon, Oct 24, 2016 at 8:33 PM, mzimmers <mzim...@gmail.com> wrote:
>>
>> > 2. What do you mean by "reverse logic?" That I've miswired my
>> > transistor?
>> > Here's my wiring:
>> >
>> > drain comes in from LED
>> > gate goes to P9, pin 23 (GPIO 49)
>> > source comes from GND
>>
>> A word of caution--some MOSFETs start conducting between source and
>> drain when you apply voltage to the the gate, and others work the
>> other way. Which one do you have---what's the type?
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/6b6a7013-43d2-45de-9913-3fe539533273%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGyEq24-MsuZhVTA6Rsxv7n3QN%2Bwmev%3DJ7OTMNB1PCj0Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: LED won't go off (Chapter 6 exercise)

[Przemek Klosowski]

On Mon, Oct 24, 2016 at 8:33 PM, mzimmers  wrote:

> 2. What do you mean by "reverse logic?" That I've miswired my transistor?
> Here's my wiring:
>
> drain comes in from LED
> gate goes to P9, pin 23 (GPIO 49)
> source comes from GND

A word of caution--some MOSFETs start conducting between source and
drain when you apply voltage to the the gate, and others work the
other way. Which one do you have---what's the type?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGaRuuTxY524kZow_QorP2iK1rRFW_nLH6oqWFn6YgoVQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: High speed encoder input capability of BBB?

[Przemek Klosowski]

On Wed, Oct 5, 2016 at 12:11 PM, beezerlm  wrote:

> I am trying to figure out where to go from here.  Libpruio looks
> promising, but I would like to take the path that would offer the best
> overall determinism & latency characteristics for reading encoder input and
> controlling IO accordingly.   I would think the best case scenario would
> be to program the PRU directly and skip linux altogether.


PRU will give you the encoder data, but where do you go from there? If all
you need is some calculations and running simple actuators of the PWM kind,
and/or display to low-pixel-count LCD, you dont' need Linux---however,  if
you need communication stacks such as Ethernet, BT or WiFi, it's probably a
bad idea to try to write them from scratch.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgHO6TC6dG84xnc5dt%2BzvddN33c8TJ%2BzJZwFDesQV3%3D8rQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Newbie how to turn a SPDT Relay(30A) on and off connected to a beaglebone green

[Przemek Klosowski]

On Tue, Aug 23, 2016 at 5:18 AM,  wrote:

When I got my new bbgw I ran an internet search to find how to use the
> relay and did not find an easy answer, so here goes:
> 1. The Grove - SPDT Relay(30A) - uses +5V , so you need to solder the
> third pin of that groove connector. Disconnect it from the board, and
> connect it to the input 5v power.
>

It seems that your relay requires nominal 5V coil voltage and 185mA coil
current. This is far beyond what a BBB pin can provide: they put out 3.3V
and barely above 10mA. Additionally, switching the coil on and off
generates inductive spikes that are likely to damage the BBB output
circuits. You need some sort of coil driver; I suggest buying something,
e.g one of http://blog.machinekit.io/p/hardware-capes.html, or building
your own circuit like this one http://i.stack.imgur.com/OhY9d.png

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgFMYszu7ETm7KWi6UvcvzRZFXE5Z2dsy3Bt2wf2tB2ROA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to Send email via Beaglebone Black?

[Przemek Klosowski]

On Fri, Aug 19, 2016 at 11:01 AM,  wrote:
>
> I want my Beaglebone Black (BBB) to send me an email when a button wired
> to it is pushed.
>


> B) I'm aware of email services include msmtp, ssmtp, exim4, etc from my
> current efforts on the topic, but I don't know how to download, install,
> and set them up (or even which one I should use)
>

Don't worry about those things---you don't need them. Instead, you need to
figure out how to connect to the email infrastructure that would transmit
your message to the final destination. Getting the email out of your system
is easy---you could literally telnet to port 25 on the mail server that is
accessible to you, and type the commands:


*helo volkalert*

*mail from: m...@my.beaglebo.ne *

*rcpt to: volkal...@gmail.com *

*data*


*button pressed.*
*quit*

The trick is to find the mail server that will accept your connection, and
what domains it allows for the to/from data. You have to ask your ISP for
that. Once you know the answer, you could just open the network connection
and issue the command sequence above, or use one of SMTP libraries in the
language you're writing your app in, or simply spawn the 'mail  -r
m...@my.beaglebo.ne volkal...@gmail.com'  command and pipe your message to
its stdin.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgF3BJ%3D39TxgR%2BzCP67R2Lw4HOTLurYXcdeb_LcKWsO%3DWQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 4-20 ma measurement with beaglebone black

[Przemek Klosowski]

 On 8/17/2016 5:26 PM, balihi...@gmail.com wrote:

> I am wondering if a beaglebone black can be used to measure industrial
> 4-20 ma loops?  I see there is an ADC feature, but the voltage range is
> only to 1.8V.  Is it possible to set it up to work with the standard 24VDC
> circuitry involved with most 4-20ma loops?
>
> A 90 ohm resistor carrying 20mA will develop a voltage of 1.8V. This is
cutting it a little close, so I recommend 68 ohm, which is a more
standard/easier to find value anyway. So, just terminate your 4-20mA line
with this resistor, and connect it to the Beaglebone analog input. Of
course if you're in an industrial environment you need to watch out for
transients, noise and interference, especially since the Beaglebone inputs
are famously fragile, so include some serious input protection (e.g. four
diodes connected as two anti-parallel 2-diode chains, with a filter cap
across it and maybe some series resistance). Then again, you could follow
evilwulfie's advice to use a dedicated buffer op-amp.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgEYNO8A-ziJKy0StkuFw6sC5eRRK05_fy3oiPAJ-4_fPQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PRU remoteproc Tutorial

[Przemek Klosowski]

On Wed, Jul 13, 2016 at 11:09 AM, William Hermans  wrote:
>
> Granted, now, I've read that redhat was contracted to build a newer gcc port
> a few years back, and that this gcc is actually used by CCS now days( for
> the MSP430 toolchain ). It is purported to support the newer MSP430G2
> variants, among others, but still is not as reliable as the gcc toolchain it
> was meant to replace.

Well, it replaced both CCS and the old MSP430 GCC, and I think the
concensus is that it's for the good. There were issues in the
beginning, but now it's being worked on by both RedHat and TI, and
nobody recommends the old stuff for use any more.

The usual argument for GCC is that it's relentlessly getting better;
proprietary alternatives tend to lose their initial advantage because
GCC contributors have a look at the differences and implement the
improvements. Look how far Dimitar got it, working on his own.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGH-eijzdkeyj9cL8O9jiGJj2QZ0L%3DqPNRFbH7%2B2R6cuQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB startup current

[Przemek Klosowski]

On Mon, Jul 4, 2016 at 9:14 PM, 'Morgaine' via BeagleBoard
 wrote:
> John Syne writes:
>>
>> > a power supply that is spec’d at 4A should not shutdown when it sees a
>> > 4A load, but rather, it should current limit at 4A. If the power supply is
>> > spec’d at 4A, then 4A should not be treated as a short circuit.
>
>
> That's impossible.  You can't recommend that fundamental electrical laws be
> overridden. :P
>
> If a PSU current limits at 4A, it can do so only by reducing its output
> voltage.  This may then drop below specification for its load and this can
> have very bad consequences such as non-stop rebooting.  There is no way for
> the voltage to be maintained above its minimum spec while still providing a
> current limit.

Yes, but remember that the problem here is a startup inrush current,
which would be handled properly by current limiting. After all, that's
what the 2A current supply is doing: essentially, it soft-starts,
providing limited current charging the input caps, while ramping up
the voltage. Once the caps are charged and the supply voltage
stabilizes at the nominal value, the system progresses to boot.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgE8MbV7LXVsU3SDOYyu%2Bie_8snkR4Lb0HjBb5153T1XXg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

[Przemek Klosowski]

On Mon, Jun 27, 2016 at 3:51 AM, TJF  wrote:
> I think Suman did already know what libpruio (and many other high
> performance PRU projects) need. But here's a private lesson for you: There
> is no "need for communications with Linux in a tight control loop". We need
> direct memory access between PRU and ARM CPU. No Linux inbetween. We need to
> bypass all that vring and RPMsg magic. We gain for speed and small memory
> footprints. We want to save resources for future extensions and we don't
> want to spend resources for features that we neither need nor want.

This is a valid design pattern and you did very impressive things with
it, but it's not compatible with the basic design of Linux hardware
integration: I don't know of a single mainline kernel driver designed
this way. The whole point of a kernel driver is that it abstracts the
hardware and presents the unified abstraction to the rest
(open/read/write/ioctl/skbuf/etc). Of course this costs performance,
and so the development identifies those bottlenecks and tries to come
up with more abstractions like no-copy networking, etc.
The challenge for those abstractions is to provide speed while still
maintaining security, e.g. by disallowing full control of the entire
physical address space. There have to be address space checks on those
kernel-userspace transitions, and they will use up some cycles; you
can optimize them but can't just not do them.

It seems to me that you just don't want the Linux machinery to
intervene: your design does feel like a bare metal, tight control
loop, using Linux mostly for setup, program loading and
administration.

Also, I would be personally obliged to you if you could refrain from
commenting on other people's motivations and abilities, and just keep
focused on the technical points everyone is making. The discussion is
much more productive this way.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGAQBn%2BAgt76ivjMW3h3Yon7hXbEROcU%2BwubWS4YG6%3DJg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] extract emmc contents to memory card for my element14 Beaglebone Black.

[Przemek Klosowski]

On Wed, Jun 1, 2016 at 10:52 AM, Akash Gajeshwar 
wrote:

I am trying to extract emmc contents to memory card for my element14
> beaglebone black. I did follow instructions mentioned on
> http://elinux.org/BeagleBone_Black_Extracting_eMMC_contents, but it is
> not working.
>
> can someone help me wit this please.
>

What errors did you see? What didn't work?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgF0vb7WExOXM7%2B2CUD-_wrCiAP%3D3iCPdXx2e-4Fcf%3Db6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Programming without programming discussion

[Przemek Klosowski]

>
> These graphical or visual programming languages you denigrate really do
>> help scientists, engineers, and other "domain experts" who aren't, and
>> don't want to become, "programmers" implement an idea for which there is
>> not, and will never be until the idea is proven sound, a budget for "hiring
>> real programmers".
>>
>
In principle, yes, they are useful and enabling. In practice, however, they
have been underwhelming, and I can think of several reasons:

   - fragmentation: they usually are designed for some domain-specific
   programming (e.g. LabView for data acquisition, GNUradio for signal
   processing, Simulink for control systems, SGI AVS/Explorer for data
   flow/processing, etc). This, however, means that their audience is limited
   to that particular domain.
   - closeness: most of graphical programming systems are commercial and
   closely held by their owners
   - lack of scaling: easy tasks are very easy,  but as the program size
   grows, they become unmanageable. It's difficult to determine whether two
   visualized data flow graphs are equivalent: the program representation and
   semantics are mixed up. My favorite dis of graphical programming:


   - Finally, we can have spaghetti code that looks like spaghetti!

Someday, someone will probably come up with visual system that's general,
open source and amenable to maintaining in git---but that day hasn't
arrived yet.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGyRF185jpBpgf%2BugqTRsfd5S6QdV9oHXc_W55%2Bs%3D5Ygw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: 1-Wire

[Przemek Klosowski]

On Mon, May 2, 2016 at 11:20 AM,  wrote:
>
>
> Here the result:
> root@c0a80090:/sys/devices/w1_bus_master1# ls -lZ
>  w1_master_max_slave_count
> -r--r--r-- 1 root root ? 4096 May  2 14:45 w1_master_max_slave_count
>
> I try to use "chmod 777 w1_master_max_slave_count" and then the command
> again, but then I get:
> root@c0a80090:/sys/devices/w1_bus_master1# ls -lZ
>  w1_master_max_slave_count
> -rwxrwxrwx 1 root root ? 4096 May  2 15:18 w1_master_max_slave_count
> root@c0a80090:/sys/devices/w1_bus_master1# echo 20 >
> w1_master_max_slave_count
> bash: echo: write error: Input/output error
>
> OK, I am out of ideas---you have correctly modified the Unix filesystem
permissions, but it still doesn't work.
I see that SELinux data is missing (the '?' part). I don't remember and
can't check right now which SElinux mode is Debian in
(off/permissive/enforcing).
Check the result of 'getenforce' command.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGHp40iGUx70-OA%2BqFKbXwrO_JEmOFa%3DEOdiE%3D%3D7nN-2g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: 1-Wire

[Przemek Klosowski]

On Fri, Apr 29, 2016 at 1:08 AM,  wrote:


> root@c0a80090:/sys/bus/w1/devices/w1_bus_master1# echo 20 >
> w1_master_max_slave_count
> bash: w1_master_max_slave_count: Permission denied
>
>
>
> Could you provide the result of running
ls -lZ  w1_master_max_slave_count

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgEa58nWSQNAdVaZxNa4z7BD-z7tUqbMdyQp0xSOT0dp%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] problem to install gnuplot on Debian OS using BBB

[Przemek Klosowski]

On Fri, Apr 22, 2016 at 3:33 AM, Nurul Ainiza 
wrote:


> I install gnuplot in debian OS
>
> - sudo apt-get update && upgrade
> - sudo apt-get install gnuplot
> - sudo apt-get install  gnuplot-x11
>
>
> i am a newbie BBB. i had a problem where my BBB is idle power off. when i
>> want to install the gnuplot the BBB will automatically turn off. i had done
>> so many time. what should i do? do u guys have the same problem?
>>
>>
>>
> I think you are powering up your BBB from USB, which is enough to boot and
run idle, but when you're starting to use the network and write to the eMMC
storage you run out of power and the system shuts down. That's why Gerald
recommended a dedicated power supply.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgE6RsXJ0y-POZ018p6tZndJf48Uc_ju2%2BtAV42sXd-MgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: C compiler

[Przemek Klosowski]

On Fri, Mar 25, 2016 at 9:03 PM, William Hermans  wrote:

> william@beaglebone:~/ti$ gcc test.c -o test
> william@beaglebone:~/ti$ test
>

That's because it's the wrong test. type 'which test' and it'll probably
say /usr/bin/test. If you don't specify the path, it's using the PATH
variable which is not supposed to contain current dir early on, precisely
to avoid this type of surprise. Note that on Windows, they automatically
prepend . to the PATH, which is why Windows is famous for confusing 'DLL
hell' where nobody knows where your executables/libraries are coming from.


> william@beaglebone:~/ti$ ./test
> 32.540001
>
right, you specified the path, so it's using your executable

>
> william@beaglebone:~/ti$ sudo ln -s /home/william/ti/test /usr/bin/test
>
you don't need sudo here: you're creating a local symbolic link (I assume
that you are in /home/william/ti directory)
You overwrote the 'test' executable with a link to /usr/bin/test


> william@beaglebone:~/ti$ test
>

still using /usr/bin/test


> william@beaglebone:~/ti$ cd ..
> william@beaglebone:~$ test
> william@beaglebone:~$ sudo test
> 32.540001
>

I don't know what happens here---maybe your root has a different path that
contains '.' early on (it shouldn't!)


> So, it's a permissions issue. . .
>
> No, I really don't think so



> On Fri, Mar 25, 2016 at 5:41 PM, William Hermans 
> wrote:
>
>> *Nothing at all to do with gcc, reread what I already posted...*
>>
>>
>> Your system, and mine behave nothing alike. For instance if I attempt to
>> run an executable without using dot slash prefixed. The executable will
>> simple fail silently.
>>
>> On Fri, Mar 25, 2016 at 5:30 PM, Mike  wrote:
>>
>>> On 03/25/2016 08:11 PM, William Hermans wrote:
>>>
>>> Im guessing that perhaps gcc's -o option now days enables the executable
>>> bit on the output file ? I haven't looked into that however.
>>>
>>> Nothing at all to do with gcc, reread what I already posted...
>>>
>>>
>>> Mike
>>>
>>>
>>> On Fri, Mar 25, 2016 at 5:08 PM, William Hermans 
>>> wrote:
>>>
 No, Mike is absolutely correct. dot's meaning in this context is
 current directory, and slash is just a path modifier / separator. Putting
 the file in ones $PATH would solve the "problem" of having to use dot slash
 I've know  this forever, I do not know why I was thinking that chmod +x
 would solve that "issue", because it wont.

 I do recall at some point perhaps not too long ago that changing file
 permissions to executable was required. But now days this does not seem to
 be the case . . . I've always in the last several years use ./executable
 until I put the executable into my local path . . .

 On Fri, Mar 25, 2016 at 2:19 PM, Mike < 
 bellyac...@gmail.com> wrote:

> On 03/25/2016 02:03 PM, William Hermans wrote:
>
> No chmod needed *IF* you precede the command with a dot slash "./". So
> when you run a regular Linux command do you have to type this dot slash ?
> No because chmod +x is run on the executable at some point . . .
>
> So be nice to fellow group users who actually know what they're
> talking about, and have been on this list a lot longer than you.
>
> Maybe we need to learn what ./ does...  It has absolutely nothing to
> do with a files permissions or whether it's executable or not.  It's use 
> is
> regarding the lack of the current directory "." in one's PATH variable.
> Umask is (largely) what controls what permissions a file is created with.
>
> mike@pride-n-joy:~/test.d$ ls -al
> total 12
> drwxr-xr-x  2 mike mike 4096 Mar 25 17:07 .
> drwxr-xr-x 37 mike mike 4096 Mar 25 16:46 ..
> -rw-r--r--  1 mike mike   78 Mar 25 16:47 hello.c
> mike@pride-n-joy:~/test.d$ umask
> 0022
> mike@pride-n-joy:~/test.d$ gcc -Wall -o hello hello.c
> mike@pride-n-joy:~/test.d$ ls -l
> total 12
> -rwxr-xr-x 1 mike mike 6696 Mar 25 17:08 hello
> -rw-r--r-- 1 mike mike   78 Mar 25 16:47 hello.c
> mike@pride-n-joy:~/test.d$ hello
> bash: hello: command not found
> mike@pride-n-joy:~/test.d$ ./hello
> Hello, world!
> mike@pride-n-joy:~/test.d$ umask 0137
> mike@pride-n-joy:~/test.d$ gcc -Wall -o hello hello.c
> mike@pride-n-joy:~/test.d$ ls -l
> total 12
> -rw-r- 1 mike mike 6696 Mar 25 17:09 hello
> -rw-r--r-- 1 mike mike   78 Mar 25 16:47 hello.c
> mike@pride-n-joy:~/test.d$ hello
> bash: hello: command not found
> mike@pride-n-joy:~/test.d$ ./hello
> bash: ./hello: Permission denied
> mike@pride-n-joy:~/test.d$ ls -l
> total 12
> -rw-r- 1 mike mike 6696 Mar 25 17:09 hello
> -rw-r--r-- 1 mike mike   78 Mar 25 16:47 hello.c
> mike@pride-n-joy:~/test.d$ chmod 0750 hello
> mike@pride-n-joy:~/test.d$ ls -l
> total 12
> -rwxr-x--- 1 mike mike 6696 Mar 

Re: [beagleboard] Beaglebone black play audio with TCP command

[Przemek Klosowski]

On Thu, Mar 17, 2016 at 9:57 AM,   wrote:
>  I would like to write a c code which will play audio like wav or
> mp3 from USB audio adapter when it receives a TCP command from Ethernet
> interface. To do this I will use a cheap USB Audio Adapter and Beagle Bone
> Black. Can anybody help me to write the code from scratch ?

A supported USB sound card would show up as /dev/audio and you can
either directly copy data to it, or use the command 'play'.
To trigger this by a TCP command, you could do something like this:

while (netcat -l 8080) ; do play sound.wav; done

will loop, waiting for connection to port 8080, and play the sound wav
file when the connection closes.
You can test this on your desktop by connecting to localhost
netcat localhost 8080
^D

-- 
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] Imagination in trouble

[Przemek Klosowski]

The SGX graphics accelerator on the Beaglebone was always a debacle:
TI didn't opensource the drivers or even release proper documentation.
This apparently was due to the proprietary conditions they received
from the IP author, Imagination.

Apparently Imagination business model, instead of pure shrewdness,
turned out to be deeply flawed, and they seem to be on the ropes now:
http://www.eetimes.com/document.asp?doc_id=1328932%3b_mc=NL_EET_EDT_EET_review_20160220%3bcid=NL_EET_EDT_EET_review_20160220=d1a283ddfdd749989b48e29b1f0d368a=a5703da753fe448e8e6cffa899d286fb=30961=1=27068

I wonder if this would somehow help the case of open-source graphics driver...

-- 
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: Is it possible to write PRU firmware for remoteproc completely in Assembler?

[Przemek Klosowski]

On Sat, Feb 20, 2016 at 2:45 PM, William Hermans  wrote:
> Is it really so much to ask for example code to demonstrate how to interact
> with the on die hardware ? Without having to download 1GB of pretty much
> useless library . . .

William,

I must be missing something, because I see remoteproc as a
communication and management mechanism for code on CPUs other than the
main processor. The actual code that you are running on those
subsidiary processors does not depend on the mechanism you use for
talking to it (other than the parts that do the talking, of course).

In particular, running ADC, I2C or GPIO should be the same, regardless
whether you use remoteproc or not---what changes is how you tell this
code what to do.

Does it make sense to you?

-- 
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] Custom Power Supply

[Przemek Klosowski]

On Fri, Feb 19, 2016 at 11:03 PM, Rizalino Antonio de Guzman
 wrote:
> I opted for the LM317 design due to the adjustable feature, since im
> supplying 3.3, 5, 12 and possibly 18V. we're controlling multiple solenoids,
> stepper motors, various sensors and multiple BBB on one system. i was
> thinking designing the p/s in a parallel manner where i have multiple LM317s
> connected to a single source (ie. battery)

You definitely don't want to use a linear regulator on a battery.
because you will waste most of the battery energy in the regulator. If
your battery is 25V and the BBB supply is 5V, and you're drawing 1A,
20W is being dissipated into heat in the linear regulator, while only
5W is being used productively to run the BBB. A switching power supply
is not 100% efficient, but can attain 80-90% so you will only draw
5-6W from the battery and your system will last 4-5 times longer on
the initial charge.

-- 
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't connect through 192.168.7.2.

[Przemek Klosowski]

On Wed, Feb 17, 2016 at 4:41 PM, Rudie van Willigen
 wrote:
> Smart people believe, that not sharing knowledge will keep you smarter then
> anyone else.
>
I'm actually curious what happened and how you solved your
problem---could you find a moment to explain this, for others'
benefit? I hope you don't take the above as your personal credo...

-- 
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] Slew rate when toggling Enhanced GPIO pins in the PRU?

[Przemek Klosowski]

On Tue, Feb 16, 2016 at 4:08 PM, John M  wrote:

> I'm trying to create a clock using the PRU, and I have it working to an
> extent, but I am noticing a discrepancy between what I read in the TRM and
> what I'm seeing. When I use a series of SET CLR SET CLR commands on a pin,
> they do not resolve completely before the next command. When I seperate
> each command by a delay, the rising edge of the clock takes ~90ns to go
> from 0V to 3.3V. I was under the impression that this operation would be
> performed at around ~5ns.
>

 Straight out Set/Clear would theoretically run at 100MHz (two instructions
of 5ns each), but when you connect them to the chip I/O, there are effects
of interconnect between the PRU and the I/O resources, Charles Steinkuehler
wrote it up in
https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p

However, the rise time of the signal as seen by your oscilloscope is
totally unrelated to that: the signal on a pin should change within a IO
clock cycle and the skew you're seeing must be due to the RC(L) delays due
to factors such as the state of the pullup on the IO pin, capacitances and
inductances within the package, on your board and in your oscilloscope
probe and cable.

-- 
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] Segmentation fault error while trying to set the direction of the GPIO pin to perform read operation

[Przemek Klosowski]

On Sun, Feb 7, 2016 at 3:03 AM,   wrote:
> Hi Everyone,
>
> I am new to beaglebone black linux and looking for some support for the
> issue I am facing. I have been following Derek Molleys video tutorials on
> how to configure and program the GPIO's here
> http://derekmolloy.ie/beaglebone/beaglebone-gpio-programming-on-arm-embedded-linux/.
> Everything was going fine, until I encountered this weird bug that has to do
> something with the memory segments I believe. Searched on net and came
> across someone who had faced the same issue here
> https://groups.google.com/forum/#!topic/beagleboard/Xe-oIuQOeI8, did the
> respective changes in the code as suggested, yet I keep getting
> segmentation fault error and the execution stops while displaying "Could not
> set the direction of the pin". Here is the code I am trying to fix,
>

> sprintf(Inputpin_dir,"sys/class/gpio/gpio%d/direction",inputpin);
>...
> //Set the direction of the pin
> if((ButtonHandle = fopen(Inputpin_dir, "rb+"))==NULL)
> {
>   printf("Could not set the direction\n");
>   return 1;> Control comes here and display "Could 
> not set the direction and segmentation fault
> }

The value for the sysfs node is not correct (you're missing the
initial /). I don't know where the SEGV comes from: compile with with
the -g flag and run under gdb, and it'll tell you which line is the
SEGV in.

-- 
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] Determine Specific Processor Type

[Przemek Klosowski]

What do you want to do with those values? There are many possible
combinations of architecture,variant, part and revision, but only few
combinations actually exist, and they are explicitly mentioned and
supported in the kernel.

On Tue, Jan 26, 2016 at 8:24 AM,   wrote:
> Hey there,
>
> I've seen multiple places where it list that the BeagleBone Black uses
> Sitara AM355x,

Actually it's AM3358, probably (not 355x)

The CPU ID values read as follows:

> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant : 0x3
> CPU part: 0xc08
> CPU revision: 2

They are decoded in arch/arm/kernel/setup.c but after a superficial
search I couldn't find a table that lists all possible values, so I
guess you have to find the ones that are possible for you  and decode
the values yourself..

Here's a short answer, provided from a list of known, supported machines

> Hardware: Generic AM33XX (Flattened Device Tree)

-- 
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] Tablet display to be used with BBB?

[Przemek Klosowski]

You can run X server on the tablet, and display X applications from
BBB to the tablet using TCP transport over USB. The touch input works
as a mouse, but is a little strange (touches vs mouseclicks).

On Fri, Jan 22, 2016 at 5:23 AM,   wrote:
> Hello. I was wondering if it's possible to use a tablet display As the 
> display for Beaglebone black? I am at the moment in a different country so 
> I'm not really thinking to buy a monitor that I would have to leave here 
> since when I finish my work here. But I have a spare tablet,  functional and 
> ready to use. If I can use it somehow as a screen that would be great. Even 
> if I have to take apart the tablet and extract the lcd and digitizer that 
> would be OK. Touch input is not my biggest concern to make it clear.
> Regards, Lemi
>
> --
> 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] VNC running on Ubuntu

[Przemek Klosowski]

On Sun, Jan 17, 2016 at 12:49 PM, Kuba S.  wrote:

> The screen that shows up is without anything (status bar, clock, start
> etc.). The only thing I can do is a right click to show context menu. There
> I can choose from couple of commands like run terminal, switch monitors or
> run web browser. And those works - I can run the terminal or view web pages.
> However I can't get to e.g. file browser.
> It's the same when I run x11vnc and tightvnc.
> I've went through couple of examples from the web and proposition of solving
> similar problems. Nothing worked.
>
> Could this be somehow connected to "headless" debian installation (the
> monitor was never attached)?

Almost certainly yes. X11 is just a display server: it's ready to
display windows for X11 applications, but visible windows are only
showing up because someone, somehow started running an X11
application. As you discovered, you can run those applications by hand
(by the way, file browser may be provided by application 'nautilus',
or several others---I am not sure which one is provided on your
system).
More importantly, there usually is an application that orchestrates
windows on an X11 display---it's a combination of a X11 session
manager and window manager. You can run it by hand just like a regular
application---try one of twm, fvwm, xfwm, lwm (again, they may or may
not be installed on your system, so you may need to use apt-get to
install some). Most window managers will have a way to start
applications by mousing/clicking around, either via clickable icons or
menus.

-- 
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] blank flasher

[Przemek Klosowski]

On Fri, Jan 8, 2016 at 1:08 AM, Tim Limon  wrote:

> I’ve included the log from the serial port during two boot attempts: one
> with S2 not depressed and one with S2 depressed.  Let me know what to do,
> please.

I don't know how to solve your problem, but I just noticed that
there's not much difference between your two boot logs.
They both fail to load slot-6 and then crash the kernel on unhandled
fault at cpsw_probe+0x348/0x960; all the other
differences seem to be immaterial.
I don't know the slot-6 issue is important or just a red
herring---Robert will probably know.

-- 
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] PRU "DMA" signalling to Linux Kernel cache issue

[Przemek Klosowski]

On Sun, Jan 3, 2016 at 8:46 AM, Tom Smith  wrote:
> Hello,
>
> I encounter a caching issue with my application. I will describe what I want
> to do, how I planned to do it and what goes wrong:
>
> WHAT:
>
> By using the PRU on my BBB, I want to timestamp a periodic rising edge on
> one input pin in a nanosecond scale and signal it to a Linux Kernel module
> on the ARM.

OK, I think I understand what you want to do.

> HOW:
>
> To receive an interrupt in my kernel module, I bridged the pin with the
> rising edge to a second one (timer4 interrupt).
> This interrupt fires a few microseconds after the event happened.
>
> To read values from the PRU with best determinism and lowest latency, I
> allocated some DDR memory with dma_alloc_coherent() in my kernel module and
> handout the address via debugfs to the PRU.
>
>
> The PRU is in endless loop:
>
> wait for rising edge, read out the PRU cycle counter and write the cycle
> counter to the DDR memory address.
> This works like a charm and I got the event's cycle counter snapshot in my
> kernel module!

That's pretty clever.

> The kernel module interrupt is firing a few microseconds after the event and
> has some jitter I want to avoid.
>
> So I decided it would be best to burst the actual cycle counter to a second
> ram address for a ten thousand times by the PRU so when the Kernel module
> reads this ddr location, It knows the difference from the event's cycle
> counter and the cycle counter now.
>
> This does not work!
>
>
> WRONG:
>
> Initially everything appered to be working. I was reading out for example:
>
> event cycles: 1000
> now cycles: 4300
>
> great!
>
>
> But to test the "now cycles" counter, I added to the kernel module to read
> it thousand times in a loop. Guess what? It is thousand times the same.
>

Just to make sure, did you declare the variables as volatile? If you
forgot, the compiler could be playing tricks on you by not reloading
them.

So, I am a little suspicious of the numbers, both of their magnitude
and of the relative difference. If the interrupt latency is few us,
then the cycle count difference should be few hundred:
PRU runs at 200MHz and your code presumably does the cycle count read,
DDR write and a loop/backward jump.

To check the exact timing, you'd have to provide the actual code,
either the relevant loop snippet or put the whole thing on pastebin.

Are you sure that you're using the correct word size?

-- 
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] IP68 enclosures

[Przemek Klosowski]

On Thu, Nov 12, 2015 at 12:42 AM, Peter Lawler  wrote:
> Just wondering if anyone has any recommendations for IP68 enclosures, with
> and/or without option to mount LCD screen (not touchscreen).

I recommend the tupperware solution:
http://www.instructables.com/id/Use-tupperware-as-Projects-Enclosures-1/
especially those containers with four locking tabs.

On the other hand, if your friend can afford the yacht, he probably
has spare change for a proper IP68 enclosures, which have come down in
price
http://www.amazon.com/Estone-Waterproof-Plastic-Electronic-Enclosure/dp/B00JEWNKR0%3FSubscriptionId%3DAKIAILSHYYTFIVPWUY6Q%26tag%3Dduckduckgo-ffnt-20%26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%26creativeASIN%3DB00JEWNKR0

-- 
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] ADC & PRU?

[Przemek Klosowski]

You can't feed more than 1.8V to ADC without damaging it. You can, however,
scale it with a simple resistor divider (resistor R1 connected between the
ground  and second resistor R2, which is then connected to your signal),
and hook the ADC to the middle of the divider  where it will be scaled down
by the ratio R1/(R1+R2). How quickly do you want the result? If it's
miliseconds, Linux is perfectly capable of that; if microseconds, then PRUs
can do it; otherwise, you'd have to come with an analog multiplier circuit.

On Fri, Oct 30, 2015 at 7:23 AM, John  wrote:

>
> I'm a hobbyist with a recent BBB and I want to use a couple of ADC
> channels in real time (alternate).  As nearly as I can tell, this is not
> supported by the two risk units.
> Have I missed something?
>
> BBB and Linux are new to me.  One of the things I would like to do is
> compute a ratio between two voltages, each of which might exceed 1.8 VDC.
> One solution might be to use DACs to sent feedback voltages to operational
> amplifiers that are supplied by 1.8 VDC.  The goal is to determine the
> ratio as quickly as possible and without waiting for Linux to get around to
> it (waiting for the ADC to happen).
>
> 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.

Re: [beagleboard] Re: My circuit that burnt my BBB needs modify: I wonder if the ground is necessary

[Przemek Klosowski]

The circuit looks reasonable in general, but it's hard to tell because you
don't show all the connections and labels. Like, what are the G and V
things on the relay boards? I assume you're talking about
http://www.superdroidrobots.com/product_info/TE-249-070_Schematic.pdf, so
probably JP17-1 and -2, but how would we know for sure? can you redraw your
schematic with more specific connection diagram, listing the specific
connections you make to the relay board and the DAC?

Also, it's possible to mess up by plugging the things in the wrong
sequence, e.g. if you work under power and connect the data lines before
connecting power.

On Wed, Oct 28, 2015 at 10:57 PM, Yongfan Men  wrote:

> Forgot to attach the illustration figure.
>
>
> On Wednesday, October 28, 2015 at 10:41:36 PM UTC-4, Yongfan Men wrote:
>>
>>
>> I burnt my BBB, which let me very sad. I ordered a new one online because
>> it's an urgent project, but until I have fully figured out what happened
>> with my circuit, I dare not connect the BBB to it again.
>>
>> This circuit, as shown in  the attached image, worked all well during the
>> last whole week. I turned it off this Monday, and turned it on this
>> morning, and Bang! The BBB's burnt. It won't boot up. When I plug the 5V
>> power cable or mini USB cable to it, only the PWR LED will light up a
>> little bit, and it never boots up again. I didn't believe it's my circuit's
>> fault, so I plugged my backup BBB on, and again, it's killed. I burned $100
>> in 10 minutes.
>>
>> I'm attaching the circuit design here because I need to know if this
>> design is really problematic. Let me explain a little bit: I'm trying to
>> control an I/P converter (SMC ITV0011), which is driven by a 0-5V voltage
>> signal and powered by 12V dc. *The problem is It only has three wires,
>> and the ground wire is shared.* That's why I think I have to connect all
>> of the ground wires together.
>>
>> I'm using a DAC chip (MCP4725) to generate a proper voltage control
>> signal to the I/P converter. This DAC chip is communicated by I2C, and
>> powered directly by the onboard 3.3V from the BBB. I have carefully checked
>> with multimeter that with digital command through I2C, the voltage could be
>> linearly generated, which is very cool.
>>
>> I'm using a GPIO to control a relay (powered by 5V) to control the on/off
>> of the I/P converter, which means only when I want the I/P converter to be
>> turned on, I will send the GPIO to 1. Otherwise, when GPIO is 0, the I/P
>> converter would not be powered, which is a way of enlarging the lifetime of
>> the $200 I/P converter.
>>
>> That's the whole idea. And I also used a Qt GUI to control the output of
>> both the I2C and GPIO. Last week, I enjoyed a lot using the stylus to drag
>> the slidebar on the touch screen to adjust the pressure output by the I/P
>> Converter. I just don't understand why it suddenly became so dangerous.
>>
>> But last week I did noticed one strange phenomenon. When the relay was
>> not working, there is a strange minus 17 volt on the relay output port.
>> This is probably 12V + 5V, But I don't understand neither why this is a sum
>> nor why it is negative, and since everything works, I didn't pay attention.
>>
>> Today, after I burned the two BBB, I measured the voltage of the relay
>> output port when it's off again. The voltage is 1.7V (5V-3.3V?). So strange!
>>
>> From my newbie understanding, any output signal should has two wires, one
>> signal wire, and one ground wire. Because you need a closed circuit to
>> transfer electrons. That's how coaxial cable works for oscilloscope, and
>> function generator, and multimeter, and so forth. Therefore I'm connecting
>> the GND from BBB to DAC, and the GND from DAC to I/P converter; also the
>> GND from 12V dc power source to the I/P converter. *This equals that the
>> Ground from the 12V dc power source is directly connected to the BBB*.
>> But theoretically, I don't see any problems, since it's just ground!
>>
>> In the image, I think once I remove the red wire, the BBB will be
>> isolated from the whole 5V and 12V dc circuits. But I don't know if this is
>> the right solution, and also if the voltage output from the DAC will be
>> transfered to the I/P converter. If any of you could explain a little bit
>> about this issue, I would appreciate a lot.
>>
>> Also, If I want to add some more protection to the BBB (on both I2C and
>> GPIO), what should I do? 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 

Re: [beagleboard] Ethernet is unable to receive packets, but is able to send packets. Any help on how to fix this?

[Przemek Klosowski]

Your BBB has two interfaces, usb0 and eth0. It looks like you're connected
via USB, presumably to your PC, but the wired ethernet interface eth0 is up
too, and the routing matches on both, so the packets could be leaving
through both interfaces. I assume you don't have the wired network
connected, so the reason you're not getting a reply is either because your
PC is not set up to route the USB out via its own uplink.
Why would that be? we don't know because you didn't say what's your
environment--you have to specify what are you running on your BBB and on
your PC, and how you've set it up.

On Thu, Oct 22, 2015 at 5:34 PM,  wrote:

>
> root@beaglebone:~# ping google.com
> PING google.com (4.35.21.173) 56(84) bytes of data.
> ping 169.254.136.128
> ^C
> --- google.com ping statistics ---
> 175 packets transmitted, 0 received, 100% packet loss, time 174012ms
>
>
>
>
> root@beaglebone:/# route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric RefUse
> Iface
> 0.0.0.0 192.168.7.1 0.0.0.0 UG0  00
> usb0
> 0.0.0.0 134.74.185.50   0.0.0.0 UG0  00
> eth0
> 134.74.185.00.0.0.0 255.255.255.0   U 0  00
> eth0
> 192.168.7.0 0.0.0.0 255.255.255.252 U 0
>
>
>
> root@beaglebone:/# ifconfig
> eth0  Link encap:Ethernet  HWaddr d0:5f:b8:f5:93:cd
>   inet addr:134.74.185.104  Bcast:134.74.185.255
>  Mask:255.255.255.0
>   inet6 addr: fe80::d25f:b8ff:fef5:93cd/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:7577 errors:0 dropped:5 overruns:0 frame:0
>   TX packets:657 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:910737 (889.3 KiB)  TX bytes:68224 (66.6 KiB)
>   Interrupt:40
>
> loLink encap:Local Loopback
>   inet addr:127.0.0.1  Mask:255.0.0.0
>   inet6 addr: ::1/128 Scope:Host
>   UP LOOPBACK RUNNING  MTU:65536  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:0
>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>
> usb0  Link encap:Ethernet  HWaddr 56:ec:45:ea:75:d9
>   inet addr:192.168.7.2  Bcast:192.168.7.3  Mask:255.255.255.252
>   inet6 addr: fe80::54ec:45ff:feea:75d9/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:3642 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:2046 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:361627 (353.1 KiB)  TX bytes:324515 (316.9 KiB)
>
> --
> 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] Inline assembly on Beaglebone.

[Przemek Klosowski]

On Sat, Oct 17, 2015 at 11:19 AM,  wrote:

> void main(void) { asm("mov r0,r0"); }
>

You are trying to use ARM machine language. If you run this on a PC with
the x86 GCC you get the error you reported. You need to either use ARM
cross-compiler on the PC or compile it on the ARM platform (beaglebone).

-- 
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 could I compile a hello.ko that can run on my BBB?

[Przemek Klosowski]

On Fri, Oct 16, 2015 at 2:53 PM, Mian Tang  wrote:

> Hi,
>
> I connect my BBB to internet do update. When I use "uname -r" to check the
> version, it displays: 3.8.13-bone79.
>
> Now, I hope to compile a hello.ko module driver on PC and run it on the
> board.
>
You seem to have a test kernel module that you want to compile and insert
into a running kernel. Normally, you'd just 'make hello.ko' and 'insmod
hello.ko'. This wouldn't work if the kernel API used by the module was so
different that it wouldn't work with the header files used by your current
kernel (btw. for this to work, your system has to have kernel development
packages installed).
Try this and report if you encounter errors--it'll be much easier to help
if you say in detail what you did and what happened as a result.

-- 
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 use libusb library to connect to ethernet using microUSB

[Przemek Klosowski]

On Thu, Oct 8, 2015 at 6:05 AM,  wrote:
>
> I am new to android i want to find a way to develop a software which can
> be used to connect and use internet by using Ethernet adapter and by not
> using wifi or mobile internet.
> I got the details that libusb can be used for this but i dont know how to
> use it and create a android side coding to send and receive IP packet using
> this USB Ethernet Adapter.
>
> You don't need libusb: when you plug in a USB ethernet adapter it should
get recognized by the kernel and create another Ethernet device, which
should become ready to carry your network traffic. This, of course, depends
on the specific hardware being recognized, i.e. having an existing network
driver support in the kernel---but most of them are covered.

-- 
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] Unable to receive data via serial line

[Przemek Klosowski]

If you suspect your USB serial converter, a quick test is to short the RX
and TX and check that whey you type in your minicom/hyperterm you see the
hardware echo it back (just make sure you don't set it up for local
software echoing).

On Sat, Oct 3, 2015 at 2:14 PM, deepak srinivasan 
wrote:

> Hi
>
> I had recently bought a Beaglebone Black rev C and was getting started
> following online tutorials
> I tried to setup basic serial communication with BBB through J1 serial
> connector
>
> I am able to transmit data from my laptop to BBB via serial line and I can
> see the data coming to /dev/ttyO0 successfully
> But receiving data from BBB is not working
> Only once receive worked where it showing just gibberish in terminal and
> after that it consistently failed to work
>
> dmesg or syslog doesnt show any errors
> I checked for basic continuity and my USB to serial converter doesnt seem
> to one causing issue
>
> Can anyone help me on this issue
> Thanks in advance
>
> regards
> deepak
>
> --
> 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] Re: 8 ADC input @20 KHz

[Przemek Klosowski]

On Sat, Oct 3, 2015 at 9:35 PM, William Hermans  wrote:

>
> http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide
>
> [listing severe limitations of the ADC driver]
>
But that page claims it's obsolete and directs to the new page:

http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User's_Guide

which seems to list fewer limitations.

-- 
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: Can a beaglebone black go through a luggage X-ray machine?

[Przemek Klosowski]

On Tue, Sep 22, 2015 at 10:39 AM, acheesehead  wrote:

> I went through security with one and TSA thought it was suspicious. They
> put it under the X-Ray machine and stared at it for about a minute. It has
> been confused since then. Sometimes boots, sometimes not. While a brief
> exposure is probably OK. A prolonged exposure might fry something.
>
> Well, normally, ionizing radiation can only change charge states in
internal electrical nodes, i.e. flip bits in memory and internal
CPU/chipset logic. In other words, it can't damage anything permanently.

Theoretically, very high energy Xrays could disrupt crystalline structure
within the chips, i.e. damage them permanently, but it requires energy and
intensity much larger than that of an airport Xray machine. Whatever your
problems are, it's not because of the Xray scan---did the TSA folk
touch/handle the BBB? if so, they could have zapped it with static
discharge, which is much deadlier than Xrays.

-- 
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 a beaglebone black go through a luggage X-ray machine?

[Przemek Klosowski]

Luggage xray machine is so gentle that it should not expose photographic
film so beaglebone should not be affected---it's put together with standard
electronic components which are supposed to be resistant to that level of
ionizing radiation. I haven't tested it myself though.

On Mon, Sep 21, 2015 at 2:03 PM,  wrote:

> Can a beaglebone black survive going through a luggage X-Ray machine?
>
> --
> 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.