[beagleboard] Re: Install Ubuntu using SD card and Windows

[Graham Haddock]

Have you tried plugging ia serial cable into the local serial port?
That should work as long as you still know the password.
No network links involved.

---Graham

==

On Saturday, September 19, 2020 at 6:30:17 AM UTC-5 pietb...@gmail.com 
wrote:

> Hi
>
> I'm a Linux blockhead.
>
> I just got a BeagleBone Black.
>
> I'm working with it from a Windows10 computer using Putty and WinSCP.
>
> In trying to set a static eth0 IP, (successful) and getting it to use 
> 8.8.8.8 as DNS, I managed to lock myself out of it completely. (Long story, 
> involving adding and deleting things in files, adjusting write permissions 
> in folders, removing connman and so forth).
>
> So now I cannot log in to the BBB with any profile. Not it's 
> default 192.168.7.1 through USB, or anything else which worked previously. 
> (I had deleted the ethernet static IP previously anyway)..
>
> I get:
> Network error: Connection refused
>
> I did not make a backup of whatever it had on it's eMMC beforehand.
>
> So:
> Putty does not work with any IP address
> WinSCP does not work with any IP address
> The Browser interface does not work with any IP address
>
> I can ping 192.168.7.1
> With the BBB plugged into a USB port, I have access to the "BeagleBone 
> Getting Started" drive in Windows File Explorer.
>
> So naturally I'm trying to get the thing working again. So would this work?
>
> I buy some sort of "USB to microSD" device. Something like this:
>
>
> 
>
> I download some Ubuntu image from somewhere onto my Windows laptop. (I 
> decided that I might as well go to UBUNTU rather than the Debian it has, 
> while I'm at it).
>
> I write this image out to the microSD through USB.
>
> I stick the microSD into the BBB and push some button to get it booting 
> from the microSD.
>
> So once I get it working again, I can transfer the UBUNTU image from the 
> microSD to the eMMC.
>
>
> Please 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/838e8c70-9da6-4345-9344-31fbc5afe6a0n%40googlegroups.com.

Re: [beagleboard] PocketBeagle USB-C

[Graham Haddock]

Another choice:
Adafruit USB C Breakout Board - Downstream Connection PRODUCT ID: 4090
Digi-Key Part Number   1528-2873-ND  

Instructions at
https://www.adafruit.com/product/4090 

It already has the two resistors on it, that Robert referred to. 

--- Graham

On Monday, August 17, 2020 at 8:43:21 AM UTC-5 RobertCNelson wrote:

> On Mon, Aug 17, 2020 at 8:25 AM  wrote:
> >
> > Hi All
> > I'm starting to delve into this
> > can someone please advise how can i connect USB-C Breakout board to 
> PocketBeagle
>
> Type-C has two more pins.. CC1 and CC2 which help determine
> orientation. Whereas the PocketBeagle is only USB2.0..
>
> https://www.sparkfun.com/products/15100
>
> Connect each CC* pin to gnd with their own 5.1k resistor
>
> Regards,
>
> -- 
> Robert Nelson
> https://rcn-ee.com/
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7305f081-bab6-472a-9675-0cbff906d447n%40googlegroups.com.

[beagleboard] Re: BB Blue repair

[Graham Haddock]

3.3 Volts is generated inside the OSD3358 by a TI TPS65217C PMIC die   
PMIC stands for Power Management IC
You can read the TI data sheet on the TPS65217C
But the OSD3358 is a multi-chip module, so not too much you can do, other 
than replace the entire OSD3358, if damaged.
And that would require BGA (Ball Grid Array) rework capability.
--- Graham

==

On Saturday, August 1, 2020 at 5:54:02 PM UTC-5 Jeff Albrecht wrote:

> On Saturday, August 1, 2020 at 2:45:33 PM UTC-7 Jeff Albrecht wrote:
>
>> On Thursday, July 30, 2020 at 6:49:03 PM UTC-7 Jeff Albrecht wrote:
>>
>>>
>>> I found @jadon Jason Kridner github beaglbone-blue repository 
>>  with Eagle files. Then found 
>> a fork that is probably more authorities as it seems to have several newer 
>> changes, and well Beagleboard :-). beagleboard / beaglebone-blue 
>>  
>>
>>
> How is 3.3V created?
>
> I have some experience with KiCad and DipTrace however very little 
> experience with Eagle.
>
> I figured out how to highlight the 3.3V net, is there any kind of show 
> origin command? 
>
> I've exported the parts list and the Netlist. In the parts list there is 
> 5VREG and 6VREG I searched on just '3.3' finding only one part L3 3.3 
> uH.What generates the 3.3 vdc? What is the origin of the 3.3 VDC?
>
>  - Jeff
>
>

-- 
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/dfee2f1f-948b-466f-ba64-e2b7532031cfn%40googlegroups.com.

[beagleboard] Re: micro - sd card

[Graham Haddock]

The answers is that the BeagleBone can address the entire 16GB micro-SD 
card.
I have used cards up to 128 GB in size.
BUT
if you installed the OS image on the card for either direct use, or for 
writing to the EMMC, then the partition size has been set to 4 GB, and you 
can not see the rest of the card.
To restore access to the entire card, do the following incantation:

cd /opt/scripts/tools/
git pull
sudo ./grow_partition.sh
sudo reboot

On the next reboot, [df -h] should show the full microSD card size.

--- Graham
On Monday, July 6, 2020 at 10:54:45 AM UTC-5 KenUnix wrote:

> I have a BBB running Debian 10.3 on a 32GB SD-Card.
>
>

-- 
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/38ed4280-f7ad-4095-ab7d-78487116c216n%40googlegroups.com.

Re: [beagleboard] Re: Pocket Beagle power question

[Graham Haddock]

>>> Does anyone have any input as to why the PocketBeagle design fails and
>>> why the BBBW works ?

Robert Nelson is really the right person to answer that.

>From what I understand, during boot, uBoot examines the configuration
EEPROM and decides which files/modules to load. Even though the hardware
is identical, it could load different modules, if the configuration
EEPROM is different. So, one load has the bug, the other doesn't.

Or, you are actually running different revision levels of silicon, and
one has a bug.


>>> Also if Tying VIN_USB to VIN_AC works, would the problem go away if a
>>> battery was connected to VIN_BAT ?

I have never tried that, but definitely worth a try.  It is a third
separate isolated power input. I assume with different management software.


>>> Any thoughts would be appreciated.
Beagleboard.org needs to decide if this is a serious enough problem that it
is worthy of being fixed.  So far, they have decided that we don't know
what
we are doing, and are inducing a spurious problem; or that it is not serious
enough a problem to spend the time fixing. I personally think it prevents
the PocketBeagle from being used for any serious application.

On Fri, Aug 16, 2019 at 12:35 AM Dave  wrote:

> As I have noted in a previous post, I am seeing this problem on a board
> with a design derived from the pocketBeagle.
> Based on the information here we have managed a workaround -  tying
> VIN_USB to VIN_AC, and as a consequence have several boards that have been
> runing for over 48hours, when we could not reach 18hrs before and often had
> resets every 30min.
>
> I have run the same software with nearly the same devicetree and the same
> linux(5.1.18) on a BBBW without any failures.
>
> I have compared the schematic of the BBBW which also uses that OSD335X SOC
> with that of my board and the pocketBeagle and  can not see a meaningful
> difference in the input power design.
>
> Does anyone have any input as to why the PcketBeagle design fails and why
> the BBBW works ?
>
> Also if Tying VIN_USB to VIN_AC works, would the problem go away if a
> battery was connected to VIN_BAT ?
>
> Any thoughts would be appreciated.
>
> Though atleast we have a workarround now.
>
> Thank you.
>
>
>
>
>
>
>
>
>
>
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/FwmkeG4itT0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/dadd11c2-3887-4c87-8d02-0048fd10dd92%40googlegroups.com
> 
> .
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CANN_KV5ySrb2ZCHv74Se1GjYDisQG15B_y46UPASRDNaX1W_xg%40mail.gmail.com.

Re: [beagleboard] Pocket Beagle power question

[Graham Haddock]

Jason:

The PocketBeagle will do this, when powered from a serious Lab-bench power
supply running into P1-Pin-1, with added capacitance on the pin, without
added capacitance on the pin, without any other accessory or cape drawing
power from the PocketBeagle.  I reported this in November 2017, and there
have been three or four other reports by other users since then.  It makes
the PocketBeagle unusable for any serious application, where it is not
powered from the microUSB connector.

--- Graham

==

On Mon, Aug 12, 2019 at 9:34 AM Pablo Rodriguez 
wrote:

> Hi,
> The past year i have to power 3 pocketbeagle from Vusb because of the
> random reset when connecting to Vin. This was the only thing that worked
> for me. Did a lot of testing adding capacitance and non work.
>
>
>
> El lun., 12 ago. 2019 a las 10:52, Jason Kridner (<
> jkrid...@beagleboard.org>) escribió:
>
>> On Sat, Aug 10, 2019 at 9:50 PM Graham Haddock 
>> wrote:
>>
>>> What I would do is some minor surgery on the PocketBeagle, disconnecting
>>> the +5V lead coming in the microUSB connector.
>>> The easiest way to do this would be to remove FB1 (ferrite bead in
>>> series with USB +5).
>>> Easy with "hot tweezers", or a pair of small soldering irons.
>>> To restore the Pocketbeagle to factory configuration, solder FB1 back in.
>>>
>>>
>> Whatever instability problems you are seeing, I don't see this addressing
>> it. The PMIC is designed to dynamically switch between the P1.1 ("AC power"
>> in PMIC terms, which always bothers me because it is never AC, but instead
>> DC assumed to come from an AC-powered wall-supply). If somehow there's not
>> enough capacitance to make the switch cleanly, I'd suspect you are doing
>> something rather odd with the *load* you are putting on it. What else do
>> you have connected?
>>
>> Anyway, I put both "AC" (P1.1) and "USB" (P1.7) on the headers on purpose
>> and the full expectation is that if you are putting a power supply in (and
>> it isn't a battery), you'll use P1.1. If it is battery, I also give you
>> that option at P2.14 (BAT).
>>
>>
>>> Short P1-Pin-1 and P1-Pin-7 together, and power the Beagle from whatever
>>> you are going to power it with at +5V.
>>> No issues with instability.
>>>
>>
>> OK, now you are just asking for trouble. There's no justification for
>> doing that.
>>
>> If the design isn't working as intended, then, let's talk about that and
>> details, such as what you are seeing on a scope and P2.13 (VOUT), which is
>> the output of the power mux on the PMIC, also referred to as SYS_5V on
>> BeagleBones. Ultimately, this is used to provide the power to the
>> regulators for the other subsystems. Perhaps your problem is drawing too
>> much current from it?
>>
>> It can be argued I put too many power options on the header, but I tried
>> to keep it flexible for people embedding it onto something. You have a lot
>> of flexibility and I don't see any need to encourage people to alter the
>> board.
>>
>> --
>> https://beagleboard.org/about - a 501c3 non-profit educating around open
>> hardware computing
>>
>> --
>> 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/CA%2BT6QPnR-AOUOp%3DPouR%3DBs%3D%3DFn_NKqTOJM%3DprURJFToD%3DQGaXw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPnR-AOUOp%3DPouR%3DBs%3D%3DFn_NKqTOJM%3DprURJFToD%3DQGaXw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/FwmkeG4itT0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAEObdD2roPt_KjXtQJj15GSrmbndBCB2KzBkvXvCAfBoT3q-SQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/beagleboard/CAEObdD2roPt_KjXtQJj15GSrmbndBCB2KzBkvXvCAfBoT3q-SQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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/CANN_KV5g6B0%3DpWahVUQmEFcHbVpscBq95ARvYZOJSDi5OQg2oQ%40mail.gmail.com.

Re: [beagleboard] Pocket Beagle power question

[Graham Haddock]

What I would do is some minor surgery on the PocketBeagle, disconnecting
the +5V lead coming in the microUSB connector.
The easiest way to do this would be to remove FB1 (ferrite bead in series
with USB +5).
Easy with "hot tweezers", or a pair of small soldering irons.
To restore the Pocketbeagle to factory configuration, solder FB1 back in.

Short P1-Pin-1 and P1-Pin-7 together, and power the Beagle from whatever
you are going to power it with at +5V.
No issues with instability.

Now you can plug in USB for programming and anything else you want/need to
do, at any time. It just won't take power through the USB cable any more.

--- Graham

==


On Sat, Aug 10, 2019 at 12:18 AM Jim F  wrote:

> Ahhh. I've had some of this pain. I did actually raise xmodem from the
> dead, but had enough problems that I just got a secondary USB port working
> and put a wifi dingle on it. Anyway what you want to do, sounds like it
> will work.
>
> On Fri, Aug 9, 2019, 9:07 PM Robert Heller  wrote:
>
>> At Fri, 9 Aug 2019 17:01:28 -0400 beagleboard@googlegroups.com wrote:
>>
>> >
>> >
>> > Robert,
>> >
>> > If you have a look at the Pocketbeagle schematic, you can see what
>> happens
>> > with the USB connector, which comes in on page 2. Power on that pin
>> goes to
>> > VIN.USB, which goes straight to (page 3) the Octavo OSD3358 VIN_USB
>> pins.
>> >
>> > You can look at the Octavo datasheet [1] - it's for the OSD335x_SM -
>> they
>> > tell you almost nothing. The only partly useful thing they tell you is
>> "The
>> > OSD335x-SM may be powered by any combination of the following input
>> power
>> > supplies. Please refer to the TPS65217C datasheet for details." The
>> > smartest thing to do would be to map the pins to the chips they are
>> > connected to using Octavo's tool [2] and the TI datasheets. I'm certain
>> > there's no isolation, but there is a switch to enable one or the other
>> > inputs (perhaps you had a looser definition of isolation in mind).
>> Figure
>> > 11 on page 27 of the TPS65217C datasheet [3] should show you what that
>> > looks like. These are configured by the PPATH register in [3], which I
>> am
>> > not precisely certain how it is configured in the first place, but you
>> > should be able to modify it on I2C0 (I think).
>> >
>> > All that said, it looks to me like it's fine to do. But I feel like I've
>> > done this and had some weird results, I just can't remember exactly what
>> > they were. I think the results included unplanned reverse power flow
>> (USB
>> > charging other things connected to the same VIN power supply), the
>> device
>> > not shutting down exactly as I expected, and similar behavior. I don't
>> > think we smoked anything, though, so there's that. Worth looking through
>> > that data sheet a little to make sure you're happy first.
>>
>> OK.  The reason I want to know is that I have an expansion board that
>> supplies
>> power (and does other things).  It does have a serial console header, so
>> I can
>> connect a TTL serial<=> USB cable for debugging, but unless I really want
>> to
>> raise XModem (from the dead?) there isn't any way to do something like
>> download a fresh executable program ("cross" built on a RPi).  I just
>> wondered
>> if it is "safest" to just unplug the Pocket Beagle from the expansion
>> board
>> and tether it to my laptop and use the Tcp/Ip over USB to do the "large"
>> transfers of things like exe files, etc.  This is what I have been doing
>> and
>> was wondering if I really have to do it that way or if I can plug in the
>> USB
>> while the Pocket Beagle is still being powered by the expansion board.
>>
>> >
>> > I would be quite interested to know precisely where PPATH is configured,
>> > beyond its default settings. It may be in the uboot source which is not
>> [I
>> > think] in the BB distributions. That stuff isn't bad to look at, and I
>> was
>> > going to, but for the life of me I can't remember where I built that
>> and I
>> > can't find it right now. Robert also has a few scripts in
>> /opt/scripts/boot
>> > which configure a LOT of things, I've only scratched the surface trying
>> to
>> > understand them.
>> >
>> > [0] -
>> >
>> https://github.com/beagleboard/pocketbeagle/blob/master/PocketBeagle_sch.pdf
>> > [1] - https://octavosystems.com/docs/osd335x-sm-datasheet/
>> > [2] -
>> https://octavosystems.com/app_notes/osd335x-family-pin-assignments/
>> > (search for VIN_USB)
>> > [3] - http://www.ti.com/lit/ds/symlink/tps65217.pdf
>> >
>> > Hope that helps. I have nothing to do with the pocket beagle but I did
>> spin
>> > a couple boards based on it and the octavo RED board.
>> >
>> > Best,
>> >
>> > Jim
>> >
>> > On Fri, Aug 9, 2019 at 3:33 PM Robert Heller 
>> wrote:
>> >
>> > > If I am applying a 5V power supply to the Vin pin (P1-1) of a Pocket
>> Beagle
>> > > (say from an expansion board that includes a power supply), is it
>> safe to
>> > > also
>> > > plug in a [powered] micro-USB cable? That is, does the Pocket Beagle
>> have a
>> > 

Re: [beagleboard] Re: Pocket Beagle power question

[Graham Haddock]

As I said, P1-Pin-1 and the microUSB connector power are two different
inputs to two different power supplies.  Having power on both of them is
not a problem, and in fact, will prevent the problem of instability I was
concerned about.

So, no problem powering both.

The concern with the random crashes is just that, it could take three days,
or could happen in the first hour.
I would power the unit from both pins, if it is doing something at all
important.

Of course, my crashing experience is from 18 months ago, and there have
been a lot of software releases since then.

I would encourage you to run some endurance tests on your board, before
putting it in service.

--- Graham

==

On Fri, Aug 9, 2019 at 8:34 PM Robert Heller  wrote:

> At Fri, 9 Aug 2019 16:23:26 -0700 (PDT) beagleboard@googlegroups.com
> wrote:
>
> >
> >
> >
> > Robert:
> >
> > It has been a while, almost a year since I did any testing with the
> > PocketBeagle.
> > But I don't think anything has changed relative to my comments below.
> > Maybe someone can correct me if I am wrong, and some things have been
> fixed.
> >
> > P1-Pin-1 is Vin, and is equivalent to the Barrel Jack input on the
> > Beaglebone Black, it
> > is a separate power supply input, and is isolated from the microUSB
> > connector power.
> >
> > P1-Pin-7 is hardwired to the +5 pin on the microUSB connector, USB Port
> 0.
> > It is not clear from the schematic, but is visible if you view the PCB
> > board plots.
> > Or check it with an Ohmmeter.
> >
> > I found that the PocketBeagle, when powered exclusively by P1-Pin-1
> would
> > randomly
> > crash about once every 24 hours of operation, without any apparent
> reason,
> > or
> > any clue in the logs. I hope that this has been fixed, but I have seen
> > other reports
> > since I initially reported it, and nothing since that reported a fix.
>
> Well, I am not expecting an application that would run 24/7.  I am working
> on
> model RR control circuits.  It does not sound like this should be an
> immediate
> problem.
>
>
> >
> > The only workaround I found was to power P1-Pin-1 and P1-Pin-7 in
> parallel,
> > in which case
> > it does not crash, but now there is no isolation between USB +5V and
> your
> > independent
> > PB power supply, and, as you are concerned about, all kinds of
> cross-feed
> > and back
> > powering can occur.
>
> That does not sound like a really good idea.
>
> Question: if the board was powered from P1-Pin-1 *and* the USB will there
> be
> problems?  Right now, that is my main concern.  Jacking in the USB (for
> file
> transfer mostly, since I can use the serial console for debugging) while
> the
> board is being powered via P1-Pin-1 is something I'd like to be able to
> do,
> but don't want to fry anything.
>
> >
> > I suggest you read the email thread "PocketBeagles are Unstable" started
> > 11/24/2017
>
> Will have a look.
>
>

-- 
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/CANN_KV4OqWQ05koKPk8-bLAG7yYocYVJoN7vw_NvJNuer_7JGQ%40mail.gmail.com.

Re: [beagleboard] Re: problem with writting os image on micro SD

[Graham Haddock]

Does Etcher install the image and verify without errors?

Did you try Dennis' suggestion to hold down the boot-select button while
plugging in the USB/power cable?

--- Graham

==

On Fri, Jun 28, 2019 at 11:29 AM  wrote:

> i tried but i'm faild again. i could write any os image for example
> rasbian on uSD successfully, but i couldn't write debian for BBB.
>
> On Friday, June 28, 2019 at 6:30:37 AM UTC+4:30, Dennis Lee Bieber wrote:
>>
>> On Thu, 27 Jun 2019 14:24:10 -0700 (PDT),
>> z.mome...@gmail.com declaimed the
>> following:
>>
>> >Thank you very much for your answer! I tried to connect to BBB via putty
>> >and SSH,before. now can you tell me about connection to BBB via any
>> other
>> >way with using uSD? how can i do that? now, i write os image on uSD such
>> as
>> >you said and seems it did successful, but i gave same error "you need to
>> >format ...", now i want to eject it and plug it on BBB and connect to
>> board
>> >via other way, if it is possible. tell me about it, please.
>> >
>>
>> You connect to the BBB the same way -- the only difference is if
>> the
>> board boots using the image in the eMMC or boots using the image on the
>> SD
>> card. Recent cards (those with eMMC flashed in the last three years or
>> so)
>> should automatically boot from the SD card, otherwise you have to hold
>> down
>> the boot select button /while/ plugging in the power cable.
>>
>>
>> --
>> Wulfraed Dennis Lee Bieber AF6VN
>> wlf...@ix.netcom.com
>> http://wlfraed.microdiversity.freeddns.org/
>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/PmssrWbNcgY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/8d14aab2-3d1d-478e-9d46-73273db98966%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/CANN_KV6YgR%2BVmQ_N85g1_8pLTpt1U0OVFMeN9Bif7BFFERfx3A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Set up Cape's EEPROM i2c-2 BeagleBoneBlack Rev-C

[Graham Haddock]

Detailed discussion on Apr 17 2017.

--- Graham

==

On Wed, Oct 31, 2018 at 10:15 AM Graham Haddock 
wrote:

> I think there is a detailed discussion as to what is supposed to be inside
> the cape EEPROMs in the
> "BeagleBone Black System Reference Manual"
>
> It looks like there is a live Wiki version at
>
> https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual
>
> But since that address has already been reserved by the kernel, for the
> cape manager,
> you will not be able to read/write it from user space.
>
> If you want to access that address from user space on a BBB, you need to
> stop the cape manager.
> Google "BBB without reserved I2C addresses" on this forum.
> and look at "am335x-bone-common-no-capemgr.dtsi"
>
> --- Graham
>
> ==
>
>
> On Wed, Oct 31, 2018 at 10:01 AM MG  wrote:
>
>> @Graham I do have a cape with EEPROM at address 0x57 but the EEPROM is
>> wiped with nothing on it so I guess that is why the board doesn't populate
>> that address by default. How can I fix that?
>>
>> On Tuesday, October 30, 2018 at 11:14:50 PM UTC-4, gra...@flex-radio.com
>> wrote:
>>>
>>> Those addresses at 0x54-0x57 are reserved by the kernel driver.
>>>
>>> Unless you have some capes with those EEPROMS populated, there is
>>> nothing actually there.
>>>
>>> --- Graham
>>>
>>> ==
>>>
>>> On Tuesday, October 30, 2018 at 7:01:27 PM UTC-5, MG wrote:
>>>>
>>>> The BeagleBoneBlack comes with an "internal" EEPROM connected to i2c-0
>>>> line. I can see that clearly when I do i2cdetect:
>>>>
>>>> debian@beaglebone:~$ i2cdetect -y -r 0
>>>>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>>>> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> 20: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
>>>> 30: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
>>>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> 50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> 70: UU -- -- -- -- -- -- --
>>>>
>>>> It is showing under address 0x50. When I try to do ahexdump I get the
>>>> following values with no issue:
>>>>
>>>> sudo hexdump -C /sys/class/i2c-dev/i2c-0/device/0-0050/eeprom |
>>>> head -5
>>>>   aa 55 33 ee 41 33 33 35  42 4e 4c 54 30 30 30 43
>>>> |.U3.A335BNLT000C|
>>>> 0010  31 38 33 37 42 42 42 47  30 36 32 32 ff ff ff ff
>>>> |1837BBBG0622|
>>>> 0020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
>>>> ||
>>>> *
>>>> 1000  aa 55 33 ee 41 33 33 35  42 4e 4c 54 30 30 30 43
>>>> |.U3.A335BNLT000C|
>>>>
>>>> Now I want to add another EEPROM (with cape) on i2c-2 line which is
>>>> supported according to [BBB SRM](
>>>> https://cdn-shop.adafruit.com/datasheets/BBB_SRM.pdf) section 8.2. It
>>>> is the CAT24C256 as mentioned in the SRM. The allowable address range for
>>>> the expansion cards is 0x54-0x57. When I do i2cdetect I can see the
>>>> following:
>>>>
>>>> debian@beaglebone:~$ i2cdetect -r -y 2
>>>>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>>>> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> 50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- --
>>>> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> 70: -- -- -- -- -- -- -- --
>>>>
>>>> I can see the addresses 0x54-0x57 showing, but when I try hex dump I
>>>> get an error:
>>>>
>>>>   hexdump: /sys/class/i2c-dev/i2c-2/device/2-0054/eeprom:
>>>> Connection timed out
>>>>
>>>> Questions:
>>>>
>>>> 1. Why are they showing as U's not actual address numbers? I know U
>>>> stands for used resource?
>>>> 2. Why am I failing to read from that EEPROM? I have tried all addreses
>>>> 

Re: [beagleboard] Re: Set up Cape's EEPROM i2c-2 BeagleBoneBlack Rev-C

[Graham Haddock]

I think there is a detailed discussion as to what is supposed to be inside
the cape EEPROMs in the
"BeagleBone Black System Reference Manual"

It looks like there is a live Wiki version at
https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual

But since that address has already been reserved by the kernel, for the
cape manager,
you will not be able to read/write it from user space.

If you want to access that address from user space on a BBB, you need to
stop the cape manager.
Google "BBB without reserved I2C addresses" on this forum.
and look at "am335x-bone-common-no-capemgr.dtsi"

--- Graham

==


On Wed, Oct 31, 2018 at 10:01 AM MG  wrote:

> @Graham I do have a cape with EEPROM at address 0x57 but the EEPROM is
> wiped with nothing on it so I guess that is why the board doesn't populate
> that address by default. How can I fix that?
>
> On Tuesday, October 30, 2018 at 11:14:50 PM UTC-4, gra...@flex-radio.com
> wrote:
>>
>> Those addresses at 0x54-0x57 are reserved by the kernel driver.
>>
>> Unless you have some capes with those EEPROMS populated, there is nothing
>> actually there.
>>
>> --- Graham
>>
>> ==
>>
>> On Tuesday, October 30, 2018 at 7:01:27 PM UTC-5, MG wrote:
>>>
>>> The BeagleBoneBlack comes with an "internal" EEPROM connected to i2c-0
>>> line. I can see that clearly when I do i2cdetect:
>>>
>>> debian@beaglebone:~$ i2cdetect -y -r 0
>>>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>>> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 20: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
>>> 30: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
>>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 70: UU -- -- -- -- -- -- --
>>>
>>> It is showing under address 0x50. When I try to do ahexdump I get the
>>> following values with no issue:
>>>
>>> sudo hexdump -C /sys/class/i2c-dev/i2c-0/device/0-0050/eeprom | head
>>> -5
>>>   aa 55 33 ee 41 33 33 35  42 4e 4c 54 30 30 30 43
>>> |.U3.A335BNLT000C|
>>> 0010  31 38 33 37 42 42 42 47  30 36 32 32 ff ff ff ff
>>> |1837BBBG0622|
>>> 0020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
>>> ||
>>> *
>>> 1000  aa 55 33 ee 41 33 33 35  42 4e 4c 54 30 30 30 43
>>> |.U3.A335BNLT000C|
>>>
>>> Now I want to add another EEPROM (with cape) on i2c-2 line which is
>>> supported according to [BBB SRM](
>>> https://cdn-shop.adafruit.com/datasheets/BBB_SRM.pdf) section 8.2. It
>>> is the CAT24C256 as mentioned in the SRM. The allowable address range for
>>> the expansion cards is 0x54-0x57. When I do i2cdetect I can see the
>>> following:
>>>
>>> debian@beaglebone:~$ i2cdetect -r -y 2
>>>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>>> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- --
>>> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 70: -- -- -- -- -- -- -- --
>>>
>>> I can see the addresses 0x54-0x57 showing, but when I try hex dump I get
>>> an error:
>>>
>>>   hexdump: /sys/class/i2c-dev/i2c-2/device/2-0054/eeprom: Connection
>>> timed out
>>>
>>> Questions:
>>>
>>> 1. Why are they showing as U's not actual address numbers? I know U
>>> stands for used resource?
>>> 2. Why am I failing to read from that EEPROM? I have tried all addreses
>>> from 0x54-0x57 with no luck. I can confirm that those addresses are showing
>>> in /sys/class/i2c-dev/i2c-2/device and the each dir has the following in it:
>>>
>>>  debian@beaglebone:~$ ls
>>> /sys/class/i2c-dev/i2c-2/device/2-0054/ -la
>>>  total 0
>>>  drwxr-xr-x 4 root root 0 Oct 26 19:46 .
>>>  drwxr-xr-x 8 root root 0 Oct 26 19:46 ..
>>>  drwxr-xr-x 3 root root 0 Oct 26 19:47 2-00540
>>>  lrwxrwxrwx 1 root root 0 Oct 26 19:47 driver ->
>>> ../../../../../../bus/i2c/drivers/at24
>>>  -rw--- 1 root root 32768 Oct 26 19:47 eeprom
>>>  -r--r--r-- 1 root root  4096 Oct 26 19:47 modalias
>>>  -r--r--r-- 1 root root  4096 Oct 26 19:47 name
>>>  lrwxrwxrwx 1 root root 0 Oct 26 19:47 of_node ->
>>> ../../../../../../firmware/devicetree/base/ocp/i2c@4819c000
>>> /cape_eeprom0@54
>>>  drwxr-xr-x 2 root root 0 Oct 26 19:47 power
>>>  lrwxrwxrwx 1 root root 0 Oct 26 19:47 subsystem ->
>>> ../../../../../../bus/i2c
>>>  -rw-r--r-- 1 root root  4096 Oct 26 19:47 uevent
>>>
>>> I can see the addresses mapping into the kernel but when I try to
>>> 

Re: [beagleboard] Re: Adafruit i2c install issue

[Graham Haddock]

did you install smbus?
It is a prerequisite.
--- Graham

On Thu, Oct 4, 2018 at 10:34 AM Dennis Lee Bieber 
wrote:

> On Wed, 3 Oct 2018 20:15:04 -0700 (PDT), Chris Bohler
>  declaimed the
> following:
>
> >
> >When attempt to execute Adafruit_BBIO.I2C as I2C:
> >   "Adafruit_BBIO.I2C deprecated. Replace with Adafruit_GPIO.I2C"
> >
>
> Note the message says "deprecated", not that it is no longer
> usable.
>
>
> >  File
> >"/usr/local/lib/python2.7/dist-packages/Adafruit_GPIO-1.0.3-py2.7.egg/Adafruit_GPIO/I2C.py",
>
> >line 98, in __init__
> >import Adafruit_PureIO.smbus
> >ImportError: No module named Adafruit_PureIO.smbus
> >
>
> Looking at the source code for I2C
>
> """
> def __init__(self, address, busnum, i2c_interface=None):
> """Create an instance of the I2C device at the specified address on
> the
> specified I2C bus number."""
> self._address = address
> if i2c_interface is None:
> # Use pure python I2C interface if none is specified.
> import Adafruit_PureIO.smbus
> self._bus = Adafruit_PureIO.smbus.SMBus(busnum)
> else:
> # Otherwise use the provided class to create an smbus
> interface.
> self._bus = i2c_interface(busnum)
> """
>
> you can bypass Adafruit_PureIO by providing your own interface object. I
> have not looked deeper into what such an object would be.
>
> >This from simple python code:
> >
> >import Adafruit_GPIO.I2C as I2C
> >import Adafruit_BBIO.GPIO as GPIO
>
> I suspect if you are using Adafruit_GPIO you should also use
>
> import Adafruit_GPIO.GPIO as GPIO
>
> (that, itself, imports Adafruit_BBIO)
>
>
>
> --
> Wulfraed Dennis Lee Bieber AF6VN
> wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/gtbcrd585viblrvujp5e3ntgo6nq0pjkgl%404ax.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/CANN_KV5cfsAd19zVKwiW9HzLA%3DZqFJC4-p4CL19eFG5MFe0BWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Announcing $25 PocketBeagle

[Graham Haddock]

No, I only connected it with the USB-tether "gadget" via a Windows 10 PC.
I also got tired of the instability of the "gadget" and moved to either SPI
or USB2 interfaced wired Ethernet, both of which work well, if they are
fast enough for your application.

--- Graham

On Tue, Sep 18, 2018 at 3:30 PM Jake Pape  wrote:

> Graham:
>
> Were you able to try this out on a Mac?
>
> I have followed the steps on here:
> https://www.hackster.io/hologram/sharing-internet-with-the-pocketbeagle-on-osx-cd62b2
>
> However, as I follow the steps the final result doesn't allow me to ping
> google.com or work with any clicks because the PocketBeagle is not
> connecting.
>
> Thanks,
> Jake Pape
>
> On Tuesday, October 3, 2017 at 9:58:51 PM UTC-5, Graham wrote:
>>
>> Andy:
>>
>> The following is an outline of what to do to connect a PocketBeagle to
>> the internet via the USB cable to a Windows 10 desktop which is connected
>> to the Internet via hardwire Ethernet.
>>
>> ~~~
>> Ethernet over USB Tether Gadget
>> ~~~
>>
>> This is to connect a PocketBeagle to the Internet through the USB
>> connection to a Windows 10 desktop, which is connected by hardwire Ethernet
>> to the Internet.
>>
>> I used 'Etcher' to load a fresh copy of the latest 'stretch' version of
>> Debian 9.1 onto the Pocketbone.
>> bone-debian-9.1-iot-armhf-2017-10-01-4gb.img
>>
>> Plug the PocketBeagle into an open USB port on your Windows 10 desktop
>>
>> The four LEDs should start blinking, and after about a minute or so, a
>> new USB serial device should appear in Device Manager\Ports(COM), and a
>> new Remote NDIS Compatible Device should appear in Device Manager\Network
>> Adaptors
>>
>> Also, a new Ethernet interface will appear in Control Panel\Network and
>> Internet\Network Connections.
>> It will be described as "Unidentified Network", Remote NDIS Compatible
>> Device
>>
>> Use Putty to connect to the new COM port
>> log into the PocketBeagle
>>
>> now type
>> sudo /sbin/route add default gw 192.168.7.1
>>
>> Now, on the Windows 10 desktop,
>> go to and open your primary Ethernet interface:
>>  Ethernet\Properties\Sharing\
>> Check the two sharing boxes.
>> Enter the name of the new NDIS Device interface into the box. [In my case
>> it was Ethernet 2 ]
>> Click 'OK' and exit the interface box
>>
>> Now open the Unidentified Network\NDIS Device
>> interface\Properties\Internet Protocol Version 4\Properties
>> Click 'Use the following IP address'
>> Enter 192.168.7.1 as the IP address
>> Enter 255.255.255.0 as the Subnet Mask
>>
>> Click 'Use the following DNS server addresses'
>> Enter 8.8.8.8 as the Preferred DNS server.
>> Click 'OK' and 'Close' to exit
>>
>> Now go to the PocketBeagle command line on Putty
>> sudo nano /etc/resolv.conf
>> down-arrow to get past the comment line
>> enter 'nameserver 8.8.8.8'   [without the quotes]
>> enter 
>> enter , then 'Y',  to exit[without the quotes]
>>
>> The Ethernet tether gadget should be operational.
>> To test, type 'ping google.com' in the command line. [without the quotes]
>> It should run and see the ping replies.
>> type  to abort.
>>
>> You should now have internet access and can
>> sudo apt-get update
>>
>> The two entries in the PockBeagle are not persistent, so after any reboot,
>> you will have to repeat the two entries in the PocketBeagle to get the
>> internet tether gadget running again.
>>
>>
>> There is more information here ...
>>
>> https://www.digikey.com/en/maker/blogs/how-to-connect-a-beaglebone-black-to-the-internet-using-usb/cdf66181b3a5436e9ad730e4ed4cf9ee
>>
>> ==
>>
> --
> 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/da7c010b-773e-48a2-bc56-a40c064abb39%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/CANN_KV6K7MUXgpAy3JOL_dKQX7ttSe5%3D56Yirk4m%2B3u9H9nAGg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] TFT Display Interface

[Graham Haddock]

Please do not use "TinyUrl" when distributing information.
It forces the receiver to open an unknown website on their computer.
Might be innocent, might be malicious.

If you want help, please provide the part number, and any URL should be the
full and exact URL.

--- Graham

==

On Mon, Sep 17, 2018 at 9:05 PM  wrote:

> Is it possible to interface this TFT display (https://tinyurl.com/y83chdbj)
> to a PocketBeagle?
>
> Can I use I2C protocol? I guess I am going to need additional hardware,
> right?
>
> --
> 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/a754e7df-7d6a-4bda-934a-32344cebdc7a%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/CANN_KV6Wt8NK_Rh7g%2B2-9FhMB%2BdTiDuOQ%3D%3DDPioAOqN0%3D-BepQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: battery power for PocketBeagle?

[Graham Haddock]

Fred:
The temperature coefficient is only important if you are going to use them
as temperature monitors, and you are going to thermally/mechanically attach
them to the battery.

If you are just trying to get the battery power supply to run, and are not
concerned about battery temperatures, a fixed resistor will work fine.

--- Graham

==

On Thu, Sep 6, 2018 at 3:34 AM Fred Kerr  wrote:

> I am looking for 10K NTC Thermistors with B=3480. How critical is the B
> value, or what range can I accept? Currently I am looking on Mouser.
>
> Is there a specific or recommended battery pack? I'm just using an 18650
> from a local surplus store.
>
> Regarding the log file, I still need to do this:
>
> sudo /opt/scripts/tools/developers/update_bootloader.sh
>
> I'll also look for 100K thermistor with B=3960
>
> On Thursday, August 30, 2018 at 5:35:43 PM UTC-7, Fred Kerr wrote:
>>
>> It runs well with the soldered implementation. My breadboards are a
>> little cheap.
>>
>> The attached minicom_20180830b.cap shows a boot with microUSB power from
>> a wall wart (from my rpi3), then a boot with the battery circuit. I left
>> both RX and TX attached; I'll play with disconnecting them another time.
>>
>> I'll look into getting some "telemetry" info from the pocket beagle. I'm
>> open to suggestions about things to add/log, etc. Also, I think this pocket
>> beagle doesn't have a fix that I got before - after the shutdown, things
>> panic.
>>
>> If anything else jumps out from the log file, please let me know!
>>
>> On Wednesday, August 29, 2018 at 10:59:03 AM UTC-7, Fred Kerr wrote:
>>>
>>> I'll try again soon with my more stable circuit (*soldered), also with
>>> RX disconnected so I just get output from the Pocket Beagle and the only
>>> power input is from the battery circuit.
>>>
>>> (*Soldered, so no loose breadboard connections, better current carrying
>>> capacity, etc.)
>>>
>>> What is a good way to share log files? Mine can get verbose! I could
>>> store it somewhere and post a link - suggestions welcomed! I have a lot of
>>> possibilities, but just let me know what works best for you.
>>>
>>> On Tuesday, August 28, 2018 at 12:51:23 PM UTC-7, Fred Kerr wrote:

 Yes, it ran quite a lot longer on the 1F, but still hung.

 I wired this up (see pic) to be more stable than the breadboard mess I
 had. The led on 1.8k resistor is gonna run a lot longer than I'll take at
 lunch!!!

 Can I isolate RX and TX or...oh I just need TX from the beagle for
 visibility!

 1F 5.5v supercap (that battery was discharged to 3.96v). This one has
 more charge. Also put a 1000uf electrolytic on the soldered version,
 "because".

 Fred Kerr (mobile)

 On Tue, Aug 28, 2018, 12:13 PM Jason Kridner 
 wrote:

>
>
> On Monday, August 27, 2018 at 11:15:36 PM UTC-4, Fred Kerr wrote:
>>
>> Hello all,
>>
>> I'm being just a little bit careful here:
>>
>> I'm about to try this, but I will connect up the serial terminal
>> first, so I can see output and interact with the board. (Graceful 
>> shutdown!)
>>
>
> Don't connect the power or RX (ie., serial cable to PocketBeagle)
> signals to avoid them interfering. Great thing to monitor.
>
>
>>
>> I will test the serial connection first with just a micro USB
>> charging cable rather than USB to a computer. (Simplify!)
>>
>
> Not sure what you are testing here. Are you just saying you'll power
> via the microUSB connection and not connect to a computer, just to see the
> behavior? You are monitoring with a serial connection?
>
>
>>
>> It's my understanding that LiPo charging is disabled or not present
>> in the firmware. (I'll give you the "uname -a" and other info the next 
>> time
>> I fire it up. Just let me know what and how to check.)
>>
>
> It is not enabled by default. There is a flag in the PMIC that needs
> to be enabled. We've been playing with a driver to set the flag, but there
> are other bugs in that driver not related to actually charging.
>
>
>>
>> Also, it's not clear (without reading the data sheet :) ) about the
>> resistor values for the thermistor and the parallel (linearizing?) 
>> resistor.
>>
>> If you have a 10K thermistor, do you put it in parallel with a 10K
>> resistor, or likewise 100K thermistor in parallel with a 100K resistor? 
>> Do
>> you put the thermistor anywhere in contact with the (e.g., 18650) LiPo?
>>
>
> Looking at the TPS65217 datasheet says to put a 75kohm resistor in
> parallel.
>
> I'm not sure, but I believe the actual thermal resistor should be
> something like
> https://www.ametherm.com/blog/thermistors/thermistors-ntc-thermistor-temperature-sensors-provide-li-ion-battery-safety/
> .
>
>
>>
>> From the prior thread, it seems to be sufficient 

Re: [beagleboard] config-pin i2c not working

[Graham Haddock]

Mark:

Well, I suspect it would take a deep dive into the drivers to answer that.

I agree with what you would expect, but there is software involved.

I obviously does not like to be configured twice?
The configuration depends on some assumed initial states that are no longer
true when it has already been configured?

I am not knowing.

--- Graham

==


On Thu, Sep 6, 2018 at 8:33 AM Mark A. Yoder  wrote:

> Graham:
>   Yes, it works without configuring, but why does it stop working when
> configured to be i2c?  And why does it start working when configured to be
> gpio?  That's the opposite of what I'd expect.
>
> --Mark
>
> On Wednesday, September 5, 2018 at 5:12:06 PM UTC-4, Graham wrote:
>>
>> Mark:
>>
>> That bus is configured by default, so you should not have to configure it
>> to use it.
>> It is the bus used to probe for and talk to the memory chip on equipped
>> capes.
>> Try using the I2C-2 bus without configuration. It should just work.
>>
>> --- Graham
>>
>> 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/CANN_KV7xD0%2BamDr-G_-tF%3DfRrSv-OH%3D0tpJufabdh_XVOA0bFA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] config-pin i2c not working

[Graham Haddock]

Mark:

That bus is configured by default, so you should not have to configure it
to use it.
It is the bus used to probe for and talk to the memory chip on equipped
capes.
Try using the I2C-2 bus without configuration. It should just work.

--- Graham

==

On Wed, Sep 5, 2018 at 3:04 PM Mark A. Yoder  wrote:

> I'm using the i2c bus 2 that appears on P9_21 and P9_22 on the Bone Black.
>
> If I run:
> bone$ *config-pin P9_21 i2c*
> bone$ *config-pin P9_22 i2c*
>
> My i2c bus doesn't work, but if I run:
> bone$ *config-pin P9_21 gpio*
> bone$ *config-pin P9_22 **gpio*
>
> it does?  What's up?
>
> --Mark
>
> sudo /opt/scripts/tools/version.sh
> [sudo] password for debian:
> git:/opt/scripts/:[ed7dd4c61a9c9307b08db8a7dcbaffac77a7f776]
> eeprom:[A335BNLT0A5C3513BBBK3281]
> model:[TI_AM335x_BeagleBone_Black]
> dogtag:[BeagleBoard.org Debian Image 2018-07-02]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
> 2018.03-2-gac9cce7c6a]:[location: dd MBR]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
> 2016.03-1-g9a81f4a]:[location: dd MBR]
> kernel:[4.18.1-bone4]
> nodejs:[v6.14.3]
> uboot_overlay_options:[enable_uboot_overlays=1]
> uboot_overlay_options:[disable_uboot_overlay_video=1]
>
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
> uboot_overlay_options:[enable_uboot_cape_universal=1]
> pkg check: to individually upgrade run: [sudo apt install --only-upgrade
> ]
> pkg:[bb-cape-overlays]:[4.4.20180628.0-0rcnee0~stretch+20180628]
> pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
> pkg:[kmod]:[23-2rcnee1~stretch+20171005]
> pkg:[roboticscape]:[0.4.4-git20180608.0-0rcnee0~stretch+20180609]
> pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
> groups:[debian : debian adm kmem dialout cdrom floppy audio dip video
> plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep
> admin spi tisdk weston-launch xenomai]
> cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1
> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M
> net.ifnames=0 quiet]
> dmesg | grep pinctrl-single
> [1.368684] pinctrl-single 44e10800.pinmux: 142 pins, size 568
> dmesg | grep gpio-of-helper
> [1.398397] gpio-of-helper ocp:cape-universal: ready
> END
>
> --
> 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/9b8153f1-ca60-420e-843e-dbb9863f68dd%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/CANN_KV77qvVWF26cphN6hDENU2d9XhEPpOOSdUZK1ohHT3s6nA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB questions

