Re: [beagleboard] apt-get upgrade breaks file system

I would recommend, when you run into issues such as this that you DO NOT mess things up further by trying to fix it. Chances are pretty good for some reason, your system is corrupt. As such be treated as a hostile environment. Get your important files off *NOW* then start over from scratch. I've

Re: [beagleboard] Enabling CAN and GPIOs at the same time.

You're probably not going to get a responce until you give the exact source you're having problems with, and the commands used to compile from source. On Fri, May 5, 2017 at 2:32 PM, wrote: > We are using a Beaglebone Black rev-C and need to have both DCAN1 and some > of

Re: [beagleboard] Re: serial terminal on HDMI Display in BBB

Ah ok, yeah never used an NOOBs image I guess. Actually, someday I'll look into creating my own images. Just need to work out what is needed from the BSP for support files, kernel, and kernel modules etc. As I do not like all this hand holding stuff, and quite honestly you never know what these

Re: [beagleboard] Re: serial terminal on HDMI Display in BBB

was just "reverse engineering", and have never used it yet. On Sat, May 6, 2017 at 1:47 PM, William Hermans <yyrk...@gmail.com> wrote: > > > On Sat, May 6, 2017 at 12:29 PM, Dennis Lee Bieber <wlfr...@ix.netcom.com> > wrote: > >> >> Talking to my

Re: [beagleboard] Re: serial terminal on HDMI Display in BBB

On Sat, May 6, 2017 at 12:29 PM, Dennis Lee Bieber wrote: > > Talking to myself in public again... > > On Sat, 06 May 2017 11:46:40 -0400, Dennis Lee Bieber > declaimed the following: > > > > > I'll admit, I'd prefer it if the default

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

> > $ python3.6 ~/reusable/BBB_pressure_streamer.py > some_log_file.txt > > When I view the log file I can't see any errors > So, actually, scripting languages in general can be far slower, that their native code counterparts. Firstly, because there is an interpreter, and secondly because of code

Re: [beagleboard] RoboticsCape Library & Node.JS

Well, specific to the beaglebone blue or Robotics cape ? I do not know of anything personally. But , I wrote this: https://github.com/wphermans/Bonejs. Basically, I wrote this because I wanted to have something I knew how it worked, was simple, very maintainable, and did not rely on npm at all.

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

On Thu, May 4, 2017 at 5:42 PM, Graham Haddock wrote: > So, the COM port on Windows is talking to a virtual serial port in the BBB > USB widget. > There is no hardware UART involved, and no hardware clocks anywhere to > throttle or pace anything. > Then, you push this for

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

Dennis, keep your comments directed at helping the OP, and stop worrying about what I'm saying. We're obviously not talking about the same thing, and your comments to me are not helping the OP solve his problem. David, As an example if I run the following program there is no data loss: > >

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

On Thu, May 4, 2017 at 3:32 PM, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote: > On Thu, 4 May 2017 15:10:07 -0700, William Hermans > <yyrk...@gmail.com> declaimed the following: > > > >I think it's important to note that the OP is not sending data from th

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

On Thu, May 4, 2017 at 3:10 PM, William Hermans <yyrk...@gmail.com> wrote: > > > On Thu, May 4, 2017 at 3:02 PM, arsi <a...@chello.sk> wrote: > >> Hi, >> >> call *flush* after write command!!! >> >> *flush**(**)* >> >> *Flush of

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

On Thu, May 4, 2017 at 3:02 PM, arsi wrote: > Hi, > > call *flush* after write command!!! > > *flush**(**)* > > *Flush of file like objects. In this case, wait until all data is written.* > Arsi > I think it's important to note that the OP is not sending data from the

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

On Thu, May 4, 2017 at 9:32 AM, David Howlett wrote: > >> First, you're going to need to learn how to use systemd, and > specifically, you're going to need to learn how to create, and use a > startup service. > > I happen to have used systemd startup services in a

Re: [beagleboard] GPIO based LEDs with USR LED functions

, 2017 at 12:53 AM, abraxas1 <abrax...@gmail.com> wrote: > excellent, thanks. > this is my first exposure to overlays etc... now i see about sysfs. > i'll just blink leds in my code. using threads won't suck up hardly any > processor time. > ciao, > > > On Thu, M

Re: [beagleboard] GPIO based LEDs with USR LED functions

