[beagleboard] Re: PinMuxing P9_21 and P9_23 to I2C2?

2016-03-22 Thread Graham
If you understand device trees, you should be able to turn off I2C2 on 
p9-19 and P9-20 and enable on P9-21 and P9-22 (as Mode 4).  I doubt that 
you can route the I2C2 out to two separate pin-outs at the same time.

If you don't understand how to make all of that work, then I would put some 
very short jumper wires from P9-19 to the next pin, which is P9-21 and 
another short jumper from P9-20 to P9-22. I2C2 is enabled and live by 
default on Pins P9-19 and -20 on the current 8.3 releases.  If you don't 
know how to turn off P9-21 and P9-22 for the jumper solution, cut the 
connector pins off going from the cape to the main BBB board.  Spend the 
rest of the time between now and the 31st finishing the rest of the 
project.  You probably have other problems that you don't even know you 
have, yet.

--- Graham

==

On Tuesday, March 22, 2016 at 10:05:59 AM UTC-5, Christopher Earley wrote:
>
>
> As stated in the topic's subject, I am currently trying to expose I2C2 
> (The I2C bus that's normally connected to P9_19, P9_20) to pins P9_21 and 
> P9_22. Since the documentation for the Beaglebone Black/Green show that 
> pins 21 and 22 can be used for I2C2 it must be possible, I just can't find 
> a solid way to do it.
>
> *Background Info*
>
> Hardware: Seeed BeagleBone Green
> OS: debian
> uname -a: Linux beaglebone 3.8.13-bone71.1 #1 SMP Wed May 20 20:13:27 PDT 
> 2015 armv7l GNU/Linux
> (Note that I am willing to flash whatever OS/kernel version it takes to 
> get this working)
>
> The requirement comes from an error I made not knowing about the default 
> I2C device tree settings for the device. Since there were two pairs of I2C2 
> pins listed in the documentation, I chose the pair that lad less overlap, 
> which was a mistake. I have since then fixed the error in my 
> schematic/board but I already have demo PCBs on the way from the fabhouse. 
> It'd be great to just expose those pins to the I2C bus rather than cut and 
> rewire traces manually. Sadly due to the time constraints for the project 
> (Deadline is on the 31st) I cannot send out for an updated PCB.
>
> The software side of this project is based on the Adafruit_BBIO library 
> which is, in turn, based on the python smbus library. There's very little 
> in terms of configuration when setting up I2C communication with those 
> libraries so the magic switch is most likely not there.
>
> *Main Methods Attempted*
>
> For all cases, assume that the UART2 device tree overlay has been disabled 
> via blacklisting in uEnv.txt and a reboot.
>
>
>- bonescript pinMode() - Does nothing to the mode of the pin in this 
>case although getPinMode() does show that I2C2_SDA/SCL is a possible mode 
>option.
>
>
>- Enabling an I2C2 device tree overlay from the bb.org-overlays 
>
> 
>  
>repo that I edited to point to P9_21 and P9_22 
> instead of the normal I2C2 pins. This 
>compiles and shows up in the cape manager after inclusion but nothing 
>happens on pins P9_21 and P9_22 when I try to communicate to my PCA9685 
>devboard. Meanwhile pins P9_19, P9_20 work just fine so the bus is still 
>functional.
>
>
>- Tried Bernhard Tittelbach's lovely Device-Tree Overlay Generator 
>
> to
>  
>make a setting file for each pin.
>
>
>- Mucked around with the Universal Cape overlay but it never really 
>seemed to change any pin states in this case.
>
>
> *Summary*
>
> Given any possible (supported) OS, how can I get pins P9_21 and P9_22 into 
> the correct pin mode to mux to the I2C2 device?
> And is it possible to have I2C2 exposed on both P9_19,20 and P9_21,22?
>
> Lastly, I apologize for any confusing nomenclature. I've been flashing 
> different OS versions and reading documentation relevant to differing 
> flavors of debian trying to solve this that I'm a bit number-dizzy.
>
> Thanks for your time!
>

-- 
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] looks like the BeagleBone Black and this community is dead. Cannot even flash 8.3.

2016-03-22 Thread William Hermans
Oh, and by the way, this hardware and community is 100% open source. If
you've got a problem that us supposedly crapper community helpers can help
you with. Go download the schematics, or source code and figure it out for
yourself. Unles of course as I suspect you're not a real engineer, but some
kid who just wants to use his rPI as a settop gimmick for his tv . . .

On Tue, Mar 22, 2016 at 7:36 PM, William Hermans  wrote:

> Yeah well those Rabbit semi boards actually are not bad, its the software
> stack you're forced to use with them that is horrible. Wulf and I built an
> ethernet connected lead acid charge controller using one of these and the
> crappy compiler you're forced to use introduced random bugs that where hard
> to track down. On top of that Rabbit semi community help was terrible.
> Snobs who think because you're a developer that you should instantly know
> everything about embedded hardware. Thus my experiences with the
> "community" which was actually a single person / engineer at rabbit semi
> was a very bad experience.
>
> Then ill tell you what. The rPI is a toy. It does a few small things well.
> But for a true embedded board, in most cases it is garbage. The actual
> physical engineering could even stand to use some work. Such as the surface
> mounted full sized sdcard . . . terrible, terrible design decision. If you
> can not figure out why, then you're not much of an engineer.
>
> On Tue, Mar 22, 2016 at 6:42 PM, John Syne  wrote:
>
>> For someone who has been "working with products like this for 18 years",
>> you would think he would be able to help himself by now. Yet he still
>> thinks he is smarter than the rest of us, advising us to “leave this BBB”.
>> Well, Karl, there are many more smarter people here who think BBB is way
>> better than Raspberry Pi because of the open source hardware design, unlike
>> the proprietary hardware design of the Raspberry Pi. You cannot even by the
>> processor used on the Raspberry Pi. I think you have completely missed the
>> value offered by the BeagleBoard organization. In addition, the BBB
>> includes two PRU processors who have a cycle time of 5ns which is very
>> important for realtime control functions. Cannot do that with the Raspberry
>> Pi. Clearly you have no clue, so your advise has no value here.
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Mar 22, 2016, at 4:42 PM, Karl Easterly 
>> wrote:
>>
>> to be a bit more nice about my grandious statement that the BBB is dead..
>> here is a bit of history.
>>
>> I have been working with products like this for about 18 years. Small
>> form factor boards like the basic stamps and zworld jack rabbits to todays
>> rasp pi's and bbb's and the banana pros and such and such
>>
>> the raspberry has a great community.. and the BBB doesnt. I have had
>> numerous instances where i was using the BBB and found an issue and there
>> are only crickets sounding on google.
>>
>> I am not saying the BBB is a bad board as it is clearly a nice peice of
>> engineering.. i am saying the product BBB will pass into the past while the
>> rasp pi will persist.
>>
>> id advise you leave this BBB behind as it has no value looking toward the
>> future. this ship has sunk.
>>
>> and thats a bummer in many ways.
>> On Mar 22, 2016 7:27 PM, "ChrisB"  wrote:
>>
>>> My experience has been quite different.  Pretty much all the progress
>>> I've made with the BBB was enabled by various forum posts and code
>>> repositories.  And every time I think I have an original question or
>>> observation, a little searching online finds the answer or a similar
>>> developer experience.  It's not easy getting things to work some of the
>>> time, but tenaciousness pays off for the most part.
>>>
>>> Anyway, thanks to everyone who's spent the time to post on forums and
>>> share their code!  Hopefully, I will have something to contribute in the
>>> near future and can start paying you all back.
>>>
>>> Chris Burak
>>>
>>> On Tuesday, March 22, 2016 at 4:58:27 PM UTC-6, Karl Easterly wrote:

 Ya.. I didn't ask for help.. as you noticed :)

 The point is the community for the beagle board is so sparse self help
 is not an option. A sparse community around this type of product equals a
 dead product.

 On Sun, Mar 20, 2016 at 4:32 PM, Robert P. J. Day <
 rpj...@crashcourse.ca> wrote:

> Quoting Robert Nelson :
>
> On Mar 20, 2016 2:28 PM, "Karl Easterly"  wrote:
>>
>
> It's clear that the BBB is a dead product. There is no meaningful
>>>
>> resources for issues, and when the system simply won't 'reset from a
>> new
>> image from their site'... that's the last straw.
>>
>>>
>>> Mine are going in the trash and I will advise anyone everywhere to
>>> do the
>>>
>> same.
>>
>> 'Last straw', I've don't remember you 

Re: [beagleboard] looks like the BeagleBone Black and this community is dead. Cannot even flash 8.3.

2016-03-22 Thread William Hermans
Yeah well those Rabbit semi boards actually are not bad, its the software
stack you're forced to use with them that is horrible. Wulf and I built an
ethernet connected lead acid charge controller using one of these and the
crappy compiler you're forced to use introduced random bugs that where hard
to track down. On top of that Rabbit semi community help was terrible.
Snobs who think because you're a developer that you should instantly know
everything about embedded hardware. Thus my experiences with the
"community" which was actually a single person / engineer at rabbit semi
was a very bad experience.

Then ill tell you what. The rPI is a toy. It does a few small things well.
But for a true embedded board, in most cases it is garbage. The actual
physical engineering could even stand to use some work. Such as the surface
mounted full sized sdcard . . . terrible, terrible design decision. If you
can not figure out why, then you're not much of an engineer.

On Tue, Mar 22, 2016 at 6:42 PM, John Syne  wrote:

> For someone who has been "working with products like this for 18 years",
> you would think he would be able to help himself by now. Yet he still
> thinks he is smarter than the rest of us, advising us to “leave this BBB”.
> Well, Karl, there are many more smarter people here who think BBB is way
> better than Raspberry Pi because of the open source hardware design, unlike
> the proprietary hardware design of the Raspberry Pi. You cannot even by the
> processor used on the Raspberry Pi. I think you have completely missed the
> value offered by the BeagleBoard organization. In addition, the BBB
> includes two PRU processors who have a cycle time of 5ns which is very
> important for realtime control functions. Cannot do that with the Raspberry
> Pi. Clearly you have no clue, so your advise has no value here.
>
> Regards,
> John
>
>
>
>
> On Mar 22, 2016, at 4:42 PM, Karl Easterly 
> wrote:
>
> to be a bit more nice about my grandious statement that the BBB is dead..
> here is a bit of history.
>
> I have been working with products like this for about 18 years. Small form
> factor boards like the basic stamps and zworld jack rabbits to todays rasp
> pi's and bbb's and the banana pros and such and such
>
> the raspberry has a great community.. and the BBB doesnt. I have had
> numerous instances where i was using the BBB and found an issue and there
> are only crickets sounding on google.
>
> I am not saying the BBB is a bad board as it is clearly a nice peice of
> engineering.. i am saying the product BBB will pass into the past while the
> rasp pi will persist.
>
> id advise you leave this BBB behind as it has no value looking toward the
> future. this ship has sunk.
>
> and thats a bummer in many ways.
> On Mar 22, 2016 7:27 PM, "ChrisB"  wrote:
>
>> My experience has been quite different.  Pretty much all the progress
>> I've made with the BBB was enabled by various forum posts and code
>> repositories.  And every time I think I have an original question or
>> observation, a little searching online finds the answer or a similar
>> developer experience.  It's not easy getting things to work some of the
>> time, but tenaciousness pays off for the most part.
>>
>> Anyway, thanks to everyone who's spent the time to post on forums and
>> share their code!  Hopefully, I will have something to contribute in the
>> near future and can start paying you all back.
>>
>> Chris Burak
>>
>> On Tuesday, March 22, 2016 at 4:58:27 PM UTC-6, Karl Easterly wrote:
>>>
>>> Ya.. I didn't ask for help.. as you noticed :)
>>>
>>> The point is the community for the beagle board is so sparse self help
>>> is not an option. A sparse community around this type of product equals a
>>> dead product.
>>>
>>> On Sun, Mar 20, 2016 at 4:32 PM, Robert P. J. Day >> > wrote:
>>>
 Quoting Robert Nelson :

 On Mar 20, 2016 2:28 PM, "Karl Easterly"  wrote:
>

 It's clear that the BBB is a dead product. There is no meaningful
>>
> resources for issues, and when the system simply won't 'reset from a
> new
> image from their site'... that's the last straw.
>
>>
>> Mine are going in the trash and I will advise anyone everywhere to do
>> the
>>
> same.
>
> 'Last straw', I've don't remember you ever posting on here.. If it's
> only
> one and done for you, then there's no reason for me to waste time
> either..
>

   how *dare* everyone not drop what they're doing ***right now*** and
 solve my problem during the first weekend of march madness?

 rday



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

Re: [beagleboard] looks like the BeagleBone Black and this community is dead. Cannot even flash 8.3.

2016-03-22 Thread John Syne
For someone who has been "working with products like this for 18 years", you 
would think he would be able to help himself by now. Yet he still thinks he is 
smarter than the rest of us, advising us to “leave this BBB”. Well, Karl, there 
are many more smarter people here who think BBB is way better than Raspberry Pi 
because of the open source hardware design, unlike the proprietary hardware 
design of the Raspberry Pi. You cannot even by the processor used on the 
Raspberry Pi. I think you have completely missed the value offered by the 
BeagleBoard organization. In addition, the BBB includes two PRU processors who 
have a cycle time of 5ns which is very important for realtime control 
functions. Cannot do that with the Raspberry Pi. Clearly you have no clue, so 
your advise has no value here. 

Regards,
John




> On Mar 22, 2016, at 4:42 PM, Karl Easterly  wrote:
> 
> to be a bit more nice about my grandious statement that the BBB is dead.. 
> here is a bit of history.
> 
> I have been working with products like this for about 18 years. Small form 
> factor boards like the basic stamps and zworld jack rabbits to todays rasp 
> pi's and bbb's and the banana pros and such and such
> 
> the raspberry has a great community.. and the BBB doesnt. I have had numerous 
> instances where i was using the BBB and found an issue and there are only 
> crickets sounding on google.
> 
> I am not saying the BBB is a bad board as it is clearly a nice peice of 
> engineering.. i am saying the product BBB will pass into the past while the 
> rasp pi will persist.
> 
> id advise you leave this BBB behind as it has no value looking toward the 
> future. this ship has sunk.
> 
> and thats a bummer in many ways.
> 
> On Mar 22, 2016 7:27 PM, "ChrisB"  > wrote:
> My experience has been quite different.  Pretty much all the progress I've 
> made with the BBB was enabled by various forum posts and code repositories.  
> And every time I think I have an original question or observation, a little 
> searching online finds the answer or a similar developer experience.  It's 
> not easy getting things to work some of the time, but tenaciousness pays off 
> for the most part.
> 
> Anyway, thanks to everyone who's spent the time to post on forums and share 
> their code!  Hopefully, I will have something to contribute in the near 
> future and can start paying you all back.
> 
> Chris Burak
> 
> On Tuesday, March 22, 2016 at 4:58:27 PM UTC-6, Karl Easterly wrote:
> Ya.. I didn't ask for help.. as you noticed :)
> 
> The point is the community for the beagle board is so sparse self help is not 
> an option. A sparse community around this type of product equals a dead 
> product.
> 
> On Sun, Mar 20, 2016 at 4:32 PM, Robert P. J. Day > 
> wrote:
> Quoting Robert Nelson >:
> 
> On Mar 20, 2016 2:28 PM, "Karl Easterly" > wrote:
> 
> It's clear that the BBB is a dead product. There is no meaningful
> resources for issues, and when the system simply won't 'reset from a new
> image from their site'... that's the last straw.
> 
> Mine are going in the trash and I will advise anyone everywhere to do the
> same.
> 
> 'Last straw', I've don't remember you ever posting on here.. If it's only
> one and done for you, then there's no reason for me to waste time either..
> 
>   how *dare* everyone not drop what they're doing ***right now*** and
> solve my problem during the first weekend of march madness?
> 
> rday
> 
> 
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

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


Re: [beagleboard] looks like the BeagleBone Black and this community is dead. Cannot even flash 8.3.

2016-03-22 Thread Gerald Coley
Source has been noted.

Gerald
On Mar 22, 2016 6:52 PM, "evilwulfie"  wrote:

> Nobody has forced you to use the BBB.
> Nobody has forced you to even LIKE the BBB
>
> As long as you feel that way remove yourself from the list and we will not
> be bothered
> by you anymore.
>
>
> On 3/22/2016 4:42 PM, Karl Easterly wrote:
>
> to be a bit more nice about my grandious statement that the BBB is dead..
> here is a bit of history.
>
> I have been working with products like this for about 18 years. Small form
> factor boards like the basic stamps and zworld jack rabbits to todays rasp
> pi's and bbb's and the banana pros and such and such
>
> the raspberry has a great community.. and the BBB doesnt. I have had
> numerous instances where i was using the BBB and found an issue and there
> are only crickets sounding on google.
>
> I am not saying the BBB is a bad board as it is clearly a nice peice of
> engineering.. i am saying the product BBB will pass into the past while the
> rasp pi will persist.
>
> id advise you leave this BBB behind as it has no value looking toward the
> future. this ship has sunk.
>
> and thats a bummer in many ways.
> On Mar 22, 2016 7:27 PM, "ChrisB"  wrote:
>
>> My experience has been quite different.  Pretty much all the progress
>> I've made with the BBB was enabled by various forum posts and code
>> repositories.  And every time I think I have an original question or
>> observation, a little searching online finds the answer or a similar
>> developer experience.  It's not easy getting things to work some of the
>> time, but tenaciousness pays off for the most part.
>>
>> Anyway, thanks to everyone who's spent the time to post on forums and
>> share their code!  Hopefully, I will have something to contribute in the
>> near future and can start paying you all back.
>>
>> Chris Burak
>>
>> On Tuesday, March 22, 2016 at 4:58:27 PM UTC-6, Karl Easterly wrote:
>>>
>>> Ya.. I didn't ask for help.. as you noticed :)
>>>
>>> The point is the community for the beagle board is so sparse self help
>>> is not an option. A sparse community around this type of product equals a
>>> dead product.
>>>
>>> On Sun, Mar 20, 2016 at 4:32 PM, Robert P. J. Day >> > wrote:
>>>
 Quoting Robert Nelson :

 On Mar 20, 2016 2:28 PM, "Karl Easterly"  wrote:
>

 It's clear that the BBB is a dead product. There is no meaningful
>>
> resources for issues, and when the system simply won't 'reset from a
> new
> image from their site'... that's the last straw.
>
>>
>> Mine are going in the trash and I will advise anyone everywhere to do
>> the
>>
> same.
>
> 'Last straw', I've don't remember you ever posting on here.. If it's
> only
> one and done for you, then there's no reason for me to waste time
> either..
>

   how *dare* everyone not drop what they're doing ***right now*** and
 solve my problem during the first weekend of march madness?

 rday



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


Re: [beagleboard] looks like the BeagleBone Black and this community is dead. Cannot even flash 8.3.

2016-03-22 Thread evilwulfie
Nobody has forced you to use the BBB.
Nobody has forced you to even LIKE the BBB

As long as you feel that way remove yourself from the list and we will
not be bothered
by you anymore.


On 3/22/2016 4:42 PM, Karl Easterly wrote:
>
> to be a bit more nice about my grandious statement that the BBB is
> dead.. here is a bit of history.
>
> I have been working with products like this for about 18 years. Small
> form factor boards like the basic stamps and zworld jack rabbits to
> todays rasp pi's and bbb's and the banana pros and such and such
>
> the raspberry has a great community.. and the BBB doesnt. I have had
> numerous instances where i was using the BBB and found an issue and
> there are only crickets sounding on google.
>
> I am not saying the BBB is a bad board as it is clearly a nice peice
> of engineering.. i am saying the product BBB will pass into the past
> while the rasp pi will persist.
>
> id advise you leave this BBB behind as it has no value looking toward
> the future. this ship has sunk.
>
> and thats a bummer in many ways.
>
> On Mar 22, 2016 7:27 PM, "ChrisB"  > wrote:
>
> My experience has been quite different.  Pretty much all the
> progress I've made with the BBB was enabled by various forum posts
> and code repositories.  And every time I think I have an original
> question or observation, a little searching online finds the
> answer or a similar developer experience.  It's not easy getting
> things to work some of the time, but tenaciousness pays off for
> the most part.
>
> Anyway, thanks to everyone who's spent the time to post on forums
> and share their code!  Hopefully, I will have something to
> contribute in the near future and can start paying you all back.
>
> Chris Burak
>
> On Tuesday, March 22, 2016 at 4:58:27 PM UTC-6, Karl Easterly wrote:
>
> Ya.. I didn't ask for help.. as you noticed :)
>
> The point is the community for the beagle board is so sparse
> self help is not an option. A sparse community around this
> type of product equals a dead product.
>
> On Sun, Mar 20, 2016 at 4:32 PM, Robert P. J. Day
>  wrote:
>
> Quoting Robert Nelson :
>
> On Mar 20, 2016 2:28 PM, "Karl Easterly"
>  wrote:
>
>
> It's clear that the BBB is a dead product. There
> is no meaningful
>
> resources for issues, and when the system simply won't
> 'reset from a new
> image from their site'... that's the last straw.
>
>
> Mine are going in the trash and I will advise
> anyone everywhere to do the
>
> same.
>
> 'Last straw', I've don't remember you ever posting on
> here.. If it's only
> one and done for you, then there's no reason for me to
> waste time either..
>
>
>   how *dare* everyone not drop what they're doing ***right
> now*** and
> solve my problem during the first weekend of march madness?
>
> rday
>
>
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

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


Re: [beagleboard] looks like the BeagleBone Black and this community is dead. Cannot even flash 8.3.

2016-03-22 Thread Karl Easterly
to be a bit more nice about my grandious statement that the BBB is dead..
here is a bit of history.

I have been working with products like this for about 18 years. Small form
factor boards like the basic stamps and zworld jack rabbits to todays rasp
pi's and bbb's and the banana pros and such and such

the raspberry has a great community.. and the BBB doesnt. I have had
numerous instances where i was using the BBB and found an issue and there
are only crickets sounding on google.

I am not saying the BBB is a bad board as it is clearly a nice peice of
engineering.. i am saying the product BBB will pass into the past while the
rasp pi will persist.

id advise you leave this BBB behind as it has no value looking toward the
future. this ship has sunk.

and thats a bummer in many ways.
On Mar 22, 2016 7:27 PM, "ChrisB"  wrote:

> My experience has been quite different.  Pretty much all the progress I've
> made with the BBB was enabled by various forum posts and code
> repositories.  And every time I think I have an original question or
> observation, a little searching online finds the answer or a similar
> developer experience.  It's not easy getting things to work some of the
> time, but tenaciousness pays off for the most part.
>
> Anyway, thanks to everyone who's spent the time to post on forums and
> share their code!  Hopefully, I will have something to contribute in the
> near future and can start paying you all back.
>
> Chris Burak
>
> On Tuesday, March 22, 2016 at 4:58:27 PM UTC-6, Karl Easterly wrote:
>>
>> Ya.. I didn't ask for help.. as you noticed :)
>>
>> The point is the community for the beagle board is so sparse self help is
>> not an option. A sparse community around this type of product equals a dead
>> product.
>>
>> On Sun, Mar 20, 2016 at 4:32 PM, Robert P. J. Day 
>> wrote:
>>
>>> Quoting Robert Nelson :
>>>
>>> On Mar 20, 2016 2:28 PM, "Karl Easterly"  wrote:

>>>
>>> It's clear that the BBB is a dead product. There is no meaningful
>
 resources for issues, and when the system simply won't 'reset from a new
 image from their site'... that's the last straw.

>
> Mine are going in the trash and I will advise anyone everywhere to do
> the
>
 same.

 'Last straw', I've don't remember you ever posting on here.. If it's
 only
 one and done for you, then there's no reason for me to waste time
 either..

>>>
>>>   how *dare* everyone not drop what they're doing ***right now*** and
>>> solve my problem during the first weekend of march madness?
>>>
>>> rday
>>>
>>>
>>>
>>

-- 
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 Broken? SPI signal is at 1.8v

2016-03-22 Thread Walker Archer
SPI1 shows the same 1.8v output.  I will attempt to move to another BBB (a 
BBG actually) and if things work there then I'll assume I toasted the SPI 
on this board.

On Tuesday, March 22, 2016 at 1:07:43 PM UTC-4, Walker Archer wrote:
>
> I suspect you're exactly right Wulf Man.  I was not really paying 
> attention to the order I applied the power and I was assuming that the POT 
> voltage would be isolated from the digital control side of the chip.  But I 
> also assumed that if I blew the drivers that I would no longer get any 
> signal from that pin.  Is it normal to get a reduced voltage?  I suppose I 
> could almost fix the issue with an opamp (except I'd be worried that the 
> defective pin would completely go dark someday.)
>
> If I really did blow those pins then I'll get a good signal out of SPI1 
> when I test it tonight.  How would I prevent this in the future?  Maybe 
> some clamping diodes to keep the voltage on the digital pins in range?
>
> Walker
>
> On Tuesday, March 22, 2016 at 11:09:29 AM UTC-4, Wulf Man wrote:
>>
>> Power sequencing is the key. How are you doing this?
>> If you are applying the 5v to the pots first you may be causing the issue 
>> and blowing the processor pins.
>> All pins on the processor need to be isolated from everything until power 
>> rails are stable.
>> Drive a input pin when the processor is not fully powered on and you risk 
>> destroying the drivers in the chip.
>>
>>
>> Schematics of your design would help identify the problem.
>>
>>
>> On 3/22/2016 7:22 AM, Walker Archer wrote:
>>
>> Forgot to add info about how the cape is powered.  The chip I'm using on 
>> the cape is an AD5206 digital potentiometer (10k).  I'm using the 3.3v rail 
>> to power the SPI side and an external 5v (4.9v measured) supply powers the 
>> pots.  However, I've been getting voltages from the pots that aren't what 
>> I'd expect, so a few days ago I disconnected the 5v supply and ran the BBB 
>> 3.3v rail to a single pot just to see if the resulting voltages would make 
>> more sense.  Maybe that was what did it? 
>>
>> On Tuesday, March 22, 2016 at 10:15:53 AM UTC-4, Walker Archer wrote: 
>>>
>>> Thanks for responding Gerald.  The scope capture above was done with no 
>>> cape.  It was taken from SPI0.  The chip has one-way communication so I'm 
>>> only using SPID1 (P9_18 from memory).  The clock is coming from P9_22. 
>>>  Chip select is P9_17.  When I get home tonight I'll try the same from SPI1 
>>> and see if it's affected as well. 
>>>
>>>
>>>
>>> On Tuesday, March 22, 2016 at 9:39:30 AM UTC-4, Gerald wrote: 

 No way for me to tell what you may have done, but 1.8V is not good. Any 
 chance you can provide more information like the pin number and connector 
 you are using? 
 What do you have connected to this pin?
 How is that device powered?

 Gerald


 On Tue, Mar 22, 2016 at 6:47 AM, Walker Archer  
 wrote:

> I've been building a custom cape for a robotics project and one of the 
> chips I'm using is controlled via SPI.  I've used an oscilloscope to 
> validate that the SPI is working as expected.  However, two days ago I 
> noticed that the chip stopped responding and after scoping the SPI signal 
> I 
> can see that the BBB is sending the SPI data pulses at 1.8v.  The SPI 
> signal is still happening... and the clock signal is still at 3.3v.  It's 
> just the SPI data line that is only peaking at 1.8v. 
>
> So, I'm wondering if I've done something bad to my BBB or if I've 
> somehow triggered a feature that I don't know about yet.  I'm attaching a 
> photo of the oscilloscope screen that shows the issue.
> -- 
> For more options, visit 
> http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google 
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to beagleboard...@googlegroups.com.
> For more options, visit 
> https://groups.google.com/d/optout.
>



 -- 
 Gerald
  
 ger...@beagleboard.org
 http://beagleboard.org/
 gco...@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...@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 

Re: [beagleboard] looks like the BeagleBone Black and this community is dead. Cannot even flash 8.3.

2016-03-22 Thread ChrisB
My experience has been quite different.  Pretty much all the progress I've 
made with the BBB was enabled by various forum posts and code 
repositories.  And every time I think I have an original question or 
observation, a little searching online finds the answer or a similar 
developer experience.  It's not easy getting things to work some of the 
time, but tenaciousness pays off for the most part.

Anyway, thanks to everyone who's spent the time to post on forums and share 
their code!  Hopefully, I will have something to contribute in the near 
future and can start paying you all back.

Chris Burak

On Tuesday, March 22, 2016 at 4:58:27 PM UTC-6, Karl Easterly wrote:
>
> Ya.. I didn't ask for help.. as you noticed :)
>
> The point is the community for the beagle board is so sparse self help is 
> not an option. A sparse community around this type of product equals a dead 
> product.
>
> On Sun, Mar 20, 2016 at 4:32 PM, Robert P. J. Day  > wrote:
>
>> Quoting Robert Nelson :
>>
>> On Mar 20, 2016 2:28 PM, "Karl Easterly" >> > wrote:
>>>
>>
>> It's clear that the BBB is a dead product. There is no meaningful

>>> resources for issues, and when the system simply won't 'reset from a new
>>> image from their site'... that's the last straw.
>>>

 Mine are going in the trash and I will advise anyone everywhere to do 
 the

>>> same.
>>>
>>> 'Last straw', I've don't remember you ever posting on here.. If it's only
>>> one and done for you, then there's no reason for me to waste time 
>>> either..
>>>
>>
>>   how *dare* everyone not drop what they're doing ***right now*** and
>> solve my problem during the first weekend of march madness?
>>
>> rday
>>
>>
>>
>

-- 
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] looks like the BeagleBone Black and this community is dead. Cannot even flash 8.3.

2016-03-22 Thread Karl Easterly
Ya.. I didn't ask for help.. as you noticed :)

The point is the community for the beagle board is so sparse self help is
not an option. A sparse community around this type of product equals a dead
product.

On Sun, Mar 20, 2016 at 4:32 PM, Robert P. J. Day 
wrote:

> Quoting Robert Nelson :
>
> On Mar 20, 2016 2:28 PM, "Karl Easterly"  wrote:
>>
>
> It's clear that the BBB is a dead product. There is no meaningful
>>>
>> resources for issues, and when the system simply won't 'reset from a new
>> image from their site'... that's the last straw.
>>
>>>
>>> Mine are going in the trash and I will advise anyone everywhere to do the
>>>
>> same.
>>
>> 'Last straw', I've don't remember you ever posting on here.. If it's only
>> one and done for you, then there's no reason for me to waste time either..
>>
>
>   how *dare* everyone not drop what they're doing ***right now*** and
> solve my problem during the first weekend of march madness?
>
> rday
>
>
>

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

2016-03-22 Thread Robert Nelson
Hi Mike,

On Tue, Mar 22, 2016 at 2:51 PM, Mike  wrote:
> root@beaglebone:/boot# grep NTP config-4.1.18-ti-rt-r52
> # CONFIG_NTP_PPS is not set
> root@beaglebone:/boot#
>
> Any chance we can get this enabled?
>
> Been chasing my tail for too long now trying to figure out why ntpd doesn't
> see my pps signal.

and fixed. ;)

https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/9458238810d9740d8d9b7175090e9b58da54f877

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


[beagleboard] CONFIG_NTP_PPS

2016-03-22 Thread Mike

root@beaglebone:/boot# grep NTP config-4.1.18-ti-rt-r52
# CONFIG_NTP_PPS is not set
root@beaglebone:/boot#

Any chance we can get this enabled?

Been chasing my tail for too long now trying to figure out why ntpd 
doesn't see my pps signal.


Thanks

Mike

--
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] RPMsg from Linux User Space to PRU on Beaglebone Black

2016-03-22 Thread John Syne
Hi Lucas,

This seems to work just fine for me. What kernel version are you using?

I’m using V4.1.13-ti-r33. As you can see, all remoteproc/rpmsg kernel modules 
are loaded automatically at boot time.

[   16.251480] pruss-rproc 4a30.pruss: 8 PRU interrupts parsed  
  
[   16.251567] pruss-rproc 4a30.pruss: memorydram0: pa 0x4a30 size 
0x2000 va e0ca 
[   16.251595] pruss-rproc 4a30.pruss: memorydram1: pa 0x4a302000 size 
0x2000 va e0ca4000 
[   16.251621] pruss-rproc 4a30.pruss: memory shrdram2: pa 0x4a31 size 
0x3000 va e0ca8000 
[   16.251644] pruss-rproc 4a30.pruss: memory intc: pa 0x4a32 size 
0x2000 va e0cac000 
[   16.251672] pruss-rproc 4a30.pruss: memory  cfg: pa 0x4a326000 size 
0x2000 va e0cb 
[   16.252174] pruss-rproc 4a30.pruss: creating platform devices for PRU 
cores
[   16.374800] pru-rproc 4a334000.pru0: memory iram: pa 0x4a334000 size 
0x2000 va e0cb4000
[   16.374858] pru-rproc 4a334000.pru0: memory  control: pa 0x4a322000 size 
0x400 va e0876000 
[   16.374901] pru-rproc 4a334000.pru0: memorydebug: pa 0x4a322400 size 
0x100 va e0c9e400 
[   16.375152]  remoteproc1: 4a334000.pru0 is available 
  
[   16.380153]  remoteproc1: Note: remoteproc is still under development and 
considered experimental. 
[   16.572902]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and 
backward compatibility isn't yet guaranteed. 
[   16.778752]  remoteproc1: registered virtio0 (type 7)
  
[   16.811201] pru-rproc 4a334000.pru0: PRU rproc node 
/ocp/pruss@4a30/pru@4a334000 probed successfully   
[   16.932818] pru-rproc 4a338000.pru1: memory iram: pa 0x4a338000 size 
0x2000 va e0ccc000
[   16.932891] pru-rproc 4a338000.pru1: memory  control: pa 0x4a324000 size 
0x400 va e0cd 
[   16.932918] pru-rproc 4a338000.pru1: memorydebug: pa 0x4a324400 size 
0x100 va e0cd2400 
[   16.933190]  remoteproc2: 4a338000.pru1 is available 
  
[   16.938192]  remoteproc2: Note: remoteproc is still under development and 
considered experimental. 
[   17.081421]  remoteproc2: THE BINARY FORMAT IS NOT YET FINALIZED, and 
backward compatibility isn't yet guaranteed. 
[   17.114912]  remoteproc2: registered virtio1 (type 7)
  