[Graham Haddock]

Ethernet

On Wed, Aug 8, 2018 at 11:15 AM,  wrote:

> Hey guys,
> I'm trying to transfer video to raspberry pi.
>
> Which one should i use? the fastest? GPIO I2C SPI UART?
>
> I want to send video data from BBB to raspberry pi and receive data from
> Raspberry pi to BBB.
> I'm going to stream live video using cheese application and send it to
> raspberry pi. I want one with the least latency and the easiest to work
> with.
>
> 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/790ef355-8219-4e46-984e-4feae074e555%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/CANN_KV4hV%2BNZFoZ68NbqTQTPwdw-RFVcDfHo7FKd%3DV7crRd_-w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: DIfferences between console, iot and lxqt builds (also 2Gb and 4Gb)?

[Graham Haddock]

The console will not have Python installed. But apt-get can install Python2
or Python3 or both and all dependencies, and a minimum set of Python
modules. Other modules are available with pip.

example:

sudo apt install git build-essential tree htop i2c-tools python3
python3-pip python3-smbus


--- Graham

==

On Sun, Apr 8, 2018 at 12:28 PM, Chris Green  wrote:

> Graham  wrote:
> > [-- multipart/alternative, encoding 7bit, 157 lines --]
> >
> > [-- text/plain, encoding quoted-printable, charset: UTF-8, 73 lines
> --]
> >
> > Chris:
> > Pretty much right on.
> >
> > The lxqt, full GUI, full set of programming languages, etc. are typically
> > in the range of 3.5 to 4 GB when loaded.
> > So not a lot of room left for a big project in the eMMC.
> >
> > IoT stands for "Internet of things" and has everything but the GUI
> > interfaces loaded.
> > Typically about 2 GB when loaded
> > Intended for network connected, but no local GUI.
> > Things like Python, Javascript, are loaded and ready to go.
> > Lots of room for most project applications.
> >
> > Console is about 1 GB loaded.  Minimum functional Linux installation,
> with
> > full network interfaces, no GUI.
> > If you want to do anything, such as to run Python, you have to load it
> and
> > its dependencies yourself.
> > But adding what you need with apt-get is usually easier than stripping
> out
> > a bunch of stuff from the IoT.
> > The best starting point for a dedicated, custom installation and
> > application.
> >
> I see, thanks for the explanation of iot.  So 'console' won't even
> have Python?  However, as you say, using apt-get to install stuff on a
> console based system will certainly be easier to get to a minimal
> system for a specific set of needs.
>
> I probably only need console + python + a couple of python modules.
>
> --
> Chris Green
> ·
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/3kzR8124gEk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/330qpe-t7j.ln1%40esprimo.zbmc.eu.
> 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/CANN_KV5D4MzABSTQ%3D3dfm01j9PCqcYQjfg4qSRnaUu5FHXux%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] SD card errors on hard reboot

[Graham Haddock]

I don't use node.js, so I am not familiar with it.
The name of the function suggests that it does a 'sync' after the write,
which is what you want.
In Linux, the 'sync' command flushes all the buffers to disk.
I would just read the manual on the function to make sure it is doing what
you want.
--- Graham

==

On Tue, Mar 20, 2018 at 12:28 PM, Troy Weber  wrote:

> How would you flush the sd card buffers from node.js? To write to the
> files I am doing using the *writeFileSync* command.
>
>
> On Monday, March 19, 2018 at 5:55:12 PM UTC-7, Graham wrote:
>>
>> As a matter of buffer hygiene, are you flushing the buffers to the sd
>> card after every time you write to it?
>> Something like the equivalent of the 'sync' command?
>> If there is still unwritten info in the buffers when the power gets
>> pulled, bye-bye data.
>>
>> In Linux, when the mounted drive is suddenly declared "read-only" it
>> means that the OS has observed some corruption or error in the file system,
>> and does so to prevent further corruption.
>>
>> --- Graham
>>
>> ==
>>
>> On Monday, March 19, 2018 at 6:59:29 PM UTC-5, Wulf Man wrote:
>>>
>>> I dont know if its for sale there was a battery cape
>>> or you can go with custom hardware
>>>
>>>
>>> On 3/19/2018 4:56 PM, Troy Weber wrote:
>>>
>>> Well we need to be able to pull the plug without damaging things. Is the
>>> best option then to have a battery system that allows BBB to listen for
>>> loss of power and gracefully shut down? Are there alternative methods?
>>>
>>> Troy Weber
>>> Mechatronics / Software Developer
>>> troyw...@gmail.com
>>> 707-761-1644 <(707)%20761-1644>
>>> sent from mobile
>>>
>>> On Mon, Mar 19, 2018, 4:42 PM evilwulfie  wrote:
>>>
 Well yes if you fail to unmount a file system you can have issues.
 On my systems i designed a battery backup system to prevent just the
 issues you
 are seeing now.
 It does not happen all the time but one time is unacceptable.

 Beaglebone is a live filesystem and you cant just pull the plug.

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to a topic in the
 Google Groups "BeagleBoard" group.
 To unsubscribe from this topic, visit https://groups.google.com/d/to
 pic/beagleboard/MfN646FtxiA/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 beagleboard...@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/ms
 gid/beagleboard/9e31b553-0c83-640b-99ab-b1b3f2c993ce%40gmail.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...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/beagleboard/CAPMxd4SkyyydxiQgzeKQY%3DKoryWZ792Wuxv2%
>>> 2BvW2Cgv-KjbwsQ%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 a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/MfN646FtxiA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/980149f3-a0a8-4863-a327-3fd4a0e2657a%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/CANN_KV5qK0zke1B88DA2U9dS4PdCeqfZZrV-WGhedZxHJ5x%3Dng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Announcing $25 PocketBeagle

[Graham Haddock]

It works fine on the PocketBeagle running Debian.
You do need to connect it to USB1, which is pinned out on the accessory
connectors, and not USB0, which is on the micro-USB connector.
--- Graham

==

On Thu, Feb 15, 2018 at 7:04 AM,  wrote:

> Hello,
>
> I'm trying to get Internet over USB working on the PocketBeagle with an
> Ubuntu 16.04 host, but without success.
> Has anybody managed to get that working ?
>
> Thanks!
>
> Le mardi 19 décembre 2017 18:15:37 UTC+1, Jason Kridner a écrit :
>>
>>
>>
>> On Tuesday, October 3, 2017 at 10:58:51 PM UTC-4, Graham wrote:
>>>
>>> Andy:
>>>
>>> The following is an outline of what to do to connect a PocketBeagle to
>>> the internet via the USB cable to a Windows 10 desktop which is connected
>>> to the Internet via hardwire Ethernet.
>>>
>>> ~~~
>>> Ethernet over USB Tether Gadget
>>> ~~~
>>>
>>> This is to connect a PocketBeagle to the Internet through the USB
>>> connection to a Windows 10 desktop, which is connected by hardwire Ethernet
>>> to the Internet.
>>>
>>> I used 'Etcher' to load a fresh copy of the latest 'stretch' version of
>>> Debian 9.1 onto the Pocketbone.
>>> bone-debian-9.1-iot-armhf-2017-10-01-4gb.img
>>>
>>> Plug the PocketBeagle into an open USB port on your Windows 10 desktop
>>>
>>> The four LEDs should start blinking, and after about a minute or so, a
>>> new USB serial device should appear in Device Manager\Ports(COM), and a
>>> new Remote NDIS Compatible Device should appear in Device Manager\Network
>>> Adaptors
>>>
>>> Also, a new Ethernet interface will appear in Control Panel\Network and
>>> Internet\Network Connections.
>>> It will be described as "Unidentified Network", Remote NDIS Compatible
>>> Device
>>>
>>> Use Putty to connect to the new COM port
>>> log into the PocketBeagle
>>>
>>> now type
>>> sudo /sbin/route add default gw 192.168.7.1
>>>
>>
>> Instead of doing this, I use 'sudo dhclient usb0' such that it updates
>> the nameservers (/etc/resolv.conf) automatically.
>>
>> For Mac/Linux, I use 'sudo dhclient usb1'.
>>
>>
>>>
>>> Now, on the Windows 10 desktop,
>>> go to and open your primary Ethernet interface:
>>>  Ethernet\Properties\Sharing\
>>> Check the two sharing boxes.
>>> Enter the name of the new NDIS Device interface into the box. [In my
>>> case it was Ethernet 2 ]
>>> Click 'OK' and exit the interface box
>>>
>>> Now open the Unidentified Network\NDIS Device
>>> interface\Properties\Internet Protocol Version 4\Properties
>>> Click 'Use the following IP address'
>>> Enter 192.168.7.1 as the IP address
>>> Enter 255.255.255.0 as the Subnet Mask
>>>
>>> Click 'Use the following DNS server addresses'
>>> Enter 8.8.8.8 as the Preferred DNS server.
>>> Click 'OK' and 'Close' to exit
>>>
>>> Now go to the PocketBeagle command line on Putty
>>> sudo nano /etc/resolv.conf
>>> down-arrow to get past the comment line
>>> enter 'nameserver 8.8.8.8'   [without the quotes]
>>> enter 
>>> enter , then 'Y',  to exit[without the quotes]
>>>
>>> The Ethernet tether gadget should be operational.
>>> To test, type 'ping google.com' in the command line. [without the
>>> quotes]
>>> It should run and see the ping replies.
>>> type  to abort.
>>>
>>> You should now have internet access and can
>>> sudo apt-get update
>>>
>>> The two entries in the PockBeagle are not persistent, so after any
>>> reboot,
>>> you will have to repeat the two entries in the PocketBeagle to get the
>>> internet tether gadget running again.
>>>
>>>
>>> There is more information here ...
>>> https://www.digikey.com/en/maker/blogs/how-to-connect-a-beag
>>> lebone-black-to-the-internet-using-usb/cdf66181b3a5436e9ad730e4ed4cf9ee
>>>
>>> ==
>>>
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/JtOGZb-FH2A/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/b1129fa8-22ef-49ba-9237-11c5586ef8a5%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/CANN_KV5TZ6Gpegs05n4aaKA7Cun7jwPhQ9tm1mVNv_-h8DQ62w%40mail.gmail.com.
For more options, visit 

Re: [beagleboard] Re: I2C woes

[Graham Haddock]

On the PocketBeagle, both I2C-1 and I2C-2 are both brought out to the
headers and both enabled by default.
I don't know that there is any reason to prefer one over the other on the
PocketBeagle.

--- Graham

==

On Sat, Feb 10, 2018 at 7:55 PM, Stuart Longland  wrote:

> On 11/02/18 11:43, Graham wrote:
> > I am not an expert at Device Tree stuff, but this is what I think I know.
> > I2C-0 is intended for internal board management, so sort of reserved,
> > except as a last resort.
> > I2C-1 is available, but not enabled, on the BBB and is
> > enabled/implemented on the PocketBeagle, so you could always look at the
> > PocketBeagle implementation.
>
> I figure then, if we want to hook our own stuff up, then I²C1 is the
> preferred port to use?  In my case I'm running a PocketBeagle, and while
> I've hooked up headers to I²C0, I haven't yet exposed those.
> --
> Stuart Longland (aka Redhatter, VK4MSL)
>
> I haven't lost my mind...
>   ...it's backed up on a tape somewhere.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/RU6TUpBEwpI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/84e8df94-7cfc-e50c-d188-b9507631cdb9%
> 40longlandclan.id.au.
> 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/CANN_KV7f9sHCb697Tf4MLYWKOD7bc7EJufNpOD%3DgeUni0cbO3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Pulsing Power Up

[Graham Haddock]

I'l look at it with both a Voltmeter and an oscilloscope.

I have a B bench supply that when you turn it on, with a BBB already
attached, did an overshoot up to around 5.7 Volts before settling back to
5.0 Volts.
It would trip the self protect on the PMIC almost every time you tried to
start the BBB.

--- Graham

==

On Wed, Jan 17, 2018 at 3:10 PM, Chip Wachob  wrote:

> I have a static 1.5A resistive load on the supply which has a 1A minimum
> load.  That would leave me with 10.5 A of wiggle room.  Out of which I need
> just less than 2A.
>
> I'll revisit the supply level, but I'm fairly certain that I am well
> within those ranges.
>
>
>
> On Wed, Jan 17, 2018 at 4:06 PM, Graham  wrote:
>
>> Still sounds like a power problem.
>>
>> A lot of 12 Amp supplies might go out of regulation at almost no load.
>> They typically need to be loaded to ten percent of max rated output load
>> to be within Voltage spec.
>>
>> The Beagle supply needs to stay between 4.5 and 5.5 Volts under all load
>> conditions.
>>
>> I recommend you stay between 4.75 and 5.25 to have noise margin against
>> the PMIC going into self-protect.
>>
>> --- Graham
>>
>> ==
>>
>> On Wednesday, January 17, 2018 at 2:03:32 PM UTC-6, epar...@gmail.com
>> wrote:
>>>
>>> Hello,
>>>
>>> I just finished reading a lot of posts on the topic of starting up the
>>> BBB and various issues that folks have had.  I didn't see anything that
>>> reflected my situation, so I'm going to reach out in hopes that someone in
>>> the group can cast some light on this.
>>>
>>> I have a BBB with a custom Cape.  The Cape is designed to interface the
>>> BBB to a cap-touch color screen.  The Cape contains the backlight power
>>> supply for the display and the obligatory EEPROM for ID, addressing pins,
>>> etc.  Very similar to the BB-CAPE-DISP-CT43
>>>  available for purchase.
>>>
>>> What is different in my case is that I'm supplying power to the Cape
>>> (5V).  The power then goes to the Cape connector on P9, pins 5 & 6.  This
>>> would be equivalent to supplying power to the BBB via the barrel connector.
>>>
>>> The BBB is internally booting (no SD, etc) with custom code.  I have
>>> written the shipping code image into the board and I get the same results.
>>>
>>> I've made several dozen of these assemblies now, and so far I have two
>>> that exhibit this odd behavior.
>>>
>>> The symptom:  The BBB will attempt to start, will shut down, and will
>>> try to start once more at a rate of about once per second.  Sometimes this
>>> only happens a couple of times, other times I simply give up after 60 of
>>> these failed boot cycles.  There is no consistency to the number of tries a
>>> board will go through.
>>>
>>> I'm using a very robust power supply that meets or exceeds the PMIC slew
>>> rate requirements.  The supply is capable of supplying 12A @ 5VDC.
>>>
>>> When the BBB is attempting to boot, the blue LED adjacent to the barrel
>>> connector (commonly referred to as the Power LED) will flash briefly.
>>>
>>> There are occasions when a 'bad' assembly will boot without issue, but
>>> most frequently it comes up in this flashing state.
>>>
>>> I've checked for the usual suspects, bad solder joints, interconnects,
>>> etc, without finding anything.  I know that my inrush current is on the
>>> order of 1.7 to 1.8 A at the initial startup, but that drops off
>>> significantly after the caps are charged up.
>>>
>>> Has anyone out there experienced this pulsing behavior and found a root
>>> cause and possibly a fix?
>>>
>>> One thought that I had was to monitor the bebug  port (X1), but is there
>>> even enough up time to have this be useful?
>>>
>>> Thank you to everyone in advance for your insight.
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/beagleboard/IbYlM9n9DIY/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/beagleboard/ffe872d5-cadb-460f-8f1f-709727d1d7a1%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 a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/IbYlM9n9DIY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view 