Can you ask a more specific question ? It seems as though as you;re asking if you can use the sysfs file system to control USR0-USR3 ? The answer is yes, you can, but it largely depends on which drivers you're loading with your hardware. Using /dev/mem/ + mmap all you need to know if the memory

Re: [beagleboard] FATAL ERROR: Unable to parse input tree,does anyone know how to fix it ?

On Tue, May 2, 2017 at 9:47 PM, Riko Ho wrote: > hehehe, fsck yourself if you don't know how to answer...yes it is the sky > is blue..and don't worry to answer if you don't know..as simple as that. > > Done mate' > Except, I had a really good idea what your problem was,

Re: [beagleboard] FATAL ERROR: Unable to parse input tree,does anyone know how to fix it ?

On Tue, May 2, 2017 at 8:33 PM, William Hermans <yyrk...@gmail.com> wrote: > > > On Tue, May 2, 2017 at 8:01 PM, Riko Ho <antonius.r...@gmail.com> wrote: > >> @William Hermans >> not a problem, learning is my part, ask to someone who knows better than >&g

Re: [beagleboard] FATAL ERROR: Unable to parse input tree,does anyone know how to fix it ?

On Tue, May 2, 2017 at 8:01 PM, Riko Ho <antonius.r...@gmail.com> wrote: > @William Hermans > not a problem, learning is my part, ask to someone who knows better than > me, making it easier. > No, you're right, it's not a problem. But it helps if you ask a question. But your pa

Re: [beagleboard] FATAL ERROR: Unable to parse input tree,does anyone know how to fix it ?

On Tue, May 2, 2017 at 8:28 PM, Robert Nelson wrote: > On Tue, May 2, 2017 at 10:25 PM, Riko Ho wrote: > > Wow, thank you very much for that, I'll try and return to you later on. > > Just remember to use the repo > >

Re: [beagleboard] FATAL ERROR: Unable to parse input tree,does anyone know how to fix it ?

On Tue, May 2, 2017 at 7:10 PM, Riko Ho wrote: > Yes I only use the "include" for a test on GPIO, > > how can I use one of the overlay and modify it ? thanks > You want a definitive answer ? Learn how device tree overlays work. Modify an overlay that is closest to

Re: [beagleboard] FATAL ERROR: Unable to parse input tree,does anyone know how to fix it ?

, and moving into the git root directory and issuing "make". Two ways to go about that, but we can get to that later. So, knowing what command you used EXACTLY what command when you attempted to build your file would be necessary. On Tue, May 2, 2017 at 5:00 PM, William Hermans <yyrk...@gma

Re: [beagleboard] FATAL ERROR: Unable to parse input tree,does anyone know how to fix it ?

Without the source, no one will be able to give you a correct answer. That is, the source file EXACTLY how it is when you got that error. On Tue, May 2, 2017 at 4:39 PM, bianchi wrote: > Hello everyone, > > I have question regarding compiling overlay for cape, > > I got

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

On Tue, May 2, 2017 at 6:26 AM, David Howlett wrote: > I couldn't easily find documentation on how to enable flow control on the > beaglebone side so I chose to add a CRC32 checksum to each line. The data > now looks like: > > This is not really so much a beaglebone

Re: [beagleboard] Debian Testing (2017-04-30) U-Boot Overlays are now enabled by Default

I've personally tested 1-wie on P8.26, a ds3232 RTC on I2C-2, enabled I2C-1, with an unusual I2C PMIC or sorts( for lead acid batteries ), UART1, all channel ADCs, and various GPO's, and GPI's. UART1 and the ADC's are using stock overlays, the rest are all in one big custom overlay. Oh, and right,

Re: [beagleboard] Sharing some thoughts on quality

I usually just delete these kind of posts without reading them, but I recognized the name as someone whose posted recently so I did not delete it, but no way I was going to try and read that wall of text. especially when I'm writing software . . . Do us a favor in the future Joseph.

Re: [beagleboard] Re: Depauperate Beagle Board Green

So, I'd have to say there is no good advice on how to proceed in this situation. Simply because it's not just hardware that needs to change. The software, from the first stage boot loader all the way into the Linux kernel and rootfs may have to be modified. Not to mention that it would be hard

Re: [beagleboard] EPS (virtual network) for BeagleBone

However, from the outside not knowing the possibilities, it seems as though there may have to be an additional system outside either of our networks with a static public IP. Which would be very similar to reverse ssh in usage . . . On Sat, Apr 29, 2017 at 7:22 PM, William Hermans <y

Re: [beagleboard] EPS (virtual network) for BeagleBone