[   17.131205] pru-rproc 4a338000.pru1: PRU rproc node 
/ocp/pruss@4a30/pru@4a338000 probed successfully   
[   17.231951]  remoteproc1: powering up 4a334000.pru0  
  
[   17.243111]  remoteproc1: Booting fw image am335x-pru0-fw, size 78652
  
[   17.271252] pru-rproc 4a334000.pru0: version 0 event_chnl_map_size 1 
event_chnl_map 039c   
[   17.271289] pru-rproc 4a334000.pru0: sysevt-to-ch[60] -> 0   
  
[   17.271305] pru-rproc 4a334000.pru0: chnl-to-host[0] -> 0
  
[   17.271318] pru-rproc 4a334000.pru0: skip intr mapping for chnl 1
  
[   17.271330] pru-rproc 4a334000.pru0: skip intr mapping for chnl 2
  
[   17.271343] pru-rproc 4a334000.pru0: skip intr mapping for chnl 3
  
[   17.271355] pru-rproc 4a334000.pru0: skip intr mapping for chnl 4
  
[   17.271367] pru-rproc 4a334000.pru0: skip intr mapping for chnl 5
  
[   17.271379] pru-rproc 4a334000.pru0: skip intr mapping for chnl 6
  
[   17.271391] pru-rproc 4a334000.pru0: skip intr mapping for chnl 7
  
[   17.271404] pru-rproc 4a334000.pru0: skip intr mapping for chnl 8
  
[   17.271416] pru-rproc 4a334000.pru0: 

Re: [beagleboard] BBB Broken? SPI signal is at 1.8v

2016-03-22 Thread Walker Archer
I suspect you're exactly right Wulf Man.  I was not really paying attention 
to the order I applied the power and I was assuming that the POT voltage 
would be isolated from the digital control side of the chip.  But I also 
assumed that if I blew the drivers that I would no longer get any signal 
from that pin.  Is it normal to get a reduced voltage?  I suppose I could 
almost fix the issue with an opamp (except I'd be worried that the 
defective pin would completely go dark someday.)

If I really did blow those pins then I'll get a good signal out of SPI1 
when I test it tonight.  How would I prevent this in the future?  Maybe 
some clamping diodes to keep the voltage on the digital pins in range?

Walker

On Tuesday, March 22, 2016 at 11:09:29 AM UTC-4, Wulf Man wrote:
>
> Power sequencing is the key. How are you doing this?
> If you are applying the 5v to the pots first you may be causing the issue 
> and blowing the processor pins.
> All pins on the processor need to be isolated from everything until power 
> rails are stable.
> Drive a input pin when the processor is not fully powered on and you risk 
> destroying the drivers in the chip.
>
>
> Schematics of your design would help identify the problem.
>
>
> On 3/22/2016 7:22 AM, Walker Archer wrote:
>
> Forgot to add info about how the cape is powered.  The chip I'm using on 
> the cape is an AD5206 digital potentiometer (10k).  I'm using the 3.3v rail 
> to power the SPI side and an external 5v (4.9v measured) supply powers the 
> pots.  However, I've been getting voltages from the pots that aren't what 
> I'd expect, so a few days ago I disconnected the 5v supply and ran the BBB 
> 3.3v rail to a single pot just to see if the resulting voltages would make 
> more sense.  Maybe that was what did it? 
>
> On Tuesday, March 22, 2016 at 10:15:53 AM UTC-4, Walker Archer wrote: 
>>
>> Thanks for responding Gerald.  The scope capture above was done with no 
>> cape.  It was taken from SPI0.  The chip has one-way communication so I'm 
>> only using SPID1 (P9_18 from memory).  The clock is coming from P9_22. 
>>  Chip select is P9_17.  When I get home tonight I'll try the same from SPI1 
>> and see if it's affected as well. 
>>
>>
>>
>> On Tuesday, March 22, 2016 at 9:39:30 AM UTC-4, Gerald wrote: 
>>>
>>> No way for me to tell what you may have done, but 1.8V is not good. Any 
>>> chance you can provide more information like the pin number and connector 
>>> you are using? 
>>> What do you have connected to this pin?
>>> How is that device powered?
>>>
>>> Gerald
>>>
>>>
>>> On Tue, Mar 22, 2016 at 6:47 AM, Walker Archer  
>>> wrote:
>>>
 I've been building a custom cape for a robotics project and one of the 
 chips I'm using is controlled via SPI.  I've used an oscilloscope to 
 validate that the SPI is working as expected.  However, two days ago I 
 noticed that the chip stopped responding and after scoping the SPI signal 
 I 
 can see that the BBB is sending the SPI data pulses at 1.8v.  The SPI 
 signal is still happening... and the clock signal is still at 3.3v.  It's 
 just the SPI data line that is only peaking at 1.8v. 

 So, I'm wondering if I've done something bad to my BBB or if I've 
 somehow triggered a feature that I don't know about yet.  I'm attaching a 
 photo of the oscilloscope screen that shows the issue.
 -- 
 For more options, visit 
 http://beagleboard.org/discuss
 --- 
 You received this message because you are subscribed to the Google 
 Groups "BeagleBoard" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to beagleboard...@googlegroups.com.
 For more options, visit 
 https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> -- 
>>> Gerald
>>>  
>>> ger...@beagleboard.org
>>> http://beagleboard.org/
>>> gco...@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...@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] Play audio throuhg HDMI on BeagleBone Black

2016-03-22 Thread Jason Kridner
Only specific video modes of the HDMI framer device support audio. See the wiki 
page. 

> On Mar 22, 2016, at 10:44 AM, yolc...@gmail.com wrote:
> 
> After work with a multitouch screen for the BeagleBone Black, now I just want 
> to play audio/sounds through the HDMI connection as the multitouch screen has 
> a speaker. 
> 
> 
> 
> First of all, I just copied an audio sample, and try to reproduce it by 
> 'vlc', but next message is shown:
> 
>  "Audio output failed. The audio device "default" could not be used. No 
> such file or directory." 
> 
> 
> 
> Then, I have installed next tools:
> 
>  'alsa-base', 'alsa-utils', 'alsa-tools', 'alsamixergui'
> 
> 
> 
> But, when I tried to launch 'alsamixergui', the next message is shown:
> 
>  "alsamixer: function snd_ctl_open failed for default: No such file or 
> directory" 
> 
> 
> 
> And at "/etc/modprobe.d/alsa-base.conf", the content is:
> 
>  # autoloader aliases
> 
>install sound-slot-0 /sbin/modprobe snd-card-0
> 
>install sound-slot-1 /sbin/modprobe snd-card-1
> 
>install sound-slot-2 /sbin/modprobe snd-card-2
> 
>install sound-slot-3 /sbin/modprobe snd-card-3
> 
>install sound-slot-4 /sbin/modprobe snd-card-4
> 
>install sound-slot-5 /sbin/modprobe snd-card-5
> 
>install sound-slot-6 /sbin/modprobe snd-card-6
> 
>install sound-slot-7 /sbin/modprobe snd-card-7
> 
>  # Cause optional modules to be loaded above generic modules
> 
>install snd /sbin/modprobe --ignore-install snd && { /sbin/modprobe 
> --quiet snd-ioctl32 ; /sbin/modprobe --quiet snd-seq ; : ; }
> 
>install snd-rawmidi /sbin/modprobe --ignore-install snd-rawmidi && { 
> /sbin/modprobe --quiet snd-seq-midi ; : ; }
> 
>install snd-emu10k1 /sbin/modprobe --ignore-install snd-emu10k1 && { 
> /sbin/modprobe --quiet snd-emu10k1-synth ; : ; }
> 
>  # Keep snd-pcsp from beeing loaded as first soundcard
> 
>options snd-pcsp index=-2
> 
>  # Keep snd-usb-audio from beeing loaded as first soundcard
> 
>options snd-usb-audio index=-2
> 
>  # Prevent abnormal drivers from grabbing index 0
> 
>options bt87x index=-2
> 
>options cx88_alsa index=-2
> 
>options snd-atiixp-modem index=-2
> 
>options snd-intel8x0m index=-2
> 
>options snd-via82xx-modem index=-2
> 
> 
> 
> Moreover, I have try with next commands:
> 
>  'alsamixer -c 1 (2, 3... 7)' 
> 
> Having next output:
> 
>  "invalid card index: 1"
> 
> 
> 
> Is there any way to reproduce any sound (*.midi, *.wav, *.mp3...) through 
> hdmi easily?
> 
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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


Re: [beagleboard] BBB Broken? SPI signal is at 1.8v

2016-03-22 Thread Walker Archer
There are no other SPI chips on that bus.  Since the AD5206 is permanently 
a slave on the SPI bus I would think it would not try to drive the line.

On Tuesday, March 22, 2016 at 10:55:49 AM UTC-4, Harvey White wrote:
>
> On Tue, 22 Mar 2016 05:47:19 -0700 (PDT), you wrote: 
>
> >I've been building a custom cape for a robotics project and one of the 
> >chips I'm using is controlled via SPI.  I've used an oscilloscope to 
> >validate that the SPI is working as expected.  However, two days ago I 
> >noticed that the chip stopped responding and after scoping the SPI signal 
> I 
> >can see that the BBB is sending the SPI data pulses at 1.8v.  The SPI 
> >signal is still happening... and the clock signal is still at 3.3v.  It's 
> >just the SPI data line that is only peaking at 1.8v. 
>
>
> Had a chip (Epson S1D13781) with an SPI interface.  Had a similar 
> problem when sharing the SPI interface with another chip.  Bottom line 
> was that, unlike the standard SPI chips where the chip gets completely 
> off line when not selected, this chip *always* (the Epson) drives MISO 
> line low. 
>
> I was getting about 1.8 volts or so maximum voltage out of the 
> paralleled chip because it was trying to pull up a driver that was 
> stuck at zero.   
>
> Not sure that you have exactly the same problem, but is the chip 
> you're driving somehow trying to drive this line (and shouldn't)? 
>
> Harvey 
>
> > 
> >So, I'm wondering if I've done something bad to my BBB or if I've somehow 
> >triggered a feature that I don't know about yet.  I'm attaching a photo 
> of 
> >the oscilloscope screen that shows the issue. 
>
>

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


Re: [beagleboard] Re: Play audio throuhg HDMI on BeagleBone Black

2016-03-22 Thread Robert Nelson
On Tue, Mar 22, 2016 at 11:31 AM,   wrote:
> Adding new information about the issue:
> filename: /lib/modules/4.1.16-bone18/kernel/sound/core/snd.kp
>


HDMI audio is in patch hell on mainline, if you want to use "4.1.x"
with hdmi audio you need to use the ti branch:

cd /opt/scripts/tools/
git pull
sudo ./update_kernel.sh --ti-channel --lts-4_1

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


[beagleboard] Re: Play audio throuhg HDMI on BeagleBone Black

2016-03-22 Thread yolcopc


Adding new information about the issue:


'lsmod':

snd 56846   6   snd_soc_core, snd_timer, snd_pcm, snd_seq, 
snd_seq_device, snd_comp

 

'modinfo snd':

filename: /lib/modules/4.1.16-bone18/kernel/sound/core/snd.kp

alias:   char-major-116-*

license:   GPL

description: Advanced Linux Sound Architecture driver for soundcards.

author:Jaroslav Kysela 

license:   GPL

description: Jack detection support for ALSA

author:Mark Brown 

depends: soundcore

intree:  Y

vermagic: 4.1.16-bone18 mod_unload modversions ARMv7 thumb2 p2v8