Re: [beagleboard] Re: PocketBeagle USB1 Question

[Graham Haddock]

Works fine.  As long as power/Vusb is on Vi  (P1-pin 7)
--- Graham

On Sun, Dec 10, 2017 at 12:18 PM, Patrick Poirier <
patrickpoirie...@gmail.com> wrote:

> Hello, I am planning to use this setup, Have you successfully implemented
> and completed tests ?
>
> Regards
>
>
> Le vendredi 17 novembre 2017 13:11:59 UTC-5, wi...@geomonkey.com a écrit :
>
>> Graham --
>>
>> Thanks for the advice! That totally makes sense. I now intend to try this
>> configuration to get the added USB1 working in host mode (e.g., to control
>> a Sony camera using the gphoto2 library):
>>
>>
>> 
>>
>> These USB power switch ICs (e.g., Diodes Incorporated AP2822AKATR-G1, 
>> Richtek RT9711CGB,
>> Richtek RT9742JNGV) limit current, prevent reverse current, etc., and
>> cost less than a dollar. I'll report back about whether this ends up
>> working okay.
>>
>> -- Will
>>
>>
>> On Thursday, November 16, 2017 at 5:10:48 PM UTC-7, Graham wrote:
>>>
>>> Your first connection does not work, because you are trying to power the
>>> USB1 from the USB_VIN, but since the is no power going into USB_VIN on
>>> USB-0, there is no power to come out USB-1.
>>> This only works when the board is powered from USB-0
>>> The schematic does not tell you, but USB_VIN, USB0_VIN and USB1_VIN are
>>> all connected together.
>>>
>>> VIN is a totally separate power supply input
>>>
>>> Since you are powering the board from VIN (P1-01) you need to hook the
>>> 5V line on your Micro-USB board to P1-01 and P1-05.
>>>
>>> In this case, it will work, although you have no current limit
>>> protection from a short on the 5V line in a downstream USB device, which is
>>> required by the USB spec.
>>> So, only plug in USB devices and cables you trust.
>>>
>>> I would not power the USB-5V-VBUS from the SYS-VOUT, because SYS-VOUT is
>>> limited to 0.2 A or so, and many USB devices draw more current than this
>>> (USB-2 devices are allowed to draw up to 0.9 A)
>>>
>>> --- Graham
>>>
>>> ==
>>>
>>> On Thursday, November 16, 2017 at 5:11:52 PM UTC-6, wi...@geomonkey.com
>>> wrote:

 I, too, am wondering about the best way to provide power to the board
 and to a device connected to USB1 as host. Here is how I learned to hook up
 a micro-b breakout to USB1 and also how I intend to provide power to the
 board. The problem is that there is no measured voltage at USB1:


 

 I was wondering if I could just power the USB1 device from P1_24 SYS
 VOUT (which does have power when board is supplied by P1_01 SYS VIN) like
 this:


 
 Would it be harmful to do it this way? Are there better ways to
 accomplish this? Thanks!

 -- Will Bain


 On Sunday, November 5, 2017 at 6:59:39 PM UTC-7, Graham wrote:
>
> Further research, looking at the Eagle board and schematic files for
> the PB, it appears that USB0.VIN and USB1.VIN are both directly connected
> to VIN.USB
> Which explains why I had no power on my USB1 host port when connected
> like the Fritzing diagram, since I am powering from VIN currently.
>
> So the question becomes,,,
> What is the best way to power USB1 VBUS as a host if I don't know in
> advance whether the customer application will run from VIN or VIN.USB?
>
> --- Graham
>
> ==
>
> On Sunday, November 5, 2017 at 6:58:06 PM UTC-6, Graham wrote:
>>
>> I note that there is a PocketBeagle pin P1-7 named USB1-VIN.
>>
>> I don't find any connection on the PB schematic, other than to P1-7.
>>
>> It was connected externally in all of the USB1 host discussions and
>> Fritzing diagrams.
>>
>> The name would imply that it is a way to deliver power to the board
>> when USB1 has an external 5 Volt power source.
>>
>> I guess the basic question is whether this needs to be used/connected
>> when USB1 is functioning as a host.
>>
>> --- Graham
>>
>> ==
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/SWNBrgsjIeA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/d3044b29-28b0-4b78-8dbd-5fe7d845206a%40googlegroups.com
> 

Re: [beagleboard] Re: PocketBeagles are Unstable

[Graham Haddock]

P1-pin7 is the 5V power input normally associated with power coming in the
USB connectors.
In the case of the PocketBeagle, it is the input from the USB0 connector.
It can be used as either a 5V input or, if there is power coming in USB
port0, as a power output for USB port 1.
It is just a straight connection.

It happens to work fine, and does not seem to have the stability problem I
am seeing on P1-pin1.

--- Graham

==

On Mon, Dec 4, 2017 at 1:23 AM,  wrote:

>
>
> On Sunday, December 3, 2017 at 4:21:33 PM UTC+1, Graham wrote:
>>
>> The PocketBeagle, when powered only by the Vin input  (P1-pin1) is
>> unstable.
>> This is the power supply input, normally assigned to the barrel jack in
>> the BBB, or the AC adapter input in the TI docs.
>>
>> Not to be confused with the Vi input (P1-pin7) which is connected to
>> Vusb0 and Vusb1 on the PocketBeagle.
>>
>
> I'm not quite sure but isn't P1/7 the same as VDD on the BBB? In this case
> you definitely shouldn't use P1/1 for powering the board...
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/8Y5COfcW-Ok/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/9de62b40-9e5c-459f-b258-8e500aa43a31%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/CANN_KV4itWBHdSRzNVD7FBftnFT7pLMUm_af0Eb7U5H8u%2Bm8%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Problem with 5V

[Graham Haddock]

Yes, try some other power supplies. and if they stay between 4.75 and 5.25
under all the different load conditions a BBB can create, it will work fine.

USB power is highly variable from computer to computer.  Sometimes it works
fine, sometimes it does not.
USB-1 was 0.5 Amps max, not enough to run a BBB, while booting or updating
the eMMC.
USB-2 is 0.9 Amps, about enough to handle the peak current from a BBB.
The Voltage limits for USB are 4.5 to 5.5 Volts. No margin if at the limits
under full load.

--- Graham

==



On Wed, Nov 8, 2017 at 12:35 PM,  wrote:

> thanks for the answer. i think i need to find other power and test with
> that. If that new one stays 4.75 - 5.25 it will working normally then?
> how about that, im thinking to run it with USB power via USB connector. is
> it 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/CANN_KV45Zi%3DOGhTxVzsd2iKECTHBAQBLp_yy-sGVSbmfcD8t9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBB not powering on

[Graham Haddock]

All of your description points at a power supply problem.
If the USB power, even for a millisecond, drops below 4.5 Volts AT THE BBB,
the PMIC (Power Management IC) will shutdown.
If you have a computer with a USB port on the low side of the USB Voltage
range (4.5 to 5.5 Volts) then what you describe happens.
So that you have some margin in the system, you should hold the power AT
THE BBB between 4.75 and 5.25 Volts, even with heavy loads of booting or
updating.

If you put an oscilloscope on the power connector of the BBB, you should be
able to see what is happening.

--- Graham

==



On Thu, Oct 19, 2017 at 6:56 AM, Marco Thome  wrote:

> Thing is that I'm using only the provided USB cable. What troubles me is
> that the board turns on when I'm using a power adapter (DC jack), but it
> dies as soon as I connect it to the computer with an USB cable.
>
> On Wednesday, October 18, 2017 at 11:15:12 AM UTC-2, Graham wrote:
>>
>> Most likely, you are having power supply issues.
>>
>> The power drain of the BBB will double or triple during boot and update,
>> (relative to idle) so you need a power supply that can handle this.
>>
>> Many long USB cables are not capable of powering a BBB during peak loads.
>>
>> Some of the cheap wall supplies can't handle it.
>>
>> --- Graham
>>
>> ==
>>
>> On Wednesday, October 18, 2017 at 7:14:48 AM UTC-5, Marco Thome wrote:
>>>
>>> Hi,
>>>
>>> I was working with a brand new beaglebone black on usb as usual.
>>> Everything was fine, until I connect it to the company's network over
>>> ethernet and updated the board with *apt-get update* then *apt-get
>>> upgrade*. In the middle of the upgrade, the beagleboard just died. None
>>> of the five leds are on, no matter which usb port or computer it's
>>> connected to. I tried the same config with another board and it turned on
>>> just fine.
>>>
>>> I'm a little worried about it because it isn't the first time this kind
>>> of problem occurs. I was working with another board also over usb but on
>>> another computer and the same thing happened, though on this board the
>>> power led at least blink once when connected.
>>>
>>> It may not be so helpful, but I'm attaching a printscreen of what I was
>>> doing at the time. I had no chance to upgrade the kernel.
>>>
>>> Both boards only turn on when on power plug, but as soon as I connect
>>> them to the computer over usb, they die (no led lit).
>>>
>>> What am I doing wrong?
>>>
>>> Regards,
>>> Marco
>>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/oVelgZJExEQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/dc6f1f34-d993-414f-ab35-3bbd054158b5%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/CANN_KV77cqkNstoc7YqB1T8eJEP8DOaoKCbE176SS53oKWkOGg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Adding a USB Port to PocketBeagle

[Graham Haddock]

I am just reporting what "speedtest-cli" says.

I note that watching "htop" at the same time, on the USB-2 to Ethernet
tests, the CPU is maxing out at 100 percent, so the speed is not
necessarily constrained by the network interface, but the CPU's ability to
feed it, through the USB stack.

I don't know how speedtest-cli works. If it runs a random number
continuously, then we might be testing the speed of the random number
generator, rather than the network.  If it builds a large data table in
advance and just streams the table, then it is probably representative of
the fastest the system can run.

A long winded way of agreeing with you.

But, there is no doubt in my mind that the USB-2 to Ethernet interface is
about an order of magnitude faster than the SPI to Ethernet interface.

One conclusion is that putting a 1Gb Ethernet interface on a PocketBeagle
is a waste of money and power.  A 10/100 Mb USB-2 to Ethernet interface
would be cheaper, just as fast for throughput, and about one fourth the
power.

--- Graham

==

On Sat, Oct 14, 2017 at 11:06 AM, William Hermans  wrote:

>
>
> On Fri, Oct 13, 2017 at 8:39 AM, Graham  wrote:
>
>> I hacked a "quick and dirty" second USB port as described.
>> Then connected a LAN7500 USB-2 to Gb-Ethernet board.
>> Came right up, drivers are already in the kernel, no device tree changes.
>> Connected to the network at 1 Gb.
>>
>> speedtest-cli results (on a 1 Gb up/down network)
>> Download 27 Mbps, Upload 41 Mbps.
>>
>> And it has a legitimate MAC address.  :-)
>>
>> (for comparison, BBB Rev.C is download 60 Mbps, upload 70 Mbps, which
>> is about all I would expect out of a 100 Mbps connection.)
>>
>>
>> So, I'm not going ot argue about this, and I'm only going to say this
> once.
>
> I've real world tested ethernet on several A5A's, several C's, and a
> boatload of green's.  Down speeds 11.6MB/s( that's megabyte ), up speed
> 11.4-11.5MB/s.
>
> Real world test was a NFS share, reading / writing 1GB of data, or more.
>
> Additionally, I've benchmarked USB networking, Down speeds 105 Mbit/s, and
> uploads were a bit shy at around 85Mbit/s.
>
> You may want to check to make sure your speed test is accurate.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/GOwSuY4oiyI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/CALHSORpcn1uNWJqCLodmUUXuYYPXJKaypKHF83JN7Sz2O%3DdHog%
> 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/CANN_KV781zChZOdy-mp_cKBmFtSE3A5q-Y4C6Ux892A2JBK3xA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: ENC28J60 Click on PocketBeagle

[Graham Haddock]

The possible bus frequencies are integer divisors of 48 MHz, so only option
above 24 MHz is 48 MHz.
Spec on the W5500 chip says it will run up to 80 MHz.
So, I will recompile the ".dtbo' for 48 and report.
--- Graham

==

On Sat, Oct 7, 2017 at 6:02 PM, Robert Nelson 
wrote:

>
>
> On Oct 7, 2017 5:30 PM, "Graham"  wrote:
>
> Steven:
>
> Thanks for pointing out speedtest-cli.
>
> I followed your tutorial and got my ETH-WIZ 10/100 Mbps Click running,
> since Robert released the overlay for that yesterday.
>
> The one addition to your tutorial is that it also required upgrading the
> kernel to 4.9 as part of the install, per Robert's instructions for the
> ETH-WIZ.
>
> As you say, it boots, and just works.
>
> Running speedtest-cli ...
> I get 3.3 Mbps down, and 4.6 Mbps up.
>
> Confirmed that the chip had negotiated a 100 Mbps connection, so not the
> connection.
>
> I note that, in reading the source for the '.dtbo', that the SPI clock is
> set to 12 MHZ.
> Recompiled the '.dtbo' with SPI clock at 24 MHz.
>
>
> How fast can you push the spi bus? I've just used the 12 mhz, as it was
> the default for one of the device tree in the docs..
>
> Regards,
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/GGhpOK-i5-4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/CAOCHtYi2bg8xZOt4yBaG9%3D6h5pVKv%2BRpGBPcrKZMa1wru%
> 3DbHSg%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/CANN_KV5AyYsvxP7h%2B%3DjeSd6C646aHZfu6-jDdn5B3EpEGtvyUg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PocketBeagle headers

[Graham Haddock]

And they are a cool Blue, rather than industrial Black.

--- Graham

-- 
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/CANN_KV7qEEgxaU3c%2B-v6x_XgtV7Fj%3Dhcrf7inj%2BBRETZ-aMxPQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Announcing $25 PocketBeagle

[Graham Haddock]

no quotes.

--- Graham

==

On Mon, Oct 2, 2017 at 9:51 PM, Andy Bushnell <ahbushn...@gmail.com> wrote:

> That didn't work.  But I noticed that there is redirection (is that what
> you call it) for the file resolv.conf.  it linkis to
> /run/connman/resolv.conf  there is also a  folder in /etc that is called
> resolv.conf. in the folder there is update.d and update-libc.d.
>
> I looked in the resolv.conf file with my editor and it has the "namespace
> 8.8.8.8" in the file.  I assume it's supposed to have the quotes
>
> Andy
>
>
>
> On Mon, Oct 2, 2017 at 8:20 AM, Alex Bagehot <ceea...@gmail.com> wrote:
>
>>
>>
>> On Fri, Sep 29, 2017 at 1:55 PM, Graham Haddock <gra...@flexradio.com>
>> wrote:
>>
>>> You use the "USB-tether-gadget", which, when your USB cable is connected
>>> to a Windows host computer, allows you to bridge and share the Ethernet
>>> port on the Windows host.
>>>
>>> I have it working on Windows 10.
>>>
>>> See
>>>
>>> https://www.digikey.com/en/maker/blogs/how-to-connect-a-beag
>>> lebone-black-to-the-internet-using-usb/cdf66181b3a5436e9ad730e4ed4cf9ee
>>>
>>>
>>> The only difference I found was that with the new security enforcements
>>> on the Beagle, you need to do something like
>>>
>>>  sudo nano /etc/resolv.conf
>>>
>>> to add "nameserver 8.8.8.8" to the resolv.conf file, instead of the
>>> echo... command in the article.
>>>
>> You may also be able to use sudo tee -a
>>
>> echo "nameserver 8.8.8.8" |sudo tee -a /etc/resolv.conf
>> Thanks,
>> Alex
>>
>>
>>
>>> The edits in the beagle are not persistent, so need to be repeated every
>>> time you reboot.
>>>
>>> --- Graham
>>>
>>> On Thu, Sep 28, 2017 at 11:09 PM, <ahbushn...@gmail.com> wrote:
>>>
>>>>
>>>> I ordered a pocket.  But I have a question with out the internet link
>>>> how do you add software to the pocket after it's up and running?
>>>>
>>>> Thanks  Andy
>>>>
>>>>
>>>> --
>>>> For more options, visit http://beagleboard.org/discuss
>>>> ---
>>>> You received this message because you are subscribed to a topic in the
>>>> Google Groups "BeagleBoard" group.
>>>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>>>> pic/beagleboard/JtOGZb-FH2A/unsubscribe.
>>>> To unsubscribe from this group and all its topics, send an email to
>>>> beagleboard+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>>> gid/beagleboard/eeea6761-7389-4429-b00d-e4265d8b197e%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/beagleboard/eeea6761-7389-4429-b00d-e4265d8b197e%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/ms
>>> gid/beagleboard/CANN_KV4n36OF%2BM5YdfvEsAo%3DXPSdSYu8Fpq5u_d
>>> sFmFSu%2B-YxA%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/beagleboard/CANN_KV4n36OF%2BM5YdfvEsAo%3DXPSdSYu8Fpq5u_dsFmFSu%2B-YxA%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 a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/beagleboard/JtOGZb-FH2A/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/beagleboard/CAHeneC9Lvpwk%2BT0nMwq%3DMj5UvAi2utRuDT_
>> SmA9%2BCmqtuO7zTA%40mail.gmail.com
>> <https://gr

Re: [beagleboard] Re: Announcing $25 PocketBeagle

[Graham Haddock]

You use the "USB-tether-gadget", which, when your USB cable is connected to
a Windows host computer, allows you to bridge and share the Ethernet port
on the Windows host.

I have it working on Windows 10.

See

https://www.digikey.com/en/maker/blogs/how-to-connect-a-beaglebone-black-to-the-internet-using-usb/cdf66181b3a5436e9ad730e4ed4cf9ee


The only difference I found was that with the new security enforcements on
the Beagle, you need to do something like

 sudo nano /etc/resolv.conf

to add "nameserver 8.8.8.8" to the resolv.conf file, instead of the echo...
command in the article.

The edits in the beagle are not persistent, so need to be repeated every
time you reboot.

--- Graham

On Thu, Sep 28, 2017 at 11:09 PM,  wrote:

>
> I ordered a pocket.  But I have a question with out the internet link how
> do you add software to the pocket after it's up and running?
>
> Thanks  Andy
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/JtOGZb-FH2A/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/eeea6761-7389-4429-b00d-e4265d8b197e%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/CANN_KV4n36OF%2BM5YdfvEsAo%3DXPSdSYu8Fpq5u_dsFmFSu%2B-YxA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PocketBeagle U-Boot Overlays [naming???]

[Graham Haddock]

Will the same Ethernet overlay work for both the ETH Click and the ETH-WIZ
Click?

Since the 10/100 Mb Ethernet (ETH WIZ) Click board is $19, and the 10 Mb
only ETH Click board is $24, I bought the 10/100 ETH WIZ click board.

--- Graham

==


On Wed, Sep 27, 2017 at 1:56 PM, Robert Nelson 
wrote:

> On Wed, Sep 27, 2017 at 8:20 AM, Graham  wrote:
> > Your naming proposal seems appropriate.
> >
> >
> > The mikro Click boards seem to be good for experimenting with one new
> part
> > or function.
> > Microchip is supporting them on their new "Curiosity" series dev boards,
> > too.
> > Great for learning to program an I2C, SPI or UART interface.
> >
> > Easy to layout unique little PCBs fitting that footprint.  I have already
> > done that for a unique ADC and a 6 pin console serial port adapter.
> >
> > Where it starts to fall apart is when you want to use more than one or
> two
> > "Click" boards worth of functionality, although mikro does have a
> separate
> > four-up universal click board motherboard.
>
> I've started listing working boards here:
>
> https://github.com/beagleboard/pocketbeagle/wiki/
> mikroBus%E2%84%A2-Click-Boards
>
> I've got a spi and i2c example working..  So it should be easy for
> others to add additional boards. ;)
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/xXIXmpVm9is/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/CAOCHtYjHc-cDSeiV3qyjfVv%3Da_VzNX5JvbycYj-hChXH%2BrGjGA%
> 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/CANN_KV6WHnzme-mfHHKcEuQ2f0qR82nUBxyPA0KS0AeRWSVXdA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBB how to manage the limited eMMC flash size of 4GB

[Graham Haddock]

If you start with a "microSD/standalone" image, then you are ready to boot
and run from the card.

If you start with a "flasher" image, then you will need to edit the
/boot/uEnv.txt file to keep it from flashing your eMMC.

The other thing to know is that you may need to expand the partitions on
the card, so as to be able to access the entire memory space of the card.

If you run   df -h   and can only see about 4 GB of memory space, follow
the instructions at

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

On the next reboot, you should see the entire card as available memory.

--- Graham



On Fri, Jul 7, 2017 at 8:44 AM,  wrote:

> Thanks for the hint.
> *> "set the SD card as boot media"*:
> I did not have to do anything apart from flashing the SD with the relevant
> image, insert in the slot and power on. Then it automatically boots on the
> flash. *Right*? or at least that's what i saw.
>
> For supplement information: The SD card will be mounted as /dev/mmcblk*0*p1
>  and if you boot from eMMC (or mount it) the eMMC will be mounted as
> /dev/mmcblk*1*p1.
> The command df will show which of those is mounted. This may come handy if
> experimenting with different boot sources.
>
>>
>>

-- 
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/CANN_KV5XQnKACjtNBRLjcpHNHxFEfboOR-qcEwbFNqRJVVUOdw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: i2c python

[Graham Haddock]

Sounds like you can move ahead, and learn a little python.
--- Graham

==

On Fri, Jun 16, 2017 at 4:01 PM,  wrote:

> now I can read :)
>
> this script works
>
> import smbus
>
> # General i2c device class so that other devices can be added easily
> class i2c_device:
> def __init__(self, addr, port):
> self.addr = addr
> self.bus = smbus.SMBus(port)
>
> def write_i2c_block_data(self, byte, array):
> self.bus.write_i2c_block_data(self.addr, byte, array)
>
> def read_nbytes_data(self, data, n): # For sequential reads > 1 byte
> return self.bus.read_i2c_block_data(self.addr, data, n)
>
> ph = i2c_device(0x65, 2)
> ph.write_i2c_block_data(0x05,[0x00]) // off LED
> print(ph.read_nbytes_data(0x00, 25)) // read all registers
>
>
>
> On Friday, June 16, 2017 at 1:34:04 PM UTC-4, Sebastián Sáez wrote:
>>
>> This are the value in hexadecimal of the 25 registers in the sensor,
>> check with datasheet and it's ok
>>
>> 1,4,1,65,0,1,0,1,0,0,0,0,0,0,0,0,9,C4,0,0,9,C4,0,0,16
>>
>>
>> I used arduino to read this, I discovered that what I read with python is
>> garbage
>>
>> On Friday, June 16, 2017 at 12:43:14 PM UTC-4, Sebastián Sáez wrote:
>>>
>>> Hi Graham, thanks
>>>
>>> here more info
>>>
>>> HW: Beaglebone seeedstudio green wireless
 OS: Debian GNU/Linux 8.8 (jessie)
 Kernel: Linux beaglebone 4.4.30-ti-r64
 Python: Python 2.7.9
>>>
>>>
>>> I made a custom cape, the sensor it's power with 3.3v and conected to
>>> I2C_2 through an isolator
>>>
>>> SDA -> P9.20
>>> SCL -> P9.19
>>>
>>>
>>> 
>>>
>>> The HW it's OK, I check with an arduino and example code and I can write
>>> registers with my python script on the beaglebone.
>>>
>>> The ph sensor is in 0x65 address and other Atlas sensor in 0x64
>>>
>>> debian@beaglebone:~$ i2cdetect -y -r 2
>>>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>>> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- --
>>> 60: -- -- -- -- 64 65 -- -- -- -- -- -- -- -- -- --
>>> 70: -- -- -- -- -- -- -- --
>>>
>>> Now I can write register with this script (can on/off onboard LED) but
>>> when I try to read all 25 register I get this
>>>
>>>
 1, 1, 0, 0, 0, 0, 0, 0, 9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 0
>>>
>>>
>>> The first 2 bytes are the ID and FW, but I expect the rest to have
>>> values such as the pH (registers 0x16, 0x17, 0x18, 0x19) but I am getting
>>> only 0 (garbage)
>>>
>>> Python script
>>> import smbus
>>> import time
>>>
>>> class i2c_device:
>>> def __init__(self, addr, port):
>>> self.addr = addr
>>> self.bus = smbus.SMBus(port)
>>>
>>> def write(self, byte):
>>> self.bus.write_byte(self.addr, byte)
>>>
>>> def write_i2c_block_data(self, byte, array):
>>> self.bus.write_i2c_block_data(self.addr, byte, array)
>>>
>>> def read(self):
>>> return self.bus.read_byte(self.addr)
>>>
>>> def read_nbytes_data(self, data, n): # For sequential reads > 1 byte
>>> return self.bus.read_i2c_block_data(self.addr, data, n)
>>>
>>> ph = i2c_device(0x65, 2)
>>> ph.write(0x00)
>>> i=0
>>> while (i <= 25):
>>> print(ph.read())
>>> time.sleep(0.5)
>>> i+=1
>>>
>>>
>>>
>>>
>>> On Thursday, June 15, 2017 at 10:38:28 PM UTC-4, Graham wrote:

 OK.
 Let's start with some background information.
 What model of Beaglebone?
 What version of OS, kernel?
 Which version of Python?
 How is the pH sensor hooked to the Beaglebone?
 What Voltage are you using to power the pH sensor?

 Now some basics to see if the I2C bus is running

 sudo apt-get install i2c-tools

 now run
 i2cdetect -y -r 1
 what do you get?

 now run
 i2cdetect -y -r 2
 what do you get?

 When you say that you get "garbage" what do you mean?
 What do you actually get? errors? tracebacks? obviously wrong data, but
 no reported errors?

 --- Graham

 ==

 On Thursday, June 15, 2017 at 5:38:58 PM UTC-5, Sebastián Sáez wrote:
>
>
> Hi,
>
> I'm writing a python script to communicate via i2c with the ph oem
> sensor from Atlas Scientific.
>
> https://www.atlas-scientific.com/product_pages/oem/oem_ph.html
> https://www.atlas-scientific.com/_files/_datasheets/_oem/pH_
> oem_datasheet.pdf
>
> I already tried with the i2c module of mraa and smbus without luck.
> Now I am trying to translate this arduino example from Atlas to python
> but I read garbage
>
>
> Any suggestions?, attached the full example arduino code
>
>
> *Atlas arduino code*
> byte i2c_device_address=0x65;
> byte 

Re: [beagleboard] Re: i2c python

[Graham Haddock]

Sebastián:

Is your Arduino 3.3V or 5.0 V I/O?

What clock speed are you running the I2C bus in the Beaglebone?
With the time distortion in the level translator, I would not go above 100
kHz until proven good at higher speeds.

I note that your schematic shows VDDP connected to 5V.
This should be connected to the same reference Voltage as the I2C bus is
using, which is 3.3V in the case of the Beaglebone.

I have not digested the ADM3260 data sheet sufficiently to understand if it
is OK to run both buses at 3.3V, and the power supply input at 5V.
Is this what you are actually doing when on the Beaglebone?

--- Graham

==

On Fri, Jun 16, 2017 at 12:34 PM, Sebastián Sáez  wrote:

> This are the value in hexadecimal of the 25 registers in the sensor, check
> with datasheet and it's ok
>
> 1,4,1,65,0,1,0,1,0,0,0,0,0,0,0,0,9,C4,0,0,9,C4,0,0,16
>
>
> I used arduino to read this, I discovered that what I read with python is
> garbage
>
> On Friday, June 16, 2017 at 12:43:14 PM UTC-4, Sebastián Sáez wrote:
>>
>> Hi Graham, thanks
>>
>> here more info
>>
>> HW: Beaglebone seeedstudio green wireless
>>> OS: Debian GNU/Linux 8.8 (jessie)
>>> Kernel: Linux beaglebone 4.4.30-ti-r64
>>> Python: Python 2.7.9
>>
>>
>> I made a custom cape, the sensor it's power with 3.3v and conected to
>> I2C_2 through an isolator
>>
>> SDA -> P9.20
>> SCL -> P9.19
>>
>>
>> 
>>
>> The HW it's OK, I check with an arduino and example code and I can write
>> registers with my python script on the beaglebone.
>>
>> The ph sensor is in 0x65 address and other Atlas sensor in 0x64
>>
>> debian@beaglebone:~$ i2cdetect -y -r 2
>>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- --
>> 60: -- -- -- -- 64 65 -- -- -- -- -- -- -- -- -- --
>> 70: -- -- -- -- -- -- -- --
>>
>> Now I can write register with this script (can on/off onboard LED) but
>> when I try to read all 25 register I get this
>>
>>
>>> 1, 1, 0, 0, 0, 0, 0, 0, 9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
>>
>>
>> The first 2 bytes are the ID and FW, but I expect the rest to have values
>> such as the pH (registers 0x16, 0x17, 0x18, 0x19) but I am getting only 0
>> (garbage)
>>
>> Python script
>> import smbus
>> import time
>>
>> class i2c_device:
>> def __init__(self, addr, port):
>> self.addr = addr
>> self.bus = smbus.SMBus(port)
>>
>> def write(self, byte):
>> self.bus.write_byte(self.addr, byte)
>>
>> def write_i2c_block_data(self, byte, array):
>> self.bus.write_i2c_block_data(self.addr, byte, array)
>>
>> def read(self):
>> return self.bus.read_byte(self.addr)
>>
>> def read_nbytes_data(self, data, n): # For sequential reads > 1 byte
>> return self.bus.read_i2c_block_data(self.addr, data, n)
>>
>> ph = i2c_device(0x65, 2)
>> ph.write(0x00)
>> i=0
>> while (i <= 25):
>> print(ph.read())
>> time.sleep(0.5)
>> i+=1
>>
>>
>>
>>
>> On Thursday, June 15, 2017 at 10:38:28 PM UTC-4, Graham wrote:
>>>
>>> OK.
>>> Let's start with some background information.
>>> What model of Beaglebone?
>>> What version of OS, kernel?
>>> Which version of Python?
>>> How is the pH sensor hooked to the Beaglebone?
>>> What Voltage are you using to power the pH sensor?
>>>
>>> Now some basics to see if the I2C bus is running
>>>
>>> sudo apt-get install i2c-tools
>>>
>>> now run
>>> i2cdetect -y -r 1
>>> what do you get?
>>>
>>> now run
>>> i2cdetect -y -r 2
>>> what do you get?
>>>
>>> When you say that you get "garbage" what do you mean?
>>> What do you actually get? errors? tracebacks? obviously wrong data, but
>>> no reported errors?
>>>
>>> --- Graham
>>>
>>> ==
>>>
>>> On Thursday, June 15, 2017 at 5:38:58 PM UTC-5, Sebastián Sáez wrote:


 Hi,

 I'm writing a python script to communicate via i2c with the ph oem
 sensor from Atlas Scientific.

 https://www.atlas-scientific.com/product_pages/oem/oem_ph.html
 https://www.atlas-scientific.com/_files/_datasheets/_oem/pH_
 oem_datasheet.pdf

 I already tried with the i2c module of mraa and smbus without luck.
 Now I am trying to translate this arduino example from Atlas to python
 but I read garbage


 Any suggestions?, attached the full example arduino code


 *Atlas arduino code*
 byte i2c_device_address=0x65;
 byte starting_register=0x00
 byte device_type;
 byte version_number;
 Wire.beginTransmission(i2c_device_address);
 Wire.write(staring_register);
 Wire.endTransmission();
 Wire.requestFrom(i2c_device_address,(byte)2);
 device_type = Wire.read();
 

Re: [beagleboard] Re: I²C reads on broken out bus #1 always return 0

[Graham Haddock]

Torsten:
Great job.
--- Graham

==

On Mon, May 29, 2017 at 9:32 AM, 'Torsten K.' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> FYI: It's working now. The PIC code that came with the motor controller
> was not I²C re-start aware.
>
> I re-implemented the ISR to accept both stop/start and re-start sequences
> before reading the slave's output. That did the trick.
>
> Best,
> Torsten
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/-cVwfP40L0M/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/24021d75-eb84-40c6-98e1-05dd27972d70%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/CANN_KV6b49tf4q5aki2jJjrTe_WUfm6akar%3Dzi4rMXeKA4hQXQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: UART5 not working on Beaglebone Black

[Graham Haddock]

Let's start with a few clues.

What board and revision level are you using?  (example: BeagleBone Black,
Rev C.)

What OS, version, release date and kernel are you using?

What other changes, if any, have you made to the system software?

What hardware / I-O do you have plugged into the accessory connectors?

Do you have a serial debug cable plugged in?  Is it giving you any boot
errors or conflicts?

==

Why are you planning to mess with I2C-1 ?  On Debian jessie, that is an
internal control bus you should not touch, unless you really know what you
are doing.


I suspect that:
BB-BONELT-HDMI,BB-BONELT-HDMIN
only disables the HDMI, not the LCD drivers, and you should only disable
the HDMI once, not twice.

I am guessing that you still need to disable the LCD drivers.


--- Graham


---



On Wed, May 24, 2017 at 10:04 AM,  wrote:

> I tried uncommenting the lines in /boot/uEnv.txt about disabling HDMI, but
> it did not help. I also tried typing in
> *optargs=capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART3,BB-UART5* at
> the end of that file.
> Then I was trying to type optargs=quiet 
> capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
> in order to explicitly disable the HDMI in the /boot/uEnv.txt, but it
> didn't help either.
>
> It appears that HDMI is not enabled there whatsoever since in the slots
> file I don't have anything dedicated to it:
> *root@beaglebone:~# cat /sys/devices/platform/bone_capemgr/slots*
> * 0: PF  -1*
> * 1: PF  -1*
> * 2: PF  -1*
> * 3: PF  -1*
> * 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-I2C1*
> * 6: P-O-L-   1 Override Board Name,00A0,Override Manuf,BB-UART1*
> * 7: P-O-L-   2 Override Board Name,00A0,Override Manuf,BB-UART2*
> * 8: P-O-L-   3 Override Board Name,00A0,Override Manuf,BB-UART4*
> * 9: P-O-L-   4 Override Board Name,00A0,Override Manuf,BB-UART5*
> *10: P-O-L-   5 Override Board Name,00A0,Override Manuf,BB-UART3*
>
> Are there any other possible sources of UART5 not working, aside from it
> interfering with HDMI? I tried several different boards and SD cards, but
> the port did not work on any of them.
>
>
>
> On Monday, May 22, 2017 at 9:47:08 PM UTC-4, Graham wrote:
>>
>> The IO pins used by UART5 are, by default, assigned to driving an LCD
>> screen.
>> You will need to reconfigure the IO, so that LCD/video is disabled, and
>> the pins are re-assigned as UART I/O pins.
>> You will need to modify the boot file and device tree.
>> Start searching about how to edit the /boot/uEnv.text file, and your
>> different options for re-configuring the necessary pins.
>>
>> --- Graham
>>
>> ==
>>
>> On Monday, May 22, 2017 at 8:04:06 PM UTC-5, sspo...@bu.edu wrote:
>>>
>>> I am using a Beaglebone Black on a student project. In order to activate
>>> the UART5 port, I type in “echo BB-UART5 > 
>>> /sys/devices/platform/bone_capemgr/slots”
>>> every time I power the board on. However, even though the port does seem to
>>> be activated, uart5 never works for any of the BBB’s I try (other UART
>>> ports on them work as well as usual) . What can cause such problems
>>> specifically with UART5? How can I fix it?
>>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/3Rby6pdTUCg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/54415aca-e655-4107-9c36-da720d79a5d5%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/CANN_KV5S3LVUEfQCpjUy-kJU94axR9uvX6SCWO_cYWNuWg94dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Development environment for BBB and Win 7 64 bit for C-programming

[Graham Haddock]

William:
Great.  Derek did update his video, although he still refers to the
original one on his website.
--- Graham

==

On Tue, May 23, 2017 at 5:16 PM, William Hermans  wrote:

> https://www.youtube.com/watch?v=T9yFyWsyyGk
>
> . . .
>
> On Tue, May 23, 2017 at 3:11 PM, Graham  wrote:
>
>> I don't know of a single resource that covers the whole chain.
>> The closest is Derek Molloy's
>> http://derekmolloy.ie/beaglebone/setting-up-eclipse-on-the-
>> beaglebone-for-c-development/
>> but it is four years old, and out of date for many of the details, but
>> the general approach is still the same.
>>
>>
>> Oracle VM VirtualBox on Windows is a standard installation.
>> Simple enough that you don't need the instructions for much.
>> You do need to allocate more than the minimum (default) memory and
>> minimum number of virtualized cores to the VM.
>>
>> Ubuntu on VirtualBox is a standard installation.
>> Get the ISO from the Ubuntu website, and put it on your Windows machine
>> where it is easy to get to.
>> Open it from inside the VM.
>>
>> Eclipse on Ubuntu is a standard installation. Instructions on the Eclipse
>> website.
>> Use the newest one preconfigured for "C/C++" from the Eclipse site.
>> The one in the Ubuntu apt repository is 4 years out of date. Don't use
>> that one.
>> RSE is an optional module for Eclipse, loaded through the application.
>> Installation instructions are inside Eclipse 'Help.'
>>
>> I assume that you will connecting between the BBB and the Windows/VM via
>> Ethernet local network.
>> I doubt that this would work through the USB widget/gadget.
>>
>> You will probably have to change the security settings on the BBB to
>> allow SSH into the Root account, for easiest operation of RSE.
>> Otherwise, you will keep running into the Linux security on the BBB.
>>
>> Google is your friend.
>>
>> Ask questions if you have problems.
>>
>> --- Graham
>>
>> ==
>>
>> On Tuesday, May 23, 2017 at 6:50:04 AM UTC-5, Stefan wrote:
>>>
>>> Hallo Graham,
>>>
>>> thank you very much for your detailed advice!
>>>
>>> We have already thought about using a VM, but now that you say, it works
>>> well, we are going for it. Actually we have very strong notebooks with i7,
>>> 16gb and pci-e SSD. Using a VM should be no problem.
>>>
>>> Is there a detailed tutorial for the ubuntu + eclipse + RSE installation
>>> for linux avaiable?
>>>
>>> Best regards
>>> Stefan
>>>
>>>
>>> On Tuesday, May 23, 2017 at 4:25:03 AM UTC+2, Graham wrote:

 If the target is a Linux machine, you will have fewer communications
 problems, if you cross compile from a Linux, rather than a Windows
 environment.

 If you must run on a Windows-64 machine, then I recommend you install
 Oracle VM Virtualbox on Windows 64.

 Install Ubuntu on the virtual machine.

 Install the Linux version of Eclipse for C language, with RSE (Remote
 System Explorer) on Ubuntu.
 RSE allows you to have full access to the target's file system from the
 Eclipse IDE.

 I find this works well for writing and running C programs on the BBB,
 provided that you have an adequate Windows machine, such as an i5,
 equivalent, or better processor.

 If you have a puny processor in your Windows machine you are better off
 running Ubuntu native on the processor.

 I ran into all kinds of Windows-Linux communications problems running
 Eclipse native on Windows.

 --- Graham

 ==



 On Monday, May 22, 2017 at 8:03:58 PM UTC-5, Stefan wrote:
>
> Hallo guys,
>
> I am trying to get a toolchain running for developing the Beaglebone
> Black in Windows 7 64bits with c-code. Me and my college are working on
> this problem for some days now, but we can't find a proper solution here.
> We are both no experts on MCUs but have some basic skills on c-coding. Our
> company is running Win 7, so we would like to stick with it.
>
> So far we tried different approaches:
>
> - Eclipse + ARM Crosscompiler and remote target
> - Code Composer + ARM Crosscompiler and jtec
>
> We tried different tutorials, but always got stuck on some point. Most
> of the times the guides were outdated, files were missing, versions were
> not compatible or we got errors.
>
> Maybe you guys have experience and can recommend a simple or standard
> solution (Toolchain and guide) to c-code the BBB from Win 7.
>
> Thank you very much!
>
> Best regards
> Stefan
>
>
> --
>> 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
>> 

Re: [beagleboard] Re: I²C reads on broken out bus #1 always return 0

[Graham Haddock]

When they say drop the clock speed on the bus, I am sure they mean to drop
it down to 50kbps or 10 kbps, and see if it starts working.
As a diagnostic, that would be strong indication of a timing problem in the
PIC software.

If they are using the PIC hardware peripheral, then it is totally I2C
compliant/conforming, although you could still screw up the response time
servicing it slowly internally.

If they are "bit-banging" the I2C interface, then anything can happen,
depending on the quality of the programmer.

--- Graham

On Mon, May 15, 2017 at 11:33 AM, Graham Haddock <gra...@flexradio.com>
wrote:

> What part number PIC?
> --- Graham
>
> ==
>
> On Mon, May 15, 2017 at 9:36 AM, 'Torsten K.' via BeagleBoard <
> beagleboard@googlegroups.com> wrote:
>
>> Hi Graham,
>>
>> just for reference: The guys who built the motor controller confirmed
>> that they are having trouble with newer kernels on the Raspberry PI, too.
>>
>> https://www.piborg.org/node/2428
>>
>> They say it's probably a timing issue. And with all the information I
>> collected so far I must assume they are probably true. ;-)
>>
>> I hope it's not the PIC itself that can't cope, but rather something that
>> could be solved in software...
>>
>> Best,
>> Torsten
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/beagleboard/-cVwfP40L0M/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/beagleboard/6eddd754-92b7-4ec8-bd01-b0aa3b500f9f%40googlegroups.com
>> <https://groups.google.com/d/msgid/beagleboard/6eddd754-92b7-4ec8-bd01-b0aa3b500f9f%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/CANN_KV6WjSW0C7y6AAyYbmpEaynz5PptSq9Nn49nT%3DmGU3RbOQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: I²C reads on broken out bus #1 always return 0

[Graham Haddock]

What part number PIC?
--- Graham

==

On Mon, May 15, 2017 at 9:36 AM, 'Torsten K.' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Hi Graham,
>
> just for reference: The guys who built the motor controller confirmed that
> they are having trouble with newer kernels on the Raspberry PI, too.
>
> https://www.piborg.org/node/2428
>
> They say it's probably a timing issue. And with all the information I
> collected so far I must assume they are probably true. ;-)
>
> I hope it's not the PIC itself that can't cope, but rather something that
> could be solved in software...
>
> Best,
> Torsten
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/-cVwfP40L0M/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/6eddd754-92b7-4ec8-bd01-b0aa3b500f9f%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/CANN_KV6D2vU68zxJ-19p-G9Ux%2B62jUE%2BfMwmbPEm0L-e5XMNsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: I²C reads on broken out bus #1 always return 0

[Graham Haddock]

I take back what I said about a non standard read sequence. I re-read the
data sheet, and they describe a standard concatenated write/read sequence
for a single byte read.  But I do note that they do not describe a simple
read only sequence, where the part would start reading from the last
register position.

A lot of the tools do not actually do the concatenated write/read, but
instead do a separate  write-stop, read-stop. I have not seen a I2C part
that would not accept this.

Do you have another "trusted" I2C device you could parallel across the bus
as a test device?
I use an MCP9808 temperature sensor on most of my boards when bringing up a
new design.

Or as suggested by David, put a bus analyzer on the bus to see if the chip
is not sending good data, or the Beaglebone is loosing the good data when
the chip sends it.

--- Graham

==

On Fri, May 12, 2017 at 10:56 AM, David Lechner 
wrote:

> On 05/12/2017 10:48 AM, 'Torsten K.' via BeagleBoard wrote:
>
>>
>> So, I'm still convinced that it has to do with the hardware and/or the
>> setup of the I²C bus of the beaglebone...
>>
>> Where else could I look?
>>
>
> Have you stuck an oscilloscope or logic analyzer on it to see what is
> actually on the bus?
>
> What are the pinconf settings for the I2C pins?
>
> --
> For more options, visit http://beagleboard.org/discuss
> --- You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/to
> pic/beagleboard/-cVwfP40L0M/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/beagleboard/1b6acd0b-c3c9-b8bd-8d58-1c3f1d0d670c%40lechnology.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/CANN_KV6OAe4SG%3DOy3LNk-0ooV%3Dq16VFyEJXEa00hwwrwsWRGTg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: I²C reads on broken out bus #1 always return 0

[Graham Haddock]

It looks like the MPU9250 has a non standard (to my way of thinking) I2C
read sequence that requires you to resend the register address as part of a
consolidated write/read sequence.  The default tool i2cget does not deal
with this, and only deals with simple (standard to my way of thinking) read
sequences.

Since you can write to the device, and a write requires an acknowledgement
from the device, there is nothing wrong down at the hardware and low-level
driver level.

If you get a driver specific to the MPU9250 running, that understands the
required byte control sequence, I would expect it to work.

If you are using Python, I would suggest using Python 2.7 rather than
Python 3.  At least to get started, until you are in control.

The last time I did Python control of I2C, you needed to load python-smbus,
and it had not yet been updated for Python 3 compatibility.

It may have been updated and re-released in the last six months.

I did find instructions on the web about how to manually recompile
python-smbus for Python 3, so it is possible.

--- Graham

==

On Fri, May 12, 2017 at 9:41 AM, 'Torsten K.' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Update: I lowered the clock frequency of i2c1 to 100kHz via the dtb. That
> also doesn't change the behaviour.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/-cVwfP40L0M/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/5b4d695c-e108-4f7e-a154-8c7e81bf8b41%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/CANN_KV7PVfz-2OakcWRqd%2BJ8vyNQus%2BS99YXj%3De7DPqG7%2BBoAA%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.

[Graham Haddock]

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 transfer rate, while running it under a non
realtime OS.
I guess I am not surprised that you are having problems.

The USB widget is nice for doing simple things, with fast, simple set up
for beginners.
I suspect you are trying to run it in an application where it has not been
well tested.

For a stable system, I would recommend considering doing the data transfer
over a real hardware serial port, or if that is not fast enough, do the
transfer using Ethernet. (And I don't mean Ethernet over USB using the
Widget.)

I find the true hardware serial ports, and the genuine FTDI serial to USB
converters to be stable well above 100,000 bits per second. Some report
success in the megabits per second range, I have just not had to personally
go there, yet.

You never have been specific about how many bits per second of data that
you have to move.
I think that is an important place to start.

--- Graham

==

On Thu, May 4, 2017 at 6:53 PM, Dennis Lee Bieber 
wrote:

> On Thu, 4 May 2017 15:39:43 -0700 (PDT), David Howlett
>  declaimed the
> following:
>
>
> >I plugged the micro USB port on the BBB into my USB hub. The USB hub is
> >currently attached to a windows PC but the same fault happens when the USB
> >cable is plugged into my mac book running OSX.
> >
>
> Which, since there is no FTDI chip on the BBB, is effectively an
> emulated serial port... The USB-serial driver responds to I/O operations as
> if it were a serial port, but things like baud rate are mostly meaningless
> -- the driver moves bytes from the client buffer to the USB buffer, and USB
> transfers at (if USB2.0 full speed -- 480kbps; ignoring the breaks caused
> by USB packet size AND that the host computer has to poll the USB device to
> ask for each packet of data; effective throughput being closer to 250kbps).
>
> And, the Windows (or Mac) side is also an emulated serial, but as
> the
> host side, the USB driver controls the polling of the other end asking for
> data or to send packets.
>
>
> >I have also come to suspect that there are no hardware UARTS involved. I
> >believe that the serial line is being emulated.
> >
>
> Unless you use wires on the UART pins of the BBB, likely true.
> Those
> may be hardware UARTs, but as soon as something is connected that converts
> to USB, the actual data transfer is USB and the other end emulated.
>
> >
> >On the PC side I can set the baudrate to any number. The data rate and the
> >error rate appear to be unaffected. For example:
> >
> >x = serial.Serial('COM10', baudrate=10)
> >x = serial.Serial('COM10', baudrate=9600)
> >x = serial.Serial('COM10', baudrate=100_000_000_000)
> >
>
> As I suspect -- the baud rate is irrelevant when you get into the
> USB
> protocol. At most, it may control a "filter" as to how rapidly the drivers
> relay stuff to the USB protocol. That is -- at slow rates there may only be
> a few bytes of data per USB packet, whereas at really high rates each USB
> packet will contain more data (and hence be more efficient when taking the
> polling overhead into account).
>
> --
> Wulfraed Dennis Lee Bieber AF6VN
> wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/to
> pic/beagleboard/1n0IkcmhEq8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/beagleboard/n0fngc1j3g8kfrh49uqngndtsj8b0ohjqi%404ax.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/CANN_KV4Z%3DnnsDDJK-br7yxVLc3XRA10z%2BM1Ys4WU8doRyr8UhQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PRU and CPU driven by different oscillators?

[Graham Haddock]

Justin:

>From your questions, you seemed to have an over-simplified view as to how
the clocks are generated in the Sitara.

It is not your grandfather's PIC.

It is a very modern, sophisticated, clock system, with many of the clock
subsystems being variable rate.

A "Clock Tree" is the generic term for the way all of the internal clocks
are generated. If you draw a block diagram, it starts to look like a tree
that branches out from the trunk and lots of the branches have more
branches.

Just because they are derived from a single (24 MHz) clock source, does not
mean that they are synchronous, or even have a constant relationship.  Lots
of them are variable rate, such as the CPU, and almost all of the
communications peripherals.  And then everything is complicated by low
power modes and sleep modes.

The PRU main clock does appear to be a constant 200 MHz.

If you want to dig into the details, they are covered in the "AM335x
Technical Reference Manual".

What I call the clock tree is page 1136, Figure 8-10.  Detail on the
branches follows on the next ten pages.

--- Graham

==




On Sun, Apr 30, 2017 at 8:42 AM, 'Roberts Maria' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