As it is, we're on two separate network in our place here, both with their own internet, so at some point when I get time I can test drive this. No guarantee as to when, or even if. I'm not a big fan of C++, but can deal with it most of the time. Hopefully you're not using any crazy template or

Re: [beagleboard] EPS (virtual network) for BeagleBone

On Sat, Apr 29, 2017 at 5:10 PM, Stéphane Charette < stephanechare...@gmail.com> wrote: > Feel free to do as you wish. The whole thing is open source. You can > choose to compile yourself, download a .deb or .rpm, modify it or not, or > just ignore it. :) > > I was simply posting it here

Re: [beagleboard] Re: 4.4.x-ti kernel with rproc & uio (r34)

Awesome. On Sat, Apr 29, 2017 at 9:35 AM, Robert Nelson wrote: > On Sat, Apr 29, 2017 at 7:34 AM, Joseph Heller > wrote: > > On Wednesday, July 6, 2016 at 4:56:13 PM UTC+2, RobertCNelson wrote: > >> > >> Step 3: (uio) > >> > >> Edit your

Re: [beagleboard] EPS (virtual network) for BeagleBone

Sounds like a cool little project. however I have issues with it. Mainly, I do not know who you are, or what your code is. Is this important to you ? I do not know, is it important for you that I use your software ? anyone else ? On Sat, Apr 29, 2017 at 9:14 AM, Stephane Charette <

Re: [beagleboard] Re: [beagle-alpha] Re: Cloud9 IDE Update (c9-core-installer_3.1.3543)

On Thu, Apr 27, 2017 at 7:07 PM, Robert Nelson wrote: > > it's a pretty small patch: > > https://patchwork.kernel.org/patch/9177249/raw/ > > Documentation/pwm.txt |6 -- > drivers/pwm/sysfs.c | 15 --- > 2 files changed, 16 insertions(+), 5

Re: [beagleboard] Re: [beagle-alpha] Re: Cloud9 IDE Update (c9-core-installer_3.1.3543)

On Thu, Apr 27, 2017 at 5:06 PM, Robert Nelson wrote: > It's a little more then that, the first 0 comes from parent: > > /sys/class/pwm/pwmchip0/pwm-0:0 > > /sys/class/pwm/pwmchipA/pwm-A:B > > Right, with my implementation as it sits. pwm(x, y) where pwmchipx, -> pwmy. x

Re: [beagleboard] Re: [beagle-alpha] Re: Cloud9 IDE Update (c9-core-installer_3.1.3543)

On Thu, Apr 27, 2017 at 3:22 PM, William Hermans <yyrk...@gmail.com> wrote: > It'll break bonejs too, but I can live with that. Just an additional two > characters in a string somewhere in my code. A few times . . .hehe > Actually, it won't break my implementation at all. Just nee

Re: [beagleboard] Re: [beagle-alpha] Re: Cloud9 IDE Update (c9-core-installer_3.1.3543)

It'll break bonejs too, but I can live with that. Just an additional two characters in a string somewhere in my code. A few times . . .hehe On Thu, Apr 27, 2017 at 3:18 PM, Robert Nelson <robertcnel...@gmail.com> wrote: > On Thu, Apr 27, 2017 at 5:15 PM, William Hermans <yyrk.

Re: [beagleboard] Re: [beagle-alpha] Re: Cloud9 IDE Update (c9-core-installer_3.1.3543)

On Thu, Apr 27, 2017 at 3:15 PM, William Hermans <yyrk...@gmail.com> wrote: > > > On Thu, Apr 27, 2017 at 3:12 PM, Robert Nelson <robertcnel...@gmail.com> > wrote: > >> >> https://lkml.org/lkml/2016/6/14/967 >> >> > Ouch, so sounds like a boot

Re: [beagleboard] Re: [beagle-alpha] Re: Cloud9 IDE Update (c9-core-installer_3.1.3543)

On Thu, Apr 27, 2017 at 2:59 PM, William Hermans <yyrk...@gmail.com> wrote: > > > On Thu, Apr 27, 2017 at 2:56 PM, Robert Nelson <robertcnel...@gmail.com> > wrote: > >> On Thu, Apr 27, 2017 at 4:55 PM, William Hermans <yyrk...@gmail.com> >> wrote:

Re: [beagleboard] Re: [beagle-alpha] Re: Cloud9 IDE Update (c9-core-installer_3.1.3543)