parm:   slots:Module names assigned to the slots. (array of 
charp)

parm:   major:Major # for sound driver. (int)

parm:   cards_limit:Count of auto-loadable soundcards. (int)



 

El martes, 22 de marzo de 2016, 16:44:53 (UTC+1), yol...@gmail.com escribió:
>
> After work with a multitouch screen for the BeagleBone Black, now I just 
> want to play audio/sounds through the HDMI connection as the multitouch 
> screen has a speaker. 
>
>
> First of all, I just copied an audio sample, and try to reproduce it by 
> 'vlc', but next message is shown:
>
>  "*Audio output failed. The audio device "default" could not be used. 
> No such file or directory*." 
>
>
> Then, I have installed next tools:
>
>  'alsa-base', 'alsa-utils', 'alsa-tools', 'alsamixergui'
>
>
> But, when I tried to launch 'alsamixergui', the next message is shown:
>
>  "*alsamixer: function snd_ctl_open failed for default: No such file 
> or directory*" 
>
>
> And at "/etc/modprobe.d/alsa-base.conf", the content is:
>
> * # autoloader aliases*
>
> *   install sound-slot-0 /sbin/modprobe snd-card-0*
>
> *   install sound-slot-1 /sbin/modprobe snd-card-1*
>
> *   install sound-slot-2 /sbin/modprobe snd-card-2*
>
> *   install sound-slot-3 /sbin/modprobe snd-card-3*
>
> *   install sound-slot-4 /sbin/modprobe snd-card-4*
>
> *   install sound-slot-5 /sbin/modprobe snd-card-5*
>
> *   install sound-slot-6 /sbin/modprobe snd-card-6*
>
> *   install sound-slot-7 /sbin/modprobe snd-card-7*
>
> * # Cause optional modules to be loaded above generic modules*
>
> *   install snd /sbin/modprobe --ignore-install snd && { 
> /sbin/modprobe --quiet snd-ioctl32 ; /sbin/modprobe --quiet snd-seq ; : ; }*
>
> *   install snd-rawmidi /sbin/modprobe --ignore-install snd-rawmidi && 
> { /sbin/modprobe --quiet snd-seq-midi ; : ; }*
>
> *   install snd-emu10k1 /sbin/modprobe --ignore-install snd-emu10k1 && 
> { /sbin/modprobe --quiet snd-emu10k1-synth ; : ; }*
>
> * # Keep snd-pcsp from beeing loaded as first soundcard*
>
> *   options snd-pcsp index=-2*
>
> * # Keep snd-usb-audio from beeing loaded as first soundcard*
>
> *   options snd-usb-audio index=-2*
>
> * # Prevent abnormal drivers from grabbing index 0*
>
> *   options bt87x index=-2*
>
> *   options cx88_alsa index=-2*
>
> *   options snd-atiixp-modem index=-2*
>
> *   options snd-intel8x0m index=-2*
>
> *   options snd-via82xx-modem index=-2*
>
>
> Moreover, I have try with next commands:
>
>  'alsamixer -c 1 (2, 3... 7)' 
>
> Having next output:
>
>  "*invalid card index: 1*"
>
>
> *Is there any way to reproduce any sound (*.midi, *.wav, *.mp3...) through 
> hdmi easily*?
>

-- 
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] UART4 not working - configuration kernel version 4.1.18

2016-03-22 Thread Le Costaouec Vincent


Le mardi 22 mars 2016 14:28:48 UTC+1, RobertCNelson a écrit :
>
> On Tue, Mar 22, 2016 at 5:40 AM, Le Costaouec Vincent 
>  wrote: 
> > Hi, 
> > 
> > I'm currently trying to configure and test UART4 on the BBB. 
> > So I my point is to connect the two pins and try to communicate with 
> them 
> > through minicom. 
> > However I haven't any response from the board. 
> > 
> > for my dts i'm using this one : 
> > 
> https://github.com/victorporof/BeagleBone-SPI-UART/blob/master/BB-UART4-00A0.dts
>  
>
> Well you have the pin's for uart4, but you've utilized uart5..  (this 
> worked in 3.8.x as the uart# was wrong.) 
>
> In v4.1.x: use 
>
> target = <>; 
>
> for uart4... 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/

I have try that and it works. So now I had a better understanding of the 
uart dts
Thanks a lot.

Regards,

Vincent
 

-- 
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] Play audio throuhg HDMI on BeagleBone Black

2016-03-22 Thread yolcopc


After work with a multitouch screen for the BeagleBone Black, now I just 
want to play audio/sounds through the HDMI connection as the multitouch 
screen has a speaker. 


First of all, I just copied an audio sample, and try to reproduce it by 
'vlc', but next message is shown:

 "*Audio output failed. The audio device "default" could not be used. 
No such file or directory*." 


Then, I have installed next tools:

 'alsa-base', 'alsa-utils', 'alsa-tools', 'alsamixergui'


But, when I tried to launch 'alsamixergui', the next message is shown:

 "*alsamixer: function snd_ctl_open failed for default: No such file or 
directory*" 


And at "/etc/modprobe.d/alsa-base.conf", the content is:

* # autoloader aliases*

*   install sound-slot-0 /sbin/modprobe snd-card-0*

*   install sound-slot-1 /sbin/modprobe snd-card-1*

*   install sound-slot-2 /sbin/modprobe snd-card-2*

*   install sound-slot-3 /sbin/modprobe snd-card-3*

*   install sound-slot-4 /sbin/modprobe snd-card-4*

*   install sound-slot-5 /sbin/modprobe snd-card-5*

*   install sound-slot-6 /sbin/modprobe snd-card-6*

*   install sound-slot-7 /sbin/modprobe snd-card-7*

* # Cause optional modules to be loaded above generic modules*

*   install snd /sbin/modprobe --ignore-install snd && { /sbin/modprobe 
--quiet snd-ioctl32 ; /sbin/modprobe --quiet snd-seq ; : ; }*

*   install snd-rawmidi /sbin/modprobe --ignore-install snd-rawmidi && 
{ /sbin/modprobe --quiet snd-seq-midi ; : ; }*

*   install snd-emu10k1 /sbin/modprobe --ignore-install snd-emu10k1 && 
{ /sbin/modprobe --quiet snd-emu10k1-synth ; : ; }*

* # Keep snd-pcsp from beeing loaded as first soundcard*

*   options snd-pcsp index=-2*

* # Keep snd-usb-audio from beeing loaded as first soundcard*

*   options snd-usb-audio index=-2*

* # Prevent abnormal drivers from grabbing index 0*

*   options bt87x index=-2*

*   options cx88_alsa index=-2*

*   options snd-atiixp-modem index=-2*

*   options snd-intel8x0m index=-2*

*   options snd-via82xx-modem index=-2*


Moreover, I have try with next commands:

 'alsamixer -c 1 (2, 3... 7)' 

Having next output:

 "*invalid card index: 1*"


*Is there any way to reproduce any sound (*.midi, *.wav, *.mp3...) through 
hdmi easily*?

-- 
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] PinMuxing P9_21 and P9_23 to I2C2?

2016-03-22 Thread cw . earley

As stated in the topic's subject, I am currently trying to expose I2C2 (The 
I2C bus that's normally connected to P9_19, P9_20) to pins P9_21 and P9_22. 
Since the documentation for the Beaglebone Black/Green show that pins 21 
and 22 can be used for I2C2 it must be possible, I just can't find a solid 
way to do it.

*Background Info*

Hardware: Seeed BeagleBone Green
OS: debian
uname -a: Linux beaglebone 3.8.13-bone71.1 #1 SMP Wed May 20 20:13:27 PDT 
2015 armv7l GNU/Linux
(Note that I am willing to flash whatever OS/kernel version it takes to get 
this working)

The requirement comes from an error I made not knowing about the default 
I2C device tree settings for the device. Since there were two pairs of I2C2 
pins listed in the documentation, I chose the pair that lad less overlap, 
which was a mistake. I have since then fixed the error in my 
schematic/board but I already have demo PCBs on the way from the fabhouse. 
It'd be great to just expose those pins to the I2C bus rather than cut and 
rewire traces manually. Sadly due to the time constraints for the project 
(Deadline is on the 31st) I cannot send out for an updated PCB.

The software side of this project is based on the Adafruit_BBIO library 
which is, in turn, based on the python smbus library. There's very little 
in terms of configuration when setting up I2C communication with those 
libraries so the magic switch is most likely not there.

*Main Methods Attempted*

For all cases, assume that the UART2 device tree overlay has been disabled 
via blacklisting in uEnv.txt and a reboot.


   - bonescript pinMode() - Does nothing to the mode of the pin in this 
   case although getPinMode() does show that I2C2_SDA/SCL is a possible mode 
   option.


   - Enabling an I2C2 device tree overlay from the bb.org-overlays 
   

 
   repo that I edited to point to P9_21 and P9_22 
    instead of the normal I2C2 pins. This 
   compiles and shows up in the cape manager after inclusion but nothing 
   happens on pins P9_21 and P9_22 when I try to communicate to my PCA9685 
   devboard. Meanwhile pins P9_19, P9_20 work just fine so the bus is still 
   functional.


   - Tried Bernhard Tittelbach's lovely Device-Tree Overlay Generator 
   
to
 
   make a setting file for each pin.


   - Mucked around with the Universal Cape overlay but it never really 
   seemed to change any pin states in this case.
   

*Summary*

Given any possible (supported) OS, how can I get pins P9_21 and P9_22 into 
the correct pin mode to mux to the I2C2 device?
And is it possible to have I2C2 exposed on both P9_19,20 and P9_21,22?

Lastly, I apologize for any confusing nomenclature. I've been flashing 
different OS versions and reading documentation relevant to differing 
flavors of debian trying to solve this that I'm a bit number-dizzy.

Thanks for your time!

-- 
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 Broken? SPI signal is at 1.8v

2016-03-22 Thread evilwulfie
Power sequencing is the key. How are you doing this?
If you are applying the 5v to the pots first you may be causing the
issue and blowing the processor pins.
All pins on the processor need to be isolated from everything until
power rails are stable.
Drive a input pin when the processor is not fully powered on and you
risk destroying the drivers in the chip.


Schematics of your design would help identify the problem.


On 3/22/2016 7:22 AM, Walker Archer wrote:
> Forgot to add info about how the cape is powered.  The chip I'm using
> on the cape is an AD5206 digital potentiometer (10k).  I'm using the
> 3.3v rail to power the SPI side and an external 5v (4.9v measured)
> supply powers the pots.  However, I've been getting voltages from the
> pots that aren't what I'd expect, so a few days ago I disconnected the
> 5v supply and ran the BBB 3.3v rail to a single pot just to see if the
> resulting voltages would make more sense.  Maybe that was what did it?
>
> On Tuesday, March 22, 2016 at 10:15:53 AM UTC-4, Walker Archer wrote:
>
> Thanks for responding Gerald.  The scope capture above was done
> with no cape.  It was taken from SPI0.  The chip has one-way
> communication so I'm only using SPID1 (P9_18 from memory).  The
> clock is coming from P9_22.  Chip select is P9_17.  When I get
> home tonight I'll try the same from SPI1 and see if it's affected
> as well.
>
>
>
> On Tuesday, March 22, 2016 at 9:39:30 AM UTC-4, Gerald wrote:
>
> No way for me to tell what you may have done, but 1.8V is not
> good. Any chance you can provide more information like the pin
> number and connector you are using?
> What do you have connected to this pin?
> How is that device powered?
>
> Gerald
>
>
> On Tue, Mar 22, 2016 at 6:47 AM, Walker Archer
>  wrote:
>
> I've been building a custom cape for a robotics project
> and one of the chips I'm using is controlled via SPI. 
> I've used an oscilloscope to validate that the SPI is
> working as expected.  However, two days ago I noticed that
> the chip stopped responding and after scoping the SPI
> signal I can see that the BBB is sending the SPI data
> pulses at 1.8v.  The SPI signal is still happening... and
> the clock signal is still at 3.3v.  It's just the SPI data
> line that is only peaking at 1.8v.
>
> So, I'm wondering if I've done something bad to my BBB or
> if I've somehow triggered a feature that I don't know
> about yet.  I'm attaching a photo of the oscilloscope
> screen that shows the issue.
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to
> the Google Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails
> from it, send an email to beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout
> .
>
>
>
>
> -- 
> Gerald
>  
> ger...@beagleboard.org
> http://beagleboard.org/
> gco...@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
> .
> 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] Issue with USB devices through a USB hub