>
> 
> On Sun, 4/30/17,   wrote:
>
>  Subject: Re: [beagleboard] Re: PRU and CPU driven by different
> oscillators?
>  To: "BeagleBoard" 
>  Date: Sunday, April 30, 2017, 2:31 PM
>
>  You may
>  find this tool from TI
>  useful: http://processors.wiki.ti.com/index.php/AM335x_Clock_Tree_Tool
>
>  On Saturday, April 29, 2017 at
>  10:14:31 PM UTC+3, Justin Pearson wrote:Thanks Graham. What
>  do you mean by "check and verify the clock tree
>  behavior"? I searched the TRM for "clock
>  tree" but I'm still not sure how to figure out
>  which timers make their way through various PLLs to the PRU
>  and main CPU.
>
>
>  On Wed, Apr 26, 2017 at
>  10:00 AM, Graham  wrote:
>  Well, best way is to
>  read the schematic. (BBB Rev C schematic, dated March 21,
>  2014)24 MHz Sitara clock crystal is on upper left of
>  page 3, hooked to main oscillator I/O.There is
>  also a 32 kHz crystal shown there for the Real Time
>  Clock.
>  The 25 MHz
>  crystal is on page 9, hooked to the LAN8710, which is the
>  Ethernet PHI.
>  I am not
>  a PRU expert, but I don't think there is, or should be,
>  a fixed relationship betweenthe PRU clock and the
>  CPU clock.  The CPU in a Sitara is a variable speed CPU,
>  and can run anywhere from a few hundred MHz to a
>  GHz, depending on loading,and it is under kernel
>  control.
>  I would not
>  think you would want the 200 MHz clock for the PRU to be
>  variablelike that, since it would totally destroy
>  the real time advantage of the PRU.
>  So, I suspect that the clock for the
>  PRU is a fixed clock coming from a differentplace
>  in the clock tree than the variable speed CPU.
>  You should really check and verify
>  the clock tree behavior.
>  --- Graham
>  ==
>  On Wednesday, April 26, 2017 at 8:02:38 AM
>  UTC-5, Justin Pearson wrote:Thanks Graham.
>  Follow-up questions:
>  1.
>  Where exactly did you find this information? I looked
>  through the TRM and SRM but couldn't find anything
>  definitive.
>  2. Is the
>  200-MHz PRU driven from the same 24 MHz oscillator that
>  drives the CPU? If so, is it correct that the PRU cycle
>  counter increments precisely once for every 5 CPU
>  cycles?
>  Thanks for
>  your help.-Justin
>
>  On Tuesday, April 25, 2017 at 7:35:19 PM UTC-7,
>  Graham wrote:The CPU in a BBB
>  runs from a 24 MHz Oscillator.There is a 25 MHz
>  oscillator on the board, but that is for the
>  Ethernet.--- Graham
>  ==
>
>  On Tuesday, April 25, 2017 at 7:09:50 PM UTC-5,
>  Justin Pearson wrote:How can I find out
>  whether the PRU and CPU are driven by the same oscillator?
>  Specifically, a colleague told me that the IEP timer (which
>  I'm reading with the PRU) is driven by a 24 MHz
>  oscillator that's PLL'd so the timer increments at
>  200 MHz, whereas the CPU is driven by a 25 MHz oscillator
>  PLL'd so that the CPU runs at 1 GHz.
>  It seems to me that if they're
>  driven by different oscillators, then they could drift apart
>  over time.
>
>  Page 1177 of the TRM (spruh73n.pdf)
>  mentions a 32-kHz crystal oscillator, but I don't see
>  how that's related.
>  Also, are these oscillators within
>  the Sitara SoC, or somewhere else on the BBB? The SRM just
>  references 24.576 MHz oscillator (pg 70 of e14 BBB_SRM_rev
>  0.9.pdf), and I'm not sure how that's related to the
>  24/25 MHz oscillators my colleague
>  mentioned.
>  Thanks for your help.
>
>
>
>
>  --
>
>  For more options, visit http://beagleboard.org/discuss
>
>  ---
>
>  You received this message because you are subscribed to a
>  topic in the Google Groups "BeagleBoard" group.
>
>  To unsubscribe from this topic, visit https://groups.google.com/d/
>  topic/beagleboard/XFv4Ha4RbD4/ 

Re: [beagleboard] Re: Reboot instead of shutdown

[Graham Haddock]

What OS/kernel is ithinu running?

"shutdown -P now" works on all my BBB/BBG boards.

But, I run from external +5V, without anything on the battery connections.

--- Graham

==


> I usually tell everyone to use:
>
> sudo systemctl poweroff
>
> as systemd knows how to tell the external tps65217 to cut power.
>
> looking at the syslog, i don't remember any issues with 4.4.39-ti-r75,
> and looking at the git log i don't see any poweroff regressions
> mentioned..
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/to
> pic/beagleboard/9VdtZKf3Dz0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/beagleboard/CAOCHtYgHtwySLzoGJOdRLwGKm34kPxxwz6GBj5BFwWY
> UUtbR9g%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/CANN_KV7mbi4A6uQzrh18hBiPabbfJ21bdqn5wGtSAMPgia5m-A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB without Cape Manager

[Graham Haddock]

Robert:
Looks like exactly what I want. I'll implement that.

William:
Thanks for your comments.

--- Graham

==

On Mon, Apr 17, 2017 at 5:03 PM, Robert Nelson 
wrote:

> On Mon, Apr 17, 2017 at 1:42 PM, 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 kernel for the 'Cape Manager', but otherwise leave I2C-2
> > operational.
> >
> > So, first I think I need to modify and re-compile the default ".dts" file
> > that is used by that release, to remove the binding for those four I2C
> > addresses.
> >
> > It is just not obvious to me, which ".dts" that it is.
> >
> >
> > I will then also need to inhibit what ever starts the 'Cape Manager.'
> > Could you point me at that process.
>
> Hi Graham,
>
> This setup has been asked for before, so it's available in the repo:
>
> Grab the 4.4-ti branch from:
>
> https://github.com/RobertCNelson/dtb-rebuilder
>
> Change:
>
> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-
> boneblack.dts#L11
>
> to:
>
> "am335x-bone-common-no-capemgr.dtsi"
>
> make
> sudo make install
> sudo reboot
>
> Regards,
>
>
> --
> Robert Nelson
> https://rcn-ee.com/
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CANN_KV47aPyY1SaWCwL0avzkiYzpeCe2VGSTAgRtSrTa-TtxYg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Difference between the console image and the IoT image

[Graham Haddock]

Luther:

I have no explanation for that.

Only the most universal, uSD resident version is posted for the 'release'
versions.

I personally find the console version is the most useful for building much
smaller custom applications.

--- Graham

==


On Sun, Mar 19, 2017 at 7:38 AM, 'Luther Goh Lu Feng' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Thanks for the clarity. I did not catch that point earlier about the
> latest console "release" version. I may have missed it but there doesn't
> seemed to be an easy way to find the latest console "release" version based
> on 11-06 if I hadnt posted here. I did not seem to find the direct link at
> https://beagleboard.org/latest-images. Is there any reason for that?
>
> --Luther
>
> On Sunday, March 19, 2017 at 11:29:55 AM UTC+8, Graham wrote:
>>
>> If you want the latest "release" version, use the 11-06 version, as
>> referenced on
>> https://beagleboard.org/latest-images
>>
>> I told you where the "console version" corresponding to that "release"
>> version was.
>>
>> ==
>>
>> If you are comfortable using a "testing" version, then I would only use
>> the ones that
>> were listed on
>> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian
>>
>> There are other intermediate builds that may or may not have completed
>> testing.
>>
>> --- Graham
>>
>> ==
>>
>> On Sat, Mar 18, 2017 at 10:09 PM, 'Luther Goh Lu Feng' via BeagleBoard <
>> beagl...@googlegroups.com> wrote:
>>
>>> Thanks for sharing. I just discovered that the latest console image on
>>> that domain is https://debian.beagleboard.org
>>> /images/rcn-ee.net/rootfs/bb.org/testing/2017-02-26/console/. I assume
>>> I should try that instead of https://debian.beagleboard.org
>>> /images/rcn-ee.net/rootfs/bb.org/testing/2016-11-06/console/
>>>
>>> When does debian.beagleboard.org get updated to list
>>> https://rcn-ee.net/rootfs/bb.org/testing/2017-03-12/console/? Is there
>>> a criteria for that too?
>>>
>>> --Luther
>>>
>>> On Saturday, March 18, 2017 at 10:49:46 PM UTC+8, Graham wrote:

 Luther:

 Should you want the reduced "Console" version of the latest "release"
 version of Debian 8.6

 Robert has convenient saved them at

 https://debian.beagleboard.org/images/rcn-ee.net/rootfs/bb.
 org/testing/2016-11-06/console/

 The one with "blank" in the name is the flasher version.
 BBB-blank-debian-8.6-console-armhf-2016-11-06-2gb.img.xz

 The other one is the uSD resident version.
 bone-debian-8.6-console-armhf-2016-11-06-2gb.img.xz

 By editing the  boot/uEnv.txt file you can make either do the job of
 the other.

 --- Graham

 ==




 On Saturday, March 18, 2017 at 12:18:35 AM UTC-5, Luther Goh Lu Feng
 wrote:
>
> On that note, I am also wondering if the non listing of the console
> image on the website makes the image less official and less supported than
> the other "stable" images listed at https://beagleboard.org/latest
> -images
>
> --Luther
>
>
>>>
>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "BeagleBoard" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>>> pic/beagleboard/cP6KnF0eI6E/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> beagleboard...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/beagleboard/be747704-becb-4346-a1ce-0949a6fe8a75%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 a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/cP6KnF0eI6E/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/ed199d86-d6ac-4e67-a4cb-dbe12c484a31%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 

Re: [beagleboard] Re: Difference between the console image and the IoT image

[Graham Haddock]

If you want the latest "release" version, use the 11-06 version, as
referenced on
https://beagleboard.org/latest-images

I told you where the "console version" corresponding to that "release"
version was.

==

If you are comfortable using a "testing" version, then I would only use the
ones that
were listed on
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian

There are other intermediate builds that may or may not have completed
testing.

--- Graham

==

On Sat, Mar 18, 2017 at 10:09 PM, 'Luther Goh Lu Feng' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Thanks for sharing. I just discovered that the latest console image on
> that domain is https://debian.beagleboard.org/images/rcn-ee.net/rootfs/
> bb.org/testing/2017-02-26/console/. I assume I should try that instead of
> https://debian.beagleboard.org/images/rcn-ee.net/rootfs/bb.
> org/testing/2016-11-06/console/
>
> When does debian.beagleboard.org get updated to list
> https://rcn-ee.net/rootfs/bb.org/testing/2017-03-12/console/? Is there a
> criteria for that too?
>
> --Luther
>
> On Saturday, March 18, 2017 at 10:49:46 PM UTC+8, Graham wrote:
>>
>> Luther:
>>
>> Should you want the reduced "Console" version of the latest "release"
>> version of Debian 8.6
>>
>> Robert has convenient saved them at
>>
>> https://debian.beagleboard.org/images/rcn-ee.net/rootfs/bb.
>> org/testing/2016-11-06/console/
>>
>> The one with "blank" in the name is the flasher version.
>> BBB-blank-debian-8.6-console-armhf-2016-11-06-2gb.img.xz
>>
>> The other one is the uSD resident version.
>> bone-debian-8.6-console-armhf-2016-11-06-2gb.img.xz
>>
>> By editing the  boot/uEnv.txt file you can make either do the job of the
>> other.
>>
>> --- Graham
>>
>> ==
>>
>>
>>
>>
>> On Saturday, March 18, 2017 at 12:18:35 AM UTC-5, Luther Goh Lu Feng
>> wrote:
>>>
>>> On that note, I am also wondering if the non listing of the console
>>> image on the website makes the image less official and less supported than
>>> the other "stable" images listed at https://beagleboard.org/latest
>>> -images
>>>
>>> --Luther
>>>
>>>
>
 --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/cP6KnF0eI6E/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/be747704-becb-4346-a1ce-0949a6fe8a75%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/CANN_KV7%3DwmP%3DPGBPayDieR2scKKz3%3DOMRmwRMesf8wTk8C9yCQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Detecting (probing) MPU-9250 connected to beaglebone board black

[Graham Haddock]

I am glad it is running now.
It is not a chip I have used, so you will have to sort it out, now that you
are communicating with it.

If you do need to remote it in the future, you should use shielded cable
with a good ground, increase the size of the bypass / filter cap at the IC,
from the 0.1 uF to something much bigger, and also reduce the value of the
pull-up resistors at the IC from the current 10K to something down in the
range of 1K to 2K.  But still keep that cable length as short as possible.

Good luck,
--- Graham

==

On Mon, Mar 13, 2017 at 7:56 AM, christ christ 
wrote:

> Thanks Graham, got it working. I think it was the cable length that was
> causing problem.  At the moment I'm just trying to figure out why the
> magnetometer data are not varying while i can see the changes for the
> accelerometer and gyroscope.
>
> On Sun, Mar 12, 2017 at 2:31 AM, Graham  wrote:
>
>> That all looks fine.
>>
>> Any I2C chip, that is properly connected to P9-19 and 20 should show up
>> on bus 2.
>>
>> What are the DC Voltages on P9-19 and P9-20?
>>
>> --- Graham
>>
>> ==
>>
>>
>>
>> On Saturday, March 11, 2017 at 6:00:00 PM UTC-6, christ christ wrote:
>>>
>>>
>>> -- Forwarded message --
>>> From: christ christ 
>>> Date: Sat, Mar 11, 2017 at 3:37 PM
>>> Subject: Re: Detecting (probing) MPU-9250 connected to beaglebone board
>>> black
>>> To: Graham 
>>> Cc: BeagleBoard 
>>>
>>>
>>> Hi Graham,
>>> I just thought that a visual of what I'm doing would help with your
>>> assistance. Please let me know if there is anything i'm missing here.​
>>>  Debian result0.jpg
>>> 
>>> ​​
>>>  Debian result1.jpg
>>> 
>>> ​​
>>>  Debian result2.jpg
>>> 
>>> ​​
>>>  Debian result3.jpg
>>> 
>>> ​​
>>>  Debian result4.jpg
>>> 
>>> ​​
>>>  Debian result5.jpg
>>> 
>>> ​​
>>>  Debian result6.jpg
>>> 
>>> ​​
>>>  Debian result7.jpg
>>> 
>>> ​
>>>
>>>
>

-- 
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/CANN_KV4BVYggSnOVsLyXtuhfNZT4sdHqUKpbPXV_8c%2Bg-RX7Ag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Detecting (probing) MPU-9250 connected to beaglebone board black

[Graham Haddock]

Under Debian 8, the external I2C bus is now I2C-2.
I2C-1 is internal only, and used for talking to the PMIC and things like
that.
Don't use it, unless you really understand what you are doing.
--- Graham

==

On Fri, Mar 10, 2017 at 8:08 AM, christ christ 
wrote:

> Hi Graham,
> I have been using the latest version of Debien, for three days now with
> the same result.
> On the other hand i checked with the oscilloscope the SDA and SCL lines
> are not acting like they are supposed to act (even on the default P9_19 and
> P9_20).
>
> Thought maybe they all need to be enable.Tried the following method but in
> vain (NO such file or directory is the response i'm getting)
> *To enable the I2c-1 on the BeagleBone Black Rev A, B and C:*
>
>1. Rev A/B: Open the file /media/BEAGLEBONE/uEnv.txt in an editor
>(vim/nano)
>2. Rec C: Open the file /boot/uboot/uEnv.txt in an editor (vim/nano)
>3. Add the key "capemgr.enable_partno="
>4. Add the ports you want to enable, comma separated (BB-I2C0,
>BB-I2C1, etc)
>5. Reboot.
>
> Am i right to say the I2c buses are not enable? or is it another proble?
>
> On Thu, Mar 9, 2017 at 4:25 PM, Graham  wrote:
>
>> Then it is not wired or connected correctly.
>> Put an oscilloscope on the data and clock lines and see if they are doing
>> what they are supposed to do.
>> It also looks like you are using an old version of the OS.
>> Move to Debian 8, and you should see the I2C devices on bus 2.
>> Hook the I2C Clock to P9-19.  Hook the I2C data to P9-20.
>> You should not have to mess with the device tree or pin configuration.
>> Power and ground also required.
>>
>> --- Graham
>>
>> ==
>>
>> On Thursday, March 9, 2017 at 6:52:04 AM UTC-6, christ christ wrote:
>>>
>>> The MPU-9250 breakout from spark fun come with pull up resistors.
>>>
>>> On 09 Mar 2017 00:42, "Graham"  wrote:
>>>
 Something is not wired right.
 Did you put pull-up resistors on the I2C lines?
 --- Graham

 ==

 On Wednesday, March 8, 2017 at 12:02:04 PM UTC-6, mamane...@gmail.com
 wrote:
>
> Hi Guys,
>
> I’m struggling to get the device address (MPU-9250). i got to the
> following stage:
>
>
> root@beaglebone:~# sudo i2cdetect -r 0
> WARNING! This program can confuse your I2C bus, cause data loss and
> worse!
> I will probe file /dev/i2c-0 using read byte commands.
> I will probe address range 0x03-0x77.
> Continue? [Y/n] y
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00: — — — — — — — — — — — — —
> 10: — — — — — — — — — — — — — — — —
> 20: — — — — UU — — — — — — — — — — —
> 30: — — — — UU — — — — — — — — — — —
> 40: — — — — — — — — — — — — — — — —
> 50: UU — — — — — — — — — — — — — — —
> 60: — — — — — — — — — — — — — — — —
> 70: UU — — — — — — —
> root@beaglebone:~# sudo i2cdetect -r 1
> WARNING! This program can confuse your I2C bus, cause data loss and
> worse!
> I will probe file /dev/i2c-1 using read byte commands.
> I will probe address range 0x03-0x77.
> Continue? [Y/n] y
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00: — — — — — — — — — — — — —
> 10: — — — — — — — — — — — — — — — —
> 20: — — — — — — — — — — — — — — — —
> 30: — — — — — — — — — — — — — — — —
> 40: — — — — — — — — — — — — — — — —
> 50: — — — — UU UU UU UU — — — — — — — —
> 60: — — — — — — — — — — — — — — — —
> 70: — — — — — — — —
>
>
> But even after connecting my device It is still the same (I mean it
> still doesn't show the device's address). Any advise?
>
> 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/CANN_KV5OQzLvi9ckb%3D8yDKubQbbCQri8t-VO4aEVe4zSx2O64Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PRU SPI ADC communication

[Graham Haddock]

Hi David:

I am glad to hear that you got it fixed.

I am posting your reply back to the Beaglebone reflector, so others can
benefit from the discussion.

If you are talking about RAM in the PRU, perhaps some PRU expert can answer
your question. (I am not a PRU expert.)

If you are talking about RAM in the main Sitara memory space, use the Linux
command "free".  You can Google that.

In order to write to a uSD card, I am sure that you will need to have a
small application that will take
the data from the PRU and move it to the uSD card.

--- Graham

==
David Caniceiro


to me
Hi Graham,

Thanks for your answer, i solved the problem minutes after, and it was a
hardware problem in the reference.

I dont know if u can answer me, but i have another two question. What is
the max RAM i can allocate to the samples from PRU, and if is possible to
write directly to an uSDcard working as external memory from the PRU. If
not, i can do the a discuss about this.

Best Regards,
David

On Wed, Feb 8, 2017 at 10:30 AM, Graham  wrote:

> Hi David:
>
> I think it is a hardware problem.
>
> It looks like you are not doing a good job referencing your ground input
> for the ADC, or you have a very dirty Voltage reference for the ADC.
>
> Either way, it is picking up some serious offset from a switching power
> supply (The PMMIC ???) somehow.
>
> I think you need to do an audit of the power going to the Voltage
> reference for the ADC, and the connection of the positive and negative
> Voltage references, and the negative input on the ADC.
>
> --- Graham
>
> ==
>
>
>
> On Wednesday, February 8, 2017 at 6:34:37 AM UTC-6,
> davidvaran...@gmail.com wrote:
>>
>> Hi,
>>
>> I adapted the code from  Derek Molloy example -
>> http://exploringbeaglebone.com/chapter13/ - https://github.com/derekmoll
>> oy/exploringBB/tree/master/chp13/adc - to read this adc - ad4000 -
>> http://www.analog.com/media/en/technical-documentation/data-
>> sheets/AD4000.pdf with a 500kHz sampling.
>> The only thing i changed, according to communicate with this adc, is that
>> i read 16 bits on the PRUADC.p and TIME_CLOCK is 1 (12.5Mhz for SPIclock).
>> I'm not an assembly expert, so i really can't figure out the problem.
>>
>> I tried read the this adc from the SPI0 of BBB(using Derek Molloy
>> exampels too http://exploringbeaglebone.com/chapter18/) , of course not
>> with a 500kHz sampling, just for test, but the problem is the same, i'm
>> working on this for more than 4 weeks, and i can't solve the problem, and
>> is not a hardware problem.
>>
>> In this examples, i have in the analog input of the adc, a square
>> wave(3.3 V), and 3 constantes voltages(680mV,1.8V,3.3V), all examples done
>> on PRU, and this are the results:
>> - Y axis -> Volts
>> - X axis -> Number of sample
>> - Vref of the adc is 4V.
>>
>>
>> 
>>
>>
>> 
>>
>>
>> 
>>
>>
>> 
>>
>>
>>
>> Any help would be aprecciated.
>>
>> Best Regards,
>> David
>>
>>
>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/i13Z9oe3EzM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/b94014a1-7158-4dee-a304-edab41c21e4d%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/CANN_KV6sxtAWLfkEaWVgpJwmekZ4%2BZrPpNo9d_4pnLFn_eNpiQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Of SPI and such

[Graham Haddock]

On Mon, Jan 30, 2017 at 12:24 PM, 'woody stanford' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> You are obviously knowledgeable, Graham, so we'll pose these questions to
> you then.
>
> (1) Is serial (ie. UART) communication on a BBBW (Rev C) Angstrom "distro"
> (ie. stock) done with the ttyO1 to ttyO6 "terminals". Is this HOW it is
> done? Elaborate if you feel the need. (Hoping he's going to say yes to this
> so I can just use stdio.h and feel confident about it)
>

Do you really mean Angstrom? If so, switch to one of the current Debian
distros as fast as you can.

ttyO1 to ttyO6 are not "terminals."  A terminal client would use ttyOx to
access the corresponding UART based serial ports.

The "stdio.h" equivalent for serial communications is "termios.h" .   I
suggest you Google that and start reading. Look for things like
"Programming with Termios".


> (2) What is THE accepted procedure(s) for enabling PWM/UART/TIMER/GPIOs on
> a BBB? Is it as they say by manipulating the uEnv.txt file, or would the
> pin-config utility be better, or am I mistaken here as well?
>
> There are many ways to enable an IO on the Beaglebone. Custom .dts/.dtb,
Universal I/O, or use the pre-compiled overlays you access from uEnv.txt.
I usually find that for a serious application, I am just better off doing a
custom .dts/.dtb for my application, so I am in control, and know
everything that is going on.
If you only want to do one or two things for a simple application, the
overlays work fine.
But, for instance, if you are using audio streaming from the McASP as part
of your application, you have to start with a different base .dtb, that I
am not sure has been tested for compatibility with all the overlays.

Not so critical but interested on your opinion:
>
> (3) How do you feel about, at the board level, running a BBB's UART's TX
> to a bunch of RX's on (slave) MCU's, and then using a 1 byte "address" to
> figure which MCU the following byte(s) were for?
>
> Lots of serial protocols do things like that.  If it is a closed system,
and you are in control of both ends, should work fine.


> (4) Conversely, how do you feel about, again at the board level, running
> the MCU's UART TX's all to one bus wire and connecting that to the BBB's
> RX. Electrically and otherwise I mean? And then prefacing each transmit
> with a 1-byte "address" so the BBB knows which MCU the following byte(s) is
> coming from?
>

See (3).  Sounds like you are re-inventing Ethernet.

The fun begins when you want status back from the slaves, and now you have
to build a custom bus receive combiner that adds everything back together
from the slaves.  And an overlay protocol that deals with bus collisions,
if the slaves can autonomously speak without being polled.

--- Graham

==

-- 
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/CANN_KV7gXcLgOCpK%2B_gmZtxrLzLphTEOL_4HOQp7%3DHx33O9Jcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Help designing-in fast ADC (e.g. Analog Devices AD7761) for sonar.

[Graham Haddock]

The ADC can be set up to run audio format TDM. You have two MCASP, which
are high speed multi-channel TDM engines to play with.

(Although I think they only did a real good job of pinning out MCASP0, need
to investigate, but one might be enough.)

Each are relatively independent bi-directional.

Curious as to why you need outbound TDM,  If for configuring the part, use
a SPI peripheral for that.

One question is if you can find a Linux driver that can be configured the
way you need it.

Without an on-board DSP, beware of the amount of number crunching you can
do, at the same time you are moving around that much data.

A DaVinci processor, which is basically a Sitara plus a C67 DSP would have
a lot more DSP capability, or the newer Keystone series processors.

The Beagleboard X-15 is probably more like what you will need, if you are
going to do a lot of signal processing.

--- Graham

==



On Sun, Nov 27, 2016 at 3:10 PM, Ruth Ivimey-Cook 
wrote:

> Hi
>
> William: Unfortunately the TI chips I found on the launchpads page have
> multichannel interfaces, but not simultaneous: that is there is only one
> actual ADC and multiple Sample/Hold units. In the application I'm
> interested in, sampling truly simultaneously is one of the requirements.
>
> Graham: Thanks for that; I hadn't considered that the McASP might be able
> to read as well as write data streams, but I guess it does make sense. I'll
> have a look.
>
> I did things like this in the past on Sun-4 workstations at 200MHz, though
> only 1/4 real time. Hoping that an ARM-8 with SIMD extensions will be able
> to do it real-time :-)
>
> Regards
> Ruth
>
>
> On Sunday, 27 November 2016 20:55:15 UTC, Graham wrote:
>>
>> Ruth
>>
>> I would suggest that you look at the MCASP peripheral feature on the
>> Beaglebone Sitara processor.
>>
>> See "AM335x Technical Reference Manual", Chapter 22
>>
>> There are two of them, and each is a multi-channel audio interface.
>>
>> It looks like your AD7761 can be configured to run serial wire per
>> channel, two four channel TDM or one eight channel TDM.
>>
>> Each MCASP can be configured as four channel, one data wire per channel
>> parallel interface, or in TDM mode each can be configured for either four
>> or eight channel 24 or 32 bit serial.
>>
>> So, it seems that one MCASP should be able to deal with the AD7761 ADC,
>> and you would have multiple options as to how to configure the interface,
>> using two MCASP periherals.
>>
>> You would have to make sure that all the wires you would need are pinned
>> out from the Sitara to one of the headers, where you could get at them, as
>> well as there are no conflicts for each of those pins, as to other things
>> you expect the Beaglebone to be doing.
>>
>> You would need to investigate the availability of a configurable driver,
>> or worst case, write your own custom driver.
>>
>> You are talking about streaming a lot of data, so likely only a modest
>> amount of signal processing can be done on the Sitara in real time.
>>
>> --- Graham
>>
>> ==
>>
>>
>>
>>
>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/CtE2AkylDCE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/5a124ba5-d2dd-4328-8eb4-b9a812da95ca%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/CANN_KV6odXnBuPmDBkxEHENpi%3DZPhdRXnA6gfC09-hyii6zrkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: question from a total newbie...

[Graham Haddock]

Hi William:

For an expert, you are totally correct.

For a newbie, the Raspberry Pi images seem to be designed to limit how much
tinkering you can do with Linux itself.

The tools and examples for modifying Linux itself are much better supported
on the Beaglebone.

Both are good for blinking LEDs and simple embedded programming experiments.

--- Graham

==



On Thu, Sep 29, 2016 at 4:12 PM, William Hermans  wrote:

>
>
> On Thu, Sep 29, 2016 at 2:04 PM, Graham  wrote:
>
>> The Beaglebone is a better choice than say, Raspberry Pi, since Linux is
>> somewhat locked-down on the R Pi, which puts limits what you can do with it.
>>
>
> This is mostly false. The images provided by the Raspberry PI foundation
> are rather "odd". However, just like with the beaglebone a user can create
> their own Linux images. Especially for the rPI2/3's. Since they are able to
> run armhf code like any other normal ARM system to date.
>
> All one needs to know is which files need to be where( text config files,
> and device tree files, etc ). But, one thing I have not seen yet is
> instructions for creating, compiling, and "installing" a boot loader for
> these systems. Presumably one could setup and use a "stock( rPI patched
> )uboot for this task.
>
> The hard part would mostly be finding good solid information on how the
> hardware is to brought up at, and prior to boot. The graphics processor is
> also hard to find good solid information on.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/memdbJws72M/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/CALHSORrRAr_UiSPjcunOnizT_zRwu%2Boc5_
> y5qVedmMCPVXLA8g%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/CANN_KV7p56PaUfWEXzyLCMEcdEP-7vTAW8d_FDB4kn5at%3DgJSQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How can I bring my 'bone completely back to as-delivered status?

[Graham Haddock]

Arnold:

I know you think you asked a simple question, but I don't think things are
actually working they way you think they are, and it could change the
answer.

Where did you get the card?

Is it a copy of something that ran on someone else's Beaglebone, that
already had a compiled version of SoftEther VPN Server on it?

Or, did you actually build/make/compile the copy of SoftEther on the card?

What else is on the card?  A Debian OS?

--- Graham

==

On Sat, Jul 9, 2016 at 9:19 AM, Arnold Podolsky M.D.,J.D. <mdj...@gmail.com>
wrote:

> Thanks Graham and William. I am not sure what I did right, but it all
> seems to be working as I wish at the moment. I flashed the eMMC with Debian
> Jessie 8.5 and now when I power-up, my Softether VPN server automatically
> runs from my uSD card.
> One newbie question: When I ssh into the BBB, how do I get a list the
> files that are on the uSD card?
> Thanks...Arnie
>
> On Fri, Jul 8, 2016 at 1:19 PM, Graham Haddock <gra...@flexradio.com>
> wrote:
>
>> Arnie:
>>
>> Simple answer: No.
>>
>> Although it is possible to have the OS running on the eMMC and an
>> application located on the uSD card, I would highly recommend that you do
>> not try to do it that way.  Life will be much easier if you have your
>> application and the OS in the same location.
>>
>> So, choose either the eMMC or the uSD card as the location for the OS and
>> the (SoftEther VPN Server) application.
>>
>> Install the OS and get it running.
>> I highly recommend you have a serial cable on the serial console port for
>> all of this.
>>
>> SoftEther VPN Server for the ARM is provided as source code, so you will
>> need to make sure you have all the prerequisite tools and files installed,
>> then use the "make" procedure provided with the source code to build the
>> application on the target beaglebone.
>>
>> It also includes some self tests to make sure the build works and is
>> compatible with the target hardware.
>>
>> Then you will need to use the command line to start the VPN server.
>>
>> Then, you will need to use either the Windows or Linux console
>> configuration tools to configure the Server.
>>
>> It is possible to write a service.d script to automatically start the VPN
>> server whenever the beaglebone boots, but these files are not provided as
>> part of the Softether distribution.
>>
>> So, I would say that this effort is not for Linux or Beaglebone
>> beginners.  You need to have sort of medium Linux skills to pull it off.
>>
>> It works real well once you get it going.  Both the Beaglebone and the
>> SoftEther VPN Server are extremely stable
>>
>> --- Graham
>>
>> ==
>>
>> On Fri, Jul 8, 2016 at 11:08 AM, William Hermans <yyrk...@gmail.com>
>> wrote:
>>
>>> Thanks William. So I just want to make sure... all I need to do is flash
>>>> the eMMC with Debian Jessie 8.4. Once I do that, it should boot up and
>>>> automatically run my Softether VPN server located on the uSD card?
>>>> Yes?
>>>> Thanks...Arnie
>>>>
>>>
>>> I have no idea what a *Softether VPN server* *is*. But no, a flasher
>>> image is used for only one purpose. Flashing a working image onto the eMMC.
>>> What's more, the flasher image will also very likely wipe the contents of
>>> the eMMC first.
>>>
>>>
>>> On Tue, Jul 5, 2016 at 12:44 PM, <mdj...@gmail.com> wrote:
>>>
>>>> This question will reveal what a newbie I am:
>>>> I have seen several posts that say I have to un-comment out a
>>>> particular line in uENV.txt on the SD card. My question is, how do I find
>>>> that file? I don't even know how to get a listing of files and directories
>>>> on the SD card. Help!!?
>>>> Thanks...Arnie
>>>>
>>>> On Monday, July 4, 2016 at 6:59:28 PM UTC-4, William Hermans wrote:
>>>>>
>>>>> *On Debian 8 and later, this usually means that you do not have the
>>>>>> "boot bit" set on the card.*
>>>>>>
>>>>>
>>>>> No . ..as I said. It means there is an older bootloader on the emmc.
>>>>> If you remove the bootloader, said problem goes away.
>>>>>
>>>>> On Mon, Jul 4, 2016 at 3:33 PM, Graham Haddock <gra...@flexradio.com>
>>>>> wrote:
>>>>>
>>>>>> It should automatically boot from the card without having to push the
>>>>>> boot butt

Re: [beagleboard] How can I bring my 'bone completely back to as-delivered status?

[Graham Haddock]

Arnie:

Simple answer: No.

Although it is possible to have the OS running on the eMMC and an
application located on the uSD card, I would highly recommend that you do
not try to do it that way.  Life will be much easier if you have your
application and the OS in the same location.

So, choose either the eMMC or the uSD card as the location for the OS and
the (SoftEther VPN Server) application.

Install the OS and get it running.
I highly recommend you have a serial cable on the serial console port for
all of this.

SoftEther VPN Server for the ARM is provided as source code, so you will
need to make sure you have all the prerequisite tools and files installed,
then use the "make" procedure provided with the source code to build the
application on the target beaglebone.

It also includes some self tests to make sure the build works and is
compatible with the target hardware.

Then you will need to use the command line to start the VPN server.

Then, you will need to use either the Windows or Linux console
configuration tools to configure the Server.

It is possible to write a service.d script to automatically start the VPN
server whenever the beaglebone boots, but these files are not provided as
part of the Softether distribution.

So, I would say that this effort is not for Linux or Beaglebone beginners.
You need to have sort of medium Linux skills to pull it off.

It works real well once you get it going.  Both the Beaglebone and the
SoftEther VPN Server are extremely stable

--- Graham

==

On Fri, Jul 8, 2016 at 11:08 AM, William Hermans <yyrk...@gmail.com> wrote:

> Thanks William. So I just want to make sure... all I need to do is flash
>> the eMMC with Debian Jessie 8.4. Once I do that, it should boot up and
>> automatically run my Softether VPN server located on the uSD card?
>> Yes?
>> Thanks...Arnie
>>
>
> I have no idea what a *Softether VPN server* *is*. But no, a flasher
> image is used for only one purpose. Flashing a working image onto the eMMC.
> What's more, the flasher image will also very likely wipe the contents of
> the eMMC first.
>
>
> On Tue, Jul 5, 2016 at 12:44 PM, <mdj...@gmail.com> wrote:
>
>> This question will reveal what a newbie I am:
>> I have seen several posts that say I have to un-comment out a particular
>> line in uENV.txt on the SD card. My question is, how do I find that file? I
>> don't even know how to get a listing of files and directories on the SD
>> card. Help!!?
>> Thanks...Arnie
>>
>> On Monday, July 4, 2016 at 6:59:28 PM UTC-4, William Hermans wrote:
>>>
>>> *On Debian 8 and later, this usually means that you do not have the
>>>> "boot bit" set on the card.*
>>>>
>>>
>>> No . ..as I said. It means there is an older bootloader on the emmc. If
>>> you remove the bootloader, said problem goes away.
>>>
>>> On Mon, Jul 4, 2016 at 3:33 PM, Graham Haddock <gra...@flexradio.com>
>>> wrote:
>>>
>>>> It should automatically boot from the card without having to push the
>>>> boot button.
>>>> On Debian 8 and later, this usually means that you do not have the
>>>> "boot bit" set on the card.
>>>>
>>>> If you created the card by installing the resident version of Debian,
>>>> then expanding the partition, the "boot bit" should already be set.
>>>>
>>>> If you created the card some other way, then put it in a Linux desktop,
>>>> and run Gparted. Go into the option-menus and manually set the boot bit.
>>>> It should then automatically boot, whenever you apply power to the BBB.
>>>>
>>>> There is probably some other way to manually edit the card and set the
>>>> bit, but I find Gparted very easy to use.
>>>>
>>>> I am running a BBG as a SoftEther VPN server and it works fine.  No
>>>> need to push buttons to get it to boot.
>>>>
>>>> --- Graham
>>>>
>>>> ==
>>>>
>>>> On Mon, Jul 4, 2016 at 4:14 PM, William Hermans <yyr...@gmail.com>
>>>> wrote:
>>>>
>>>>> > Graham (or anyone who knows):
>>>>> > I use my BBB as a VPN server running Softether. Right now, it is all
>>>>> running from a 16gb uSD card which means that I >have to hold the button
>>>>> every time I power it up.
>>>>> The reason for this is that you have an older bootloader on the emmc.
>>>>> You can change this behavior if you wish. BY two differnt method I
>>>>> personally am aware of.
>>>>>
>>>>> &g

Re: [beagleboard] How can I bring my 'bone completely back to as-delivered status?

[Graham Haddock]

It should automatically boot from the card without having to push the boot
button.
On Debian 8 and later, this usually means that you do not have the "boot
bit" set on the card.

If you created the card by installing the resident version of Debian, then
expanding the partition, the "boot bit" should already be set.

If you created the card some other way, then put it in a Linux desktop, and
run Gparted. Go into the option-menus and manually set the boot bit.  It
should then automatically boot, whenever you apply power to the BBB.

There is probably some other way to manually edit the card and set the bit,
but I find Gparted very easy to use.

I am running a BBG as a SoftEther VPN server and it works fine.  No need to
push buttons to get it to boot.

--- Graham

==

On Mon, Jul 4, 2016 at 4:14 PM, William Hermans  wrote:

> > Graham (or anyone who knows):
> > I use my BBB as a VPN server running Softether. Right now, it is all
> running from a 16gb uSD card which means that I >have to hold the button
> every time I power it up.
> The reason for this is that you have an older bootloader on the emmc. You
> can change this behavior if you wish. BY two differnt method I personally
> am aware of.
>
> >Can you tell me how to get this all into the eMMC memory? I don't use any
> >video or GUI but don't know how to eliminate >those features from the
> Debian Jessie 8.4 that I am running so that there >would be room for
> Softether as well in the eMMC.
> > Thanks in advance for help with this...Arnie
>
> You download and put a flasher image onto an sdcard. Instead of a
> standalone image.
>
> On Mon, Jul 4, 2016 at 11:05 AM,  wrote:
>
>> Graham (or anyone who knows):
>> I use my BBB as a VPN server running Softether. Right now, it is all
>> running from a 16gb uSD card which means that I have to hold the button
>> every time I power it up. Can you tell me how to get this all into the eMMC
>> memory? I don't use any video or GUI but don't know how to eliminate those
>> features from the Debian Jessie 8.4 that I am running so that there would
>> be room for Softether as well in the eMMC.
>> Thanks in advance for help with this...Arnie
>>
>> On Wednesday, April 20, 2016 at 10:18:44 AM UTC-4, Graham wrote:
>>>
>>> You never said how you are running the BBB.
>>> If you are running without a video display, local or remote, then you
>>> don't need about half of what is in the full package.
>>> Then you could load a minimum "console" package, which will only fill
>>> 1.7G of your 4 G eMMC, then add in what else you need to run your
>>> application.
>>> So, you would have about 2 GB of play space.
>>>
>>> If you have a video display you are better off going with the full
>>> package..
>>>
>>> --- Graham
>>>
>>> ==
>>>
>>>
>>> On Wednesday, April 20, 2016 at 8:27:27 AM UTC-5, blues man wrote:

 Thanks, Graham!  I'll just use my 64G uSD card, expand the file system,
 and go back to JRMC on Debian.  I guess the older images didn't fill the
 eMMC, so I still had room for JRMC - but the latest one tipped the scale
 too far.  I've been viewing having to run from the card as a sign of
 defeat, for some odd reason! :)