@Robert, I'm thinking at this point in time, that we may have to fall off the last creation of files in that path, and do single file permission changes, would would be tedious, and painful. So whatever the last path to be created, you run the udev rule off that, and just traverse down into the

Re: [beagleboard] Re: [beagle-alpha] Re: Cloud9 IDE Update (c9-core-installer_3.1.3543)

On Thu, Apr 27, 2017 at 2:46 PM, Robert Nelson <robertcnel...@gmail.com> wrote: > On Thu, Apr 27, 2017 at 4:43 PM, William Hermans <yyrk...@gmail.com> > wrote: > > Still having issues with PWM ? > > Yeah i took a break from that, PWM was too painful.. > > Fix

Re: [beagleboard] Re: [beagle-alpha] Re: Cloud9 IDE Update (c9-core-installer_3.1.3543)

By the way, I think the small amount I talked about udev, and permissions on my git for bonejs. I pretty much got most of that information from rPI content all over the web. I did have to make several modifications though . .. On Thu, Apr 27, 2017 at 2:43 PM, William Hermans <yyrk...@gmail.

Re: [beagleboard] Re: [beagle-alpha] Re: Cloud9 IDE Update (c9-core-installer_3.1.3543)

Still having issues with PWM ? On Thu, Apr 27, 2017 at 2:41 PM, Robert Nelson wrote: > and inside one: > > debian@beaglebone:/sys/class/gpio/gpio2$ ls -lha > total 0 > drwxrwxr-x 3 root gpio0 Apr 27 21:38 . > drwxrwxr-x 16 root gpio0 Apr 27 21:38 .. >

Re: [beagleboard] Re: [beagle-alpha] Re: Cloud9 IDE Update (c9-core-installer_3.1.3543)