2016-03-22 Thread Robert Nelson
On Tue, Mar 22, 2016 at 9:58 AM, Karina Bond  wrote:
> A question about Robert's commentsmy USB devices are powered with their 
> own supply though. In this case neither of the devices should be requesting 
> the full 500mA.
>
> Anything I try To make this work with an unpowered USB HUB?

These come in handy, to find out what's really happening..

https://www.adafruit.com/products/1852

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


Re: [beagleboard] Issue with USB devices through a USB hub

2016-03-22 Thread Karina Bond
A question about Robert's commentsmy USB devices are powered with their own 
supply though. In this case neither of the devices should be requesting the 
full 500mA. 

Anything I try To make this work with an unpowered USB HUB?

-Karina

Sent from my iPhone

> On Mar 22, 2016, at 7:18 AM, Robert Nelson  wrote:
> 
>> On Tue, Mar 22, 2016 at 8:56 AM, Karina Bond  wrote:
>> 
>> So the hub in my setup is unpowered. But I have tried powering up the USB
>> devices first. Then powering up the beagle bone . In this case the two USB
>> show up in the output of 'lsusb'.
>> 
>> I am working on finding a powered USB hub to try this with.  But ideally I'd
>> like to use an unpowered hub.
> 
> Not going to happen...  Use a powered hub..
> 
> USB is not magic, it needs a specific amount of power on startup to
> correctly enumerate a device.  By using an un-powered hub, with
> multiple downstream devices, as soon as the "first" requests the full
> "500mA" vs it's initial "100mA", the other device's chances of being
> detected is toast...
> 
> 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.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] BBB Broken? SPI signal is at 1.8v

2016-03-22 Thread Harvey White
On Tue, 22 Mar 2016 05:47:19 -0700 (PDT), you wrote:

>I've been building a custom cape for a robotics project and one of the 
>chips I'm using is controlled via SPI.  I've used an oscilloscope to 
>validate that the SPI is working as expected.  However, two days ago I 
>noticed that the chip stopped responding and after scoping the SPI signal I 
>can see that the BBB is sending the SPI data pulses at 1.8v.  The SPI 
>signal is still happening... and the clock signal is still at 3.3v.  It's 
>just the SPI data line that is only peaking at 1.8v.


Had a chip (Epson S1D13781) with an SPI interface.  Had a similar
problem when sharing the SPI interface with another chip.  Bottom line
was that, unlike the standard SPI chips where the chip gets completely
off line when not selected, this chip *always* (the Epson) drives MISO
line low.

I was getting about 1.8 volts or so maximum voltage out of the
paralleled chip because it was trying to pull up a driver that was
stuck at zero.  

Not sure that you have exactly the same problem, but is the chip
you're driving somehow trying to drive this line (and shouldn't)?

Harvey

>
>So, I'm wondering if I've done something bad to my BBB or if I've somehow 
>triggered a feature that I don't know about yet.  I'm attaching a photo of 
>the oscilloscope screen that shows the issue.

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


[beagleboard] RPMsg from Linux User Space to PRU on Beaglebone Black

2016-03-22 Thread lucas
I am trying to use rpmsg from user space. I am following the PRU training 
of TI 
(http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#Part_1:_Linux_Command_Line_LED_Toggling)

I use the latest beaglebone black image (Debian 8.3 2016-01-24 
from https://beagleboard.org/latest-images). 

The three kernel modules that are needed appear to be already part of this 
image (virtio_rpmsg_bus.ko, pruss_remoteproc.ko,rpmsg_pru.ko). It seems 
like I have to load them in this exact order. Unfortunately 
pruss_remoteproc.ko is already loaded and there seem to be a bug that 
prevents reloading the module 
(https://groups.google.com/forum/#!topic/beagleboard/EXBjL4TkBiU). So what 
could be a solution for this problem? 

- Can I load the modules in the right order on boot? (I cannot find the 
point where pruss_remoteproc.ko gets loaded)
- Can I prevent pruss_remoteproc.ko from being loaded on boot and insmod it 
later on? 
- Or, is my problem something completely different and rpmsg doesn't work 
like that from user space out of the box with the image that I am using 
i.e. I have to recompile the kernel?

Thank you!

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


Re: [beagleboard] BBB Broken? SPI signal is at 1.8v

2016-03-22 Thread Walker Archer
Forgot to add info about how the cape is powered.  The chip I'm using on 
the cape is an AD5206 digital potentiometer (10k).  I'm using the 3.3v rail 
to power the SPI side and an external 5v (4.9v measured) supply powers the 
pots.  However, I've been getting voltages from the pots that aren't what 
I'd expect, so a few days ago I disconnected the 5v supply and ran the BBB 
3.3v rail to a single pot just to see if the resulting voltages would make 
more sense.  Maybe that was what did it?

On Tuesday, March 22, 2016 at 10:15:53 AM UTC-4, Walker Archer wrote:
>
> Thanks for responding Gerald.  The scope capture above was done with no 
> cape.  It was taken from SPI0.  The chip has one-way communication so I'm 
> only using SPID1 (P9_18 from memory).  The clock is coming from P9_22. 
>  Chip select is P9_17.  When I get home tonight I'll try the same from SPI1 
> and see if it's affected as well.
>
>
>
> On Tuesday, March 22, 2016 at 9:39:30 AM UTC-4, Gerald wrote:
>>
>> No way for me to tell what you may have done, but 1.8V is not good. Any 
>> chance you can provide more information like the pin number and connector 
>> you are using?
>> What do you have connected to this pin?
>> How is that device powered?
>>
>> Gerald
>>
>>
>> On Tue, Mar 22, 2016 at 6:47 AM, Walker Archer  
>> wrote:
>>
>>> I've been building a custom cape for a robotics project and one of the 
>>> chips I'm using is controlled via SPI.  I've used an oscilloscope to 
>>> validate that the SPI is working as expected.  However, two days ago I 
>>> noticed that the chip stopped responding and after scoping the SPI signal I 
>>> can see that the BBB is sending the SPI data pulses at 1.8v.  The SPI 
>>> signal is still happening... and the clock signal is still at 3.3v.  It's 
>>> just the SPI data line that is only peaking at 1.8v.
>>>
>>> So, I'm wondering if I've done something bad to my BBB or if I've 
>>> somehow triggered a feature that I don't know about yet.  I'm attaching a 
>>> photo of the oscilloscope screen that shows the issue.
>>>
>>> -- 
>>> For more options, visit http://beagleboard.org/discuss
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to beagleboard...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> Gerald
>>  
>> ger...@beagleboard.org
>> http://beagleboard.org/
>> gco...@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.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] BBB Broken? SPI signal is at 1.8v

2016-03-22 Thread Walker Archer
Thanks for responding Gerald.  The scope capture above was done with no 
cape.  It was taken from SPI0.  The chip has one-way communication so I'm 
only using SPID1 (P9_18 from memory).  The clock is coming from P9_22. 
 Chip select is P9_17.  When I get home tonight I'll try the same from SPI1 
and see if it's affected as well.



On Tuesday, March 22, 2016 at 9:39:30 AM UTC-4, Gerald wrote:
>
> No way for me to tell what you may have done, but 1.8V is not good. Any 
> chance you can provide more information like the pin number and connector 
> you are using?
> What do you have connected to this pin?
> How is that device powered?
>
> Gerald
>
>
> On Tue, Mar 22, 2016 at 6:47 AM, Walker Archer  > wrote:
>
>> I've been building a custom cape for a robotics project and one of the 
>> chips I'm using is controlled via SPI.  I've used an oscilloscope to 
>> validate that the SPI is working as expected.  However, two days ago I 
>> noticed that the chip stopped responding and after scoping the SPI signal I 
>> can see that the BBB is sending the SPI data pulses at 1.8v.  The SPI 
>> signal is still happening... and the clock signal is still at 3.3v.  It's 
>> just the SPI data line that is only peaking at 1.8v.
>>
>> So, I'm wondering if I've done something bad to my BBB or if I've somehow 
>> triggered a feature that I don't know about yet.  I'm attaching a photo of 
>> the oscilloscope screen that shows the issue.
>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Gerald
>  
> ger...@beagleboard.org 
> http://beagleboard.org/
> gco...@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.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Issue with USB devices through a USB hub

2016-03-22 Thread Robert Nelson
On Tue, Mar 22, 2016 at 8:56 AM, Karina Bond  wrote:
>
> So the hub in my setup is unpowered. But I have tried powering up the USB
> devices first. Then powering up the beagle bone . In this case the two USB
> show up in the output of 'lsusb'.
>
> I am working on finding a powered USB hub to try this with.  But ideally I'd
> like to use an unpowered hub.

Not going to happen...  Use a powered hub..

USB is not magic, it needs a specific amount of power on startup to
correctly enumerate a device.  By using an un-powered hub, with
multiple downstream devices, as soon as the "first" requests the full
"500mA" vs it's initial "100mA", the other device's chances of being
detected is toast...

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


Re: [beagleboard] Issue with USB devices through a USB hub

2016-03-22 Thread Karina Bond

So the hub in my setup is unpowered. But I have tried powering up the USB 
devices first. Then powering up the beagle bone . In this case the two USB show 
up in the output of 'lsusb'.

I am working on finding a powered USB hub to try this with.  But ideally I'd 
like to use an unpowered hub. 

-Karina 

Sent from my iPhone

> On Mar 22, 2016, at 12:53 AM, Chris Morgan  wrote:
> 
>> On Tuesday, March 22, 2016, Karina  wrote:
>> Hi,
>> 
>> I have a unpowered 2-port USB hub that I have connected to the BeagleBone 
>> Black (Rev C). I have two (serial over ) USB devices connected to the two 
>> port of the USB hub. They are are not powered to begin with. When i power up 
>> the Beagle Bone, i see the USB hub listed in the output for 'lsusb'. Now i 
>> power up the two USB device hanging off the USB hub. But i do not see the 
>> USB devices listed in the output of 'lsusb'. Also, there is no /dev/ttyUSB* 
>> file. For my project, it wold be ideal for the beagle bone to be powered up 
>> before these USB devices. Any idea on what i have messed up or missed?
>> 
>> I have verified that if i connect the USB device directly into the USB port 
>> on the beagle bone black, then I can power the USB device after the beagle 
>> bone is powered up and it shows up in the output of 'lsusb' and i can 
>> control the device.
>> 
>> Here are some more specifics about my setup.
>> 1. I am using the beagle bone black Rev C board.
>> 2. I am running Debian linux (jessie v 8.3) on the beagle bone black . The 
>> version of the linux kernel is v3.8.15 -bone 71. 
>> 3. I am powering the beagle bone with the power supply ( instead of over the 
>> USB connector for etherent over USB).
>> 
>> Thanks,
>> Karina
>> 
>> -- 
>> 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.
> 
> 
> 
> 
> Have you tried powering the hub and devices up before the bbb?
> 
> Chris
> 
>  
> -- 
> 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/nzPuic8Eq-k/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] Need support in compiling ubuntu for BBB

2016-03-22 Thread Robert Nelson
On Tue, Mar 22, 2016 at 2:58 AM,   wrote:
> hello,
> almost the same problem with me but as i am following the link:
> https://eewiki.net/display/linuxonarm/BeagleBone+Black
> after downloading the boot loader and linux kernel for "am33x-v4.5 (Stable)"
> i.e git checkout origin/am33x-v4.5 -b tmp, the build_kernel.sh script is not
> running and is showing like that.
>
>
> debian@beaglebone:~/bb-kernel/stable-kernel$ ./build_kernel.sh
> + Detected build host [Debian GNU/Linux 8.3 (jessie)]
> + host: [armv7l]
> + git HEAD commit: [fc591451959669c6d6acf0304c48fa41c09d37c1]
> -
> scripts/gcc: Using: gcc (Debian 4.9.2-10) 4.9.2
> Copyright (C) 2014 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> -
> CROSS_COMPILE=
> -
> scripts/git: Warning: LINUX_GIT is not writable:
> -
> scripts/git: LINUX_GIT not defined in system.sh
> cloning https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> into default location: /home/debian/bb-kernel/stable-kernel/ignore/linux-src
> Cloning into '/home/debian/bb-kernel/stable-kernel/ignore/linux-src'...
> remote: Counting objects: 4672394, done.
> remote: Compressing objects: 100% (90332/90332), done.
> fatal: Out of memory, calloc failed
> fatal: index-pack failed

"Out of memory, calloc failed"

Don't run it on the BeagleBoard Black...

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


[beagleboard] UART4 connexion and configuration with kernel 4.1.18

2016-03-22 Thread vincent . lecostaouec


Hi, 

I'm currently trying to configure the UART4 of the BBB. 
In addition my test is simply to connect the RX and TX pins and try to 
received the message through minicom. 
However after my configuration I didn't succeed to make it work. I don't 
really understand why.

I use the following dtb 
https://github.com/victorporof/BeagleBone-SPI-UART/blob/master/BB-UART4-00A0.dts

concerning my configuration

 $ uname -a
Linux beagle01 4.1.18-bone20 #4 Fri Mar 18 15:16:19 CET 2016 armv7l 
GNU/Linux
 $ lsb_release -da
Distributor ID:Debian
Description:Debian GNU/Linux 8.3 (jessie)
Release:8.3
Codename:jessie


$ dmesg | grep tty
[0.00] Kernel command line: console=ttyO0,115200n8 capemgr.
enable_partno=BB-UART4 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait
[0.000298] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'
[3.102953] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 154, 
base_baud = 300) is a 8250
[3.903811] console [ttyS0] enabled
[6.705576] systemd[1]: Expecting device dev-ttyS0.device...
[7.174265] systemd[1]: Starting system-getty.slice.
[7.192955] systemd[1]: Created slice system-getty.slice.
[7.198476] systemd[1]: Starting system-serial\x2dgetty.slice.
[7.222958] systemd[1]: Created slice system-serial\x2dgetty.slice.
[ 1023.102502] 481aa000.serial: ttyS5 at MMIO 0x481aa000 (irq = 187, 
base_baud = 300) is a 8250