>>> --
>> 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/4cc6fa59-245f-4eae-bb87-60a14cbbd3de%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 a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/Sfpg7Ohg_Z4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CALHSORoqGr_xYzoVHiGbg2FCTpBbnBOeCy40%2BdQWF405ew2LbQ%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 

Re: [beagleboard] Re: Looking for recommendation for BBB cross-compile toolchain and IDE for Windows

[Graham Haddock]

My personal favorite C/C++ IDE is Eclipse, with the C/C++ Development and
Remote System Explorer (RSE) environment packages.  I use the GCC cross
compiler.

A reference on how to set this up, although needing some updating, due to
newer current versions of Debian and Eclipse, is Derek Molloy's book,
website, and youtube videos.

Since the target system is Linux/Debian, things will run a lot smoother if
you run Eclipse and the appropriate GCC cross compiler under Linux, rather
than Windows. I use either a separate computer running Ubuntu, or Ubuntu
running on a VM under Windows.


Setting up Eclipse on the Beaglebone for C++ Development ...
http://derekmolloy.ie/beaglebone/setting-up-eclipse-on-the-beaglebone-for-c-development/
by Derek Molloy

Google: Eclipse, beaglebone, RSE, GCC ARM Crosscompiler

--- Graham

=

> For C++/C
>
> On Friday, July 1, 2016 at 3:42:55 PM UTC+3, Graham wrote:
>>
>> For which programming language(s) ?
>>
>> Which OS will you be running on the BBB?
>>
>> --- Graham
>>
>>
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/QN5ojiYDcDU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/dcbcb103-21d0-4b30-ac60-83b2d0b4e190%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/CANN_KV6USTQz6nw%2BD%2BBreAN3sqg_xjE7nodB79Z-MereK8s_PQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Beaglebone crashing during thunderstorms!

[Graham Haddock]

The PMIC in the BeagleBone will go into shutdown, if the DC supply voltage
goes below 4.5 Volts, or above 5.5 Volts, even for a few milliseconds.

In use it should be held between 4.75 and 5.25, so you have some margin.

If the "lights flickered" then the power supply for the BBB did not have to
shut down or loose power, just loose regulation enough to go below 4.5 or
above 5.5.
The BBB is more sensitive than a lot of devices in that respect.

--- Graham

==

On Thu, Jun 30, 2016 at 3:54 PM, William Hermans  wrote:

> But yeah have a look at this:
> https://plus.google.com/106867156582775247949/posts/gFPzDcwyWCs The
> second image on that post is a really good close up, of what happens to
> equipment out here once in a while ;)
>
> On Thu, Jun 30, 2016 at 1:40 PM, William Hermans 
> wrote:
>
>> Wally, why don't you put shielding around your beaglebone, and see if it
>> happens next time.
>>
>> We've seen very similar reset situations here with PTP WIFI routers ( WDS
>> ), from very close lightning strikes we get here every year this time of
>> year. Yet, none of our beaglebone's have been affected.
>>
>> So what's the difference between you, and us ? We live inside a 80' x
>> 100' steel building. In other words, all our equipment is shielded, except
>> the PTP routers which are outside of the building . . .
>>
>> On Thu, Jun 30, 2016 at 1:30 PM, Gerald Coley 
>> wrote:
>>
>>> So, on this crashDoes it basically reset or just stop? How do you
>>> recover?
>>>
>>> Gerald
>>>
>>>
>>> On Thu, Jun 30, 2016 at 3:14 PM, Wally Bkg 
>>> wrote:
>>>
 "Well, I don't know where to start. A detailed diagram of the entire
 system hookup would help.

 Gerald"

 Being in active use for ~25 years and hooked to a variety of computers
 as the years have passed, its never been a problem, but the best I could do
 would be a scan of the diagrams I've built it from.  Its very repetitive,
 four basic interface circuit designs repeated 2, 4, 8, 16 times.  But I may
 get desperate enough to do this, eventually.

 But it acted as if the power button had been held down and just shut
 off, and there was minimal disturbance to lights (mix of incandescent, CF,
 and LED) and the various USPes around the house, so I'm thinking maybe EMP
 sensitivity in the power controller chip.  Its an old house (built circa
 1950), but this outlet is one that I ran a 12ga stranded wire straight from
 the outlet to the grounding rod at the service entrance when we first moved
 in to give me a good ground back in the days I did a lot of hardware work
 -- remember the days of wire-wrapped S-100 bus prototypes :)

 OTOH, as I've upgraded the security cameras to HD I've reused the SD
 camera wiring to add additional PIR motion detectors, and I just discovered
 (after posting this thread) I'd one added PIR unintentionally powered from
 a different UPS (but they are all on the same breaker and safety ground
 connection), so I'll see if it happens again.  This had been the case for
 the first thunderstorm crash a few months ago as well.

 --
 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/6cc15654-ade8-4aea-821b-c7bed75f5575%40googlegroups.com
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> --
>>> Gerald
>>>
>>> ger...@beagleboard.org
>>> http://beagleboard.org/
>>> gcol...@emprodesign.com
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/beagleboard/CAHK_S%2Be95AW5w7o5gwcyvnULgy_3cvVqOVMOmj30g-P5tJF3Ag%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 a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/l8hri0SzSKE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> 

Re: [beagleboard] Hardware watchdog for BBB

[Graham Haddock]

William:

That would work.

The only "edge case" I might see as a problem would be if your ping target
went off line.  Then the BBB would reboot itself every ten minutes even
though nothing was wrong with the BBB.  I guess you could ping several
different targets in rotation and only reboot if they all disappeared.
This gets us back to a real cheap local watchdog.

As an aside: Does anyone know what test a computer runs to determine if it
is connected to the internet?
Most desktop/laptop computers have a different network icon as to whether
the network/WiFi you connected to has internet connectivity.   Is the
Windows computer pinging some Microsoft location that is "guaranteed" to be
up?

--- Graham

==


On Tue, May 17, 2016 at 2:30 PM, William Hermans  wrote:

>
> @Graham,
>
> What I propose is that you do not need an Ethernet Micro connected to the
> BBB. Instead, you have the BBB ping the outside world once every set time
> frame, and it a ping comes back unreachable after say 5-10 minutes. You
> just stop "kicking the dog". Which does present a potential problem that
> Your internet connection may just be down. But a remote system that reboots
> once every 5-10 minutes because the internet connection is down is not
> something I'd personally see as a bad thing. After all you're unable to
> connect to the system anyway.
>

 ==

-- 
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/CANN_KV6MEtkBkkjA-xc3KKzeNRh6LDpoB1xrBnN%2BZo6gJgLX6w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Single Cape Expansion Connector

[Graham Haddock]

Hm.

Both "Major League Electronics" and Samtec are located in New Albany,
Indiana.

What are the chances ?

Sounds like there is a back-story there, somewhere.

--- Graham



On Wed, May 4, 2016 at 4:51 PM, evilwulfie  wrote:

> I know about breakaway headers and all. just when quoting its best to
> specify real connectors with
> no waist.
>
> On 5/4/2016 2:47 PM, Charles Steinkuehler wrote:
> > 46-pin headers are a bit unusual.  Normally, you'd just buy a longer
> > snap-able header (like 50-pin) and snap off the unneeded pins.
> >
> > You can also buy the "official" connectors from Major League via their
> > BeagleBone store:
> >
> > http://beaglebone.mlelectronics.com/
> >
> > That's a good source if you need a lot of connectors.  The price is
> > good, and you won't have to manually break each header to length.
> >
> > On 5/4/2016 4:32 PM, evilwulfie wrote:
> >> yeppers... but only 44 in stock. mouser digikey and others are all on
> back order
> >>
> >> On 5/4/2016 2:14 PM, Graham wrote:
> >>> https://www.adafruit.com/products/2076
> >>>
> >>> ???
> >>>
> >>> --- Graham
>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/FyhgopTkZBg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/3085c918-4b8f-fd88-2fec-a7172bef9323%40gmail.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/CANN_KV7-BTyA_B8Sybu_OCHmFryoB%2BCMJViPjOH7WQbGxpiK4w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Single Cape Expansion Connector

[Graham Haddock]

Well, in an emergency, you can make your own out of breakaway stock.

Or, if you are in the US and looking for manufacturing volumes,
then call your local Samtec rep. They can turn this kind of stuff in days.
They normally don't use stocking reps.  Factory direct.  Very fast response.

https://www.samtec.com/

https://www.samtec.com/connectors/standard-board-to-board/0100-inch-square-post

--- Graham

On Wed, May 4, 2016 at 4:32 PM, evilwulfie  wrote:

> yeppers... but only 44 in stock.  mouser digikey and others are all on
> back order
>
> On 5/4/2016 2:14 PM, Graham wrote:
>
> https://www.adafruit.com/products/2076
>
> ???
>
> --- Graham
>
> ==
>
> On Wednesday, May 4, 2016 at 4:13:24 PM UTC-5, Graham wrote:
>>
>> Is this what you are looking for?
>>
>> https://www.adafruit.com/products/706
>>
>> Or something different?
>>
>> --- Graham
>>
>> ==
>>
>> On Wednesday, May 4, 2016 at 3:16:32 PM UTC-5, Wulf Man wrote:
>>>
>>> anybody know where there is stock on these. BBB is so popular
>>>
>>> all stock has vanished
>>>
>>>
>>> ---
>>> This email has been checked for viruses by Avast antivirus software.
>>> https://www.avast.com/antivirus
>>>
>>> --
> 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/9d95b1a5-2bc8-4bf2-949b-94be4155a05b%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/FyhgopTkZBg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/14c2d2be-ed08-8d2c-b492-84afd593eb87%40gmail.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/CANN_KV7-y011N_-hgnuT-Yx9pMvbBjiyoX6mHwDVx9EgNfsL0w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How can I bring my 'bone completely back to as-delivered status?

[Graham Haddock]

David:

The whole button press thing is old information.
Even then, you needed to have either a "flasher" or a uSD card resident
package.
The software installation process has evolved a lot. (for the better.)

The good news is that the Beaglebone and embedded Linux are rapidly
evolving.
The bad news is that there is a lot of old/obsolete information available
on the internet.

Good luck,
--- Graham

==



On Tue, Apr 19, 2016 at 5:16 PM, blues man  wrote:

> Thanks, Graham. I thought that holding the boot button down until the leds
> light does flash the MMC and that the flasher image was instead of holding
> the button while powering up. I'm using 32 & 64 cards, but I didn't expand
> the memory partition on either one. I'll just do that and run from the 64.
>
> Thanks & best regards-
>
> David
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/Sfpg7Ohg_Z4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/5b0d7a76-e174-4db4-9e5d-21b53ab1bb37%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/CANN_KV4ryTdA2jwBwx8hTc67QEiAnUyhUHPr1eeHNtHsSb%2BHtw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beagle Board outdoors?

[Graham Haddock]

The problem is, that if it is not perfectly airtight, then the next time
you open it, you find the little silica gel packets floating in a puddle of
water.  :-)

If it is not perfectly airtight, then every time it rains, or a cold front
passes, the box cools and it sucks in a little wet air (or rain).  If the
leak is not at the bottom of the box, then the condensation builds up as
water there.  It takes a year or so.

It is easier to drill a little 2 or 3 mm hole in the center of the bottom
of the box, than to make something perfectly airtight.  Particularly if you
have wires going into and out of the box.


--- Graham

==


On Mon, Apr 18, 2016 at 12:32 PM, evilwulfie  wrote:

> Or if your sure the box is sealed and there is no chance of water getting
> in use some silica jell in the little pouches that will absorb all the
> moisture that is in the box.
>
>
>
> On 4/18/2016 7:36 AM, Graham wrote:
>
>
>
> On Monday, April 18, 2016 at 7:49:09 AM UTC-5, Gerald wrote:
>>
>> Put it in a watertight box. Google NEMA boxes.
>>
>> Gerald
>>
>>
>> Put it in a watertight NEMA box, but always make sure there is a 'weep
> hole' in the bottom of the box.
> Otherwise the humidity inside the box when you closed it will condense out
> on the components when the temperature drops.
>
> The 'weep hole' needs to be big enough to let humidity equalize between
> the inside and out side, small enough to not let insects get inside, and
> somewhere in the central bottom where rain will never hit the hole.
>
> --- Graham
>
> ==
>
>
> --
> 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/95b1f388-34d3-4d48-8fd4-956c3827169b%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/uPEfixR3rrQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/57151A32.5090105%40gmail.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/CANN_KV5jWuFQzbHZohQ5VRgvLWWLqEB6pyqprJ%3Dtv-kY8SyHtg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: C compiler

[Graham Haddock]

To Richard Cook:

My personal recommendation is Derek Molloy's:

Exploring BeagleBone: Tools and Techniques for Building with Embedded Linux
by Derek Molloy for John Wiley & Sons, 2014 -- ISBN 9781118935125

Book WebSite:  includes errata, discussion
http://exploringbeaglebone.com/

Source Code:
https://github.com/derekmolloy/exploringBB/


It has a lot of basic information about setting up a cross-compile system
using Eclipse,
and how to work with the low level I/O and basic Linux commands
He is on faculty at Dublin City University.

The only problem, is that the book is now two years old, and the BeagleBone
systems
are moving fast, so you may need to adjust some things for newer operating
systems releases,
and newer tool versions.

--- Graham

==

-- 
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: C compiler

[Graham Haddock]

Yes.
sudo chmod 755 myprogram
or
sudo chmod 755 myprogram.o

--- Graham

On Fri, Mar 25, 2016 at 9:50 AM, Seppo Nikkilä <
seppo.nikk...@innovativeideas.fi> wrote:

> myprogram.o
>
> On Fri, Mar 25, 2016 at 3:27 PM, Graham  wrote:
>
>> And after you create the file for the first time, you will need to change
>> its permissions
>> so that it is executable.
>> use an incantation like:
>> sudo chmod 755 myprogram.c
>>
>> You will really need to become familiar with the basics of Linux, if you
>> are
>> working on a Linux platform like the BeagleBone Black.
>>
>> --- Graham
>>
>> ==
>>
>> On Friday, March 25, 2016 at 7:33:35 AM UTC-5, c...@isbd.net wrote:
>>>
>>> Wadi Ben Rhouma  wrote:
>>> > [-- text/plain, encoding quoted-printable, charset: UTF-8, 66 lines
>>> --]
>>> >
>>> > thx ,sorry i have another question, i'm not failiar with LINUX , so
>>> can u
>>> > help me with this , how can i write a C code on the terminal and
>>> excute it
>>> > on my BBB ??
>>> >
>>> Create your code in a file called, say, myprogram.c.
>>>
>>> Then:-
>>>
>>> gcc -o myprogram myprogram.c
>>>
>>> This will create a compiled program called myprogram which you can
>>> execute by typing its name at the command prompt.  For C++ you can do
>>> the same using g++ instead of gcc.
>>>
>>> For more complex programs and libraries it gets more involved.
>>>
>>> --
>>> Chris Green
>>> ·
>>>
>>> --
>> 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.
>>
>
>
>
> --
> Developing next generation wireless audio
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/Q6Ed3hfRQag/unsubscribe.
> To unsubscribe from this group and all its topics, 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: PinMuxing P9_21 and P9_23 to I2C2?

[Graham Haddock]

PCB rework skills are very useful, and not explicitly taught in college.
Good luck with your project.
--- Graham

==

On Wed, Mar 23, 2016 at 3:13 AM, Christopher Earley 
wrote:

> That bit about only being able to mux a specific mode's signal (e.g.
> I2C2_SDA or I2C2_SCL) to one pin at a time is the clincher. I didn't feel
> it vital to state in my intro post but turning off the default I2C2 bus
> pins would mean losing the Seeed I2C2 Grove connector (which is connected
> to P9-19 and 20) on the BeagleBone Green. Since that port is also in use
> for my demos, a software solution is just not in the cards for working
> around my poor design decision.
>
> I'll brush up on my PCB rework skills as you discussed and push forward
> with the intent to come back to learning about the BeagleBone's device tree
> system at a later date.
>
> Thanks for your help, Graham and wish me luck!
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/rjWUlnwe8n8/unsubscribe.
> To unsubscribe from this group and all its topics, 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: prolific serial adpater only work if BBB is powered by computer

[Graham Haddock]

Do you have a terminal plugged into the command line serial port?
What does it say is happening?
--- Graham


On Sun, Feb 28, 2016 at 3:14 PM, Graham  wrote:

>
> Alex:
>
> You are probably trying to draw too much power through the USB port from
> the BBB.
> I would try the same setup, but using a Powered USB Hub.  See if any of
> your hubs have a
> wall-wart accessory that can power the hub directly, and take the power
> load for
> all the USB devices away from the BBB.
>
> --- Graham
>
> ==
>
> On Sunday, February 28, 2016 at 1:25:16 PM UTC-6, awesomea...@gmail.com
> wrote:
>>
>> Hi all,
>>
>> So i have a bealge bone black with a 4.3 LCD cape running on debian. I
>> also have a usb hub with 4 output. I currently use 3 of these output (wifi
>> dongle, usb key and a prolific usb to DB9 serial adapter).
>>
>> The serial adapter is here to read some values from an industrial scale.
>>
>> Here is the problem. if the BBB is connected to a computer via the mini
>> usb port, everything run well. (with an without a 2.5 amp on the power
>> barrel.)
>>
>> The second that i disconnect the BBB from the computer, the serial
>> adapter will only receive 0xff caracter. Iv'e tried on others computer with
>> DB9 connector to exclude the scale from the equation.
>>
>> I have no clue and I can't leave a computer connecter to the BBB just to
>> get the serial adapter happy...
>>
>> ps. I have 3 different serial adapter and same result for all. Also 3
>> different usb hub.
>>
>>
>> Thanks in advance
>>
>> Alex
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/OwteDyHFF9E/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Anything similar

[Graham Haddock]

So, tell me again what the market is for a $250 "embedded" processor card.

I understand that TI is using it for an eval board for the AM572x.
OK, I get that. And they add an LCD and double the price. (?!?)

A pair of DSPs brings a lot of crunch power to the party.
OK, cool. RF transceivers, modems for unique protocols that don't have
dedicated hardware solutions. Military gonna like it.

But one, two, or three 2.4 GHz Pentiums can do a lot of crunching if that
is all you do with them.

I am just amazed at what you can get for $179 in a NUC.
There was a discussion earlier today of someone wanting a headless X-15
stripped of all of the GPIO. H.

It is actually quite easy to support SPI, I2C buses and GPIO via USB.
Check out FTDI FT232HL.  One chip.  USB2 to I2C, or SPI or 16 GPIO. (or
serial UART)
Adafruit sells little eval boards. With windows drivers.
FTDI sells them as a lump in a USB cable.
Same guys that have been doing USB to Serial chips for a decade. They are
branching out.  USB to hardware buses, USB to video, etc.

Not hard to get a little or a lot of A->D, D->A, GPIO, in or out of a more
traditional CPU architecture.

--- Graham

==



On Sun, Feb 21, 2016 at 4:47 PM, John Syne  wrote:

> I’m not saying the NUC isn’t a great deal, but it is targeting a different
> market to the x15. You are talking about a computer which doesn't interface
> directly to buses like I2C, SPI, GPIO, I2S, etc. Connecting these buses via
> USB is a real headache. You cannot use a Linux driver for devices connected
> to these buses. You have to write your own user space drivers. The only
> solution I know of that compares to the x15 is the Qualcomm Snapdragon
> Evaluation board, which has CortexA15, GPU, DSP and direct access to
> peripherals. Problem is, this board is over $1,000.
>
> Regards,
> John
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: 46 position female stackable header ?

[Graham Haddock]

I have installed right angle connectors on most of my BBB, so that the
serial console connector comes out the bottom of the board.
Works fine.  You do need to know how to solder to do this, without hurting
the board.  It will no longer fit in a case when you bring
the right angle serial console connector out the bottom of the board, but
is great for development on an open bench.

--- Graham



On Wed, Feb 17, 2016 at 8:08 AM, Taceant Omnes  wrote:

> On 17 February 2016 at 13:48, Taceant Omnes  wrote:
>
> The main reason why I need spacers is because the FTDI cable that I
> connect to UART0 for debug purposes needs it. I have not checked if
> there is another FTDI cable that would fit. The cable I am using was
> bought by a colleague for purposes other than BBB development.
>
> If the BBB had a right-angle connector (such as in the link below)
> then a spacer might not be needed, however I am not sure if that would
> not cause other problems such as electrical noise or issues with EMC
> compliance. That may be the reason why a straight up connector is
> fitted in the BBB.
>
>
> http://www.mouser.co.uk/ProductDetail/Molex/22-28-8063/?qs=sGAEpiMZZMs%252bGHln7q6pmxD%2f5kNJnZVedr5Qq69vbIk=&_cdc=3
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/v7D3_lcbszk/unsubscribe.
> To unsubscribe from this group and all its topics, 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: PRU Clocks phase shifting with respect to each other??

[Graham Haddock]

Bill:

I don't think the PRU clocks are externally available.

I don't know what your interface looks like, but if there was a clock line
involved in the data transfer, or marking when data is valid, I would look
at inverting or adding some delay in that line going to the receiving PRU.
If your interface does not look like that, then I don't have a suggestion,
other than using a second BBB for monitoring.

--- Graham

==

On Wed, Dec 23, 2015 at 5:21 PM, WZ9V  wrote:

> Could you use a second BBB as the capture device instead?  That would
> isolate the PRUs from each other and possibly allow for the HW capture that
> was mentioned.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/zhCplP-SEok/unsubscribe.
> To unsubscribe from this group and all its topics, 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: Out yet?

[Graham Haddock]

I found another one:

http://www.nextwarehouse.com/item/?2221755_g10e

Claims they have one in stock.

I am sure they will say they have just sold it to someone else if you order
it, and your waiting time for the next delivery is 8 weeks.
Except that they will keep forgetting to take that one available off the
website.

I had Element 14 do that to me during one of the BBB shortages.
I initially thought it was an honest mistake, but after a few weeks of that
one unit in stock still being advertised for sale, I wrote to them telling
them what I thought of their marketing practices.
They wrote back apologizing, and pretty much admitting that is what had
happened, that it was some kind of administrative error, and was not
intentional, etc., etc.
But they still did not take that one non-existant unit off their webpage
for several more weeks.

I don't buy from them anymore, either.

I guess the good news, is that it means a lot of people are interested in
the X-15, and it will be a success.

--- Graham

==



On Sun, Nov 29, 2015 at 10:19 AM, David Culp  wrote:

> Here is one place:
> http://www.neutronusa.com/prod.cfm/2368628/glb?gclid=CJXhrIOEtskCFQaJaQod5iII_A
>
> i have never heard of the place before.  I saw at least one other place
> claiming to have boards in stock but they are not coming up in a google
> search right now.
>
>
> On Sunday, November 29, 2015 at 8:43:41 AM UTC-6, Graham wrote:
>>
>> David:
>> Who is saying they have stock?
>> I am always looking for scumbag vendors to NEVER buy from.
>> --- Graham
>>
>> ==
>>
>> On Saturday, November 28, 2015 at 11:41:29 PM UTC-6, David Culp wrote:
>>>
>>> I didn't think it was due out until mid-December.  I'm seeing one or two
>>> places on the net that claim to have stock.
>>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/vMJsTDIIvIA/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Console output garbled?

[Graham Haddock]

Do you have the option to lock it in the basic ASCII 7 bit character set?
That would likely solve the problem.

The problem with Teraterm is that the BBB will sometimes put out some
gibberish or perhaps some non-printing control characters at the start of
the console output (don't know why) and it will intermittently kick
Teraterm into alternate Japanese character set.  Putty only prints ASCII,
so no problems.

--- Graham


On Thu, Nov 5, 2015 at 2:01 PM, Rick Mann  wrote:

> No, I'm using screen on OS X.
>
> > On Nov 5, 2015, at 11:08 , Graham  wrote:
> >
> > By any chance are you using "Teraterm" ?
> > If so, switch to Putty, and your problem will go away.
> >
> > --- Graham
> >
>

-- 
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] BBB P8/P9 GPIO pin availability

[Graham Haddock]

Well, by definition, the boot programming pins are going to have the
pull-ups / pull-downs, so you know what they are going to be doing, until
over-ridden.

Most processors start up with the programmable pins as inputs, then move to
the configured state.
Anything else can be dangerous to the pins.  But, as Charles says, RTFM.

If you are concerned, use the bus-isolation /transmission-gate  chips,
power them early, supply your own pull-ups/pull-downs, and switch the
connection on when SYS_RESETn goes high.  Then you are unconditionally
safe, and in-control.

--- Graham

==


On Mon, Sep 7, 2015 at 6:43 PM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 9/7/2015 6:26 PM, rattus wrote:
> > This does beg one last question - as I am using expansion connector pins
> to
> > provide chip selects for numerous peripherals, what is the default state
> of
> > the AM335X pins at powerup, until the boot configuration is loaded? I've
> > slogged through the TRM as best I could, but want to make sure we're not
> > inadvertently enabling multiple chip selects that may drive competing,
> say,
> > SDOs (peripheral) into SDI (cpu) before the boot configuration is loaded.
> >
> > Ideally, they would be defaulted as inputs or tri-stated outputs, in
> which
> > case a weak pulldown on the peripheral CSn lines should keep things
> quiet.
> > Despite my best efforts at searching the 4K+ pages of the TRM, I have not
> > found a clear answer as to the pre-boot load default pin configuration. I
> > probably missed it, but my search-fu fails me.
>
> You want the AM335x data sheet (currently SPRS717H):
>
> http://www.ti.com/lit/gpn/am3358
>
> Refer to section 4.2, starting on page 18.  You are interested in the
> "BALL RESET STATE" and "BALL RESET REL. STATE" (Table 4-1, pages
> 20-50).  These indicate the state of the various pins when reset is
> asserted (at power up, or when being physically reset), and the value
> once reset is released (this value will be held until application
> software* changes it).  The reset release state is _usually_ (but not
> always) the same as the state when reset is asserted.
>
> NOTES:
> * "Application software" can be anything from the on-chip ROM
> boot-loader to U-Boot to the Linux kernel to your running user-mode
> program.
>
> You have to also review the BBB schematics to see if there are any
> pull-up/pull-down resistors or other drivers or loads connected to a
> GPIO pin that might affect the state prior to specific configuration
> of any I/O pin by software.
>
> --
> Charles Steinkuehler
> char...@steinkuehler.net
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/g_gNimjfQhg/unsubscribe.
> To unsubscribe from this group and all its topics, 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] BBB P8/P9 GPIO pin availability

[Graham Haddock]

I think the VDD_3V3B rail is deliberately held off until the unit has
started booting,
and has already read the boot instructions.  It is not a rise time issue.
I suspect it was done deliberately to help with the "don't drive the rest
of the pins" issue.

A little 5V to 3.3V regulator to power your LVC "input" IC will work nicely.
Provided that it is powered at the same time the BBB is.
That is, use VDD_5V if powered from the power jack.

Relative to power appearing at the power jack:
SYS_5V is delayed 50 ms.
VDD_3V3B is delayed 100 ms.
SYS_RESETn is delayed ~130 ms.

I have not measured power supply sequencing when powered by USB.

Or if you are dealing with both I and O on the boot pins, use something like
a 74CBTLV3126 bus switch / transmission gate to  isolate your circuitry
from the BBB while it is booting.  Just make sure the bus-switch /
transmission-gate
is powered while the BBB is booting.

This issue only comes up about once a week here on the forum.  :-)

--- Graham

-- 
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: Booting issue with a cape - servo input load

[Graham Haddock]

>
> What is the minimum voltage I should have on the GPIO input so it is read
> as 1 logic?
>
>
> For most CMOS the minimum input voltage guaranteed to be read as a one is
0.7 times Vcc.

But not always. Read the spec sheet for the part in use.  For instance, the
transmission gate you found was rated for Vcc of 5 V , but said that the
gate
control was compatible with both 5V and 3.3V systems, which tells me the
Voltages are offset from standard.

>
> I guess that I have to take the maximum current sink a GPIO can handle? I
> cant find these values - only current source (4mA). Can I find the same
> value for current sink?
>
> Normally CMOS can sink more current than it can source, typically by a
factor
of about three, if the device designer used the same geometries for the
pull up
and pull down transistors.
But not always. They could have used a smaller geometry for the sinks.
As usual, read the data sheet.  If you can't find the sink current, then I
think
you must assume it is the same, in this case 4 mA.