Wow, the Pine64 community is actually active ? hehe. . . On Thu, Apr 27, 2017 at 2:35 PM, Robert Nelson <robertcnel...@gmail.com> wrote: > On Thu, Apr 27, 2017 at 4:27 PM, Metelko <mary.vuw...@gmail.com> wrote: > > I used the following udev rule (similar to Wil

Re: [beagleboard] Re: Reboot instead of shutdown

've highlighted above. You'd have to modify this board file here: https://github.com/jadonk/cape-firmware/blob/master/arch/arm/boot/dts/am335x-bone-common.dtsi#L204 And recompile all of, or the single board file you use at boot time. Of course then you've have to move the old board file out of

Re: [beagleboard] Re: Reboot instead of shutdown

It would not be part of "my" FAQ. I have no affiliation with beagleboard.org, at all. I'm just some guy, who has had 4+ years hands on experience with this specific platform, who also just so happens to get paid by a third party who builds systems based on this platform as well. But obviously I do

Re: [beagleboard] Re: Depauperate Beagle Board Green

Andrea, Maybe this will solve your problem: https://www.adafruit.com/product/909 There are also panel mount USB pass through cables too. I'm not sure if adafruit has them, but if not amazon has them for sure. On Thu, Apr 27, 2017 at 9:59 AM, William Hermans <yyrk...@gmail.com> wrote: >

Re: [beagleboard] Re: Reboot instead of shutdown

On Thu, Apr 27, 2017 at 9:53 AM, ithinu wrote: > Perhaps a work-around would be to provide a software possibility of > freezing the unit after the kernel is down. Handy for someone who has a > power-hungry cape requiring a power supply, no Ethernet and would like to >

Re: [beagleboard] Re: Depauperate Beagle Board Green

Seems I was not awake, enough, before I read the post. But was still good for a laugh while I was off in left field somewhere. But changing out ethernet, *AND* USB for DIP connectors is still odd to me. I'll just chalk that up to me not being an EE, and move on with my life. Andrea, OrCAD is a

Re: [beagleboard] Re: Reboot instead of shutdown

. Well actually, all the boards we have in our "lab" are connected via ethernet for communications. On Thu, Apr 27, 2017 at 9:34 AM, William Hermans <yyrk...@gmail.com> wrote: > > > On Thu, Apr 27, 2017 at 1:27 AM, ithinu <arturra...@gmail.com> wrote: > >> &

Re: [beagleboard] Re: Reboot instead of shutdown

On Thu, Apr 27, 2017 at 1:27 AM, ithinu wrote: > > Short story, you're using a powered hub, and you need to keep that hub > from sending power back into the host. > > No, the hub is not powered. Also, as I said, the problem exists only with > the combination power

Re: [beagleboard] Re: Depauperate Beagle Board Green

removing -> changing. On Thu, Apr 27, 2017 at 9:16 AM, William Hermans <yyrk...@gmail.com> wrote: > > > On Thu, Apr 27, 2017 at 9:00 AM, Gerald Coley <gcol...@emprodesign.com> > wrote: > >> I could modify the DSN file, but I am on a diet, trying to cut back

Re: [beagleboard] Re: Depauperate Beagle Board Green

On Thu, Apr 27, 2017 at 9:00 AM, Gerald Coley wrote: > I could modify the DSN file, but I am on a diet, trying to cut back on all > the free work I have been doing lately. > > > > The DSN file is only the schematic, it will not change the PCB. > lol, you did better than

Re: [beagleboard] No GPIO access from PRU's - GPIO toggle example - device tree overlay/pinmux problem?

. It seems to be very solid. I'm seriously considering putting this image to work in the field on 30ish live production systems. I'm that happy with it. On Wed, Apr 26, 2017 at 8:39 PM, William Hermans <yyrk...@gmail.com> wrote: > So, there is another *possible* work around that you could

Re: [beagleboard] No GPIO access from PRU's - GPIO toggle example - device tree overlay/pinmux problem?

So, there is another *possible* work around that you could try. Keep in mind that I have not tested this myself. But config-pin can load overlays too. So it is possible that you could do something like this: config-pin overlay Then your overlay would have to exist in /lib/firmware, as I seem to

Re: [beagleboard] 2017-04-02-1gb.img capemgr bug

=/lib/firmware/BB-UART1-00A0.dtbo The first cape is nothing special that could possibly interfere with capemgr. It just enables I2C-1 bus, and loads the ds3232 RTC driver, for a ds3232 on I2C-2 bus. On Wed, Apr 26, 2017 at 7:54 PM, William Hermans <yyrk...@gmail.com> wrote: > B

Re: [beagleboard] 2017-04-02-1gb.img capemgr bug

By the way, Universal IO is disabled on both boards. On Wed, Apr 26, 2017 at 7:52 PM, William Hermans <yyrk...@gmail.com> wrote: > So the image I'm using on two separate boards: > bone-debian-8.7-console-armhf-2017-04-02-1gb.img > > One board has uboot capes enabled, an

[beagleboard] 2017-04-02-1gb.img capemgr bug

So the image I'm using on two separate boards: bone-debian-8.7-console-armhf-2017-04-02-1gb.img One board has uboot capes enabled, and they do function. The other board is not using uboot overlays, but seems odd at times. So on both board inserting an overlay as such: root@wgd:~# echo BB-UART1

Re: [beagleboard] Re: Reboot instead of shutdown

On Wed, Apr 26, 2017 at 8:31 AM, ithinu wrote: > The board is connected to a 5V power supply, to a USB hub and via Ethernet > to a router. It has no capes. > > uname -a > Linux beaglebone 4.4.39-ti-r75 #1 SMP Thu Dec 15 22:16:11 UTC 2016 armv7l > GNU/Linux > > The command >

Re: [beagleboard] No GPIO access from PRU's - GPIO toggle example - device tree overlay/pinmux problem?

On Tue, Apr 25, 2017 at 11:34 AM, ThomasL wrote: > Hi, > > We are trying to get the GPIO toggle example running on the beaglebone > black. > > At this point we succeeded in the following: running the RProc echo > example from the TI hands on lab which works. Writing and

Re: [beagleboard] Re: Reboot instead of shutdown

On Tue, Apr 25, 2017 at 3:13 PM, Robert Nelson wrote: > On Tue, Apr 25, 2017 at 5:00 PM, ithinu wrote: > > shutdown -P now does the same as shutdown -h now: reboots the board. So I > > still do not know a way of shutting it down. > > > > I attach

Re: [beagleboard] 'apt-get update' error

<robertcnel...@gmail.com> wrote: > On Tue, Apr 25, 2017 at 12:44 PM, William Hermans <yyrk...@gmail.com> > wrote: > > How much longer with Wheezy support I wonder. My x86 support system for > my > > beaglebones here has already stopped upgrading. Not a single securit

Re: [beagleboard] 'apt-get update' error

How much longer with Wheezy support I wonder. My x86 support system for my beaglebones here has already stopped upgrading. Not a single security update either. Which when security updates stop happening thats really what queue's me to move on . . . On Tue, Apr 25, 2017 at 7:21 AM, Robert Nelson

Re: [beagleboard] Re: [beagle-alpha] Re: Cloud9 IDE Update (c9-core-installer_3.1.3543)

This is what I had to do with the gpio pins, note the last two parts of the rules. SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio; chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/platform/ocp/4000.gpio/gpio/; chmod -R 770

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

I think Charles' suggestion is probably the best way to go about dealing with this issue. Enable some kind of hardware flow control. XON / XOFF is probably a good bet. On Fri, Apr 21, 2017 at 5:22 PM, William Hermans <yyrk...@gmail.com> wrote: > > > On Fri, Apr 21, 2017 at 3:26

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

On Fri, Apr 21, 2017 at 3:26 PM, Graham wrote: > What is the current speed you are using for the serial ports? > > There is also a transmit buffer inside the serial port transmitter in the > BBB. > If you are putting streaming character data into the transmit buffer >

Re: [beagleboard] Re: [beagle-alpha] Re: Cloud9 IDE Update (c9-core-installer_3.1.3543)

Another thing that come to mind right off is that some files can only be read, while others still can only be written to. If you're attempting to change permissions to these files in a way that it's not meant to be used. It could potentially cause the whole rule to fail. -- For more options,

Re: [beagleboard] Re: [beagle-alpha] Re: Cloud9 IDE Update (c9-core-installer_3.1.3543)

On Fri, Apr 21, 2017 at 3:11 PM, Robert Nelson wrote: > On Fri, Apr 21, 2017 at 3:44 PM, Robert Nelson > wrote: > > On Fri, Apr 21, 2017 at 3:27 PM, Robert Nelson > wrote: > >> On Fri, Apr 21, 2017 at 1:39 PM, Robert

Re: [beagleboard] Re: Debian Testing, un-root athon!!! (2017-04-18)

On Fri, Apr 21, 2017 at 10:34 AM, Mark A. Yoder wrote: > H so why does config-pin work for you and not for me? > > --Mark > Hi Mark, Did yo utry loading the same overlay at boot that Robert's loading through uboot overlays ? > uboot_overlays: loading

Re: [beagleboard] Newbie Question Using BBB for Telemetry

There is another way to go about this bit is slightly more complex, and would require an additional "server" somewhere. This server could be another embedded Linux system if you so wished. Such as a beaglebone. But basically how this works if you have an MQTT broker running locally, with the MQTT

Re: [beagleboard] Newbie Question Using BBB for Telemetry

I am a programmer, and have hands on with doing a few projects that fall into this category. What you're attempting to do does not sound very hard at all. But it could turn out to be fairly complex in nature. Tacking a few ADC values, GPI value as well as "toggling" a few GPO's is not that hard.

Re: [beagleboard] Re: Debian Testing, un-root athon!!! (2017-04-18)

, Apr 19, 2017 at 2:29 PM, William Hermans <yyrk...@gmail.com> wrote: > Just a quick worklog to give an idea of how you set this up and how it > works. Of course, you may want todo things a little differently. It depends > on if you want to keep the cloud9 directory "update

Re: [beagleboard] Re: Debian Testing, un-root athon!!! (2017-04-18)

of the mountpoint before unmounting ):* root@wgd:~# *cd ..* root@wgd:/# *umount /root/* *Change back into our root home directory and retest:* root@wgd:/# *cd ~* root@wgd:~# *ls* git testfile root@wgd:~# *cat testfile* On Wed, Apr 19, 2017 at 1:10 PM, William Hermans <yyrk...@gmail