$ cat $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-UART4

$ ls -l /dev/ttyS*
crw--- 1 root tty 4, 64 Mar 22 10:20 /dev/ttyS0
crw-rw 1 root dialout 4, 65 Sep  7  2015 /dev/ttyS1
crw-rw 1 root dialout 4, 66 Sep  7  2015 /dev/ttyS2
crw-rw 1 root dialout 4, 67 Sep  7  2015 /dev/ttyS3
crw-rw 1 root dialout 4, 68 Sep  7  2015 /dev/ttyS4
crw-rw 1 root dialout 4, 69 Mar 22 09:58 /dev/ttyS5

$ cat /boot/uEnv.txt 
uname_r=4.1.18-bone20
optargs=capemgr.enable_partno=BB-UART4


Finally I shorted the pins P9_11 and P9_13  on the board and then I launch
$ minicom -b 9600 -o -D /dev/ttyS5
  
Serial port setup
| A -Serial Device  : /dev/ttyS5
| B - Lockfile Location : /var/lock 
| C -   Callin Program  :   
| D -  Callout Program  :   
| E -Bps/Par/Bits   : 9600 8N1  
| F - Hardware Flow Control : No
| G - Software Flow Control : No


So normally I should have the answer of what I enter on the terminal (i.e 
an echo).
So I don't really understand what I did wrong.
Remarque :
I don't know if it is link but I find strange that I configure UART4 but it 
modifies ttyS5. However I didn't control it,

In addition in the minicom cession it is always Offline
CTRL-A Z for help | 9600 8N1 | NOR | Minicom 2.7 | VT102 | Offline | 
ttyS5 

If anyone have an Idea 
Thanks by advance
Regards 
Vincent








-- 
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] jSSC install problem on BBB Rev C Debian

2016-03-22 Thread mihainigrini
you can just package it from the IDE in the jar and use default jssc jar 
2.8 version.

On Tuesday, July 29, 2014 at 10:01:03 PM UTC+3, RobertCNelson wrote:
>
> On Tue, Jul 29, 2014 at 9:40 AM,   
> wrote: 
> > I'm having problems using jSSC on my BBB Rev C running Debian.  Has 
> anyone 
> > successfully installed jSSC??  It doesn't seem to be available using 
> > apt-get. 
>
> It's packaged in "jessie" 
>
> https://packages.debian.org/jessie/libjssc-java 
>
> Regards, 
>
> -- 
> Robert Nelson 
> http://www.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.


Re: [beagleboard] Need support in compiling ubuntu for BBB

2016-03-22 Thread sheri1771
hello,
almost the same problem with me but as i am following the link:
https://eewiki.net/display/linuxonarm/BeagleBone+Black
after downloading the boot loader and linux kernel for "am33x-v4.5 
(Stable)" i.e git checkout origin/am33x-v4.5 -b tmp, the build_kernel.sh 
script is not running and is showing like that.


debian@beaglebone:~/bb-kernel/stable-kernel$ ./build_kernel.sh
+ Detected build host [Debian GNU/Linux 8.3 (jessie)]
+ host: [armv7l]
+ git HEAD commit: [fc591451959669c6d6acf0304c48fa41c09d37c1]
-
scripts/gcc: Using: gcc (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-
CROSS_COMPILE=
-
scripts/git: Warning: LINUX_GIT is not writable:
-
scripts/git: LINUX_GIT not defined in system.sh
cloning https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
into default location: /home/debian/bb-kernel/stable-kernel/ignore/linux-src
Cloning into '/home/debian/bb-kernel/stable-kernel/ignore/linux-src'...
remote: Counting objects: 4672394, done.
remote: Compressing objects: 100% (90332/90332), done.
fatal: Out of memory, calloc failed
fatal: index-pack failed

i have also followed the link and made changes accordingly:
http://www.crashcourse.ca/wiki/index.php/Robert_Nelson's_kernel_build_for_the_BBB

but still the same error generates.

please tell me what to do to resolve this issue regarding building the 
kernel.

On Tuesday, November 5, 2013 at 2:32:49 PM UTC, RobertCNelson wrote:
>
> On Mon, Nov 4, 2013 at 10:39 PM, vinayak aghor  > wrote: 
> > Hello, 
> > I want to compile OS ubuntu for BBB. 
> > 
> > I am referring http://eewiki.net/display/linuxonarm/BeagleBone+Black 
> > 
> > In downloaded linux-dev-am33x-v3.12 in home directory. Then ran script 
> > ./build_kernel.sh 
> > 
> > It initially downloaded cross-compiler toolchain (around 48MB) and did 
> set 
> > the CC, which is expected. 
> > debug: 
> > 
> CC=/home/vinayak/linux-dev-am33x-v3.12/dl/gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux/bin/arm-linux-gnueabihf-
>  
>
> > 
> > Then it tried to download linux directory 
> > 
> > scripts/git: LINUX_GIT not defined in system.sh 
> > cloning git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> > into default location: 
> /home/vinayak/linux-dev-am33x-v3.12/ignore/linux-src 
> > Cloning into '/home/vinayak/linux-dev-am33x-v3.12/ignore/linux-src'... 
> > remote: Counting objects: 3239961, done. 
> > remote: Compressing objects: 100% (486062/486062), done. 
> > ^Cceiving objects:   0% (1535/3239961), 836.00 KiB | 50 KiB/s 
> > 
> > After downloading complete (around 650MB), got message as - Resolving 
> deltas 
> > 
> > Now internet connection lost. Again ran script ./build_kernel.sh 
>
> Did the "clone" finish before the network was lost? 
>
> > 
> > Now script again downloading 650MB data, which is not expected. In the 
> > previous run, it has downloaded the same data & again downloading. There 
> > should be some catch in this. 
>
> the bash logic is as follows... 
>
> https://github.com/RobertCNelson/stable-kernel/blob/master/scripts/git.sh#L62 
>
>
> > 
> > How to permanently fix this? How to download LINUX_GIT permanently. 
> so,again 
> > will not download same file 
>
> You could always "clone" 
> "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git" 
> anywhere in your system, just set the LINUX_GIT variable to the 
> directory to where you cloned it.. If you mess up the logic, will just 
> re-clone it to the 'ignore/linux-src' directory... 
>
> Regards, 
>
> -- 
> Robert Nelson 
> http://www.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.


Re: [beagleboard] BBB Broken? SPI signal is at 1.8v

2016-03-22 Thread Gerald Coley
No way for me to tell what you may have done, but 1.8V is not good. Any
chance you can provide more information like the pin number and connector
you are using?
What do you have connected to this pin?
How is that device powered?

Gerald


On Tue, Mar 22, 2016 at 6:47 AM, Walker Archer  wrote:

> I've been building a custom cape for a robotics project and one of the
> chips I'm using is controlled via SPI.  I've used an oscilloscope to
> validate that the SPI is working as expected.  However, two days ago I
> noticed that the chip stopped responding and after scoping the SPI signal I
> can see that the BBB is sending the SPI data pulses at 1.8v.  The SPI
> signal is still happening... and the clock signal is still at 3.3v.  It's
> just the SPI data line that is only peaking at 1.8v.
>
> So, I'm wondering if I've done something bad to my BBB or if I've somehow
> triggered a feature that I don't know about yet.  I'm attaching a photo of
> the oscilloscope screen that shows the issue.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> 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.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Driving a Multiplexed LED matrix directly from gpio

2016-03-22 Thread CEinTX
David,

William's suggestion of the PRU is a really good one.
I know there are examples on the forum for using them - even though I 
personally haven't looked at them.
You should be able to do everything inside the PRU - You only need 144 
bytes per buffer (assuming 1 color / 1 bpp).
So even having multiple buffers shouldn't be an issue. You should even 
still be able to leverage the SPI interface if desired.
I understand that bit-banging via the PRU is much more efficient than even 
bare metal inside the CPU.

The UNC5821 driver has a much simpler interface than the ws28xx serial 
lighting chips. It's an old retired chip that is essentially a shift 
register and a latch.
Which makes it quite suitable for SPI as you really only need clk and data 
to send info to it.
It's also not as timing dependent - 800KHz - 1 wire timing.
These parts are also forgiving if you get word boundary bound that you can 
always just push extra data through the chain - leaving valid data in the 
register
behind it. So for instance if you end up having to do 32-bit xfers into a 
144 bit chain, you can shift out 160 bits (5 xfers) and just have the 1st 
16 bits be
don't care. The remaining 144 will remain in register and get xfer'd when 
latched.

This is a fairly high power chip - haven't looked to see if there is a new 
version for new designs - so I'm expecting that you (David) must be
recycling an old display. If not, there are a bunch of similar chips out 
there - most are 16-bits wide - see TI, ST Micro, Silicon Touch, 
Macroblock, Toshiba...


Good Luck,
Matt


On Tuesday, March 22, 2016 at 12:12:31 AM UTC-5, William Hermans wrote:
>
> The way I see it is that you have two options. You could use the PRUs, or 
> you could use the McSPI hardware module. I would attempt to help you but I 
> really do not have any experience with the ws28xx style serial protocol 
> that many seem to use with external lighting of this type.
>
> I can tell you that a very simple, and cheap msp430g2553 project would be 
> more that enough to do all this - bare metal. So no needs for a cpld or 
> FPGA or anything fancy like that. But again as mentioned by Matt above, you 
> have to design a PCB, + circuit and the costs add up despite the fact that 
> a G2553 is only about $2-$3 sold as singles.
>
> Anyway, maybe someone here knows the McSPI module well enough to comment 
> on "shifting out" data to your matrix ? As in actually knowing what they're 
> talking about . . .
>
> How does this buffer work anyhow ? Is this like a bit field in both 
> dimensions, or what ? Kind of hard to grasp on a simple code glancing ;)
>
> On Mon, Mar 21, 2016 at 4:36 PM, David Good  > wrote:
>
>> Yes, I would love for someone to give me tips on setting up a periodic 
>> timer interrupt.  What I have might be the only way to really do it, but I 
>> would assume not.
>>
>> Thanks for your tips on ghosting.  I will use it when I start to see real 
>> data in the buffers rather than my simple test patterns.
>>
>> About using SPI.  Yes, this is what I was doing on the Raspberry Pi, but 
>> haven't done it on the Beaglebone yet.  I will definitely give it a shot.  
>> Bit banging the clock and data looks like it's costing me ~1ms per row as 
>> currently implemented.
>>
>> On the topic of dedicated hardware offloading the workload, I suppose 
>> that this is exactly what the PRUs are designed for.  Perhaps it's time to 
>> say Hello World to one of them.  Since this is a personal project, there 
>> aren't any real design requirements, so any option is open to me right 
>> now.  I was planning to layout a PCB to clean things up a bit because right 
>> now I have a hand soldered perf board with ribbon cables :)
>>
>> Thanks for the suggestions!  Let's see if someone can answer about a 
>> kernel timer interrupt.
>>
>> --David
>>
>> On Mon, Mar 21, 2016 at 6:07 PM, CEinTX  
>> wrote:
>>
>>> David,
>>>
>>> Without seeing your circuit of how you are setting up your rows & 
>>> columns to be driven, I'll take a blind stab at your issue.
>>> To get rid of artifacts / ghosting / etc...
>>> 1) Shift out all your data
>>> 2) Turn off your drivers and row power if that is available
>>> 3) Delay ~20us
>>> 4) Latch the data into your drivers
>>> 5) Delay ~20us or more
>>> 6) Change your row address
>>> 7) Enable your outputs and/or row power
>>>
>>> You must have some dead time between rows or you will get artifacts / 
>>> ghosting / whatever you choose to call it.
>>> You might get away with less than 20us but also you might need more 
>>> depending on your circuit.
>>> Too much dead time and you will get flicker - not enough and you guessed 
>>> it - artifacts/ghosting.
>>>
>>> For what it seems like you are doing, I'd use the SPI interface to shift 
>>> out your data in blocks of 16-bits  - 9 xfers gets you 144 bits out.
>>> You obviously could bit bang this but why when you have built-in 
>>> hardware that will do it for you. I'd think it 

