Re: [beagleboard] Help! Beaglebone Blue seems to have died

On Thu, Mar 30, 2017 at 9:22 PM, Ted Carancho wrote: > Thanks for the response William, > I followed the directions online to put in a formatted uSD card with > firmware, held the boot button down (it's a momentary push button, not an > on/off switch) while plugging in a

Re: [beagleboard] BeagleBoard doesn't boot from SD card (only power LED, no other LEDs)

I use dd regularly so get images onto sdcards, and have had zero issues. bmap-tools is supposed to be much faster. but I was unable to get bmap-tools working on my Debian workstation. Which runs wheezy, and is probably the problem. william@eee-pc:~$ *uname -a* Linux eee-pc 3.2.0-4-686-pae #1 SMP

Re: [beagleboard] Help! Beaglebone Blue seems to have died

Hello, I do not have a beaglebone blue personally, but if you mentioned it I'm not seeing if you switched the boot switch or not. https://github.com/beagleboard/beaglebone-blue/blob/master/docs/BeagleBone_Blue_ShortSpec.pdf Scroll down to the "balloon" diagram, and look at the switch that is

Re: [beagleboard] Add a sensitive motion detector, and also to send a picture

Yes, this can be done. In fact I'm working on a system right now that does something similar to this. I can not get into much detail of this project, as there is an NDA involved. What I could say however, is that you may want to look into using a PIR sensor, which can be had fairly inexpensively

Re: [beagleboard] How will the ROM boot loader detect the MMC card without any driver

The MLO *file* is the first stage bootloader, which in turns sets up, or instructs uboot( the second stage boot loader ) how it can use the hardware. To a point. If you need a better explanation of that then you have google to help you. But if you need to know why you need to copy the MLO file

Re: [beagleboard] Hardware backdoor / violation / malware / spyware risks after purchase

https://wiki.debian.org/SELinux It would be very hard for this to happen without some one seeing this, and posting all over the internet about it. This sort of thing happens more often than some realize. Take the Sony rootkit situation years ago, that was posted all over the internet, and the bad

Re: [beagleboard] Connect Bridge Board Through Cape

It does, and it doesn't. If both capes use some, or all of the same pins, it probably won't work. So you'll need to do the research, and see what pins the capes use. On Sat, Mar 25, 2017 at 7:54 AM, wrote: > Currently I have a beaglebone Green connected to a Melzi board via

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

On Fri, Mar 24, 2017 at 11:10 AM, Przemek Klosowski < przemek.klosow...@gmail.com> wrote: > > 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

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

On Fri, Mar 24, 2017 at 9:34 AM, ags <alfred.g.schm...@gmail.com> wrote: > @William Hermans I thought I'd share the result of my efforts to reliably > stream data from ARM host (Linux userspace) to PRU. > > I instrumented the PRU ASM code to use the CYCLE register for very prec

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

two lines of easy to read / understand code? You know, I can not say with 100% certainty that is is not. But I seriously doubt it. On Thu, Mar 23, 2017 at 12:32 PM, William Hermans <yyrk...@gmail.com> wrote: > > > On Thu, Mar 23, 2017 at 5:48 AM, ags <alfred.g.schm...@gmail.com

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

On Thu, Mar 23, 2017 at 5:48 AM, ags wrote: > OK, I will use the busy-wait loop w/ usleep and test. The reason I used > select was I thought it would allow me to do other things (I need to have > another process, thread, or loop in this same application serving out

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

. Have that remote location time stamp the data. On Thu, Mar 23, 2017 at 3:03 AM, William Hermans <yyrk...@gmail.com> wrote: > > > On Wed, Mar 22, 2017 at 10:13 PM, ags <alfred.g.schm...@gmail.com> wrote: > >> I thought using select() to wait for notification

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

On Wed, Mar 22, 2017 at 10:13 PM, ags wrote: > I thought using select() to wait for notification of an event (by > "listening" to the fsys uio files) would free the ARM cpu to do other > things while waiting, but provide the most immediate path to the user space >

Re: [beagleboard] Map gpio button to a combination of keyboard keys in device tree or otherwise

Start with this: https://wiki.archlinux.org/index.php/extra_keyboard_keys#In_Xorg If you're not running X, go up a bit to the console explanation, and follow that to get your key combination number. So there are a couple ways to get this number, You hook up a keyboard to the beaglebone, through

Re: [beagleboard] Re: Ssh server

So the point of my original post was that you did not tell us which OS you're running on your beaglebone. So you at best are going ot have a bunch of people speculating at what the potential cause can be. However the Original OS( distro if you prefer ) was Angstrom, which had issues with the

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

On Wed, Mar 22, 2017 at 8:45 AM, Charles Steinkuehler < char...@steinkuehler.net> wrote: > > Note you might need an -rt or -xenomai kernel to achieve reliable > operation, I've seen the non-rt kernels occasionally "wander off into > the weeds" for several hundred mS at a time. > > -- > Charles

Re: [beagleboard] Ssh server

On Wed, Mar 22, 2017 at 7:07 AM, wrote: > Hello everyone, > > The beagle bone black board ssh server suddenly stopped working! Please > can you help me. > My mind reading apparatus stopped working ! can you please help me ? -- For more options, visit

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

I'd say you most likely have a flaw in your code, because what you describe is only around 1.6 MiB/s. I'd also like to point out that you will rarely, if ever see any USB interface that will achieve a full 450Mbit/s. For example, the g_ether network gadget driver at best usually only achieves

Re: [beagleboard] Issues with configuration of USB Ethernet adapter under Debian

On Mon, Mar 20, 2017 at 8:44 PM, Jon Seymour wrote: > > William, > > I just tried the systemctl stop/start networking scenario again and found > that it does actually work in this case, so the problem I initially > reported does appear to be a startup race condition as you

Re: [beagleboard] Issues with configuration of USB Ethernet adapter under Debian

So, it's very likely you need the driver to come up before you can bring the interface up. So, one option would be to "inject" your driver into the initrd( very advanced ), or to write a systemd service( a systemd timer may also work ) that sets the device up appropriately. My thinking is that

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

This can all be done from userspace. Seriously, how do you games that use joysticks as in input work ? All those other board mentioned are not worth the time investment, specifically for this single task. Also, I own several TI LM4F dev boards as well as the TM4C1294. The TM4C1294 has issues, but

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

On Fri, Mar 17, 2017 at 10:49 PM, 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

Re: [beagleboard] Industrial Sensor with BeagleBone Green

Hello Anna, What exactly is it that you think a cape will offer you instead of using the sensor you linked to ? I mean technically, a sensor, and a cape solve two completely different problems, but I think I can see where you're coming from. Also , just looking( glancing ) at the sensor you

Re: [beagleboard] Re: on accessing the p8/9 headers

Well, this guy is already on my blacklist, so as far as I'm concerned . . . let me post corny joke garbage posts. Granted, I'm only 1 of those 11,495 people who got mailed. . . On Mon, Mar 13, 2017 at 2:29 PM, Robert Nelson wrote: > On Sun, Mar 12, 2017 at 8:26 PM,

Re: [beagleboard] debian testing: 2017-03-12

Yeah,sorry about that, had overlays on the mind, and couldn't find my workflow file easily to remember the name of the service. -- 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] debian testing: 2017-03-12

On Mon, Mar 13, 2017 at 12:06 PM, Robert Nelson wrote: > > > Yeah, we are back to being more stable again.. The Windows Driver > "patch" required lots of changes behind the scenes to now deal with > the "dual" usb-ethernet adapters. > > OK, cool.So what I should be able

Re: [beagleboard] debian testing: 2017-03-12

Robert, heh, i like the hash tag for the last link. Would you say that these images to the best of your knowledge are stable enough to test on a "production" system? e.g. a test system that is looking towards production. I wouldn't mind testing, but I do have work to complete as well. What we're

Re: [beagleboard] Managing GPIO with C++

On Sun, Mar 12, 2017 at 4:58 PM, Jacek Radzikowski < jacek.radzikow...@gmail.com> wrote: > The library does not use sysfs, but mmap. This was one of the most > important reasons why I spent time to write it. > Oh, ok right, I remember that git now. Pretty cool library. However, I'd still argue

Re: [beagleboard] Managing GPIO with C++

On Sun, Mar 12, 2017 at 4:48 PM, Jacek Radzikowski < jacek.radzikow...@gmail.com> wrote: > Dror, > > a while ago I wrote for myself a small class library which implements > wrappers for gpio, spi, and i2c, and provides simple and user friendly > interface to the application. Take a look at it,

Re: [beagleboard] Managing GPIO with C++

pin, to start manipulating it. But if you have any problems with the example code in the link i gave above, I'd be able to help sort it out. Generally though if you google error messages, you should be able to figure things out on your own. On Sun, Mar 12, 2017 at 4:38 PM, William Hermans <yyrk...@gm

Re: [beagleboard] Managing GPIO with C++

On Sun, Mar 12, 2017 at 5:47 AM, Dror Lugasi wrote: > Hi guys! > > I am writing a program with C++ for the BBB that has some serial ports and > Ethernet communication, and i want to control the GPIO with it. > > At this moment i am able to activate / read / write / and

Re: [beagleboard] Re: Is there a way to send an interrupt from userspace to the PRU-ICSS?

the opening paragraph labeled "purpose", and replace "DSP" with "PRU", for all intents and purposes. of this discussion. On Fri, Mar 10, 2017 at 7:59 PM, William Hermans <yyrk...@gmail.com> wrote: > OK, according to some dicumentation I was able to find q

Re: [beagleboard] Re: Is there a way to send an interrupt from userspace to the PRU-ICSS?

OK, according to some dicumentation I was able to find quickly, address 0x800 is the base address for the start of the DDR memory on the TI EVM board. Which is very similar to the beaglebone in memory layout. On Fri, Mar 10, 2017 at 7:38 PM, William Hermans <yyrk...@gmail.com>

Re: [beagleboard] Re: Is there a way to send an interrupt from userspace to the PRU-ICSS?

10, 2017 at 7:24 PM, William Hermans <yyrk...@gmail.com> wrote: > > > On Fri, Mar 10, 2017 at 2:53 PM, ags <alfred.g.schm...@gmail.com> wrote: > >> I've had a hard time getting any definitive responses to questions on the >> subject of memory access & lat

Re: [beagleboard] Re: Is there a way to send an interrupt from userspace to the PRU-ICSS?

On Fri, Mar 10, 2017 at 2:53 PM, ags wrote: > I've had a hard time getting any definitive responses to questions on the > subject of memory access & latency. It is true that the PRU cores have > faster access to DRAM that is part of the PRU-ICSS (through the 32-bit >

Re: [beagleboard] Re: Making a custom SD image of BBB's eMMC

For example here you will notice two different H tags for two of the same type of image: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_iot Jessie Snapshot iot Flasher: (iot) (All BeagleBone Variants) > > Get prebuilt image: > > wget >

Re: [beagleboard] Re: Making a custom SD image of BBB's eMMC

On Fri, Mar 10, 2017 at 10:24 AM, Justin Pearson wrote: > This sounds like what I'm looking for, thanks. > > Follow-up: Is there an easy way to modify this procedure so the new BBB > simply boots from the SD card instead of wiping out its eMMC with the image > on the SD

Re: [beagleboard] cape-universal and console image?

On Wed, Mar 8, 2017 at 11:47 PM, Drew Fustini wrote: > Hi Robert - > > Is the Debian Jessie console image expected to work with cape-universal? > > I just tried the console image from: > https://rcn-ee.com/rootfs/bb.org/testing/2017-02-12/console/ > > No cape-universal

Re: [beagleboard] Re: Is there a way to send an interrupt from userspace to the PRU-ICSS?

On Wed, Mar 8, 2017 at 4:34 PM, ags wrote: > Correct - to preserve deterministic execution, the PRU cannot be > asynchronously interrupted. Polling (of some form) is required. > > Back to the OP, there is a way to register a (non-async) interrupt with > the PRU. One

Re: [beagleboard] Re: Is there a way to send an interrupt from userspace to the PRU-ICSS?

On Wed, Mar 8, 2017 at 9:04 AM, William Hermans <yyrk...@gmail.com> wrote: > For the purpose of this discussion with ags, I do not think the actual > definition of what an interrupt is, is quite so important, as much as how > to achieve an end goal. On a single threaded &quo

Re: [beagleboard] Re: Is there a way to send an interrupt from userspace to the PRU-ICSS?

On Wed, Mar 8, 2017 at 7:21 AM, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote: > On Tue, 7 Mar 2017 21:52:21 -0700, William Hermans > <yyrk...@gmail.com> declaimed the following: > > >I get the feeling however that you're misunderstanding the purpose of an > >

Re: [beagleboard] Is there a way to send an interrupt from userspace to the PRU-ICSS?

y well be faster to > just set a bit in PRU memory and have PRU poll. > > If this is just nonsense, even in theory, then I'd welcome an education as > to why. > > On Tuesday, March 7, 2017 at 8:52:27 PM UTC-8, William Hermans wrote: >> >> >> >> On Tue, Mar 7, 2

Re: [beagleboard] Is there a way to send an interrupt from userspace to the PRU-ICSS?

On Tue, Mar 7, 2017 at 9:45 PM, ags wrote: > The mechanism for generating an interrupt from a PRU to the A8 (host) is > well-documented. Is there a way to send an interrupt (one of the 64 system > interrupt events documented in the PRU-ICSS literature) from userspace?

Re: [beagleboard] Wifi problems

@Robert, Which wireless chipsets are you recommending now days. As as USB<->WiFi dongles go ? On Fri, Mar 3, 2017 at 7:02 PM, William Hermans <yyrk...@gmail.com> wrote: > > > On Fri, Mar 3, 2017 at 5:35 PM, jhalpin100 <jhalpin...@gmail.com> wrote: > &g

Re: [beagleboard] Wifi problems

On Fri, Mar 3, 2017 at 5:35 PM, jhalpin100 wrote: > I'm not usinig HDMI, it seems to be disabled by default. I updated the > kernel, and it almost works now. > root@beaglebone:~# cat /boot/uEnv.txt |grep -e Audio/Video -e -emmc-overlay *##BeagleBone Black: HDMI

Re: [beagleboard] Re: Root login change?

On Fri, Mar 3, 2017 at 5:53 PM, Dennis Lee Bieber wrote: > > > Well -- if I were exposing one to the wild, I'd probably delete the > debian account too, after creating a new user account. > > That's understandable. One could actually just change the account name if

Re: [beagleboard] Re: Root login change?

if your local network ? What kind of damage are you most afraid of happening to systems on your network ? Just think about the above for a while until it sinks in. On Fri, Mar 3, 2017 at 6:28 AM, William Hermans <yyrk...@gmail.com> wrote: > > > On Fri, Mar 3, 2017 at 5:56 AM, Dennis L

Re: [beagleboard] Re: Root login change?

On Fri, Mar 3, 2017 at 5:56 AM, Dennis Lee Bieber wrote: > Let me guess -- the next step will be to have the first connection > to > "debian/temppwd" require the user to change the password. > Anyone with half a brain should already be doing that one their own.

Re: [beagleboard] Root login change?

lol . . . So I'm left wondering how many people were watching last nights conversation between the three of us, and waiting to pounce . . .lol On Thu, Mar 2, 2017 at 10:12 PM, Robert Nelson wrote: > On Thu, Mar 2, 2017 at 6:22 PM, Kurt Talke wrote:

Re: [beagleboard] Re: PRU Development

protocol. On Thu, Mar 2, 2017 at 12:34 AM, William Hermans <yyrk...@gmail.com> wrote: > Back on topic. > > I wonder if it wouldn't be simpler, and easier for everyone if someone > where to just write / create a setup script for both options. It's been a > while, so I do not rec

Re: [beagleboard] Re: PRU Development

uio_pruss, to create an all software( in PRU ) VGA adapter ? That's the last really cool project I remember achieved through the PRU's anyway . . . On Wed, Mar 1, 2017 at 11:52 PM, William Hermans <yyrk...@gmail.com> wrote: > > > On Wed, Mar 1, 2017 at 10:19 PM, Robert Nelson

Re: [beagleboard] Re: PRU Development

On Wed, Mar 1, 2017 at 10:19 PM, Robert Nelson < robertcnel...@beagleboard.org> wrote: > The above is disabled by default as of 2-3 weeks ago.. > I'm still kind of on the fence. I can completely understand wanting to just type ssh root@beaglebone and *bam* be right where I need to be to start

Re: [beagleboard] Re: PRU Development

at 8:27 PM, Robert Nelson <robertcnel...@gmail.com> wrote: > On Wed, Mar 1, 2017 at 8:39 PM, Robert Nelson <robertcnel...@gmail.com> > wrote: > > On Wed, Mar 1, 2017 at 8:13 PM, Jason Kridner <jkrid...@gmail.com> > wrote: > >> > >> > >> On W

Re: [beagleboard] Re: PRU Development

On Wed, Mar 1, 2017 at 7:53 PM, Jason Kridner wrote: > > Let's see who screams. > > Probably the same people as disabling root ssh access. ;-) > That's actually kind of funny. Funny in that recently I noticed that when rebooting one of the later 2016 image from ssh.

Re: [beagleboard] Re: PRU Development

Jason, Is this a pure uEnv.txt edit only now ? Last I looked, you had to modify the the board overlay file. Or maybe it was one of the includes, I forget which. On Wed, Mar 1, 2017 at 6:37 PM, Jason Kridner <jkrid...@gmail.com> wrote: > > > On Mar 1, 2017, at 7:48 PM, Willia

Re: [beagleboard] Re: PRU Development

I had the PRU's working with an 4.x kernel around 4-5 months ago. Basically I downloaded Jason's PRU github files, and got two of the examples working. Back then, you could only use the older UIO PRU source examples with the *bone* kernel, as TI's kernel was remoteproc only. Now days, supposedly

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

On Tue, Feb 28, 2017 at 3:41 PM, Drew Fustini wrote: > > eCAP is interesting as there seems to be two modes: capture input, and PWM > output. The use of eCAP as PWM output is already supported in mainline as > part of epwmss. > > However, the eCAP input driver written Matt

Re: [beagleboard] Re: X15 as a Build Machine

I'm actually looking into using an ODRIOD XU4 for a build machine. I bought one, and have had it here for a couple weeks now. I just have not had time to work with it yet. The XU4 is an octa-core SBC with quad A15's running at 2Ghz, and quad A7's which I do not recall what frequency these core

Re: [beagleboard] how to (physically) connect the Arduino Pro Mini?

On Tue, Feb 28, 2017 at 9:32 AM, mzimmers wrote: > Hi, William - > > Thanks for the suggestions. I think I know Linux well enough to start > learning the nuances of how its embedded features work. And, I'm already > somewhat familiar with various peripheral devices. In

Re: [beagleboard] how to (physically) connect the Arduino Pro Mini?

On Mon, Feb 27, 2017 at 3:13 PM, mzimmers wrote: > Hi, William - > > Small scale answer is that I'm trying to perform the exercises in Molloy's > book. Large scale answer is that I'm trying to learn about embedded Linux, > particularly as it applies to bus and peripheral

Re: [beagleboard] how to (physically) connect the Arduino Pro Mini?

net> wrote: > you will also need a copy of Electrical Engineering 101 by Ashey. You'll > probably want to read it before going further. > > On Mon, Feb 27, 2017 at 2:53 PM, William Hermans <yyrk...@gmail.com> > wrote: > >> >> >> On Mon, Feb 27, 201

Re: [beagleboard] how to (physically) connect the Arduino Pro Mini?

On Mon, Feb 27, 2017 at 12:32 PM, Andrew Kirch wrote: > you likely don't need an overlay, simply modify /sys at boot to mux the > pins to serial.. > That would take an awful lot of work, and knowledge compared to simply loading an overlay at boot, or interactively from the

Re: [beagleboard] how to (physically) connect the Arduino Pro Mini?

On Mon, Feb 27, 2017 at 12:19 PM, Andrew Kirch wrote: > I'm going to make a couple assumptions here and hope I'm not going in the > wrong direction. > assuming you have a breadboard, solder some male pins on the arduino pro > mini and stick it on a breadboard across the

Re: [beagleboard] how to (physically) connect the Arduino Pro Mini?

On Mon, Feb 27, 2017 at 11:49 AM, mzimmers wrote: > Hi, Andrew - > > Yeah, I suppose I should have included that information. If your book is > the same edition as mine, on page 315 you'll find figure 8-16. There, the > author shows the wiring connections between the BBB and

Re: [beagleboard] how to (physically) connect the Arduino Pro Mini?

Additionally, each pin has a maximum value in current that it can sink or source. I can not remember is these values are listed in the datasheet, TRM, or SRM. But these values are listed for each pin. On Mon, Feb 27, 2017 at 12:13 PM, William Hermans <yyrk...@gmail.com> wrote: > > &

Re: [beagleboard] usage of internal "realtime" and M4 cores

On Mon, Feb 27, 2017 at 10:34 AM, MDX wrote: > so i am pretty amazed of how big a punch AM5728 packs: 2 fast CPU cores, 2 > very versatile KeyStone cores (of which i`ll be a happy user very soon > thanks to you), 2 "realtime" (whichever they are) ,and 2 Cortex-M4 cores, >

Re: [beagleboard] Managing Wi-Fi

Do I sense sarcasm ?! ;) On Mon, Feb 27, 2017 at 8:26 AM, Robert Nelson wrote: > > > On Feb 27, 2017 9:14 AM, "Steve Groen" wrote: > > > > > > Managing Wi-Fi: > > > > If the BBGW is moved to a new Wi-Fi environment, what is the > > easiest procedure

Re: [beagleboard] Re: BeagleBone Black GPIO max frequency/bus latency (without using PRU)?

Well, you wont be toggling a GPIO pin at 10Mhz unless you are using the PRU . . ./dev/mem + mmap(), or a kernel module ar best *may be able to achieve ~1.5Mhz. On Mon, Feb 27, 2017 at 7:45 AM, Dennis Lee Bieber wrote: > On Sun, 26 Feb 2017 23:05:33 -0800 (PST), >

Re: [beagleboard] can't connect to the internet beaglebone black

So first off, stop posting multiple posts on the same topic Quickest way for someone like me to permanently ignore all future posts from you. Secondly, why don't you contact the author from that video and ask him for help ? Seems like it's one of D.R. Molloy's videos. On Sat, Feb 25, 2017 at 4:22

Re: [beagleboard] How to connect WD Element 1 TB HDD to beaglebone black

You can not power a hard drive directly from, the beaglebone. Period. Full sized 3.5" drives can peak to 2-3A draw when first spinning up. For a 2.5" "laptop" type drive. It would not be unheard of for the drive to need 1-2A at spin up. So, you need a different enclosure for a hard drive, that

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

On Sat, Feb 25, 2017 at 11:23 AM, Drew Fustini wrote: > Thanks for following up. > > I've been using the tieqep module to read absolute position count of a > rotary encoder knob. I'm curious what other use cases people have for eQEP? > I'm not sure I would have an out of

Re: [beagleboard] Tips on using a BBGW in a consumer product

Fri, Feb 24, 2017 at 12:06 PM, William Hermans <yyrk...@gmail.com> wrote: > > > On Tue, Feb 21, 2017 at 1:32 PM, Steve Groen <s.gr...@mchsi.com> wrote: > >> Generally: >> >> How do you incorporate a BBGW into a consumer product? >> >>

Re: [beagleboard] Tips on using a BBGW in a consumer product

On Tue, Feb 21, 2017 at 1:32 PM, Steve Groen wrote: > Generally: > > How do you incorporate a BBGW into a consumer product? > > Does anybody do this, or do they design their own board > > using BBGW as a base? > I almost did not respond to your post. Because we

Re: [beagleboard] Running GUI apps in a non-desktop debian BBB

So, I've got an idea. Let's take a single core processor system with only 512M of ram, and try to make things worse by running an app, and other software that will make the system crawl. There are better ways to approach this problem without the need to bog the system down with needless

Re: [beagleboard] Re: using desktop window for BBB console

On Fri, Feb 17, 2017 at 2:21 PM, mzimmers wrote: > Yeah, I was originally running Ubuntu...changed when I started playing > with the BBB, as most of the examples used Debian and I figured there might > be some advantage to having the same OS on my desktop. > So every day

Re: [beagleboard] Re: using desktop window for BBB console

17, 2017 at 10:58 AM, William Hermans <yyrk...@gmail.com> wrote: > You can always retrograde to Wheezy, or use one of the Ubuntu 14.04 > variants. Personally I lean towards Lubuntu when I need a Linux desktop. > But I do not use a Linux desktop all that often. I like Lubunt

Re: [beagleboard] Re: using desktop window for BBB console

You can always retrograde to Wheezy, or use one of the Ubuntu 14.04 variants. Personally I lean towards Lubuntu when I need a Linux desktop. But I do not use a Linux desktop all that often. I like Lubuntu because its LXDE that is highly configurable, and fast due to the desktop being accelerated.

Re: [beagleboard] Best method to run config-pin after bootup?

On Fri, Feb 17, 2017 at 2:07 AM, William Hermans <yyrk...@gmail.com> wrote: > It's been my experience that if you're running 4.x kernel it's best not > to use config-pin at all. For simple GPIO it works ok most of the time. But > for more complex configurations it may not wor

Re: [beagleboard] Best method to run config-pin after bootup?

It's been my experience that if you're running 4.x kernel it's best not to use config-pin at all. For simple GPIO it works ok most of the time. But for more complex configurations it may not work all that well. There is at least one GPIO( P9.27 I think ) that won't properly display it's high /

Re: [beagleboard] Re: using desktop window for BBB console

On Thu, Feb 16, 2017 at 6:44 PM, mzimmers wrote: > mzimmers@debian:~$ dmesg | grep USB0 > [3.392399] usb 3-3: FTDI USB Serial Device converter now attached to > ttyUSB0 > [6.672343] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now > disconnected from ttyUSB0 >

Re: [beagleboard] Re: using desktop window for BBB console

Well you could run this command: *william@eee-pc:~$* dmesg | grep USB0 [9831384.302124] usb 3-1: pl2303 converter now attached to ttyUSB0 On Thu, Feb 16, 2017 at 6:31 PM, mzimmers wrote: > No, I get this. Perhaps the tail isn't long enough? > > mzimmers@debian:~$ dmesg |

Re: [beagleboard] Re: using desktop window for BBB console

And when running dmesg |tail you do not get something similar to this ? dmesg | tail ... ftdi_sio 1-1.1:1.0: FTDI USB Serial Device converter detected usb 1-1.1: Detected FT232RL usb 1-1.1: Number of endpoints 2 usb 1-1.1: Endpoint 1 MaxPacketSize 64 usb 1-1.1: Endpoint 2 MaxPacketSize 64

Re: [beagleboard] Re: using desktop window for BBB console

Run this really quickly and show me the output. $ find / -type f -name ttyUSB0 On Thu, Feb 16, 2017 at 6:21 PM, William Hermans <yyrk...@gmail.com> wrote: > > > On Thu, Feb 16, 2017 at 6:14 PM, mzimmers <mzimm...@gmail.com> wrote: > >> mzimmers@debian:~$ lsmod

Re: [beagleboard] Re: using desktop window for BBB console

On Thu, Feb 16, 2017 at 6:14 PM, mzimmers wrote: > mzimmers@debian:~$ lsmod | grep usbserial >> usbserial 36293 1 ftdi_sio >> usbcore 195468 11 btusb,snd_usb_audio,usb_ >> storage,usbserial,snd_usbmidi_lib,ehci_hcd,ehci_pci,usbhid, >>

Re: [beagleboard] Re: using desktop window for BBB console

And the output you get from this ? *william@eee-pc:~$* lsmod |grep usbserial usbserial 27365 5 pl2303 usbcore 104555 13 ehci_hcd,uhci_hcd,usbnet,cdc_subset,usb_storage,cdc_ether,usbserial,uvcvideo,pl2303,cdc_acm,rndis_host,rndis_wlan On Thu, Feb 16, 2017 at 6:00 PM,

Re: [beagleboard] using desktop window for BBB console

On Thu, Feb 16, 2017 at 5:44 PM, mzimmers wrote: > mzimmers@debian:~$ ls -I "tty[0-9]*" /dev |grep tty > tty > ttyS0 > ttyS1 > ttyS2 > ttyS3 > mzimmers@debian:~$ > So, you serial interface does not seem to be showing up. Is it plugged into the USB port ? What output do you

Re: [beagleboard] using desktop window for BBB console

of that with Debian. A little bit with Mandrake( Red Hat ), and a tiny bit with Sabayon Linux( a Gentoo fork ). On Thu, Feb 16, 2017 at 5:06 PM, William Hermans <yyrk...@gmail.com> wrote: > So. . . > > *william@eee-pc:~$* ls -I "tty[0-9]*" /dev |grep tty > tty > ttyS0 &g

Re: [beagleboard] using desktop window for BBB console

So. . . *william@eee-pc:~$* ls -I "tty[0-9]*" /dev |grep tty tty ttyS0 ttyS1 ttyS2 ttyS3 ttyUSB0 william@eee-pc:~$ sudo screen /dev/ttyUSB0 115200 [sudo] password for william: Press enter if you need a prompt, but this is mostly only good for viewing serial debug output from the kernel. Press

Re: [beagleboard] Re: how to unfreeze my BBB?

On Thu, Feb 16, 2017 at 1:20 PM, mzimmers wrote: > Before I do anything, it would seem to make sense to find out the name of > the device on my Debian desktop. As I mentioned, I have /dev/ttyS[0-3]. Is > there some way to determine which of these is the one I plugged the

Re: [beagleboard] Deep sleep & wake through GPIO and RTC

On Thu, Feb 16, 2017 at 1:04 PM, Davide Aguiari wrote: > We're looking for something less external mcu-based in order to exploit > all the AM335x capabilities. I would prefer consume a bit more without > making the project too complex with programming an external mcu :) > >

Re: [beagleboard] Re: how to unfreeze my BBB?

at 12:53 PM, mzimmers <mzimm...@gmail.com> wrote: > But what do I do for seeing console messages? Terminal doesn't show me > those. > > On Thursday, February 16, 2017 at 12:51:20 PM UTC-7, William Hermans wrote: >> >> Well, actually the remote host *MU

Re: [beagleboard] Re: how to unfreeze my BBB?

, 2017 at 12:49 PM, William Hermans <yyrk...@gmail.com> wrote: > Why would you want to use putty on Linux ? Literally it is as simple as > ssh user@host. Where user is the username you wish to use once ssh'd into > the remote system. Where host is the host address for the remote system

Re: [beagleboard] Re: how to unfreeze my BBB?

Why would you want to use putty on Linux ? Literally it is as simple as ssh user@host. Where user is the username you wish to use once ssh'd into the remote system. Where host is the host address for the remote system. You can run this command like you would any other command. From a Linux

Re: [beagleboard] Re: WakeUp GPIO features is missing

On Thu, Feb 16, 2017 at 9:43 AM, Davide Aguiari wrote: > Did you resolve? I'm looking for a solution. > @William: I don't think that you can use select() or poll() while your > system is sleeping. > You can't do *anything* on a Linux system while it is sleeping. Except

Re: [beagleboard] Deep sleep & wake through GPIO and RTC

. If no internet, or you would like to keep time from the control MCU, Then one would probably need an external RTC. Which would complicate things a good bit, but is possible. On Thu, Feb 16, 2017 at 12:36 PM, William Hermans <yyrk...@gmail.com> wrote: > If you want the lowest possible po

Re: [beagleboard] Deep sleep & wake through GPIO and RTC

If you want the lowest possible power usage from the beaglebone, and using something like, or akin to sleeping the system. You will need an external processor( low power MCU ) involved. It would work something like this: - The beaglebone is completely powered down - the External MCU would

Re: [beagleboard] Re: how to unfreeze my BBB?

On Thu, Feb 16, 2017 at 9:55 AM, mzimmers wrote: > Hi, William - actually, I do have another question: what terminal app do > you use for connecting to the BBB's serial port? I'm trying to use PuTTY, > but I don't know the correct port name/number. Molloy's book uses >

Re: [beagleboard] Re: how to unfreeze my BBB?

On Wed, Feb 15, 2017 at 3:45 PM, mzimmers wrote: > Heh...OK, I think I got it right this time. The BBB now boots up without > the SD card. I'm now running Debian 8.7, which was the goal, so I can end > this thread. > > Thanks to everyone who helped on this. I'm not really

Re: [beagleboard] Re: how to unfreeze my BBB?

On Wed, Feb 15, 2017 at 6:55 PM, Dennis Lee Bieber wrote: > On Wed, 15 Feb 2017 14:45:51 -0800 (PST), mzimmers > declaimed the following: > > >Heh...OK, I think I got it right this time. The BBB now boots up without > >the SD card. I'm now running

Re: [beagleboard] Re: Real time application development for BBB

On Wed, Feb 15, 2017 at 1:00 PM, TJF wrote: > Use Debian OS, version 3.8 is most reliable. > > Why additional hardware (TI-CC2531)? When your temperature is in the range > of -50 to 125 °C you can use Dallas sensors. Connect a bunch of them > directly to a GPIO line of

<    1   2   3   4   5   6   7   8   9   10   >