[beagleboard] Re: Beaglebone: Bonescript on Ubuntu, GPIO Pins not working

[garyamort]

On Tuesday, September 24, 2013 7:00:38 PM UTC-4, dsm...@gmail.com wrote:
>
> I have Ubuntu 13 and a beaglebone black.   The ubuntu is from the 
> beaglebone image section which I flashed onto the bone.
>
> uname:   Linux arm 3.8.13-bone21 #1 SMP Fri Jun 14 03:10:29 UTC 2013 
> armv7l armv7l armv7l GNU/Linux
>
> I compiled nodejs from source and it's version 0.10.18.
>
> node -v  :   v0.10.18
>
> I'm having a big problem installing bonescript.  When I run "sudo node 
> install -g bonescript" I get the following:
>
> ubuntu@arm:~$ sudo npm install -g bonescript
> [sudo] password for ubuntu: 
> npm http GET https://registry.npmjs.org/bonescript
> npm http 304 https://registry.npmjs.org/bonescript
>

Your getting a 304 error, so the problem is in trying to download 
bonescript from npmjs.org 

When I just tried going to https://registry.npmjs.org/bonescript in my 
browser, Chrome complained about the certificate for that website, so my 
guess would be that npm defaults to some strict certificate checking.

Try installing from http://registr.npmjs.org/bonescript instead

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

[beagleboard] Re: LCD7 Portrait mode in GDM

[garyamort]

On Monday, September 23, 2013 3:09:16 PM UTC-4, Louis McCarthy wrote:
>
> WellIt is not using the fbdev module.it is using Kernel Mode 
> Setting (KMS) driver.
>

KMS is a TYPE of driver, but it is not the driver.  IE on my workstation I 
use the open source KMS radeon driver.  

I'd really like to see a copy of /var/log/Xorg.0.log and if you don't mind 
dumping dmesg to a text file and posting that as well I'd appreciate it.

Simplest way of getting ALL the data to go through.

Again, don't be too discouraged.  Video issues with non-standard/current 
hardware are usual with Linux.  I tend to use older hardware and run into 
problems with Radeon cards all the 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/groups/opt_out.

Re: [beagleboard] Re: Is it possible to connect an SHT75 sensor to I2C bus of BBB?

[garyamort]

On Sunday, September 22, 2013 5:10:22 PM UTC-4, Eric Westphal wrote:
>
> It looks like it has to be done within the device tree, setting gpio_data, 
> gpio_sck, and supply_mv in a platform device struct.  I have yet to tackle 
> the device tree myself, and it's too late here for me to start that 
> tonight...
>
>
>
I think your right about it being in the device tree - I know there is a 
way of specifying drivers and such there, but have not gotten around to 
needing that yet. 

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

[beagleboard] Device tree for HDMI and HDMI-Audio

[garyamort]

Can someone point me to the source code for the HDMI and HDMI-Audio device 
trees?

I've run into an odd situation where when booting Ubuntu under the latest 
Robert Nelson 3.8 kernel, the HDMI-Audio device tree fails to load when the 
BBB is plugged into the ethernet network at bootup.  I seem to get a 
complaint about the pin for the clock already being in use - which makes 
sense since I believe the ethernet interface also requires that same clock 
and probably enables it.   I was thinking I could test my theory by 
dropping that pin from the source and compiling a new DTBO to test - but I 
can't find the sourcecode for that one.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

[beagleboard] Re: LCD7 Portrait mode in GDM

[garyamort]

On Wednesday, September 25, 2013 3:21:14 PM UTC-4, Louis McCarthy wrote:
>
> Thanks for sticking with me. Knowing that KMS is a type helps me 
> understand more about the video system.
>

Hmm, learn something new.  modesetting is a driver too!  I thought it just 
referred to the KMS type of driver, but it also refers to a fallback driver 
for X11.

And it only supports a couple of options, one of which is not rotate!


If your using some form of debian variant, you can try:
"sudo apt-get install xserver-xorg-video-fbdev"

Install the basic fbdev driver and give that a shot.