Re: [beagleboard] Re: Debian Testing, un-root athon!!! (2017-04-18)

revert the directory from the img file I suppose, but that would be a minor hassle at best. Also, using the zram tmpfs method i mentioned above would not require chroot at all. On Wed, Apr 19, 2017 at 1:06 PM, William Hermans <yyrk...@gmail.com> wrote: > How about using a chroot ? Basically

Re: [beagleboard] Re: Debian Testing, un-root athon!!! (2017-04-18)

How about using a chroot ? Basically you keep a chroot image where ever you want, mount it where ever you want, and just wipe it out for a fresh start when you need to get back to pristine. I am trying to think what would be the smartest way to do this as you wouldn't necessarily want to spend a

Re: [beagleboard] Bonescript support for Blue?

Hi Drew, According to this: https://github.com/beagleboard/beaglebone-blue/blob/master/BeagleBone_Blue_Pin_Table.csv I believe the answer to your question is yes. As far as mapping goes anyhow. Jason would probably have to answer the Bonescript half of your question. But I'd think the answer

Re: [beagleboard] Debian Testing, un-root athon!!! (2017-04-18)

How soon before a stretch console image ? On Tue, Apr 18, 2017 at 6:49 PM, Robert Nelson wrote: > Hey everyone, > > As we try to move more things from "root" -> "debian" please give > this image a shot: > >

