[beagleboard] Re: Beaglebone + LIDD-capable LCD
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
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?
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=3094861id=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=3094859id=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=3094859id=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
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: IS possible to use an LCD without controller, on the BBB?
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?
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] Neon enhanced FB Driver[fbdev replacement for Xorg]
Ran across this article last night: http://www.phoronix.com/scan.php?page=news_itempx=MTI5MDI Siarhei Siamashka http://ssvb.github.io/ 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.
[beagleboard] SMD Circuit Design Question
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)
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
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
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.
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] Changing cape from CAN to RS232
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.
Re: [beagleboard] HDMI and LCD design
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.
Re: [beagleboard] Bootchart on Ubuntu (slow boot)
On Wednesday, October 2, 2013 10:02:05 AM UTC-4, RobertCNelson wrote: On Tue, Oct 1, 2013 at 8:18 PM, Dan Lipsitt d...@typeamachines.comjavascript: 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.
[beagleboard] Re: BBB, Ubuntu 13.10 (RCN distro) - stk1160 (EasyCap) not recognized
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=33t=18831sid=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
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] Re: Beaglebone + LIDD-capable LCD
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: Fast ADC access on BBB causes buffer underflow error (seg fault)
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.
[beagleboard] Re: How can I improve processing time on BB?
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: Touchscreen Jitter / Jumping on Beaglebone Black LCD Capes
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 required to pay engineers to fix problems you discover.
[beagleboard] Re: Anyone interested in writing or helping with a media playback app?
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] BBB Video Drivers
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] Re: Is it possible to connect an SHT75 sensor to I2C bus of BBB?
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
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.