You can also try xserver-xorg-video-omap and xserver-xorg-video-omapfb
[the name may be slightly different, so you can also try "apt-cache search 
fbdev", omap and omapfb


Now the bad news: I /think/ none of the above will work because they will 
only be used by the HDMI display by default.  Checking the device tree 
source for BB-BONE-LCD7 I see lines such as:
/* Settings for ThreeFive S9700RTWV35TR / LCD7 cape: */
panel {
compatible = "tilcdc,panel";

My gut feeling is that this specifies the driver to use: ie use the 
tildc-panel driver.  You could try exiting x-windows and then running
"sudo modprobe -v panel-generic-dpi" [might need to do "sudo modprobe -v 
panel-generic-dpi.ko"]

If that succeeds, then reload x-windows and check the x11 logs to see if 
the driver has changed.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

[beagleboard] Re: How can I improve processing time on BB?

[garyamort]

On Thursday, September 26, 2013 4:47:17 AM UTC-4, 서재필 wrote:
>
> I'm trying to use Beagle Board for real-time audio-processing.
>  
> I bought this one because of these clock speed(1Ghz).
>  
> My algorithm running time is about 0.6 ms for one frame in my 
> computer(window7, 2.6Ghz Quad-core).
>  
> But when I run my algorithm on BB(Angstrom, 1Ghz), it spends about 
> 40ms for one frame.
>  
> Isn't it ridiculous? Because clock speed defference is just 2 or max 3 
> times. But measuring processing speed is not.
>  
> Wha'ts wrong with it?
>


Assuming that you can make a fair comparison of clock speed to 
performance[which you can't], your difference is over 10 times, not 2 or 3. 
 Your comparing a quad core device with a single core device.  Right off 
the bat this will cause issues since Linux is not real time operating 
system tuned for a specific set of tasks, it is a general operating system 
- so it is running multiple processes at the same time.  On your quad core 
device, you have some buffer since the running programs will be spread 
between different processors.  The Bone will be running everything on one 
core.


Firstly, did you make sure to adjust the priority of your process to give 
it a big share of the processor space?  If running from the command line, 
for example "runmyprogram" instead run it as "sudo nice --adjustment=-20 
runmyprogram*"*

Secondly, you have to consider what your doing.  Your doing audio 
processing.  What do musicians do for that? They use Linux with the Real 
Time performance enhancements installed.  This lets you give your process 
higher priority over almost everything else, including most of the 
operating system.  So you need to recompile your kernel for that.

Thirdly, your processing a large amount of data, correct?  And your trying 
to store it on the "hard drive" I bet - which is a slow MMC card[as opposed 
to your fast SATA hard drive on your windows box].  The simple solution 
there is to sacrifice some memory and setup a ram disk.  Check your 
/etc/fstab file - you probably already have a small ramdisk setup there to 
map to the /temp directory using the tmpfs file system.  Just increase that 
up to 128M and do all your file processing in the /temp folder.

Fourthly, avoid disparaging seeming comments like "isn't it ridiculous" and 
instead phrase them in such a way as to take responsibility for the failing 
such as "I'm sure I am doing something wrong.  What methods are there to 
increase performance?"

Speaking for myself personally, it makes the difference when I answer 
between my taking the time to do a few google searches and provide links to 
articles explaining how to implement something vs just giving the answers 
and leaving looking up implementation to the other party.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

Re: [beagleboard] Re: Modbus

[garyamort]

On Wednesday, September 25, 2013 2:00:52 PM UTC-4, Gerald wrote:
>
> The BB cannot be modified. But, there is another board that supports it.
>
> http://www.ti.com/tool/tmdxice3359
>
> It requires special SW in the PRU to support it.
>
> Gerald
>
>
>
I'm not at all familiar with Modbus, so I expect I am wrong, but would not 
his use case be supported?  He's not doing direct Modbus communication, but 
rather encapsulating it inside TCP/IP and then sending it over the network. 
 The gateway device is responsible for converting the TCPIP packets into 
correct modbus format for the actual modbus network[and vice versa going 
back]

Wouldn't the PRU/ethernet configuration be used if using the Ethernet 
wiring to run an Ethercat network ?

For testing, instead of node.js I'd go with libmodbus as it is an extremely 
mature implementation: http://libmodbus.org/

Install libmodbus and compile the test apps 
https://github.com/stephane/libmodbus/tree/master/tests and run them.

Then modify the bandwidth-client and random-client to swap the localhost 
address[127.0.0.1, port 1502] with the gateway adddress[192.168.7.3, port 
502] and rerun them to see if you get a connection.

After that, your dependent on what you actually want to do - you will need 
to copy one of the client apps and modify it to send the commands your 
interested in.

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

Re: [beagleboard] Re: Modbus

[garyamort]

On Thursday, September 26, 2013 8:43:44 AM UTC-4, garyamort wrote:
>
>
>
>
> Then modify the bandwidth-client and random-client to swap the localhost 
> address[127.0.0.1, port 1502] with the gateway adddress[192.168.7.3, port 
> 502] and rerun them to see if you get a connection.
>

Opps. I think I have my terminology wrong.  I automatically think of 
"master" as the server and "slave" as the client - but for Modbus this is 
reversed?  Ie the Master is the system which makes the connection and 
requests data.  While the slave is the one to wait for connections and 
respond?

If that's the case, then you would need to change the port number in 
bandwidth-server and random-server from 1502 to 502[to match the HMI 
Master] and run them, then the HMI Master can connect to them and try to 
read/write data.  Obviously once you have it connecting then you will need 
to modify your server code to respond to the appropriate commands.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

[beagleboard] Re: Beaglebone Black ... What a Bull Shit !!!

[garyamort]

On Thursday, September 26, 2013 5:09:30 AM UTC-4, Diogene wrote:
>
> We have tested BBB with LCD7 cape and Unbuntu 12.04 & 13.04.
> Nothing does work as expected!!!
> Use of Touchscreen is hawfully slow and use of ADC with this screen hangs 
> up the system!
>
> How to get a such bad system. It is the same with angstrom distrib!!!
>
> We had developp a specific cape and we can put it in garbage!!!
>
>
I'll happily pay for shipping if you want to send me the cape and board. :-)

 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

Re: [beagleboard] Re: Touchscreen Jitter / Jumping on Beaglebone Black LCD Capes

[garyamort]

On Tuesday, September 24, 2013 5:33:36 AM UTC-4, Anguel wrote:
>
>
>  
>
>> The concept here is the people that buy them, know how Linux works and 
>> can get things going themselves and make what ever tweaks are 
>> required. Supporting all the different kernel versions and distributions, 
>> that is no feasible.
>>
>
> Probably this is the nice business concept used by TI, CircuitCo, etc. 
> Sell chips and boards, make money, but let the open source community write 
> the software and support everything for free. Just make a product, label it 
> to be "for developers" and sell it without any support.
>


There is a difference between "any support" and "not supported".

"Not supported" means that it has been tested under a very specific 
software configuration and works for that configuration.  If you check the 
Linux Source code, you will find a LOT of code written by Texas Instruments 
- so they are certainly providing SOME support.

Interestingly, if you check the LCD drivers you will find that for small 
LCD screens, most of those drivers come from Nokia[or at the very least are 
based off Nokia drivers].

So no, it is not "the community" that is expected to support things "for 
free".  How it works is that Nokia, a cell phone manufacturer, decides to 
use a Texas Instruments processor in a cell phone.  They decide to use a 
specific model of LCD screen.   They pay developers to create an LCD driver 
for a Texas Instruments supported linux kernel.  If they find a bug in the 
TI LCD interface, they contact TI and TI works with them to fix it.  Once 
they have the TI supported kernel working, they then try to use the same 
driver in the latest version of Android.  If it doesn't work, their 
developers have to figure out what changes were made that broke something, 
and then they fix it.  Considering that their going to order 100,000+ TI 
processors, they probably pay TI for support so their developers and TI's 
developers work on the driver.

When that is all done, this driver which was written by Nokia with Texas 
Instruments help is then given to "the community" for free - under the 
terms of the standard GPL license, including:
"THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY 
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT 
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY 
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, 
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM 
IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, *YOU ASSUME THE COST OF 
ALL NECESSARY SERVICING, REPAIR OR CORRECTION*."

Please note that last line as it is the one you seem to object to, and yet 
it is the very reason companies are willing to give away applications they 
paid developers to write to the community - as they are not required to 
support them and you agreed to assume the cost.

Android does NOT use the X11 window system, so the driver written by Nokia 
for their phone may not work properly for a Ubuntu desktop.  As the reason 
Nokia paid developers to write it was for an android phone, I can't see any 
reason to expect them to make sure it works for Ubuntu "for free".

Your receiving a huge amount of support from TI and CitcuitCo - however 
your "tone of voice" is demanding that they FIX the problem.  They are not 
required to fix the problem, and you agreed to assume the cost of all 
correction.  In all fairness, they should be billing you for the time spent 
responding to you as you agreed to "assume the cost".  

You have identified a problem.  Programmers from "the community", "Texas 
Instruments", and "CircuitCo" have acknowledged the problem, done a good 
bit of deductive reasoning to determine where the problem lies and the 
general idea of how to fix it and given this information to you for free.

There are four solutions specifically for you:

A) Use the linux versions that are known to work for the device, move on 
with your life.

B) Wait for someone to be willing to fix it "for free"

C) Fix it "yourself" - note this does not mean you personally, this means 
either you fix it or hire someone to fix it.

D) Give up in frustration and use a different product.  If you wish, loudly 
proclaim that "everything just works out of the box".  A few weeks down the 
road you will discover a different problem with the interaction of a 
completely different set of drivers that the vendor of that product doesn't 
use and does not support.  When you do, if you choose to loudly proclaim 
your "solution" you can choose to acknowledge that your solution that "just 
worked" actually does not work so others who may be misled by your comments 
to also switch don't suffer the same issue.  Or you can keep quiet about it 
to avoid looking foolish and thus cause economic harm to others.


As a summary "not supported" means that the company is not

[beagleboard] Re: Anyone interested in writing or helping with a media playback app?

[garyamort]

On Thursday, September 26, 2013 2:24:11 AM UTC-4, Mike Langensiepen wrote:
>
> Apologies in advance if this is in the wrong area
>
> Is there an app or does anyone fancy giving me a price for writing an app 
> do to the following:
> Play an ambient audio/video track (whatever format needed)
> On receiving a trigger input switch to playing another specified 
> audio/video track
> When 2nd track is finished go back to playing the ambient track.
>
> Tracks would need to be full HD
>
>
I know that VLC Media player has a web interface for adding items to the 
playlist and playing videos remotely.  It can also be configured to loop 
the playlist.

So with that, you could invoke VLC from the command line and give it a file 
to play automatically - then use the web interface to "trigger" switching 
to another file immediately while leaving the initial file in the playlist 
to be looped back to once done.

I'm fairly sure ALL the major video player apps for linux have a web 
interface.

Of course this moves the time/cost from "writing an app" to "configuring 
the system" as you will need to setup your linux distribution, have it 
start the x-windows environment upon bootup[but not a desktop, just the 
windowing system], and then start VL - that is assuming you don't want a 
desktop, you just want a pure video player.

Then you can design your trigger app. 

Not a non-trivial amount of time, mind 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/groups/opt_out.

[beagleboard] Re: How can I improve processing time on BB?

[garyamort]

On Thursday, September 26, 2013 8:24:38 AM UTC-4, garyamort wrote:
>
>
>
> On Thursday, September 26, 2013 4:47:17 AM UTC-4, 서재필 wrote:
>>
>> I'm trying to use Beagle Board for real-time audio-processing.
>>
>>
Oh, I just ran across this link[again] when trying to fiddle with my 
desktop sound  - it has no direct bearing for me  but I'd suggest you take 
a look at it.

If your doing Real Time Audio Processing, there is a group dedicated to 
doing just that and have produced a bunch of tools in an open source 
package for working on it.  It's called "Jack", http://jackaudio.org/

Note that the consensus of the Jack Community[which includes professionals 
in audio development] is that the Real Time Kernel options aren't needed 
for most use cases.  http://jackaudio.org/realtime_vs_realtime_kernel

*"No. Realtime scheduling is available on all Linux systems no matter what 
kernel they use, and current versions of JACK use it by default. A kernel 
built with the realtime patches (an "RT kernel") is needed only if:*


   - *You want to run JACK with very low latency settings that require 
  realtime performance that can only be achieved with an RT kernel*
  - *Your hardware configuration triggers poor latency behaviour which 
  might be improved with an RT kernel*
   
*Most users do not need an RT kernel in order to use JACK, and most will be 
happy using settings that are effective without an RT kernel."*