Re: [beagleboard] Slow reading speed from DDR allocated for pru (uio_pruss driver)

ation, sizeof(u_int32_t) * 76800); //takes > aprox 0.5 - 1 ms > > //close pru... > } > > > > > On Tuesday, April 18, 2017 at 8:09:44 PM UTC+3, William Hermans wrote: > >> On Tue, Apr 18, 2017 at 4:38 AM, <letterdot...@gmail.com> wrote: >> >&g

Re: [beagleboard] Slow reading speed from DDR allocated for pru (uio_pruss driver)

I'd have to see actual code myself, before I could even think about considering what could be the problem. Earlier, what I mentioned about running the executable from memory, is really a stab in the dark, and is most likely not the case. My reasoning with that is if the executable is running from

Re: [beagleboard] Slow reading speed from DDR allocated for pru (uio_pruss driver)

, 2017 at 10:09 AM, William Hermans <yyrk...@gmail.com> wrote: > On Tue, Apr 18, 2017 at 4:38 AM, <letterdotandnum...@gmail.com> wrote: > >> Hello, >> I've encountered a problem with very slow reading speed from memory >> allocated by pru kernel driver uio_p

Re: [beagleboard] Slow reading speed from DDR allocated for pru (uio_pruss driver)

On Tue, Apr 18, 2017 at 4:38 AM, wrote: > Hello, > I've encountered a problem with very slow reading speed from memory > allocated by pru kernel driver uio_pruss comparing to reading from usual > address spaces. Here is an performance tests on my Beagle Bone black:

Re: [beagleboard] Re: TMP36 and BoneScript on BBB/Hello

Dies <fun...@gmail.com> wrote: > Okay...I can check on that too. I just thought using the bonescript > software and the BBB would be fun. > > Seth > > P.S. I have been using the analog pin P9_39 and/or P9_40. Thank you. > > On Monday, April 17, 2017 at 8:01:18 P

Re: [beagleboard] Re: TMP36 and BoneScript on BBB/Hello

Why don't you just learn how to use the ADC module from userspace LInux, then setup the ADC yourself, and read from the file in oneshot mode every cycle ? It's not that difficult . . . On Mon, Apr 17, 2017 at 5:53 PM, Mala Dies wrote: > *var b = require('bonescript');* > *var

Re: [beagleboard] BBBlue Ethernet?

On Mon, Apr 17, 2017 at 11:34 AM, wrote: > Hello! Really like the specs of this product. Are there any plans in the > future to have a wired Ethernet version? Or has anyone tested Ethernet over > USB with this board? If not, I guess I could hijack one of the SPI ports > for

Re: [beagleboard] BBB without Cape Manager

, and working board file blob, editing that source, then recompiling worked. YMMV. On Mon, Apr 17, 2017 at 1:29 PM, William Hermans <yyrk...@gmail.com> wrote: > On Mon, Apr 17, 2017 at 11:42 AM, Graham <gra...@flex-radio.com> wrote: > >> I would like to build a revision to the c

Re: [beagleboard] BBB without Cape Manager

On Mon, Apr 17, 2017 at 11:42 AM, Graham wrote: > I would like to build a revision to the current 2017-3-19 release (Console > version) that does not include the Cape Manager. > > I would like to get rid of the four blocked I2C memory addresses that are > reserved by the

Re: [beagleboard] 802.11s

So in order to find your kernel headers you need to: root@wgd:~# *apt-get update* root@wgd:~# *apt-cache search linux-headers-`uname -r`* linux-headers-4.4.55-ti-r94 - Linux kernel headers for 4.4.55-ti-r94 on armhf Then to install that package: root@wgd:~# *apt-get install

Re: [beagleboard] Adding BBB Support For Kotlin Native

On Wed, Apr 12, 2017 at 7:07 PM, Nick Apperley wrote: > Greetings. I am a Kotlin community member that > is working on adding BBB support for Kotlin Native > and need some help with the > following: > > >

Re: [beagleboard] Failed password for invalid user in /var/log/auth.log ?