--- Graham

==

-- 
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: Booting issue with a cape - servo input load

[Graham Haddock]

Hi Frederic:
You could make the 74HC541 work, since it has a CMOS input and should not
load the BBB during boot, provided that it has power supplied the entire
time the BBB is booting.

I was thinking more of something like the 74CBTLV3126 bus switch which
would disconnect your existing circuits from the BBB, rather than buffer
them like the 74HC541.

In both cases, the switching should be done from the 3.3 V bus, but you can
not power the ICs from the 3.3V bus as you mentioned.  As I remember, on
the BBB, the 3.3V bus rail on the P9 connector does not power up until
AFTER the BBB has completed booting, so if you power the buffer or
isolation switch ICs from the 3.3V rail, the ESD protection diodes in the
IC will clamp the boot lines to ground, preventing the BBB from booting.
You will need to power the ICs, whichever you choose to use, from a
separate 3.3V regulator that provides power anytime the BBB has power
applied.

I think the +5V rail is powered anytime the BBB is powered, so it could
drive the separate +3.3V regulator.

A few Voltage measurements are appropriate, before you finish your
re-design.

--- Graham

==

On Tue, Aug 18, 2015 at 12:19 PM, Frédéric f...@gbiloba.org wrote:

 Le Tuesday 11 August 2015, Graham a écrit :

  If you look at the diagrams in the System Reference Manual, the BBB uses
  100K Ohm pull up and pull down resistors to tell the processor how to
  boot.  So any load low enough to cause a line with 100K Ohm pull up or
  pull down to change logic state will cause boot problems.  I would
  estimate that any load, less than 200 K Ohms can cause this problem,
  even though it is an Input.  Also, inputs connected to unpowered ICs
  will clamp a line to ground, because of the ESD diodes in the IC.
 
  So, either use powered buffer ICs that have only a CMOS input load, or a
  transmission gate as you described.  I think you can switch the
  transmission gate using the 3.3V rail coming out of the BBB, since it
  does not come up until the unit is finished booting.  Do not put an
  unpowered transmission gate on the GPIO lines, because of the ESD
  clamping I described.

 Thanks for the explanations! Didn't know about this ESD clamping
 problem...

 I started to modify my cape, adding 4x 74HC541; can you confirm they are
 OK regarding the inputs? They will be powered up from the 3V3 rail.

 --
 Frédéric

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to a topic in the
 Google Groups BeagleBoard group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/beagleboard/ndlZtL9E1u4/unsubscribe.
 To unsubscribe from this group and all its topics, 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] Image 2015-7-26, kernel 4.1.3-ti-r6

[Graham Haddock]

It is not a flakey DC jack. But yes the symptoms do mimic that kind of
failure.
Same hardware works fine with Debian 8.1/kernel 3.14 and prior.

It happens under all loading /activity, but easy to reproduce with the
board idling, minimum console software load.

It does not happen with the board powered by the USB port.
It only happens when powered by the +5V barrel jack.

No indication in syslog as to what happened.

==

I note that you were working in area changing ticks to jiffies or something
like that.

I personally suspect that there was some code dependent on the previous
timing system
that was used to time some of the USB power switch over mechanisms, that
was not updated
to deal with the timing system changes you made.

For instance, the On-the-Go USB system periodically pushes power out the
USB port
to see if someone has connected a USB device.  The PMIC sees this and can
interpret
this as power has appeared on the USB connector and to attempt a
switchover.  It really
needs to wait some time period to see that it is stable input power rather
than a power probe
pulse generated by the BBB itself.  If your timing system changes modified
this
switchover timing, the system could attempt to switch to a non-existant
power source and
die, causing a power-on reboot.

This theory is supported by experimental tests run by William that says if
the USB
power line is shorted to ground, then the unit does not reboot.

I am just summarizing several weeks of observations by all the guys on this
thread.

--- Graham



On Mon, Aug 10, 2015 at 2:00 PM, Felipe Balbi ba...@ti.com wrote:

 Hi,

 On Mon, Aug 10, 2015 at 01:56:04PM -0500, Robert Nelson wrote:
  On Mon, Aug 10, 2015 at 1:05 PM, Robert Nelson robertcnel...@gmail.com
 wrote:
   On Mon, Aug 10, 2015 at 11:23 AM, Nuno Gonçalves nuno...@gmail.com
 wrote:
   3 weeks ago I asked for it For what is worth I believe the OMAP and
   PMIC reset reason registers should be part of the boot log so future
   reboot problems can be sorted..
  
   But I just asked, I didn't actually code!
  
   Not sure if it is easy to retrieve both, or if PMIC is that much
   relevant for this issues.
  
   Anyway, this will surely take out black magic from the equation when
   debugging this problems.
  
   Okay here's something quick/dirty...
  
  
 http://rcn-ee.homeip.net:81/farm/testing/v4.1.x/MLO-am335x_evm-v2015.07-r3
  
 http://rcn-ee.homeip.net:81/farm/testing/v4.1.x/u-boot-am335x_evm-v2015.07-r3.img
  
   #patch:
  
 https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2015.07/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L21
  
   make sure the eMMC doesn't have it's own bootloader:
  
   U-Boot 2015.07-1-gd8d32cf (Aug 10 2015 - 12:54:52 -0500)
  
  Watchdog enabled
   I2C:   ready
   DRAM:  512 MiB
   Reset Source: Global external warm reset has occurred.
   Reset Source: Power-on reset has occurred.
   MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
   Using default environment
  
   dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10
  
   sudo dd if=MLO-am335x_evm-v2015.07-r3 of=/dev/sde count=1 seek=1
 bs=128k
   sudo dd if=u-boot-am335x_evm-v2015.07-r3.img of=/dev/sde count=2
 seek=1 bs=384k
  
   I need to fire up x86, that's attached to the bbb's (right now i can't
   log serial)
 
  Okay within a few minutes the first board rebooted...
 
  Reset Source: Power-on reset has occurred. 

 weird, this is likely either flakey DC Jack connection, or PMIC going
 bonkers.

 How do you guys reproduce this ? Is the board idle or is it running ?
 Which gadget driver ? Is USB cable connected to a host ? A desktop
 host or wired back into the host port of BBB itself ?

 I wanna try to reproduce it here.

 --
 balbi


-- 
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] Image 2015-7-26, kernel 4.1.3-ti-r6

[Graham Haddock]

I will add anecdotal comment in support of Guenter's comment about a serial
port problem.

Three times, I have had the ttyS0 port hardware serial console port stop
working in advance
of the reboot, while I could still sign in on SSH via Ethernet, and the BBB
seemed to be
otherwise still working.

It may be the same problem, or it may be a different problem, but I suspect
that the serial port
is involved.

--- Graham

==

On Wed, Aug 5, 2015 at 7:03 AM, Robert Nelson robertcnel...@gmail.com
wrote:

 Nice Job Nuno!

 Right now I can confirm up to 1a370f4cd95e056d55ef5bf1a183880e70195e59

 I have 5/5 boards running for 21 hours..

 The worst delay I've seen between reboots has been around 2.5 days..

 On Wed, Aug 5, 2015 at 2:31 AM, Nuno Gonçalves nuno...@gmail.com wrote:

 Just a quick update.


 If I didn't get it wrong so far:


 git bisect start



 git bisect good v4.0

 git bisect bad v4.1-rc1

 git bisect bad 6c373ca89399c5a3f7ef210ad8f63dc3437da345 #
 v4.0-5833-g6c373ca

 git bisect bad e95e7f627062be5e6ce971ce873e6234c91ffc50 #
 v4.0-2825-ge95e7f6

 git bisect bad c4be50eee2bd4d50e0f0ca58776f685c08de69c3 #
 v4.0-1399-gc4be50e

 git bisect good1a370f4cd95e056d55ef5bf1a183880e70195e59 #
 v4.0-682-g1a370f4

 git bisect good 3be1b98e073bdd4c1bb3144201a927c4a21330ba #
 v4.0-1013-g3be1b98

 git bisect bad c6ab3aec4bc4beda2d6eb8ea43c6f5be3b215d3f #
 v4.0-rc5-193-gc6ab3ae

 git bisect bad ab330cf3888d8e0779fa05a243d53ba9f53a7ba9 #
 v4.0-rc3-96-gab330cf



 This results in the following suspects:




 https://lh3.googleusercontent.com/-YNwUnIaBp7I/VcG7DM0ugXI/AAADD34/yksejFzmH-s/s1600/bisect_visualize.png


 It will still take up to 3 days to pinpoint the evil commit...


 Thanks,

 Nuno




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


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
BeagleBoard group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Image 2015-07-19

[Graham Haddock]

Agreed.  But at the same time, the same hardware, right or wrong, works
fine under 3.14 and prior.  So there has been some software change since
3.14 in the way that the hardware is managed.

--- Graham

==

On Tue, Jul 28, 2015 at 5:47 PM, Dennis Cote denn...@harding.ca wrote:



 On Monday, July 27, 2015 at 10:27:52 AM UTC-6, dl4mea wrote:

 I meanwhile tried if a 1k resistor from Vbat-Sense to ground helps: No,
 does not.

 Summarizing my feeling: Feeding +5V to the back side USB helps a little,
 1k resistor over Vbat-Sense does not help.


 You might want to try connecting TP5 (BAT) to TP6 (BAT_SENSE). You can use
 a resistor if you want, but BAT_SENSE is a high impedance input.

 These terminals would normally be connected to each other at the battery.
 On the BBB they are not connected to anything. The PMIC sends test currents
 out the BAT pin and measures the resulting voltages on the BAT_SENSE pin.
 These functions can't work if they are not connected. The measured voltage
 on BAT_SENSE may drift depending upon the leakage currents at the floating
 input.

 Dennis Cote


-- 
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] BBB intermittently rebooting.

[Graham Haddock]

William:
OK. I plan to let it run for at least two days, perhaps three.
--- Graham



On Mon, Jul 20, 2015 at 11:34 AM, William Hermans yyrk...@gmail.com wrote:



 *William/Wulfman: So far, running on USB Power module (no USB
 communications) the BBB is staying up. It has been 18 hours or so now.
 Running the same software that rebooted twice in 24 hours on +5V barrel
 connector input.  I have seen the 'bad' configuration run as long as 36
 hours between reboots, so the test needs to continue for at least two days.*


 *Thanks to Maxim for the explanation.  If that is the problem, it looks
 like the problem existed in 2013, a software patch was applied, and the
 software patch was lost between kernel 3 and kernel 4.*
 *--- Graham*


 Glad to hear that so far everything seems good Graham. So far. However I
 have a sneaking suspicion it will continue to run until you decide to shut
 it off. Not 100% sure though, hence the need for someone like you to test.
 In hopes of narrowing down this problem.

 On Mon, Jul 20, 2015 at 9:10 AM, evilwulfie evilwul...@gmail.com wrote:

  usb0_vbus on the processor is an analog input to a comparator.
 page 80 of the processor ref manual says - USB0_VBUS (7) Supply voltage
 for USB VBUS comparator input
 i do not see it saying supplies any voltage to the circuit anywhere in
 the PDF.
 I can see the software causing the issue if there is some kind of noise
 in the line.
 maybe instead of a hard ground which would cause headaches if one was to
 plug a usb power connector to the BBB
 a pulldown of 10k on the line to keep it low.
 One would need to test this idea out.

 Gerald might have a comment ?



 On 7/20/2015 12:41 AM, Maxim Podbereznyy wrote:

 As far as I remember how the Vbus issue was described in details, hope
 I'm not mistaken:
 Vbus connects to both CPU and PMIC. CPU has a charge-pump circuit to
 detect OTG devices (inject some power and track USB signals for incoming
 events) and it injects 5V periodically into Vbus line. Sometimes PMIC
 detects this 5V on the Vbus input as a good voltage and turns inner power
 switch to Vbus where in fact no 5V with sufficient current. Next power
 failure and immediate reboot occur

 2015-07-20 3:08 GMT+03:00 john dough software...@live.com:



 Sent from my Windows Phone
  --
 From: William Hermans yyrk...@gmail.com
 Sent: 7/19/2015 11:11 AM
 To: beagleboard@googlegroups.com
 Subject: Re: [beagleboard] BBB intermittently rebooting.

   Graham, thats where you're wrong. I've been using all those testing
 kernels EXACT SAME KERNELS you've been having troubles with. Except, I'm
 not having troubles with them. Why ? Becasue I'm powering via USB.

  So if you REALLY want to prove the problem this won't work for *you*
 try powering via USB . . .

 On Sun, Jul 19, 2015 at 7:55 AM, Graham gra...@flex-radio.com wrote:

 Eric:
 You never said what you were trying to do with the BBB, and why you need
 Debian 8.1/kernel 4.x.x.
 As you have seen, it is temporarily broken, but is being worked on. This
 is a test release, and not recommended for active use, unless you like
 adventures, like you are having.

 If you need the capemanager, consider Debian 7.8/kernel 3.8

 If you don't need the capemanager, but need some other benefit of Debian
 8, then use Debian 8.x and kernel 3.14.

 Both of these options are solid, do not reboot by themselves, and don't
 care whether it is powered from the 5V barrel connector or USB.
 --- Graham

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




  --
   LinkedIn - http://www.linkedin.com/in/maximpodbereznyy
  Company - http://www.linkedin.com/company/mentorel
  Facebook - https://www.facebook.com/mentorel.company
   --
 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 

Re: [beagleboard] BBB intermittently rebooting.

[Graham Haddock]

William/Wulfman: So far, running on USB Power module (no USB
communications) the BBB is staying up. It has been 18 hours or so now.
Running the same software that rebooted twice in 24 hours on +5V barrel
connector input.  I have seen the 'bad' configuration run as long as 36
hours between reboots, so the test needs to continue for at least two days.

Thanks to Maxim for the explanation.  If that is the problem, it looks like
the problem existed in 2013, a software patch was applied, and the software
patch was lost between kernel 3 and kernel 4.

--- Graham

==

On Mon, Jul 20, 2015 at 2:41 AM, Maxim Podbereznyy lisar...@gmail.com
wrote:

 As far as I remember how the Vbus issue was described in details, hope I'm
 not mistaken:
 Vbus connects to both CPU and PMIC. CPU has a charge-pump circuit to
 detect OTG devices (inject some power and track USB signals for incoming
 events) and it injects 5V periodically into Vbus line. Sometimes PMIC
 detects this 5V on the Vbus input as a good voltage and turns inner power
 switch to Vbus where in fact no 5V with sufficient current. Next power
 failure and immediate reboot occur

 2015-07-20 3:08 GMT+03:00 john dough software...@live.com:



 Sent from my Windows Phone
  --
 From: William Hermans yyrk...@gmail.com
 Sent: 7/19/2015 11:11 AM
 To: beagleboard@googlegroups.com
 Subject: Re: [beagleboard] BBB intermittently rebooting.

   Graham, thats where you're wrong. I've been using all those testing
 kernels EXACT SAME KERNELS you've been having troubles with. Except, I'm
 not having troubles with them. Why ? Becasue I'm powering via USB.

  So if you REALLY want to prove the problem this won't work for *you* try
 powering via USB . . .

 On Sun, Jul 19, 2015 at 7:55 AM, Graham gra...@flex-radio.com wrote:

 Eric:
 You never said what you were trying to do with the BBB, and why you need
 Debian 8.1/kernel 4.x.x.
 As you have seen, it is temporarily broken, but is being worked on. This
 is a test release, and not recommended for active use, unless you like
 adventures, like you are having.

 If you need the capemanager, consider Debian 7.8/kernel 3.8

 If you don't need the capemanager, but need some other benefit of Debian
 8, then use Debian 8.x and kernel 3.14.

 Both of these options are solid, do not reboot by themselves, and don't
 care whether it is powered from the 5V barrel connector or USB.
 --- Graham

 ==

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

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




 --
 LinkedIn - http://www.linkedin.com/in/maximpodbereznyy
 Company - http://www.linkedin.com/company/mentorel
 Facebook - https://www.facebook.com/mentorel.company

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to a topic in the
 Google Groups BeagleBoard group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/beagleboard/2yOpE3XYJ1Y/unsubscribe.
 To unsubscribe from this group and all its topics, 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] BBB intermittently rebooting.

[Graham Haddock]

Yes, I will go run the USB-Power test.

I guess my question is... are you are powering your BBB from the USB port
on a computer, or, are you powering your BBB via the USB port from
something like a power supply or cellphone charger, which does not have a
computer and USB driver in it.

If you are powering the BBB from a computer, and that computer has the BBB
driver on it, that allows you to see the BBB's internal web site, etc,
then, even though you are not using it, when you plug it in, the driver
comes up and starts polling the BBB at 1000 times per second, to see what
is going on. A lot is happening at the lower levels of USB that take time
to service on the BBB.

--- Graham

==

On Sun, Jul 19, 2015 at 11:14 AM, William Hermans yyrk...@gmail.com wrote:

 *Or, are you just powering it via the USB connector and not using/engaging
 the USB subsystem in the BBB?*


 Not sure if g_multi or g_ether is setup on this image. In either case, I'm
 only using ethernet. I'll look though. *looks*

 *Looks like the answer is no.*

 *debian@beaglebone:~$ lsmod*
 *Module  Size  Used by*
 *snd_soc_evm 5854  0*
 *omap_rng5140  0*
 *rng_core8755  1 omap_rng*
 *snd_soc_davinci_mcasp18528  2*
 *snd_soc_edma1166  1 snd_soc_davinci_mcasp*
 *snd_soc_hdmi_codec  2514  1*
 *uio_pdrv_genirq 3657  0*
 *uio 9930  1 uio_pdrv_genirq*


 Anyway, I can understand that you may not want to use USB to power the
 device. However as a test to see if vbus / vusb is floating . . . this can
 not really hurt to power via USB for a little while during tests.

 Once it is established that this problem is related or not, then you and
 others can act accordingly. Grounding the necessary lines, or not.

 This really makes sense to me though, at least from my own perspective.
 Since I'm not having the problems you all are having with the same kernels.
 Passed that, if it does not pan out. Well, a little wasted time, but well
 worth the effort considering this problem seems to plague several people.
 Easy enough to test anyway . . .

 On Sun, Jul 19, 2015 at 9:00 AM, Graham Haddock gra...@flexradio.com
 wrote:

 My advice to Erik is that, if he has something important to do, to go
 back to an official release.  He should use a Beta release only if he can
 afford the additional problems it might bring, and in this case there are
 some.  In my application for the BBB, I do not use or want to use the USB
 connector. The previous kernels worked fine with the +5V power.  Although
 the +5V versus USB power behavior could be an important clue to what the
 problem is.

 ==

 When you say powered by USB are you also running the USB g_multi
 interface to a PC and engaging the driver in the PC?

 Or, are you just powering it via the USB connector and not using/engaging
 the USB subsystem in the BBB?

 I think there are (at least) two variables here.

 I will go power my BBB via the USB connector, which will power the Vusb
 line, but without any USB activity on the USB connector and see what
 happens.

 I agree that systemd is not the likely problem, since kernel 3.14 uses
 systemd, and works fine, USB or +5V connector.

 My personal observation is that the less the BBB is doing, the more
 likely the self-reboot is to happen.
 If I turn off the four blinking blue LEDs, with the BBB not doing
 anything else, the reboots seem to happen more often.
 So, if you are powering the USB connector from a computer, it may be the
 USB activity, not the power source that is changing the behavior.

 --- Graham

 ==



 On Sun, Jul 19, 2015 at 10:11 AM, William Hermans yyrk...@gmail.com
 wrote:

 Graham, thats where you're wrong. I've been using all those testing
 kernels EXACT SAME KERNELS you've been having troubles with. Except, I'm
 not having troubles with them. Why ? Becasue I'm powering via USB.

 So if you REALLY want to prove the problem this won't work for *you* try
 powering via USB . . .

 On Sun, Jul 19, 2015 at 7:55 AM, Graham gra...@flex-radio.com wrote:

 Eric:
 You never said what you were trying to do with the BBB, and why you
 need Debian 8.1/kernel 4.x.x.
 As you have seen, it is temporarily broken, but is being worked on.
 This is a test release, and not recommended for active use, unless you
 like adventures, like you are having.

 If you need the capemanager, consider Debian 7.8/kernel 3.8

 If you don't need the capemanager, but need some other benefit of
 Debian 8, then use Debian 8.x and kernel 3.14.

 Both of these options are solid, do not reboot by themselves, and don't
 care whether it is powered from the 5V barrel connector or USB.
 --- Graham

 ==

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

Re: [beagleboard] Re: Debian 8.1 / kernel 4.1.x test releases are unstable

[Graham Haddock]

What version Debian, and which version kernel is your friend running?

On Sat, Jul 18, 2015 at 7:46 PM, evilwulfie evilwul...@gmail.com wrote:

  My friend powers his from USB and all is fine.
 sounds like its related to the Vusb line issue posted here recently



 On 7/18/2015 5:34 PM, Nuno Gonçalves wrote:

 Also on the barrel jack.

  For what is worth I believe the OMAP and PMIC reset reason registers
 should be part of the boot log so future reboot problems can be sorted.

  Nuno

 On Sunday, July 19, 2015 at 1:28:48 AM UTC+1, Graham wrote:

  I power off the 5Volt power connector.
 The only other connection to the unit is Ethernet cable.
  --- Graham

 ==

 On Sat, Jul 18, 2015 at 7:21 PM, evilwulfie evilw...@gmail.com wrote:

  powered how


 On 7/18/2015 5:14 PM, Graham wrote:

 For what it is worth...

 I loaded the console version
 bone-debian-8.1-console-armhf-2015-07-12-2gb.img onto a uSD card.
 Then booted and installed linux-image-4.1.2-ti-r4

 Then rebooted, and let it run doing nothing else.
 It autonomously rebooted after seven hours.

 --- Graham

 ==
  --
 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.
 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 a topic in the
 Google Groups BeagleBoard group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/beagleboard/lF1X1XINjDo/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 beagleboard...@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.


  --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to a topic in the
 Google Groups BeagleBoard group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/beagleboard/lF1X1XINjDo/unsubscribe.
 To unsubscribe from this group and all its topics, 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: Debian 8.1 / kernel 4.1.x test releases are unstable

[Graham Haddock]

I power off the 5Volt power connector.
The only other connection to the unit is Ethernet cable.
--- Graham

==

On Sat, Jul 18, 2015 at 7:21 PM, evilwulfie evilwul...@gmail.com wrote:

  powered how


 On 7/18/2015 5:14 PM, Graham wrote:

 For what it is worth...

 I loaded the console version
 bone-debian-8.1-console-armhf-2015-07-12-2gb.img onto a uSD card.
 Then booted and installed linux-image-4.1.2-ti-r4

 Then rebooted, and let it run doing nothing else.
 It autonomously rebooted after seven hours.

 --- Graham

 ==
  --
 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 a topic in the
 Google Groups BeagleBoard group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/beagleboard/lF1X1XINjDo/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 beagleboard+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
BeagleBoard group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable

[Graham Haddock]

What does cpufreq-set -g performance do?
Sounds like it would lock the BBB at max CPU clock speed, or at least, not
let it go down to the lowest speeds.

I found the generic Debian docs on *cpufreq-set*, but not the BBB specific
instruction set and meanings.

--- Graham


On Mon, Jul 13, 2015 at 8:41 AM, Graham Haddock gra...@flexradio.com
wrote:

 OK.
 I took my Rev.C unit (1c:ba:8c:d9:5e:dd) and loaded
 bone-debian-8.1-lxqt-4gb-armhf-2015-07-05-4gb.img onto a
 16 GB uSD card.  Unit, power supply and card are trusted.

 Absolutely no changes to the image, just install, boot, run. No updates,
 additions or modifications.
 No cape, only connections are 5V power and Ethernet.
 Times are GMT/UTC. I define the boot completion as the time when systemd
 updates the internal time from the network.

 Initial boot completion: Jul 12 19:12:09
 Autonomous reboot:Jul 13 10:54:19

 This time it took 15 hours for the autonomous reboot to occur. I'll let
 this one keep going, and report.

 --- Graham

 ==

 On Mon, Jul 13, 2015 at 12:13 AM, William Hermans yyrk...@gmail.com
 wrote:

 *(3) System bb4f8e still has 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC
 2015 armv7l GNU/Linux: but cpufreq-set -g performance: no more reboot*


 Interesting . . . If memory serves correctly, that was the fix for an
 older kernel. So possibly older code crept into the newer ?

 On Sun, Jul 12, 2015 at 8:35 PM, 'dl4mea' via BeagleBoard 
 beagleboard@googlegroups.com wrote:

 Results from overnight test:

 I used the worst rebooters for some tests:

 (1) System bb1cf1 got installed with 3.19.3-bone4: *no more reboot*
 uptime
  03:23:37 up 14:50,  1 user,  load average: 0.00, 0.01, 0.05

 (2) System bb6c1f: installed with 4.1.1-ti-r2 #1 SMP PREEMPT Wed Jul 8
 17:03:29 UTC 2015 armv7l GNU/Linux: *2 reboots*
 Jul 13 00:55:17 bb6c1f kernel: [0.00] Booting Linux on physical
 CPU 0x0
 Jul 13 01:51:02 bb6c1f kernel: [0.00] Booting Linux on physical
 CPU 0x0

 (3) System bb4f8e still has 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC
 2015 armv7l GNU/Linux: but cpufreq-set -g performance: *no more reboot*
 uptime
  03:29:57 up  9:01,  1 user,  load average: 0.02, 0.06, 0.05

 As I have to leave for the day, I will let all my systems run for at
 least 12h without changes.
 If then still like this, I will do (1) and (3) on some more devices.

 @RobertCNelson: If you have further suggestions which image to test, let
 me know.

 --- Guenter (dl4mea)

 --
 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 a topic in the
 Google Groups BeagleBoard group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/beagleboard/lF1X1XINjDo/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 beagleboard+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.




-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
BeagleBoard group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable

[Graham Haddock]

OK.
I took my Rev.C unit (1c:ba:8c:d9:5e:dd) and loaded
bone-debian-8.1-lxqt-4gb-armhf-2015-07-05-4gb.img onto a
16 GB uSD card.  Unit, power supply and card are trusted.

Absolutely no changes to the image, just install, boot, run. No updates,
additions or modifications.
No cape, only connections are 5V power and Ethernet.
Times are GMT/UTC. I define the boot completion as the time when systemd
updates the internal time from the network.

Initial boot completion: Jul 12 19:12:09
Autonomous reboot:Jul 13 10:54:19

This time it took 15 hours for the autonomous reboot to occur. I'll let
this one keep going, and report.

--- Graham

==

On Mon, Jul 13, 2015 at 12:13 AM, William Hermans yyrk...@gmail.com wrote:

 *(3) System bb4f8e still has 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC
 2015 armv7l GNU/Linux: but cpufreq-set -g performance: no more reboot*


 Interesting . . . If memory serves correctly, that was the fix for an
 older kernel. So possibly older code crept into the newer ?

 On Sun, Jul 12, 2015 at 8:35 PM, 'dl4mea' via BeagleBoard 
 beagleboard@googlegroups.com wrote:

 Results from overnight test:

 I used the worst rebooters for some tests:

 (1) System bb1cf1 got installed with 3.19.3-bone4: *no more reboot*
 uptime
  03:23:37 up 14:50,  1 user,  load average: 0.00, 0.01, 0.05

 (2) System bb6c1f: installed with 4.1.1-ti-r2 #1 SMP PREEMPT Wed Jul 8
 17:03:29 UTC 2015 armv7l GNU/Linux: *2 reboots*
 Jul 13 00:55:17 bb6c1f kernel: [0.00] Booting Linux on physical
 CPU 0x0
 Jul 13 01:51:02 bb6c1f kernel: [0.00] Booting Linux on physical
 CPU 0x0

 (3) System bb4f8e still has 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC
 2015 armv7l GNU/Linux: but cpufreq-set -g performance: *no more reboot*
 uptime
  03:29:57 up  9:01,  1 user,  load average: 0.02, 0.06, 0.05

 As I have to leave for the day, I will let all my systems run for at
 least 12h without changes.
 If then still like this, I will do (1) and (3) on some more devices.

 @RobertCNelson: If you have further suggestions which image to test, let
 me know.

 --- Guenter (dl4mea)

 --
 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 a topic in the
 Google Groups BeagleBoard group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/beagleboard/lF1X1XINjDo/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 beagleboard+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
BeagleBoard group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable

[Graham Haddock]

Hi William:
Doing nothing with the board.  It is just sitting on the side connected to
+5V power and Ethernet.
So, for example, late last night (Central US time) I loaded
bone-debian-8.1-lxqt-4gb-armhf-2015-07-05-4gb.img
onto a trusted uSD card expanded the memory using gparted to the full 16GB,
and turned off the four blue
blinky lights. No other changes.

Then I went to bed.