Personally, I'm such an extremely lazy programmer that I'd START with 
implementing my application using Jack and a reasonably sized tempfs drive 
to store files while working - and then ask my performance tuning questions 
on their mailing list as 80% of the issues won't be related to the hardware.



-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

Re: [beagleboard] Re: LCD7 Portrait mode in GDM

[garyamort]

Thanks Gerald, I went ahead and sent that suggestion on the CircuitCo 
directly.

On Thursday, September 26, 2013 3:09:11 PM UTC-4, Gerald wrote:
>
> That suggestion needs to go to the supplier of the cape.
>
> Gerald
> . 
>
>
> On Thu, Sep 26, 2013 at 2:08 PM, garyamort 
> > wrote:
>
>>
>>
>> On Thursday, September 26, 2013 2:15:39 PM UTC-4, Louis McCarthy wrote:
>>
>>> Success! 
>>>
>>> I installed fbdev (2:0.4.2-r17.0.12):
>>> opkg install xf86-video-fbdev
>>>
>>> I then enabled fbdev in X11
>>>
>>
>> Thanks for taking the time to troubleshoot all this Louis!  I took the 
>> liberty of emailing Gerald Coley directly via the e-mail link on 
>> CircuitCo's wiki [
>> http://circuitco.com/support/index.php?title=BeagleBoneBlack] and asked 
>> him to add your config info to the wiki as screen rotation seems to be a 
>> recurring issue with the BBB, and at least having a good "how to" for one 
>> flavor of linux should point the way for others!
>>  
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you 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/groups/opt_out.
>>
>
>

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

[beagleboard] Re: LCD7 Portrait mode in GDM

[garyamort]

On Thursday, September 26, 2013 2:15:39 PM UTC-4, Louis McCarthy wrote:
>
> Success! 
>
> I installed fbdev (2:0.4.2-r17.0.12):
> opkg install xf86-video-fbdev
>
> I then enabled fbdev in X11
>

Thanks for taking the time to troubleshoot all this Louis!  I took the 
liberty of emailing Gerald Coley directly via the e-mail link on 
CircuitCo's wiki [
http://circuitco.com/support/index.php?title=BeagleBoneBlack] and asked him 
to add your config info to the wiki as screen rotation seems to be a 
recurring issue with the BBB, and at least having a good "how to" for one 
flavor of linux should point the way for others!

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

[beagleboard] BBB Video Drivers

[garyamort]

As a stick in the ground, I wanted to provide a quick summary of  video 
drivers for the BeagleBoneBlack.

There is the Xorg Kernel Mode Setting Driver : an extremely basic frame 
buffer driver and the fallback driver if no better Xorg driver is found. 
 It has extremely limited functionality and does not support screen 
rotation.

There is the Xorg fbdev Driver: a still basic frame buffer driver, but it 
does support some configuration options including rotate.

There is the tilcdc Driver:  Released by Ron Clark at the beginning of 
2013. http://lwn.net/Articles/533731/  This driver, if installed, is 
configured via the Device Tree.  For example, see the BB-BONE-LCD7-*.dts 
files.   These files contain the pin connection info and the LCD display 
configuration information and will be used by the tilcdc driver to 
configure the display.   Note: I do not know what configuration options are 
supported for userland configuration[ie setting rotation on bootup, or 
configuring rotation in the Xorg.conf file]  This drivers sourcecode is 
located at drivers/gpu/tilcdc

There is the omap  frame buffer driver: Located at drivers/video/omap   
This driver requires LCD panel configuration information which is available 
for some LCD panels in the same directory as the driver.  Does this work 
for the BeagleBoneBlack?

There is the omap2 frame buffer driver: Located at 
drivers/video/omap2/omapfb.  This driver requires LCD panel configuration, 
of which many are already written - see drivers/video/omap2/displays for 
them.  Does this work for the BeagleBoneBlack?

There is the PVRSRVKVM Driver: Uses the built in SGX graphcis processor to 
accelerate graphics processing and offload processing from the CPU.  This 
driver may not work under Linux Kernel version 3.8.   According to the 
latest release notes, http://processors.wiki.ti.com/index.php/RN_4_10_00_01, 
version 4.10.00.01 works for the Linux 3.8 kernel.  From the release notes:

Validation information

*NOTE - *

*1. This release has been tested on AM parts only.* 

*2. This release is build tested only for 387x(TI814x) & 389x(TI816x) & DM 
parts.* 

*3. This release is build tested only against 3.8 kernel. *


The BBB uses a 335x processor, not 387x or 389x - so it does not appear 
that it has been tested for the BBB, but it has been tested for the 3.8 
kernel.

Also note that the above statement is contradicted later in the release 
notes by:

Kernel(Linux PSP) versions supported or used for validation

Please note that this release has been tested only on AM devices. No 
testing has been done on the DM parts. Only the following devices have been 
tested & details below -


   - AM335x - 3.2 kernel - 
  http://arago-project.org/git/projects/linux-am33x.git
   - 
  - AM335x Linux PSP 04.06.00.10
 - Branch – v3.2-staging, TAG - v3.2_AM335xPSP_04.06.00.10-rc1, 
 commit id -c8cce6279f5c126cbf6b6054f1ea0148bfc19511
  

   - AM35xx/AM37xx - 2.6.37 kernel
   - 
  - Linux PSP Release : 04.02.00.07.
 - Display drivers with DSS2 support ie, CONFIG_OMAP2_DSS=y
  
 


My assumption is that the earlier statement overrides the later statement.

 To add to the confusion, many of these drivers are used in combination. 
 For example, you might have both the Omap 2 Framebuffer Driver AND the SGX 
Driver installed.  The SGX driver overrides some of the functions in the 
Omap driver(?).   Xorg configuration would be for the Omap driver, not the 
SGX driver[?]

Please correct any of my misassumptions in the above.

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

Re: [beagleboard] BBB Video Drivers

[garyamort]

On Thursday, September 26, 2013 4:02:34 PM UTC-4, RobertCNelson wrote:
>
> On Thu, Sep 26, 2013 at 2:54 PM, garyamort > 
> wrote: 
> > 
> > There is the tilcdc Driver:  Released by Ron Clark at the beginning of 
> 2013. 
> > http://lwn.net/Articles/533731/  This driver, if installed, is 
> configured 
> > via the Device Tree.  For example, see the BB-BONE-LCD7-*.dts files.   
> These 
> > files contain the pin connection info and the LCD display configuration 
> > information and will be used by the tilcdc driver to configure the 
> display. 
> > Note: I do not know what configuration options are supported for 
> userland 
> > configuration[ie setting rotation on bootup, or configuring rotation in 
> the 
> > Xorg.conf file]  This drivers sourcecode is located at 
> drivers/gpu/tilcdc 
>

Extra note: There is Device Tree Documentation for tilcd, see
https://github.com/torvalds/linux/tree/master/Documentation/devicetree/bindings/drm/tilcdc


 

> > 
> > There is the omap  frame buffer driver: Located at drivers/video/omap   
> This 
>
> No... different IP block... tilcdc != video/omap 
>
> > There is the omap2 frame buffer driver: Located at 
>
> No... different IP block... tilcdc != omapfb 
>
>
Great!  Thanks for the correction.  So it seems like the most basic choice 
is between the fallback driver, fbdev, and tilcdc.

I'm guessing that I am incorrect there and that tilcdc is a more low level 
driver which is loaded regardless, and fbdev just provides some higher 
level Xorg config options.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

Re: [beagleboard] Re: Touchscreen Jitter / Jumping on Beaglebone Black LCD Capes

[garyamort]

On Friday, September 27, 2013 4:47:44 AM UTC-4, Anguel wrote:
>
> Gary,
>
> Thank you for your extensive and philosophic point of view. I just don't 
> understand how Nokia is related to the problem...
> It is clear that at some point in time some bug has slipped into the TI 
> SoC ADC kernel drivers or the touchscreen drivers that use these ADC drivers



If your talking about touchscreens interfaces and LCD screens, your very 
likely using code written by Nokia or one of the other major cell phone 
manufacturers.  If there is a "bug" in the code it is likely that they 
wrote it.  Because the code DOES work under a different version of Linux 
and works under versions of Android - it is not even fair to say the the 
driver has a bug in it.  The driver works for the system it was written in. 
 Why it doesn't work in later versions of Linux may be because there was a 
true bug which only showed up when something else in the kernel changed. 
 It may also be that there were changes to the api functions being used by 