In that case yeah I did not pay attention to the IPs. It may be best to disable ssh login passwd's all together, and use ssh certificates / key login's only Something like this: https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server But

Re: [beagleboard] Failed password for invalid user in /var/log/auth.log ?

If that person is trying to log in with root from one of the latest image, they're going to get an error, which is possibly a PAM error. Robert changed the root account so one can not by default log in over ssh as root. It can be fixed, but it's probably nto a good idea for anyone to "fix" this.

Re: [beagleboard] Error loading shared library. Invalid ELF header

This sounds like a platform incompatibility issue. e.g. something you're trying to use it not meant for the ARM ABI. In other words, perhaps either your executable, or shared library is for x86 or x86-64. On Sun, Apr 9, 2017 at 8:59 PM, wrote: > I am trying to compile a

Re: [beagleboard] can't update Wheezy on BBB revC

This probably means you have no internet connection to that beaglebone. On Sun, Apr 9, 2017 at 1:47 PM, wrote: > I recently put a new disk image on my SD card to boot a BeagleBone Black, > Rev C. The image is : bone-debian-7.11-lxde-4gb-armhf-2016-06-15-4gb.img. > No

Re: [beagleboard] Latest image with uboot overlays.

, William Hermans <yyrk...@gmail.com> wrote: > By the way, the remoteproc modules went away on their own. I'm not sure > why, but good ;) > > On Wed, Apr 5, 2017 at 8:49 PM, William Hermans <yyrk...@gmail.com> wrote: > >> It appears everything loaded fine. >> >&

Re: [beagleboard] Latest image with uboot overlays.

By the way, the remoteproc modules went away on their own. I'm not sure why, but good ;) On Wed, Apr 5, 2017 at 8:49 PM, William Hermans <yyrk...@gmail.com> wrote: > It appears everything loaded fine. > > *uEnv.txt* > ### > ###Additional custom capes > uboot_overlay_ad

Re: [beagleboard] Latest image with uboot overlays.

glebone would not function correctly, or at all. Well done Robert ! This is pretty awesome stuff. You too Panto ! On Wed, Apr 5, 2017 at 8:19 PM, William Hermans <yyrk...@gmail.com> wrote: > Ok so an observation. > > I've got one custom overlay to load. Well technically two, but only

Re: [beagleboard] Latest image with uboot overlays.

es loaded by issuing the command lsmod, and seeing what's loaded, but running cat on */slots did not really yield much information. On Wed, Apr 5, 2017 at 6:36 PM, William Hermans <yyrk...@gmail.com> wrote: > So after: > > root@wgd:~# *systemctl disable generic-board-startup.service*

Re: [beagleboard] Latest image with uboot overlays.

custom overlays I have to test, and it's dinner time, so will add all that info afterwards. On Wed, Apr 5, 2017 at 5:58 PM, William Hermans <yyrk...@gmail.com> wrote: > So, I've not actually gotten to testing the overlays loaded through uboot > yet. But I must say Robert, good job. R

[beagleboard] Latest image with uboot overlays.

So, I've not actually gotten to testing the overlays loaded through uboot yet. But I must say Robert, good job. Running lsmod after removing cape universal from uEnv.txt (cmdline ) works awesomely. The only thing left is the RNDIS related stuff, which can be disabled through your generic-board

Re: [beagleboard] Beaglebone Blue Wifi dissappeared

One thing I can think of that may need looking at, is the serial debug output if you have a 3v3 logic to USB module or cable. There is no guarantee this will tell you anything, but it *may* give some info. That is, if the driver is having issues loading related to hardware problems at boot. >From

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

On Fri, Mar 31, 2017 at 8:25 PM, Ted Carancho wrote: > Thanks so much for all your help William! > > I went into purchasing the BB Blue with eyes wide open, knowing it's brand > new. When the board was working I was very impressed with the cloud9 IDE > and the capability

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

On Fri, Mar 31, 2017 at 1:47 PM, William Hermans <yyrk...@gmail.com> wrote: > > For instance, if you had any IO connected to this board through any of the > GPIO, or other periphery pins while you powered the board up, or down. You > could have damaged the processor. So

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

, or down. You could have damaged the processor. So all the pins need to be isolated in that case. Ethernet, USB, and the serial debug port are exceptions to this rule. But are not what I'd exactly consider "periphery" in the context of embedded systems. On Fri, Mar 31, 2017 at 1:29 PM, Willi

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