Reading syslog,
(Times are GMT, boot completion defined as systemd updating the time to
network time.

the initial boot (completion) was at JUL 12, 05:09:27
the lab was quiet, lights off, nothing running.
The BBB automously rebooted at 08:25:33, 13:13:22, and 14:32:27

I am now rerunning with untouched reload of
bone-debian-8.1-lxqt-4gb-armhf-2015-07-05-4gb.img
Just load, install and boot.  Talk to command line by SSH.

--- Graham

==

On Sun, Jul 12, 2015 at 2:22 PM, William Hermans yyrk...@gmail.com wrote:

 Anyway, guys, give me an idea of what you're doing on these boards. When
 you get random system reset, and I'll test here too. I have a couple free
 beaglebones I can run arbitrary tests on at the moment.

 On Sun, Jul 12, 2015 at 12:19 PM, William Hermans yyrk...@gmail.com
 wrote:

 I've had this, or something similar happen to me a few times. When I did
 apt-get update again right after, it succeeded. But I'm still not sure of
 the cause.

 On Sun, Jul 12, 2015 at 11:48 AM, 'dl4mea' via BeagleBoard 
 beagleboard@googlegroups.com wrote:

 If I look on one - but not the target worst case Beaglebone, I see
 only one package matching Robert's suggestion
 apt-cache search linux-image | grep ti | grep 4.1
 linux-image-4.1.1-ti-r2 - Linux kernel, version 4.1.1-ti-r2

 However, if I want to apt-get update on the two current worst case
 targets, I am getting

 Get:10 http://ftp.us.debian.org jessie-updates/non-free armhf Packages
 [20 B]
 Fetched 9247 kB in 20s (457 kB/s)
 W: Failed to fetch
 http://repos.rcn-ee.com/debian/dists/jessie/main/binary-armhf/Packages
 Hash Sum mismatch

 E: Some index files failed to download. They have been ignored, or old
 ones used instead.

 This system has installed
 uname -a
 Linux bb6c1f 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l
 GNU/Linux

 Is this a temporary hickup or any other idea?

  --
 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 a topic in the
 Google Groups BeagleBoard group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/beagleboard/lF1X1XINjDo/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 beagleboard+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
BeagleBoard group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable

[Graham Haddock]

I will try it by reloading a totally untouched
bone-debian-8.1-lxqt-4gb-armhf-2015-07-05-4gb.img,
and report back.  No cape, trusted Rev.C hardware and power supply. All
communications via
Ethernet.



By my saying that 3.14 is rock solid, this includes up to
bone-debian-8.1-lxqt-4gb-armhf-2015-06-15-4gb.img,
which was the last non-kernel-4 test release.

Same hardware, same power supplies, same Ethernet connection. No other
hardware or connections.


--- Graham

==

-- 
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: connecting MS5803-14BA pressure sensor to BBB

[Graham Haddock]

Well, some suggestions and thoughts.

1.) In kernel 3.8, I think I2C Pins P9.19 and P9.20 report as I2C-1, so you
should see the part on that bus.

2.) Make sure you have not swapped the SCL and SDA lines. Make sure that
you are really connected to P9.19 and P9.20.
You should see activity on both lines with an oscilloscope when you are
running an I2C probe.  Make sure that you have
pull-up resistors on each line, so that the lines go high when idle

3.) If you have another I2C part, like an EEPROM memory chip, or an I/O
Expander, wire that onto the bus and see if it works.

4.) Try a later version of Debian with the 4.1 kernel.  2015-06-19 or
2015-06-29.  These have the latest cape manager installed,
and they boot with P9.19 and P9.20 enabled as I2C-2.  Although the
bone_capemgr.x/slots stuff is not present.

5.) The MS5803-14BA has both SPI and I2C interfaces. Have you set the
jumpers so that it is in the I2C mode?

--- Graham

On Wed, Jul 1, 2015 at 1:22 AM, Csangomorfozis simonzsolt0...@gmail.com
wrote:

 Hi Graham :) Yes, I tried. On default I2C-0 and I2C-1. I2C2 was disabled
 by default and i enabled it when the Beaglebone was running with the echo
 BB-I2C1  /sys/devices/bone_capemgr.9/slots command.
 The sensor was connected to the board. And here is another question: if i
 enable the I2C2 bus real time on the board, should it see the sensor or the
 memory map, without restarting the board?


 2015. június 29., hétfő 20:28:34 UTC+3 időpontban Graham a következőt írta:

 Well, on the new Debian releases, P9.19 and P9.20 are mapped to i2c-2.
 Did you look there?

 --- Graham

 ==

 On Monday, June 29, 2015 at 6:15:09 AM UTC-5, Csangomorfozis wrote:

 Hello everyone! :) I tried to connect an MS5803-14BA pressure sensor to
 my Beaglebone Black, and when i test i2c-1 (pins P9_19 and P9_20), the
 sensor's address doesn't appear on the memory map. My hookup is the
 following MS5803-14BA   Beaglebone_Black GND  - P9_1 3.3V
  - P9_3 SDA  - P9_20 SCL   - P9_19 I am
 using the latest Debian image on the BBB with the kernel version 3.8.13 My
 question is: Did i something wrong on the hookup or on the Beaglebone do i
 need to configure something to make the i2c probing correctly?
 Theoretically if i connected the sensor properly, then i should see its
 address on the Beaglebone. Can give me somebody an advice? Thanks :)

  --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to a topic in the
 Google Groups BeagleBoard group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/beagleboard/zlxn63mVCbQ/unsubscribe.
 To unsubscribe from this group and all its topics, 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: i2c question (BBB)

[Graham Haddock]

The signal on the bus is the same.
Just the name is different.
So to talk to the part using Linux, use the address in 7-bit format,
which for your part is 0x21.

If you are writing in C, you will use i2c-dev and ioctl

If you are writing in Python 2.7, you will use SMbus and something like the
Adafruit Python I2C BBB-IO

Best regards,
--- Graham

==


On Thu, Jun 25, 2015 at 1:27 AM, 멘지 hyungon1...@gmail.com wrote:

 thank you for your answer

 When the '1' shift is not this lead?

 Then how to i write register in Ov7670  ??

 I must register modification in OV7670

 I wonder how to I2C write .


 *Please understand the lack of  my English skills. ^^ 

 thanks



 2015년 6월 25일 목요일 오전 2시 18분 37초 UTC+9, Graham 님의 말:

 There is an 8 bit representation of an I2C address, where the bottom
 bit is actually the Read/Write bit and is, by convention, set to zero to
 describe the address.

 There is a 7-bit representation of an I2C address, where the address is
 shifted one bit to the right, so the read/write bit disappears and is not
 part of the address.
 Half the manufacturers do it one way, the other half the other way.

 Linux/Debian uses the 7 bit representation.

 0x42  1 = 0x21

 --- Graham

 ==

 On Wednesday, June 24, 2015 at 3:13:48 AM UTC-5, 멘지 wrote:


 I'm trying i2c bus on BBB

 slave module is OV7670 ( CMOS Camera )

 OS is angstrom



 https://lh3.googleusercontent.com/-zT9VFvtWOmo/VYpkZj8P2MI/FDw/Abor6TYsMrg/s1600/dd.png


 when i connect ov7670 on BBB  P9 Header (19,20)

 and command i2cdetect -r -y 1

 look at the picture above you fine '21' is creating

 0x21 is slave address 

 but slave address of ov7670 is 0x42 in datasheet

 what means 0x21 ??

 and

 am i better try i2c ???



 My purpose is writing data to the ov7670 register.


 Advice please

  --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to a topic in the
 Google Groups BeagleBoard group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/beagleboard/c0M35cLIS4Q/unsubscribe.
 To unsubscribe from this group and all its topics, 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: Beagle Bone Black power LED blinks once when powered

[Graham Haddock]

I thought that it would work on USB, and not on external power supply.
If the situation is that you get the one blink and no boot, is the same for
both USB power and external power, then there is a hard failure of the
Beaglebone. Either a damaged power supply chip, or a short circuit
downstream from there.

--- Graham

On Fri, Jun 19, 2015 at 11:18 AM, Vinicius Maciel vinicius...@gmail.com
wrote:

 Hi,

 I do not think the problem is the power sypply. I was using the same power
 supply before the problem occurred, power supply is functioning normally, I
 use it to charge my cell phone!

 In this video, https://youtu.be/qojeLqazkK8, I tested two power
 supplies. The same that I have used to power up through USB connector and a
 common DC power supply. Nothing else works :(

 2015-06-19 11:21 GMT-03:00 Graham gra...@flex-radio.com:

 If the BBB will run from USB power, then the BBB is probably OK.

 Put an oscilloscope on the output of the power supply that is causing the
 problem, and watch what the voltage does when you turn things on.

 I had a bench power supply (BW 1550) that when set to 5 Volts, then the
 output turned on, would throw a transient up to 6 Volts then return to 5
 Volts. (The bigger the capacitor across the load, the greater the
 transient.) This would trip the over-voltage detect in the BBB power
 supply, which would blink the power LED once, then off after that.

 So, make sure the power supply is working properly.  Some of the cheap
 power supplies out there will NOT run a BBB.

 --- Graham

 ==

 On Thursday, June 18, 2015 at 7:27:54 PM UTC-5, Gerald wrote:

 Sounds like an overvoltage condition on the 5V DC input may have damaged
 the DC input. Usually from a cheap 5V power supply. If the USB power works,
 then the rest of the board is OK.

 Gerald


 On Thu, Jun 18, 2015 at 11:17 AM, vinic...@gmail.com wrote:

 Hi, my Beaglebone Black have the same behavior, gives a short blink at
 the power LED when powered.
 But, I turned on via usb connector with power supply 5V@1A. What may
 have happened?


 Em sexta-feira, 16 de agosto de 2013 13:44:09 UTC-3, magu_ escreveu:

 Hi

 I powered the BBB over the DGND - VDD_5V. But by accident I plugged it
 into PWR_BUT.

 Now it only gives a short blink at the power LED when powered. I know
 this is a bad sign... But does anybody of you know if this does not mean
 the end of it and if it can be somehow reset?

 yours
 magu_

  --
 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.
 For more options, visit https://groups.google.com/d/optout.




 --
 Gerald

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

  --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to a topic in the
 Google Groups BeagleBoard group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/beagleboard/ilf5jOwbgFE/unsubscribe.
 To unsubscribe from this group and all its topics, 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 a topic in the
 Google Groups BeagleBoard group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/beagleboard/ilf5jOwbgFE/unsubscribe.
 To unsubscribe from this group and all its topics, 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] Boot Freezes with a single P8-P9 connection; reproduced on two boards

[Graham Haddock]

BeagleBone Black SRM Version C.1

Section 6.7  Boot Configuration Design, Page 67.

See Page 68, Figure 38.

Yes, DNI means Do Not Insert.
Or some time the term NP , meaning No Pop or do not populate is used.

Section 6.8  Default Boot Options, Page 68.

It is covered again on page 106, Section 8.3 Pin Usage Considerations.

--- Graham

==


On Fri, Apr 24, 2015 at 1:04 PM, Bit Pusher ken.w.mar...@gmail.com wrote:

 I totally understand their are many compromises in designs; I just wish
 there was documentation; in this case, I find it sadly inadequate. Finally,
 the input is another GPIO header pin that has a reset defaultof input with
 a pull down which I believe is about 23K  (it took me 2 hours to find
 documentation on reset defaults - one statement in a very large TRM table
 describing registers stating to look at data sheets, about 1 hour to find
 and understand in data sheet where the mux reset defaults are given) . If
 the pull-up and pull-down resistors on the board had been chose to be
 something like 4.7K this error would not have happened, and I don't believe
 this would have any impact on power except maybe 0.7mA additional current
 just during the time the boot button is pushed at power up, which is
 insignificant.

 On Thursday, April 23, 2015 at 11:28:53 PM UTC-4, Graham wrote:

 Kenneth:

 There are fifteen lines, and a field of 100 K Ohm resistors that tell the
 Sitara how to boot.
 There are locations for a pull up and a pull down on each of the boot
 instruction lines.
 Only one of those resistors is populated for each line. Read the SRM.

 Any load that would cause a logic state established by a 100K resistor,
 pull up or pull down, to change logic state, will modify, and likely kill
 the boot process.

 If your input was a CMOS gate, it would probably have worked.
 If your input was one of those Panasonic driver transistors with the
 built-in resistors to ground, you are changing the boot instructions by
 attaching it.

 --- Graham

 ==


 On Thursday, April 23, 2015 at 9:23:08 PM UTC-5, Kenneth Martin wrote:

  If they cause the BBB to not boot, by hooking an input to them, I would
 argue they should never have been brought out to the header, and that
 examples of how to handle this sensitivity while still making use of the
 header pins should be more readily available. The documentation on this
 sensitivity appears to be a single poorly written paragraph in the SRM
 which only states they should not be driven (actually 3 lines only in
 section 7.12.1 following Fig 58; to be specific: *If you plan to use
 any of these signals, then on power up, these pins should not be driven. 
 **If
 you do, it can affect the boot mode of the processor and could keep the
 processor from **booting or working correctly*. I can't see this
 addressed anywhere else in the documentation). It should state that not
 even inputs can not be connected to these header pins. There is no
 documentation that I can see on why they were even brought out to the
 header. Issues like this make other alternatives to using the BBB's look
 more attractive (such as the new PI). At a minimum, this will cost us
 another 4 lost weeks and $2K for new populated boards for another iteration
 on our cape. Very frustrating, and I would argue both poor design and poor
 documentation. Looking at the schematic, it appears the existing load on
 each pin is 2 100K resistors? If this is correct, I would not call this
 well loaded when a typical gpio output current is 4-6mA.

 On 15-04-23 02:08 PM, Gerald Coley wrote:

 ANY load can affect how they are read. These pins are already well
 loaded as it is. If you want to use them, use a buffer to isolate them
 until after the processor is running.

  Gerald


 On Thu, Apr 23, 2015 at 12:20 PM, Bit Pusher ken.w@gmail.com
 wrote:

 This is not clear as they are connected to other inputs which I would
 normally think means they are not being driven. Is there a definition you
 can give a link to defining what driven is? Also, can you supply a link of
 how to control and what are the mux defaults before boot? Thank you.


 On Thursday, April 23, 2015 at 12:29:26 PM UTC-4, Wulf Man wrote:

   you are messing with the boot pins. its been stated here 100s of
 times you cannot do anything to these pins before board boots.
 check the BBB schematic and the using the bbb board guide.,


 On 4/23/2015 9:09 AM, Bit Pusher wrote:

  I have found a reproducible boot freeze (on two boards); could
 someone else possibly check; it's very easy to try.
 No connections besides power plug and one (or two) wires from header
 P8 to P9
 Scenario 1: connect P8-43 to P9-30, plug in power, only power light
 comes on and BBB does not boot up
  Scenario 2: connect P8-44 to P9-28, plug in power, only power light
 comes on and BBB does not boot up
 Scenario 3: connect both P8-43 to P9-30 and P8-44 to P9-28, plug in
 power, power light and all 4 LEDs come on steady and BBB does not boot up.

  Discussion:
 1) doing 

Re: [beagleboard] Re: Newbie questions on general complier usage with BBB

[Graham Haddock]

Rodney:

I highly recommend this book.  The answers to all your questions with
examples are either
answered in this book, or Derek Molloy's website.

Exploring BeagleBone: Tools and Techniques for Building with Embedded Linux
Paperback - December 31, 2014
by Derek Molloy (Author)

ISBN-13: 978-1118935125  ISBN-10: 1118935128

http://www.amazon.com/Exploring-BeagleBone-Techniques-Building-Embedded/dp/1118935128/ref=sr_1_1

--- Graham

==


On Tue, Apr 21, 2015 at 5:50 PM, William Hermans yyrk...@gmail.com wrote:

 By the way, if you're looking for speed. You're probably wanting to use C.
 As a Programming language.

 On Tue, Apr 21, 2015 at 3:30 PM, William Hermans yyrk...@gmail.com
 wrote:

 *How do you load an image on a blank BBB?*


 There are no blank BBB's shipped that I'm aware of. However . . .

 a) a boot medium is needed that recognizes the hardware. Usually
 requiring an sdcard. I've also heard of loading serially, but have not
 looked into it at all. Aside from reading a bit on it in the TRM a couple
 years ago.

 b) A functional Linux image is needed for the standard tools needed to
 move files / directories where they need to be.

 c) A bit of time to carry out a) and b)


 *Are there stand alone compliers, where you can developed a program that
 will run natively on the Debian OS?  Not an interpreted version of the
 program, but an actual complied to machine code language, one that can
 handle the hardware specific to the BBB?*


 Yes, however, you would probably be best served by using a cross
 compiler. The GCC toolchain works in either case, and can be used with
 Eclipse, and code::blocks at minimum. Hell you can even use Visual Studio(
 cross compiling ) using make files - If you're a glutton for punishment.

 *Can a complier handle tasks with functions like button de-bounce, or
 more complex functions like capture with the eCAP?*


 Compiler ? No. As a function of any programming language / skilled
 programmer ? Yes. I've seen de-bounce code written in a single line using a
 ternary operator. Typically though de-bouncing  is best done using
 electronic components. At an added cost of course. . .  So best is purely
 subjective. Each way has it's attractions.

 *Is the Code Composer Studio (CCS) what we need to be looking at?
 http://www.ti.com/tool/ccstudio-sitara
 http://www.ti.com/tool/ccstudio-sitara Will this work on the BBB?*


  As an embedded device developer, you should never stop looking into your
 options - Ever. The age  old stagnation argument . . . With that said, yes
 you can use CCS, and you can also use free ( as in beer ) open source
 tools such as GCC. Me personally, I use GCC for a few reasons, but if you
 like all the bells and whistles that CCS offers perhaps that may serve you
 better ? Only you can answer that questions.

 On Tue, Apr 21, 2015 at 11:38 AM, Graham gra...@flex-radio.com wrote:

 Rodney:

 A.) This is not your grandfather's PIC.

 B.) The BBB is intended/supported for a Linux environment.  You really
 need to understand Linux, specifically embedded Linux to be successful.

 C.) Yes, you can write code, C or Assembler, down on the metal, but then
 you are re-inventing and re-writing everything, which is missing the whole
 point of using Linux.

 D.) If you buy into the Linux thing, then it usually involves using the
 GCC compiler, and an IDE like Eclipse, and all the associated tools, and
 writing programs to run in a Linux environment.

 E.) You can do real time like things on the BBB, but the Linux supplied
 is not a Real Time OS.  RT variants are available.  Or, a lightly loaded
 Linux will probably do just fine.

 F.) Yes, you can write things like button de-bouncers.

 --- Graham

 ==

 --
 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 a topic in the
 Google Groups BeagleBoard group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/beagleboard/2RmPQ1AwhP4/unsubscribe.
 To unsubscribe from this group and all its topics, 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: Beaglebone black not booting when circuitry connected

[Graham Haddock]

You don't have to short anything out for what he is describing to happen.

The BBB-Sitara uses a field of 100K resistors, which are either pull-ups or
pull-downs
on 15 different lines, pinned out from P8-31 through P8-46, which instructs
it how to boot.

Any load on any of these pins, of lower than several hundred thousand Ohms,
can derail the boot process.

You can only load those pins after the Sitara has completed booting.

BBB System Reference Manual, Version C1, page 106.

--- Graham

==



On Tue, Apr 7, 2015 at 1:26 PM, smith.winston@gmail.com wrote:


 On Monday, April 6, 2015 at 2:32:55 PM UTC-4, star...@gmail.com wrote:

 Hello there, I have been working on a robotics project using the
 beaglebone black and have just run into some difficulty.

 I am using a protocape for holding all of my circuitry to various
 sensors. While the protoboard is connected, the board turns on but does not
 boot. When I disconnect the protocape, my board turns on and boots
 normally. This happened in between runs with no changes made.


 Sounds to me like you're shorting something on your protocape.  Check your
 pin usage, particularly the power/gnd pins.  Also look for shorts on the
 protoboard (again, pwr/gnd lines), I know it's easy to make mistakes on the
 protoboards.

  --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to a topic in the
 Google Groups BeagleBoard group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/beagleboard/aTIZkGGlNdI/unsubscribe.
 To unsubscribe from this group and all its topics, 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: Having to manually start Wifi

[Graham Haddock]

Brian:

Thanks for the pointers.
I will go read up on it.

Thanks,
--- Graham

==

On Fri, Mar 27, 2015 at 7:06 PM, Brian Anderson b...@nwlink.com wrote:

 Since you are using Jessie images, have you tried using ConnMan to manage
 the WiFi connection rather than resorting to all of this systemd and
 ifup/ifdown stuff?

 You can configure ConnMan using the connmanctl command line utility, or
 via the cmst GUI utility. to setup your link (ssid, credentials).  Or,
 you can create a config file and put it in
 /var/lib/connman/my_config.config.  There is documentation in the ConnMan
 source tree on this format.  I've also attached a template for reference.
 You might also consider adding '/etc/connman/main.conf' and specify
 PreferredTechnologies in the order that you want.  Again, there is
 documentation in the ConnMan source tree on this file, and also the Google
 will help.

 Note that if you use this method, you should NOT do any wifi configuration
 in /etc/network/interfaces as ConnMan will override these.  If you would
 rather use /etc/network/interfaces, then be careful that you don't also
 have conflicting configuration setup with ConnMan, as ConnMan will override
 configuration in /etc/network/interfaces.

 I use the ConnMan method all the time for my work and have no problem
 getting a WiFi connection after boot using my TP-Link TL-WN-722N (uses an
 Atheros chipset), Jessie snapshot images, and 3.19.x kernels.

 ba

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to a topic in the
 Google Groups BeagleBoard group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/beagleboard/rRHUR8mltmg/unsubscribe.
 To unsubscribe from this group and all its topics, 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: Having to manually start Wifi

[Graham Haddock]

To get a reliable start of the WiFi service with jessie, I did the
following:

1.) do NOT uncomment the wireless enable/start lines in
/etc/network/interfaces.
This would try to start up the WiFi before USB is up and running and stable.
Apparently, once wpa_supplicant gets the error, it will not try again.

2.) I wrote a file named wlan0-start.timer, that waits 30 seconds after the
start of boot, which
ends up being about 5 seconds after the end of booting.

3.) I wrote a file named wlan0-start.service that calls a script named
wlan0-start.sh
This service is started when the .timer of the same file name is satisfied.

4.) I wrote a script named wlan0-start.sh that simply calls  'ifup wlan0'

So, it appears that the normal .service dependency
'WantedBy=multi-user.target'
does not wait long enough for the USB subsystem to be fully running.

If you try to start wpa_supplicant without the USB subsystem running,
it fails, hangs, and will not respond to later attempts to re-start.

If you can find the right dependency for wlan0-service, you might come up
with a simpler solution.

I gave up looking, and just wait 30 seconds (which is after the start of
boot, not
the end of boot) which gives USB subsystem time to come up, and then
start the Wifi sub-system, and everything works.

This is not the optimum solution, but it does work.

--- Graham

==


On Thu, Mar 26, 2015 at 8:15 AM, Upol Ryskulova upol.ryskul...@gmail.com
wrote:

 Hello Graham,
 I have problem in getting stable wireless connection on BBB. I asked this
 quiestion
 https://groups.google.com/forum/#!searchin/beagleboard/Beaglebone$20black$20$3A$20Using$20Systemd$20service$20to$20make$20wireless$20stable$20is$20not$20working$20as$20expected/beagleboard/nlerqNauuGw/ursY7OfJAJ4J
 yesterday, but then saw your answer here. Tried to force systemd service to
 start running after 30 sec as you said. And edited my service like this
 [Unit]
 Description=Ifup wlan automatically

 [Service]
 Type=oneshot
 RemainAfterExit=true
 TimeoutStartSec=30s
 ExecStart=/usr/testifup/ifupscript.sh

 [Install]
 WantedBy=multi-user.target


 https://lh3.googleusercontent.com/-NlkQynwTmzQ/VRQEDuVMDOI/AAo/xJDinli1SHI/s1600/timePlot.jpeg


 To be sure that this new service started runnning after the 30sec I did
 systemd plot. As you see ifupwlan.service is not waiting for 30 sec. To
 achieve this result I also have tried systemd.timer but no use. I will be
 very glad for your advice.
 Thanks in advance.
 Regards,
 Upol

 четверг, 19 марта 2015 г., 23:28:23 UTC+2 пользователь Graham написал:

 It is a boot order problem.
 I reported it a month ago, or so.

 Debian is trying to start WiFi before the USB interface is fully up,
 therefore it fails.

 If you wait until after the USB interface is fully up and running, you
 can manually start the WiFi.

 Or, write a systemd service to start it automatically.  I found waiting
 until 30 seconds after
 the start of boot worked fine, to have systemd start WiFi successfully.

 --- Graham

 ==

 On Thursday, March 19, 2015 at 11:06:22 AM UTC-5, Nathaniel Johnson wrote:


 I have been trying to get wifi to work on the latest debian image.  It
 does work but requires me to manually start it after logging in. If I log
 in and type 'ifup wlan0' It works fine.  Even putting 'ifup wlan0' in
 /etc/rc.local does not work.

 Here is a link to my etc/network/interfaces http://pastebin.com/37AjV6tG

 I also noticed this repeating over and over in /var/log/wicd/

 2015/03/01 22:03:16 :: Autoconnecting...
 2015/03/01 22:03:16 :: No wired connection present, attempting to
 autoconnect to wireless network
 2015/03/01 22:03:18 :: Unable to autoconnect, you'll have to manually
 connect


 The full file http://pastebin.com/8sznu2bB

 Any help would be appreciated.

  --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to a topic in the
 Google Groups BeagleBoard group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/beagleboard/rRHUR8mltmg/unsubscribe.
 To unsubscribe from this group and all its topics, 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: Having to manually start Wifi

[Graham Haddock]

I have not tried it. No time, yet. It seems like a much simpler solution
than mine.

What I intend to do is look in the .service file called by Frederik's
solution, and
see what that uses for dependencies they used for starting the service.

Thanks,
--- Graham

==

On Thu, Mar 26, 2015 at 11:56 AM, Nathaniel Johnson 
gruyere.emmenta...@gmail.com wrote:

 Graham, did you try Fredrik's solution?  It works fine for me though left
 the auto wlan0 line in the interfaces file.

 -Nathaniel

 On Thu, Mar 26, 2015 at 11:54 AM, Graham Haddock gra...@flexradio.com
 wrote:

 To get a reliable start of the WiFi service with jessie, I did the
 following:

 1.) do NOT uncomment the wireless enable/start lines in
 /etc/network/interfaces.
 This would try to start up the WiFi before USB is up and running and
 stable.
 Apparently, once wpa_supplicant gets the error, it will not try again.

 2.) I wrote a file named wlan0-start.timer, that waits 30 seconds after
 the start of boot, which
 ends up being about 5 seconds after the end of booting.

 3.) I wrote a file named wlan0-start.service that calls a script named
 wlan0-start.sh
 This service is started when the .timer of the same file name is
 satisfied.

 4.) I wrote a script named wlan0-start.sh that simply calls  'ifup wlan0'

 So, it appears that the normal .service dependency
 'WantedBy=multi-user.target'
 does not wait long enough for the USB subsystem to be fully running.

 If you try to start wpa_supplicant without the USB subsystem running,
 it fails, hangs, and will not respond to later attempts to re-start.

 If you can find the right dependency for wlan0-service, you might come up
 with a simpler solution.

 I gave up looking, and just wait 30 seconds (which is after the start of
 boot, not
 the end of boot) which gives USB subsystem time to come up, and then
 start the Wifi sub-system, and everything works.

 This is not the optimum solution, but it does work.

 --- Graham

 ==


 On Thu, Mar 26, 2015 at 8:15 AM, Upol Ryskulova upol.ryskul...@gmail.com
  wrote:

 Hello Graham,
 I have problem in getting stable wireless connection on BBB. I asked this
 quiestion
 https://groups.google.com/forum/#!searchin/beagleboard/Beaglebone$20black$20$3A$20Using$20Systemd$20service$20to$20make$20wireless$20stable$20is$20not$20working$20as$20expected/beagleboard/nlerqNauuGw/ursY7OfJAJ4J
 yesterday, but then saw your answer here. Tried to force systemd service to
 start running after 30 sec as you said. And edited my service like this
 [Unit]
 Description=Ifup wlan automatically

 [Service]
 Type=oneshot
 RemainAfterExit=true
 TimeoutStartSec=30s
 ExecStart=/usr/testifup/ifupscript.sh

 [Install]
 WantedBy=multi-user.target


 https://lh3.googleusercontent.com/-NlkQynwTmzQ/VRQEDuVMDOI/AAo/xJDinli1SHI/s1600/timePlot.jpeg


 To be sure that this new service started runnning after the 30sec I did
 systemd plot. As you see ifupwlan.service is not waiting for 30 sec. To
 achieve this result I also have tried systemd.timer but no use. I will be
 very glad for your advice.
 Thanks in advance.
 Regards,
 Upol

 четверг, 19 марта 2015 г., 23:28:23 UTC+2 пользователь Graham написал:

 It is a boot order problem.
 I reported it a month ago, or so.

 Debian is trying to start WiFi before the USB interface is fully up,
 therefore it fails.

 If you wait until after the USB interface is fully up and running, you
 can manually start the WiFi.

 Or, write a systemd service to start it automatically.  I found waiting
 until 30 seconds after
 the start of boot worked fine, to have systemd start WiFi successfully.

 --- Graham

 ==

 On Thursday, March 19, 2015 at 11:06:22 AM UTC-5, Nathaniel Johnson
 wrote:


 I have been trying to get wifi to work on the latest debian image.  It
 does work but requires me to manually start it after logging in. If I log
 in and type 'ifup wlan0' It works fine.  Even putting 'ifup wlan0' in
 /etc/rc.local does not work.

 Here is a link to my etc/network/interfaces http://
 pastebin.com/37AjV6tG

 I also noticed this repeating over and over in /var/log/wicd/

 2015/03/01 22:03:16 :: Autoconnecting...
 2015/03/01 22:03:16 :: No wired connection present, attempting to
 autoconnect to wireless network
 2015/03/01 22:03:18 :: Unable to autoconnect, you'll have to manually
 connect


 The full file http://pastebin.com/8sznu2bB

 Any help would be appreciated.

  --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to a topic in the
 Google Groups BeagleBoard group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/beagleboard/rRHUR8mltmg/unsubscribe.
 To unsubscribe from this group and all its topics, 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 a topic in the
 Google

Re: [beagleboard] Chipsee 7 inch display

[Graham Haddock]

Robert:
Thank you.
--- Graham

==

On Sun, Mar 22, 2015 at 12:35 PM, Robert Nelson robertcnel...@gmail.com
wrote:

 http://elinux.org/Beagleboard:Capes_3.8_to_3.14#Chipsee_bbb-exp-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.
For more options, visit https://groups.google.com/d/optout.