those drivers which changed the way they work.  The word bug tends to be 
taken negatively, as in the programmer of the code containing the bug made 
a mistake.  In the case of changing API's there was no "mistake".  

To understand why you have to understand how Linux itself is developed.   
There are thousands of drivers in the codebase for different items.   For 
those drivers to get into the source tree they must compile AT THE TIME 
THEY ARE ADDED, they must follow Linux Coding Standards, they must work AT 
THE TIME THEY ARE ADDED, and they must be licensed under the GPL.

Once they are IN the codebase then when changes are made to any of the 
functions they use, the programmer making those changes MUST run an 
automatic program to find every single call to that function and fix them - 
hopefully the process will be automatic.   Those changes have to follow the 
same rules as above PLUS every bit of code that they modified[all the 
drivers] must still compile successfully.  Note: it doesn't have to WORK, 
it just hast to compile.  That is because it would cost millions of dollars 
to test every single bit of hardware[since you have to have access to every 
single bit] to ensure that the drivers still function.  The best that can 
be reasonably expected is that they compile.

A better word to use is incompatibility - as you simply have no idea where 
the "bug" is so unless you specify each and every component that is being 
integrated then saying there is a bug in X companies code comes across as 
blaming the companies listed.

As for why I went into the long explanation, you were making comments about 
how TI expects "the community" to support their product for free - so I was 
giving you the true picture - how is a symbiotic relationship and how in 
this case your benefiting from work done by TI and Nokia - and that "the 
community" is expected to modify that work for their own usage if needed.
 

> . What I am angry about is that CircuitCo (and 4D Systems) know about the 
> problem. Besides the fact that they don't do anything to fix it (although 
> afaik they have good people working on Angstrom), they could at least post 
> a notice on their product's webpages so customers don't have to chase where 
> the bugs come from for weeks.
>


The comments in this thread indicated to me that they contributed to fixing 
the problem - in this case identifying where they think the problem lies 
and therefore cutting down on the time needed to debug code.

I will agree 100% that CircuitCo should update their product pages to 
include notices of compatibility issues as well as listing a known good 
software version compatibility matrix.  I only agree about 60% that 4D 
Systems should be doing this as well.

 

> The fact that they have still not done it makes me think that they want to 
> keep their sales high. Again, the prices for the LCD boards are not low and 
> we cannot talk about break even here.
>


We can't?  Consider the following:
SainSmart makes a similiar LCD module for Ardunio:
http://www.sainsmart.com/arduino-compatibles-1/lcd-module/sainsmart-3-2-tft-lcd-display-touch-panel-pcb-adapter-sd-slot-for-arduino-2560.html
  
It costs 16$.  If you go to ebay you can find similiar products for 12$.

Compare this to CircuitCo's 3" board:
http://www.mouser.com/ProductDetail/CircuitCo/BB-BONE-LCD3-01/?qs=2TuNuDMZFZ5UQcnBUi0fGw%3D%3D&gclid=CIy6vY7n67kCFUWd4AodLxkAqg
Which is 70$.

So what are the differences?  Well, first of all, the pin layouts for the 
boards are completely different.  BeagleBone capes have 2 rows of pins, 
while the Ardunio board has 1 row of pins.  I know that pins seem like a 
nothing cost, but the truth is that every time you add big bulky items to a 
board - you increase production costs.  So taking a stab in the dark, I'm 
going to guess that we added 4$ to the cost of the card(20$).  In addition 
to this, a beaglebone cape needs an EEPROM on it which is programmed with 
t

[beagleboard] Re: BBB, Ubuntu 13.10 (RCN distro) - stk1160 (EasyCap) not recognized

[garyamort]

On Saturday, September 28, 2013 4:50:14 PM UTC-4, Ivan Korman wrote:
>
>
> Hi
>
> I'm running on my BeagleBone Black Ubuntu 13.10 from Robert Nelson (full 
> prebuilded install from https://rcn-ee.net/deb/rootfs/saucy/, as-is, no 
> customizations) and I'm trying to use USB video capture device, EasyCap 
> which is based on stk1160 chipset. As I'm running kernel 3.8.13-bone28, my 
> understanding was that stk1160 should be supported in the kernel
>


It should be. Checking both my Mint desktop and my Ubuntu bone kernel 
config options, they both compile stk1160 as a module.

So my question would be, are you plugging the webcam directly into the 
large USB plug or do you have a USB hub attached to it to allow multiple 
devices to connect?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

[beagleboard] Re: Fast ADC access on BBB causes buffer underflow error (seg fault)

[garyamort]

On Saturday, September 28, 2013 12:21:37 PM UTC-4, geo...@gmail.com wrote:
>
> I discovered a problem when accessing the Analog pins on the BBB.
>
> Whenever I would read the value of the pins, I needed to read a second 
> time to get the correct value. This is because the first file read 
> initiates the conversion, and the second gets the actual value. I found 
> that if I did the read back to back, with no delay in between, the second 
> read would fail by way of a buffer underflow (reading the file using the 
> ifstream class in C++). I am assuming this happens because the conversion 
> is not complete, and as such there is no data yet.
>
> My question is this: Is there a way to check if the conversion is done 
> before attempting the read? I need these reads to happen pretty quick, so I 
> cant afford to burn 50ms before the second read, and if I try to read them 
> too much quicker than that, I get an occasional seg fault from the 
> underflow.
>


See 
http://beagleboard-gsoc13.blogspot.com/2013/07/sampling-analogue-signals-using-adc-on.html
 for 
some more info and code on doing "continuous" ADC samples.

The important bit I think would be that you can't just read from the file, 
you need to use some version of poll on the file descriptor so as to wait 
for the data to be ready, then you can go ahead and read from it.  Also 
since I think poll() will return when there is any change to the file 
descriptor[ie file permissions change, file data changes, file owner 
change, etc] to be safe you need to doublecheck that there actually IS data 
after poll() returns and loop if there is not.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

Re: [beagleboard] Re: Beaglebone + LIDD-capable LCD

[garyamort]

On Monday, September 30, 2013 2:15:22 PM UTC-4, engka...@gmail.com wrote:
>
> Yeah. I think I can disable the onboard HDMI framer and enable my own LCD 
> display through the cape manager at runtime or set it in the Env.txt to do 
> it at boot process( as I have read from here 
> http://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/exporting-and-unexporting-an-overlay
> ). 
>


It would be easiest to disable the onboard HDMI framer at boot time, and 
then you can test enabling and disabling the LCD display via the cape 
manager.

IE modify  the DTS.  Don't even worry about touchscreen for now, just focus 
on graphics.

Modify and compile the DTS, place the compiled mods into the /firmware 
directory and then send the file name to the cape manager, ie

echo yourfilename >/sys/devices/bone_capemgr.*/slots


The file is fairly self explanatory and as long as your sticking with 16 
data lines your in good shape.

>From the BB-BONE-LCD4-01 file you would delete the following sections:
tsadc - this is for the touchscreen, just remove it for now to avoid errors 
while loading it
gpio-leds-cape-lcd4 - this is for some status led's on the lcd.   While 
they should not cause any problems, if you remove the section then you 
won't have any problems