Re: [beagleboard] UART4 not working - configuration kernel version 4.1.18

2016-03-22 Thread Robert Nelson
On Tue, Mar 22, 2016 at 5:40 AM, Le Costaouec Vincent
 wrote:
> Hi,
>
> I'm currently trying to configure and test UART4 on the BBB.
> So I my point is to connect the two pins and try to communicate with them
> through minicom.
> However I haven't any response from the board.
>
> for my dts i'm using this one :
> https://github.com/victorporof/BeagleBone-SPI-UART/blob/master/BB-UART4-00A0.dts

Well you have the pin's for uart4, but you've utilized uart5..  (this
worked in 3.8.x as the uart# was wrong.)

In v4.1.x: use

target = <>;

for uart4...

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


[beagleboard] BBB Broken? SPI signal is at 1.8v

2016-03-22 Thread Walker Archer
I've been building a custom cape for a robotics project and one of the 
chips I'm using is controlled via SPI.  I've used an oscilloscope to 
validate that the SPI is working as expected.  However, two days ago I 
noticed that the chip stopped responding and after scoping the SPI signal I 
can see that the BBB is sending the SPI data pulses at 1.8v.  The SPI 
signal is still happening... and the clock signal is still at 3.3v.  It's 
just the SPI data line that is only peaking at 1.8v.

So, I'm wondering if I've done something bad to my BBB or if I've somehow 
triggered a feature that I don't know about yet.  I'm attaching a photo of 
the oscilloscope screen that shows the issue.

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


[beagleboard] UART4 not working - configuration kernel version 4.1.18

2016-03-22 Thread Le Costaouec Vincent
Hi,

I'm currently trying to configure and test UART4 on the BBB.
So I my point is to connect the two pins and try to communicate with them 
through minicom.
However I haven't any response from the board.

for my dts i'm using this one :
https://github.com/victorporof/BeagleBone-SPI-UART/blob/master/BB-UART4-00A0.dts

for my configuration : 
( for the kernel, I follow this tutoriel : 
https://eewiki.net/display/linuxonarm/BeagleBone+Black
)

# uname -a
Linux beagle01 4.1.18-bone20 #4 Fri Mar 18 15:16:19 CET 2016 armv7l 
GNU/Linux
# lsb_release -da
No LSB modules are available.
Distributor ID:Debian
Description:Debian GNU/Linux 8.3 (jessie)
Release:8.3
Codename:jessie

# dmesg | grep tty
[0.00] Kernel command line: console=ttyO0,115200n8 capemgr.
enable_partno=BB-UART4 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait
[0.000298] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'
[3.102953] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 154, 
base_baud = 300) is a 8250
[3.903811] console [ttyS0] enabled
[6.705576] systemd[1]: Expecting device dev-ttyS0.device...
[7.174265] systemd[1]: Starting system-getty.slice.
[7.192955] systemd[1]: Created slice system-getty.slice.
[7.198476] systemd[1]: Starting system-serial\x2dgetty.slice.
[7.222958] systemd[1]: Created slice system-serial\x2dgetty.slice.
[ 1023.102502] 481aa000.serial: ttyS5 at MMIO 0x481aa000 (irq = 187, 
base_baud = 300) is a 8250


# cat $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-UART4

# ls -l /dev/ttyS*
crw--- 1 root tty 4, 64 Mar 22  2016 /dev/ttyS0
crw-rw 1 root dialout 4, 65 Sep  7  2015 /dev/ttyS1
crw-rw 1 root dialout 4, 66 Sep  7  2015 /dev/ttyS2
crw-rw 1 root dialout 4, 67 Sep  7  2015 /dev/ttyS3
crw-rw 1 root dialout 4, 68 Sep  7  2015 /dev/ttyS4
crw-rw 1 root dialout 4, 69 Mar 22 11:15 /dev/ttyS5

# cat /boot/uEnv.txt 
uname_r=4.1.18-bone20
optargs=capemgr.enable_partno=BB-UART4

So finally I shorted P9_11 and P9_13 of the BBB and I launch minicom :
# minicom -b 9600 -o -D /dev/ttyS5
In addition, here is the configuration of the serial port setup for minicom
| A -Serial Device  : /dev/ttyS5
| B - Lockfile Location : /var/lock 
| C -   Callin Program  :   
| D -  Callout Program  :   
| E -Bps/Par/Bits   : 9600 8N1  
| F - Hardware Flow Control : No
| G - Software Flow Control : No 


So normally, after all, I sould see an echo on the minicom but nothing.
So I didn't really understand why did I do wrong ?

Notes :
I don't know if it is link but :
- I find strange the fact that I configure UART4 but it is ttyS5 which is 
configure
- The minicom stay offline

CTRL-A Z for help | 9600 8N1 | NOR | Minicom 2.7 | VT102 | Offline | 
ttyS5 

So if anyone have an Idea.
thanks by advance
Regards
Vincent


-- 
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] Issue with USB devices through a USB hub

2016-03-22 Thread Chris Morgan
On Tuesday, March 22, 2016, Karina  wrote:

> Hi,
>
> I have a unpowered 2-port USB hub that I have connected to the BeagleBone
> Black (Rev C). I have two (serial over ) USB devices connected to the two
> port of the USB hub. They are are not powered to begin with. When i power
> up the Beagle Bone, i see the USB hub listed in the output for 'lsusb'. Now
> i power up the two USB device hanging off the USB hub. But i do not see the
> USB devices listed in the output of 'lsusb'. Also, there is no /dev/ttyUSB*
> file. For my project, it wold be ideal for the beagle bone to be powered up
> before these USB devices. Any idea on what i have messed up or missed?
>
> I have verified that if i connect the USB device directly into the USB
> port on the beagle bone black, then I can power the USB device after the
> beagle bone is powered up and it shows up in the output of 'lsusb' and i
> can control the device.
>
> Here are some more specifics about my setup.
> 1. I am using the beagle bone black Rev C board.
> 2. I am running Debian linux (jessie v 8.3) on the beagle bone black . The
> version of the linux kernel is v3.8.15 -bone 71.
> 3. I am powering the beagle bone with the power supply ( instead of over
> the USB connector for etherent over USB).
>
> Thanks,
> Karina
>
> --
> 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.
>




Have you tried powering the hub and devices up before the bbb?

Chris

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

2016-03-22 Thread Pierce Nichols
So... I have a BBB rev C with a wifi dongle. I downloaded the 8.3 disk
image, started it, no channels blocked by rfkill when I first started
with the new image. I was able to modify /etc/network/interfaces and
connect to wifi. I then ran the apt-get update/upgrade combo. After
that, I rebooted... and rfkill once again defaults to blocked.
Suggetions?

-p

On Thu, Feb 4, 2016 at 4:55 PM, Robert Nelson  wrote:
> On Thu, Feb 4, 2016 at 5:11 PM,   wrote:
>> Hi,
>>
>> To start with, I'm running Debian 8.2 with kernel version 4.1. I'm trying to
>> get the wifi, wlan0 interface, to come up on boot, however rfkill is
>> blocking it. I can get it working again by running rfkill unblock all and
>> ifdown wlan0, ifup wlan0 however this setting doesn't persist on reboot.
>> I've attempted writing a service to run the rfkill unblock all command at
>> startup but it doesn't work very consistently. Regardless, there should be a
>> built in way to prevent rfkill from ever blocking an interface. If anyone
>> could help me out with this I'd greatly appreciate it.
>
> I pushed a systemd update to fix this rfkill problem for a few years..
>
> Double check that you have the fix:
>
> sudo apt-get update
> sudo apt-get upgrade
>
> 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.
> For more options, visit https://groups.google.com/d/optout.



-- 
Pierce Nichols
Principal Engineer
Logos Electromechanical, LLC

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