The panel section is the important one:
panel {
compatible = "tilcdc,panel";
...

This tells Linux that it should load the tilcdc panel driver and gives the 
configuration information.   Normally, the tilcdc driver would be loaded 
upon bootup and when a new device was found[either from the hdmi connection 
or from an i2c connection] it would auto configure based on the data.   
Since your just using a raw LCD panel, you have to manually load it.  Make 
sure to adjust the panel-info and display-timings section to match your LCD 
configuration.


 One of the really cool things with the device tree  is how you should be 
able to configure/adjust settings for all sorts of drivers automatically. 
 Pre-device tree tended to require a seperately compiled "driver" for every 
variation.  Browsing through older video drivers, I find large numbers of C 
files that only exist to define panel timings for different models of 
LCD's.   These files are duplicated in lots of different video display 
drivers to add the panel definitions there.

Wheras with the device tree and TI's addition of support for fragments, you 
can place the timing information in one DTS fragment, and then include 
those fragments in the DTS file on a driver by driver basis.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

[beagleboard] Re: BBB RT patch

[garyamort]

According to the RT Wiki
https://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch

You can get the patchsets from either:
http://git.kernel.org/cgit/linux/kernel/git/rt/linux-stable-rt.git
or
https://www.kernel.org/pub/linux/kernel/projects/rt/


On Monday, September 30, 2013 3:32:07 PM UTC-4, jeshu wrote:
>
> Hello List,
>
> Previously I have implemented my applications with Real time kernel in my 
> Beaglebone White using Robert Nelson's kernel. Now I am going to change the 
> platform/board to BBB, I am unable to find any RT patched kernel. Can 
> anybody post me the links where I can find the PT patched 3.8. kernel ?
>
> Thanks,
> Jeshwanth
> Bangalore
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

[beagleboard] Re: BBB RT patch

[garyamort]

On Monday, September 30, 2013 3:32:07 PM UTC-4, jeshu wrote:
>
> Hello List,
>
> Previously I have implemented my applications with Real time kernel in my 
> Beaglebone White using Robert Nelson's kernel. Now I am going to change the 
> platform/board to BBB, I am unable to find any RT patched kernel. Can 
> anybody post me the links where I can find the PT patched 3.8. kernel ?
>

As a side note: you may not need rt patches.

I find the JACK faq invaluable despite not using Jack, as they do heavy 
audio processing which sometimes needs rt.
http://jackaudio.org/faq

Of special note is that regular linux comes with the option to place 
applications into the "Realtime Scheduling Group" and thus performance for 
RT processing without needing to patch the kernel.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

[beagleboard] Re: adding 3 I2C ports on BBB

[garyamort]

On Tuesday, October 1, 2013 3:38:35 AM UTC-4, jacques...@gmail.com wrote:
>
> Dear All, 
>
> I  know that there are already 2 I2C ports on the BBB, but I would need at 
> least five of them :
> I am accessing  sensors that use all the time available. I want thus to be 
> able to 
> access in parallel to 5 of them on five different I2C ports and process 
> the data on the BBB. 
>
> Is  there a way to convert general GPIO to I2C ports in software ? 
>

You can use the i2c-gpio driver
http://lxr.free-electrons.com/source/drivers/i2c/busses/i2c-gpio.c?v=2.6.32

It's a quick and dirty way to give you some extra i2c ports so you can 
focus on developing your app. 

Probably not the ideal solution for production - but if the Bone is just 
the dev platform than your final product can use the additional i2c ports 
from the chip.   And if you are deploying from the bone, then you always 
have the option of adding additional hardware to get more i2c connections 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

Re: [beagleboard] Re: Beaglebone + LIDD-capable LCD

[garyamort]

On Tuesday, October 1, 2013 2:16:04 AM UTC-4, engka...@gmail.com wrote:
>
> Thanks. I will be focusing on the display first. I am thinking of 
> separating the dts for the LCD display and the touch screen. Is that ok?
>

The DTS just defines:
Pins to use and what mode the pin should be configured for
Possibly: some friendly labels to use to label the pins in the sysfs tree
Possibly: a driver to load and some configuration information for the driver

As such you can certainly have a separate DTS file for each 
function/driver[LCD, Touchscreen, Buttons, etc]

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

[beagleboard] Re: Changing cape from CAN to RS232

[garyamort]

On Tuesday, October 1, 2013 10:57:35 AM UTC-4, Jesper We wrote:
>
>
> So... questions:
>
> Is there any utility to write to the cape EEPROM? 
>

i2c-tools - built in to tools.  BUT as you have already discovered, Capemgr 
is tied into the i2c ports and as soon as it detects an EEPROM programmed 
for a cape, it will load it.  Sooo, disable the cape first, see 
http://circuitco.com/support/index.php?title=Weather_Cape_Work-Around for 
how to disable capes in the uEnv.txt file.  Once you place the label for 
the CAN cape in the disabled list, Capemgr will refuse to load it no matter 
what.  That should free up the EEPROM so you can program it.

Of course, there is no reason to program it, just create a DTS for it and 
load it manually.  See 
http://www.berriman.co.uk/beaglebone-black-with-rs232-cape/ for a writeup 
on creating a DTS file and loading it for an RS232 cape.  Of course, you 
will need to modify this as needed to match your pin layout.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

Re: [beagleboard] Changing cape from CAN to RS232

[garyamort]

On Tuesday, October 1, 2013 8:24:10 PM UTC-4, lazarman wrote:
>
> Maxim 
>
> You must have some magic Hexedit that writes I2C . Very nice (-: how does 
> that work?
>

You use one of the Linux I2C EEPROM drivers to access the EEPROM like a 
file.  I don't have any capes, but it is quite possible that Linux already 
mounted that for you.

Check for the directory /sys/bus/i2c/devices/X/eeprom 

Where X will change depending on the address of the device and which i2c 
port it is on.

If it's there, you can edit it directly as the super user.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

Re: [beagleboard] Changing cape from CAN to RS232

[garyamort]

On Wednesday, October 2, 2013 3:57:48 AM UTC-4, Jesper We wrote:
>
> Thank you Gary, brilliant!
> That made it simple to alter the partnumber and get the correct dts loaded:
>
> (I didn't bother to change the board name :-) )
>

Ah, so you were able to edit the eeprom through a sys file then?  A brief 
writeup on what you did would be nice so others have more concrete steps 
beyond my vague "it's somewhere in the directory tree".

I'm perfectly happy poking through the file trees and source trees but 
there are a lot of people with different skillsets coming to these forums 
who might not..  [I have NO idea how you managed to turn a CAN cape into an 
RS232 cape...the idea of trying to modify those little boards makes me 
shudder... :-)]

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

Re: [beagleboard] Bootchart on Ubuntu (slow boot)

[garyamort]

On Wednesday, October 2, 2013 10:02:05 AM UTC-4, RobertCNelson wrote:
>
> On Tue, Oct 1, 2013 at 8:18 PM, Dan Lipsitt 
> > 
> wrote: 
>
>
> > The reason I ask is that it takes about two minutes for a login prompt 
> to 
> > show up over my ftdi serial line. The console logging from the kernel 
> stops 
> > after about ten seconds, then nothing for a long time, then finally the 
> > prompt comes up. 
>
> "2 minutes" do you have the ethernet port connected to anything?  If 
> not, nuke the eth0 line in /etc/network/interfaces ...  (the delay is 
> a 'fix' for another bug..) 
>
>
Alternately, edit the file /etc/init/failsafe.conf and place a comment 
symbol(#) in front of each of the "sleep" lines.
http://tech.pedersen-live.com/2012/05/disable-waiting-for-network-configuration-messages-on-ubuntu-boot/
 

I do this on all my systems at home[running Linux Mint]...when I forget to 
my kids are sure to remind me the next time they boot one up and it takes 
too long to start.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

Re: [beagleboard] Bootchart on Ubuntu (slow boot)

[garyamort]

On Wednesday, October 2, 2013 3:06:26 PM UTC-4, Dan Lipsitt wrote:
>
>
>
> On Wednesday, October 2, 2013 7:02:05 AM UTC-7, RobertCNelson wrote:
>>
>> did update your boot arguments in uEnv.txt to include: 
>>
>> optargs=initcall_debug printk.time=y quiet init=/sbin/bootchartd 
>>
>>
> As I said, there's no bootchartd on my system. There is something called "
> /lib/bootchart/collector". Is bootchartd supposed to be in my initrd or 
> something?
>

Check to see if /var/log/upstart/bootchart.log  exists and what is in it.
Also try running "sudo /etc/init.d/bootchart restart" to make sure 
bootstart is runnable.

I suspect Robert meant to say to add "init=/sbin/bootlogd" in order to get 
some of the earlier boot messages into the logfile.
 

>  
>
>> "2 minutes" do you have the ethernet port connected to anything?  If 
>> not, nuke the eth0 line in /etc/network/interfaces ...  (the delay is 
>> a 'fix' for another bug..) 
>>
>>
>  I have tried with eth0 set to allow-hotplug and also entirely commented 
> out, but I still have the two-minute delay. I don't see any "Waiting for 
> network configuration..." messages coming from failsafe either.
>

If the message is occurring before the serial console has been activated, 
you won't see any.  Disable those sleep calls and see if your boot becomes 
faster - it's extremely quick to check. 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

[beagleboard] Re: Audio-cape eeprom dump wanted

[garyamort]

As I understand it, the EEPROM just contains a copy of the compiled device 
tree, which you already have on any up to date kernel in the /firmware 
directory[for example BB-BONE-AUDI-01-00A0.dtbo]

If you use one of the kernel compilation scripts, you should even have a 
copy of the source code in KERNEL/firmware/capes

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

Re: [beagleboard] Bootchart on Ubuntu (slow boot)

[garyamort]

On Wednesday, October 2, 2013 6:04:12 PM UTC-4, Dan Lipsitt wrote:
>
> Stuff started showing up in /var/log/bootchart after I ran service 
> bootchart restart. I didn't have to change my uEnv.txt.
>
> Removing the sleep commands from /etc/init/failsafe.conf did indeed speed 
> up the boot. I wish I understood better what the failsafe was meant to fix. 
> I'm trying to create a system that can work over wired or wireless 
> ethernet. Am I in for bootup problems later on when I add eth0 back in?
>

I have no idea, but it is a real pain.  I'm using Linux Mint 14 and 
15[which are based on Ubuntu] on 2 older desktops, 1 new desktop, and one 
recent laptop.  All of them work perfectly fine on both my wired network 
and the wireless network without the failsafe function - so I don't think 
it will cause any major issues.


Don't forget to disable bootchart after you have finished using it for 
troubleshooting!  Under certain conditions, it will continue running and 
logging even after bootup.  My recollection is that bootchart will only 
stop logging when gdm starts running - so if your not running x-windows on 
bootup, it will run forever[or in my case, if your running a downstream 
distribution based on ubuntu which uses it's own logon manager in place of 
gdm!].  After a few days of running, it filled up /var/log with useless 
data and caused weird issues.   A better "solution" would of course be to 
modify the control scripts to modify the "finished booting" checks to match 
your system configuration - but I was too lazy to do that when I could 
simply disable it and not worry.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

[beagleboard] Re: BBB, Ubuntu 13.10 (RCN distro) - stk1160 (EasyCap) not recognized

[garyamort]

On Wednesday, October 2, 2013 4:56:34 PM UTC-4, Ivan Korman wrote:
>
> Any further hint?
>
>
>>
At a loss.  If you could
 Unplug it and plug in a device that works
 Then unplug the working device and plug the broken one back in. 

Afterwards run 'dmesg | grep usb' again and post those results it would at 
least provide a bit more information.  IE showing what a "good" insertion 
looks like in the log vs the "bad" insertion.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

[beagleboard] Re: BBB, Ubuntu 13.10 (RCN distro) - stk1160 (EasyCap) not recognized

[garyamort]

On Wednesday, October 2, 2013 4:56:34 PM UTC-4, Ivan Korman wrote:
>
> Any further hint?
>
>
So, finally googled skt1160 and after looking through the results, I'm 
thinking the issue might be the device.  Based on 
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=33&t=18831&sid=057d5de92feb665cf10f4905c1929e32
 where 
you have many different people having varying degrees of failures - 
including some where it works only if plugged in upon bootup and not 
unplugged, and others where they have to periodically unplug it and plug it 
back in - my guess is that because this chip is so generic that the quality 
of production is all over the place.

I'd also guess that your issue is related to power.   Even though your BBB 
has a decent power supply, I'm betting that TI was very careful with power 
regulation for the USB host and it just will NOT supply more than 500mA of 
power[which is what it is clearly rated to for and which is more than 
enough for any USB compliant device].

Wheras if the producer of your your particular device was sloppy/didn't 
care they may need more than 500mA which most PC's these days will provide 
despite it being so far out of spec.

 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

Re: [beagleboard] Changing cape from CAN to RS232

[garyamort]

On Thursday, October 3, 2013 8:09:02 AM UTC-4, stephane...@gmail.com wrote:
>
> Hello,
>
> I had the same need and try to change my RS485 cape into a 232 one on my 
> BB White.
> I have the folowing issue :
> the command  cp eeprom.new /sys/bus/i2c/devices/3-0054/eeprom failed due 
> to connexion timeout.
> When trying some commands with i2ctools, the ressource device seems to be 
> busy.
>
> Any idea about what I missed ?
>

Well according to the PDF schematics for the RS485 cape, the Write Protect 
pin is tied high on it's EEPROM and from the datasheet that turns on write 
protect for that eeprom.


You did do something to cut the power to the WP pin right?

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

[beagleboard] Anyone used an SPI or GPIO LCD display?

[garyamort]

The current display shields are somewhat limited in that you can have an 
HDMI display OR an LCD display..and that's it.  Only a single monitor.

I ran across a driver to run some small LCD displays via SPI or GPIO[or 2 
SPI at the same time, or SPI and GPIO...etc] on the Raspberry Pi:
https://github.com/notro/fbtft

Checking through the driver code, the only thing that is specific to the 
Raspberry Pi is the pin assignments - and even there the driver is 
extremely flexible and allows you to specify the pin assignments when 
loading the driver, so it should be usable right out of the box without any 
changes.

I went ahead and ordered a couple inexpensive LCD's from Sainsmart[one 
'ardunio' module and one SPI model] which are already supported by the 
driver so as soon as I get them in I can give it a try.

Frames per second will of course be rather low when using GPIO, but for a 
text console or a small desktop that shouldn't matter much.

I was wondering if anyone else has used GPIO or SPI and if so, what drivers 
your using?  The main downside of FBFT is that since the Pi doesn't support 
the device tree yet, all those device settings either have to be coded in 
the C program or inserted via command line - but it doesn't seem too 
difficult to move those configurations to a DTS file later after confirming 
the driver works to begin with.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

Re: [beagleboard] HDMI and LCD design

[garyamort]

On Thursday, October 3, 2013 6:43:35 PM UTC-4, Flavio Alves wrote:
>
> Hello, 
>
> I want to be able to manage 2 displays with BBB. Each display will 
> show differente information. 
>
> For instance: a HDMI output playing video and a LCD display with 
> internet browser. Both applications must be executed by BBB. 
>
> Is it possible to do that? 
>
>
In respects to a monitor, the BBB is like any other computer with onboard 
video.  You need a way to attach the monitor to the PC.  The BBB has ONE 
built in interface for a monitor - the LCD pins.   These pins can be 
connected to either the HDMI port OR they can be connected to an LCD 
monitor.


Like any other computer, in order to get more monitors than that you will 
need to install another interface.  So you could use a DisplayLink based 
USB monitor to get a second monitor if you wanted.

Unlike a windows computer, Linux has lots of weird little experimental 
video drivers made to scratch an itch.

There are at least 3 different SPI display drivers for linux, one of them 
might work. See https://github.com/notro/fbtft for a working driver using 
SPI on the Raspberry Pi.

There are at least 2 different GPIO drivers that bit bang the lcd 
controller.   One of them is again, https://github.com/notro/fbtft

There are also a number of "virtual" display drivers that create a virtual 
screen[but then you need some way of switching to that frame].  For 
example, if you setup VNC Server on your BBB it can be configured to 
provide a "virtual" monitor display for remote users.  There is probably a 
way to configure it so you can have multiple monitors over a single remote 
system as I'm sure someone would have played with that - it just might not 
be very reliable.

There are also TWO projects primarily focused on providing "auxilary LCD 
display" capabilities:
LCDProc http://lcdproc.omnipotent.net/
LCD4Linux http://ssl.bulix.org/projects/lcd4linux/

Their primary focus is in using text LCD displays such as those sold by 
CrystalFontz http://www.crystalfontz.com/ but I have run across 
hacks/drivers that build off of those projects to use some of the more 
advanced LCD's as regular displays.

It all depends on how much "work" you want to put into it.  It you want to 
just do "plug and play" go with a USB Display.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

[beagleboard] SMD Circuit Design Question

[garyamort]

I've mulling about an really off the wall idea, and I'm wondering if there 
is a standard way to do this.

I want a "cape" which can be used to connect a BeagleBoneBlack with another 
dev board in a manner to maximize flexibility.

IE P8 pins 1 to 45 will connect to 45 pins on the other board, with the 
assumption that
P8-1 and P8-2 will both connect to GROUND on the other board

3 to 45 will be used in GPIO mode on both boards and both boards are using 
the same voltage levels.


However, since they are 2 dev boards, it's always possible that the 
hobbyist will want to use the pins differently.  For example, he might want 
to attach an LCD to the Bone, using pins P8 28-45 in LCD mode.  And he 
doesn't want those signals being sent to the other dev board.

Using larger parts, one could use dip switches or jumpers inline with the 
connection.   But that adds bulky parts to the board.

What I'm thinking is that I could use a very low value SMD resistor for 
each line - with the expectation that if the hobbyist wishes to disconnect 
a line they will remove the SMD resistor.  It's not as flexible as a jumper 
- but it allows for the end user relatively easily disable some links if 
they need to.

Similarly, both boards provide some voltage rails for powering attached 
chips.  For example, P9-3 and P9-4 provides 3V   Those power rails should 
not connect from one board to the other in expected usage.   However, it's 
possible that the end user would prefer to use the 3V rails provided by the 
bone for everything.  As such, would it be appropriate to place 2 SMD 
diodes on that line in opposition, with the expectation that the end user 
would remove one of those diodes and replace it with a small resistor if 
they want to use it?

IE:  P9-3  3V SMD Diode---><--- 3V SMD Diode---Other Boards 3v Rail

The 2 diodes would block each other in "normal" operation, giving the 
hacker the flexibility to switch usage if they want.


I'm assuming in my ignorance I am missing some more obvious solution/type 
of part to use to configure this.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

Re: [beagleboard] Re: DBTO is not loaded by capemgr (Capes eeprom-info is correct and dbto-file exists in /lib/firmware)

[garyamort]

On Friday, August 23, 2013 8:29:27 PM UTC-4, Seth wrote:
>
> This particular thread looks promising, but I am not sure how the two 
> patches Pantelis posted fit into a solution. Pantelis says "This should fix 
> kind of problem when the dtbo is not included in the kernel image." which 
> seems to be my issue. Does that mean we still have to recompile the kernel 
> to have our cape firmware changes included? What is the purpose of the 
> /lib/firmware folder in that case? I am pretty new to this and it would be 
> appreciated if Pantelis (or anyone else who's been successful at this) 
> could share how they got their custom *dtbo* files loaded and working 
> with more detail. Thanks.
>


It means that the kernel must be compiled with the two changes Pantelis 
made in order to work.  Depending on how you are keeping your software 
image up to date will control whether or not you need to recompile.  I am 
using Robert Nelson's build image scripts and currently am using the 3.8 
kernel with his patches up through version bone28.  Checking the linux 
source files I do not see those two patches - and checking his 3.8 kernel 
branch, https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8 I don't 
see the patches so I'm assuming they are not there yet.

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

[beagleboard] How to Submit Patches for Robert Nelson's Linux-Dev

[garyamort]

Out of curiosity, what is the process to get patches into the 3.8 Kernel 
Linux-Dev repository?
https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8

There are some updates for the Cape Manager in 
https://github.com/pantoniou/linux-bbxm/commit/66166f29c1cfa5035ba4782266d677b908e81f0e
 which 
I'd like to use and I figured if I was going to fork Robert Nelsons 
repository and make the additions - if there is a process to submit those 
changes back I'd go ahead and do that as well.

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

Re: [beagleboard] SMD Circuit Design Question

[garyamort]

On Friday, October 4, 2013 12:00:34 PM UTC-4, Jonathan Smith wrote:
>
> Lattice use to produce, and I believe it is still available, a product 
> called ispGDX, ispGDX2 allows one to reprogram I/O's any to any, as well as 
> adjust input/output threshholds.  Something like that would be great for 
> what your describing.
>
>
Thanks, I'll play around with that and see what I can come up with.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

Re: [beagleboard] Different HARDWARE same Rev.

[garyamort]

On Friday, October 4, 2013 1:11:48 PM UTC-4, synko...@gmail.com wrote:
>
>
> so from what i see is impossible to scale an image flashing to multiple 
> BBB without setting the eth interface... is it correct?
>
>

When Linux boots up, it assigns loads the various network drivers for each 
network device and assigns names "randomly"

IE eth0 is the FIRST ethernet device to initialize.  eth1 is the SECOND 
ethernet device to initialize.  Etc.

Because some people depend on eth0 always being assigned to the SAME 
network card, there are a number of different "systems" in place for linux 
to force this to occur.  Most of them revolve around using a program called 
udev can detect very specific information about the card[mac address, 
hardware id, etc] and then force the name to be assigned that you want. 
 See 
http://www.linuxfromscratch.org/blfs/view/development/chapter07/network.html 
for 
details.

This means if you take a "working" image of linux from one machine and copy 
it to another machine, eth0 can ONLY be assigned to the network interface 
from the original machine.   So on your second machine, you may end up with 
eth1 instead of eth0 or none at all!

Depending on what distribution of linux you use[Ubuntu, Debian, Angstrom, 
Arch, etc] AND what version you are using  - there will be installed some 
shell scripts that when you boot the system up will
1) Check to see if network interface configuration file exists[the file 
which defines MAC Address N should be called eth0]
2) If the file does not exist, it will automatically create one using the 
current configuration.

This means that you cannot "copy" an entire linux installation from one 
system and put it on another.  You have to delete the network configuration 
file that was automatically generated, so that a new one will become 
automatically generated on the new system.  

Other alternatives are to delete that file AND to disable those programs 
which automatically generate new files and just live with the possibility 
of "random" network device names.  

The "difference" your referring to is that many of the different devices on 
the board are assigned unique serial numbers.   The hardware is identical, 
it is the serial number which changes.  



-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

Re: [beagleboard] Different HARDWARE same Rev.

[garyamort]

On Friday, October 4, 2013 7:24:10 PM UTC-4, synko...@gmail.com wrote:
>
> Im glad to see you explanation, now is solved... a doubt is left: How 
> could the Sys Builder make image that boot always in eth0? might they use 
> eth0 or wifi... IMHO 
>

I'm afraid my knowledge pretty much ends at knowing WHAT the issue is and a 
generalized way to solve it - but not the specifics for your case.

I only remember all of this because I ran across the same "issue" with 
running Ubuntu on virtual systems via Amazon EC2.   I'd try to "clone" a 
working system to turn it into an EC2 image and when I booted a new 
copy[which received a new virtual ethernet card with a new MAC address] it 
would not work.   I eventually figured out the specific steps to follow 
when creating an EC2 image to purge this information so they would work - 
but I honestly don't know what exactly the "process" should be when dealing 
with the BBB.  At the moment I only have one BBB so it doesn't affect me.

Sorry I couldn't be more help. :-(  I just figured I'd try to explain it in 
some extra detail because it was quite frustrating/difficult to understand 
when I first encountered it[especially since this "feature" had not been in 
the previous version of Ubuntu I used at the time, so it initially felt 
like the new version of Ubuntu "broke" EC2].

  

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

[beagleboard] Neon enhanced FB Driver[fbdev replacement for Xorg]

[garyamort]

Ran across this article last night: 
http://www.phoronix.com/scan.php?page=news_item&px=MTI5MDI

Siarhei Siamashka  wasn't happy with the open 
source framebuffer driver for his Raspberry Pi that utilizes the built in 
Mali GPU.

It seems the main problem was that the driver was just a basic  driver with 
some function call replacements to use the Mali GPU's special functions.

This means that it didn't include any of the other accelerated function 
calls that come with the Arm platform[NEON and VFRP]

So he rewrote the fbdev driver using their code, and went ahead and added 
the calls for neon and vfrp.   He also has done it in a very smart manner, 
his driver is a drop in replacement for xf86-video-fbdev.  

It's default mode of operation is exactly the same as fbdev - so it will 
work on any platform including both desktops[intel or amd processors] and 
embedded platforms.

During initialization, it will check to see if the Neon features are 
available, if so it will configure itself to use them.  It checks for VFRP 
and enables those functions.  Finally it checks for the Mali GPU and if it 
is there it enables use of those functions.

He's very appropriately named his driver 'fbturbo' amd posted it up to 
Github.  https://github.com/ssvb/xf86-video-fbturbo

This means it should work on the BBB as well and give you a performance 
boost if running a desktop environment.

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

Re: [beagleboard] Device Tree Overlay ? why do we need it?

[garyamort]

On Sunday, October 6, 2013 3:19:55 AM UTC-4, Amalinda J' Gamage wrote:
>
>
> thank you Pedro  and Przemek .
>
> I read through the materiel provided but I still have some doubts. 
>
> 1. Do you know a place where a very beginner coming from TI 
> microcontrolers (e.g. MSP430 and ARM Cortex M) can learn this embedded 
> linux from the begining? can you provide a guidance? a series of videos or 
> an extemely good book or some really good source? because I dont seem to 
> get the hang of these stuff by going through posts and blogs because none 
> start from scratch. I haven't taken any units on e linux in uni either.
>

I personally highly recommend the book "Bad to the Bone" You can read my 
review here: 
https://groups.google.com/forum/?fromgroups#!category-topic/beagleboard/osLlMAbfKac
 


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

[beagleboard] Re: IS possible to use an LCD without controller, on the BBB?

[garyamort]

On Sunday, October 6, 2013 4:45:05 AM UTC-4, Karl Longen wrote:
>
> So, I've trashed an old laptop, and I have this nice 13 inch LCD screen 
> that is sitting in my drawer.
>
> I was planning to use it for some project, and I thought that the BBB 
> would be perfect. 
>
> From what I understand, to use the LCD I need a LCD controller, which per 
> se is an inverter and a board that has IN for HDMI or VGA; I've seen some 
> on Ebay.
>
> Altho they are big, they need power, and they are cluttering the display. 
> so I would end up having the BBB plus 3 boards and the LCD.
>
> My question is: is the BBB able to drive an LCD, without the need of the 
> inverter and the LCD controller? 
>


The BBB can send LCD control signals.   Laptop Panels generally use LVDS 
signals so you need to convert them.

http://circuitco.com/support/index.php?title=BeagleBone_LVDS_LCD_Cape is a 
cape for connecting the BeagleBone White to a LVDS.  Whether or not it 
would work for the BBB I don't know.  And you still need configuration data 
for your panel.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

Re: [beagleboard] Device Tree Overlay ? why do we need it?

[garyamort]

On Sunday, October 6, 2013 11:38:31 AM UTC-4, Amalinda J' Gamage wrote:
>
> Dear garyamort,
>
> Since the book is written for the Linux Kernel version 3.2 and the current 
> version is 3.8 do you think I will have any problem? 
>  awaiting your reply. 
>



It includes both versions - the examples generally will have "here is how 
to do it in 3.2" followed by "here is how to do it in 3.8"

 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

[beagleboard] Re: BBB 24-bit LCD using device tree

[garyamort]

On Monday, October 7, 2013 10:31:17 AM UTC-4, bdwi...@gmail.com wrote:
>
> I have created a custom cape for a 24-bit LCD and am having trouble 
> getting the upper bits (>16) to work.  I have disabled the HDMI and on 
> board eMMC. The panel comes up but is not showing all 24-bit color.
>

What video driver are you using?  The tlcdc code uses a fixed 16 bits.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

[beagleboard] Re: IS possible to use an LCD without controller, on the BBB?

[garyamort]

On Sunday, October 6, 2013 7:46:49 PM UTC-4, Karl Longen wrote:
>
>
> I wish that on the next model of BB, someone will put a programmable LCD 
> controller; you may not use it, but it is great to know that it is there if 
> needed
>

It HAS a programmable LCD controller.   The tilcdl driver uses the 
controller.   What it does not have is LCD to LVDS converter built in - 
most people will want to connect small LCD's directly.  The cape I posted a 
link to has a LCD to LVDS converter built in to it.

Here is an LCD to HDMI converter:
http://www.chalk-elec.com/?page_id=1280#!/~/product/category=3094861&id=14647633

Basically it converts the LVDS signals to LCD signals and then feeds the 
LCD signals to a LCD to HDMI converter.

>From the same company they have a BBB to LVDS converter:
http://www.chalk-elec.com/?page_id=1280#!/~/product/category=3094859&id=13415465

[Note: the pins carry the LVDS signals, I beleive it comes with a converter 
to plug the panel into, as seen on this page: 
http://www.chalk-elec.com/?page_id=1280#!/~/product/category=3094859&id=13727570
]

There is also this one: http://www.tincantools.com/Animal-LVDS-Mini.html

Note: the LVDS/LCD conversion chip seems to fluctuate in availability, 
which also fluctates the cost.  I've seen various LVDS to X adapters 
ranging in price from 20$ to 80$ over the course of the year.  Based on the 
fact that all those companies LVDS products are out of stock, I'd assume 
that currently it is a low availability 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/groups/opt_out.

[beagleboard] Re: SMD Circuit Design Question

[garyamort]

Thanks for the feedback.  I think for my purposes a simple buffer will 
work[now that I know how they work].

I want to attatch 2 BBB's to each other in a master/slave setup, so to 
stack them on top of each other means the board needs to reverse the P8/P9 
headers[I'd make the board bigger than the BBB so the 2 sets of header 
attachments are offset and connections can be made between them].

I assume it is safe to tie the GROUND pins of each board directly to each 
other.

Wheras the 3V and 1.8V power rails should not connect.  

The 5V pin from the master should connect to the 5V pin on the child to 
power it.  For that, an i2c --> parallel latch can be used to enable a 
transistor after the Master boots in order to power up the Slave.

Beyond that, around 8GPIO pins connecting one board to the other is all I 
need.  So a couple of buffers for each direction can be used to connect 
them, and the same i2c-->parallel chip can be used to enable the chip.

I figure if I get to the point of actually making a board for the device, I 
might as well throw some extra buffers on there to allow additional GPIO's 
to connect - my driver can simply not enable them, but someone else might 
want to use them and can go through and enable them in 8 pin blocks.

The one exception for my purposes is that all the GPMC pins should map to 
each other without buffers to avoid timing issues.  I want to play with 
connecting a camera cape to both boards at the same time.  The slave board 
has a single job: processing the video stream, saving each frame out to 
permanent storage.  The master board will only read about 5-6 FPS for 
"preview" mode.

All in all, I think that by repurposing a lot of the software written for 
the Elphel, an open source camera can be put together for under $250 - 
which makes it much more accessible for hacking.   At the same time, it 
would have lots of things which could be "improved" - ie replace the second 
BBB with the upcoming FPGA cape.  Many options to swap the sensor for a 
better one either by replacing just the sensor[if pin compatible] or 
creating a new sensor connection board. 

If done right, it should even be possible to use a USB webcam instead of 
the cam cape, and run both the master and slave software on a single board. 
 I can't imagine doing that for practical usage, but if someone just wanted 
to contribute a better user interface or additional jimage macro's, they 
can do so by purchasing just a single BBB.

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

[beagleboard] Re: Has any activated both user I2C buses with a DT overlay?

[garyamort]

I'd suggest switching to the latest Robert Nelson Ubuntu 3.8 Kernel - there 
have been a lot of patches with DTS files for various single pin modes, so 
your i2c config may already be there.



On Monday, October 7, 2013 5:10:14 PM UTC-4, ky...@cranehome.info wrote:
>
> At this point i'd almost be ready to paypal someone if they can provide a 
> working sample.   Now my earlier edits no longer work in the boneblack.dtb 
> file and prevent the system from booting up at all.  I still seem no closer 
> to understanding how some of the magic numbers in the fragment syntax are 
> derived.  Still need to have both I2C buses.  One high and one low speed.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

[beagleboard] Re: Beaglebone + LIDD-capable LCD

[garyamort]

On Saturday, October 12, 2013 6:45:21 AM UTC-4, engka...@gmail.com wrote:
>
> Oh well, I got it working. I disconnected the PWM pin in the backlight 
> controller an just left it pulled up. I now have a display. But it is a 
> console. I though angstrom has gui. 
>

When booting up, most modern linux configurations check for a working 
monitor when booting.  If the monitor is there it starts the windowing 
system.  If there is no monitor it doesn't.

Considering the window system takes a lot of memory, it just makes sense 
not to load it if it doesn't do anything.

If you have a keyboard connected, try logging in and running 'startx" from 
the command line.

If you don't have a keyboard connected, then you will need to SSH to the 
system...  I'm not sure what the command is from remote...maybe try 'startx 
&' ? 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.

[beagleboard] Re: BBB 24-bit LCD using device tree

[garyamort]

On Tuesday, October 8, 2013 10:20:46 PM UTC-4, bdwi...@gmail.com wrote:
>
> I based it off the LCD4 dt.  It I am reading this right, it uses the 
> tilcdc driver.  The LCD4 is supposed to be a 24-bit panel, but they are 
> connecting it at 18-bit.  
>  
>

TILCD will only use 16 pins for data.  If your LCD display needs 24 bits in 
one cycle, then you can't do 24bit.  If it can take 2 cycles and combine 
the 2 16 bit frames into 1 24bit frame then you may be in good shape - but 
I don't know if tilcd is capable of sending 24bits of data in that manner.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/groups/opt_out.