Re: [beagleboard] DTS for keyboard Keys question
I have just tested the dts again. My configruation is a tact switch connecting the line to ground. The line is internally pulled up. When i used: gpios = gpio3 9 0x0; The letters apperead when i released the button, not when i pressed it. When i changed to: gpios = gpio3 9 0x1; The letters apperad on a button press. It seems like is the way around. 1 means falling edge and 0 is rising edge. Is this correct? W dniu 2015-05-19 o 16:12, Robert Nelson pisze: On Tue, May 19, 2015 at 9:08 AM, Bremenpl breme...@gmail.com wrote: This is 3.8+. So is gpio2 = gpio3? Then in my case, if my button lines are internally pulled up and the keys short them to gnd, should i use: gpios = gpio3 9 0x0; ? Correct Regards, -- Bremenpl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] optimal board
Hi, I'm trying to choose between the diferents beagleboards products We are looking for a development board which allows us to communicate with a camera with these principal feautres: - GB Ethernet - USB - 8 bit parallel camera interface Any suggestion? Thank you for your help. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Bone VDD_3V3EXP Disable Issues
Thanks for your response. I see your point about not using SYS_RESETn signal... it can be driven low by the processor. I was considering that one because it's a 3.3V logic signal. PGOOD is a 1.8V signal and the EN pin of U4 has a minimum of 2V to consider it high. [image: Inline image 1] I will probably have to add an extra buffer to have PGOOD in 3.3V level to drive the U4-1 and also use it to enable a regulator in my cape (it's actually more like a motherboard). Maybe in the next rev of my custom BBB I will make U16 a dual gate. The reason I'm investigating these PMIC details is that I'm using a custom BBB for am industrial application, and we had a couple boards (BBB and custom one) fail. I recently found warnings in new BBBs to avoid damage in the board. https://groups.google.com/forum/#!topic/beaglebone/CKuTbHepHYE On Tue, May 19, 2015 at 7:51 PM, Matthijs van Duin matthijsvand...@gmail.com wrote: On 19 May 2015 at 22:41, Max msonnail...@gmail.com wrote: Did you try any change in the EN pin of U4 (enable signal of 3V3B)? No, we replaced U4 by this state-of-the-art voltage-tracking regulator: It can't supply as much current as the original, but our needs are modest enough. I'm about to try SYS_RESETn (PMIC_PGOOD after U16), but I'm concerned about the 20ms turn on delay (plus 10ms due to the RC). The other option is to go back to use 3V3AUX, and add a 1k load resistor to reduce the discharge time. I would advise against both of these choices: Only PORz guarantees that the AM335x IOs will be high-Z, SYS_RESETn is deasserted considerably later during power-on. Using it would also case 3v3b to be power-cycled during warm reset, which may have pros and cons but in any case if I'm reading the TRM right it is asserted too early in this case and therefore there's a risk the AM335x ends up driving into unpowered external peripherals. Any reason why you're not considering PMIC_PGOOD itself? In general I'd restrict to PMIC signals that transition somewhere between strobe 4 and PGOOD, which makes PGOOD itself basically the only signal that qualifies. If you do use LDO2 (3v3aux) for whatever reason, try to avoid having any signal to the AM335x being driven high from the 3v3b during boot. In particular, avoid having a console cable connected at boot (at least during production use) given the stress this would put on the UART0_RXD pin. It would then also be a good idea to reprogram LDO2 to strobe 7 as soon as possible during early boot (preferably in the SPL). A load resistor on 3v3b may be a good idea anyway since it lacks the active discharging that the PMIC LDOs have. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] no acces to UART* anymore after flashing new Debian version
I recently had to re-install Debian. After some trials it flashed correctly. But now I have no access to the UARTs anymore. Not via uEnv.txt (located in /boot and not in /boot/uboot, for this version), nor via Python. Both have worked fine before. Do I also need a newer version of Adafruit, maybe? Or something else I have overlooked? I hope one of you can help me out. Cheers, Harke -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Beaglebone Black Ethernet Phy Not Detected on Boot.
Hello guys,
So my hardware people found out the problem, I forgot to mention that the
problem only happened when the beagleboard was in our custom cape, so they
run some tests and the problem was in our board there was some delay when
powering the board sometimes and this cause the problem and they were using
the 3.3 pin of the beaglebone as well. I hope that this information help
someone.
On Tuesday, May 19, 2015 at 5:56:44 PM UTC-3, RobertCNelson wrote:
On Tue, May 19, 2015 at 3:48 PM, Fernando Derkoski bri...@gmail.com
javascript: wrote:
Hi, first thank you for the response, here is the output where the
network
did not work:
root@beaglebone:~# dmesg | grep mdio
[1.040419] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[1.040439] davinci_mdio 4a101000.mdio: detected phy mask fffb
[1.047217] libphy: 4a101000.mdio: probed
[1.047246] davinci_mdio 4a101000.mdio: phy[2]: device
4a101000.mdio:02,
driver SMSC LAN8710/LAN8720
Humm, that is odd, it corrected for [phy mask fffb] with
[4a101000.mdio:02]
But it should have been phy[4]... [4a101000.mdio:04]
The math conversion in the phy search patch is:
phy_mask = fffb
for (i = 0; i PHY_MAX_ADDR; i++) {
if ((phy_mask (1 i)) == 0) {
addr = (u32) i;
break;
}
}
Regards,
--
Robert Nelson
https://rcn-ee.com/
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
BeagleBoard group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Losing bytes in RX buffer?
Am 20.05.2015 um 10:35 schrieb ralphvannellest...@gmail.com: Thanks Nikolaus, tonight I will give it a try. But where do I place the echo? Without an echo to write some character there is nothing to read. for ((x=0;x100;x++)); do echo -en '\xAA' /dev/ttyO4 read -n 1 -t 1 /dev/ttyO4 remove the /dev/ttyO4 here or you have it twice done /dev/ttyO4 Something like this? Just add the /dev/ttyO4 at the bottom to hold the file descriptor open? you can also move the /dev/ttyO4 to the end of the do. Basically this tells the shell to redirect for all commands inside the loop. Op maandag 18 mei 2015 17:18:00 UTC+2 schreef Dr. H. Nikolaus Schaller: read /dev/ttyO4 opens the file and after the command is done it is closed. The UART throws away characters received while the tty is closed. What you can do is for … do read done /dev/ttyO4 Am 18.05.2015 um 15:18 schrieb ralphvann...@gmail.com: I have a problem with ttyO4. It looks like something is emptying the uarts buffer. When is run two bash scripts at the same time I can send characters and receive characters at the same time. The two files running parallel look like this (simplified): 1: for ((x=0;x100;x++)); do echo -en '\xAA' /dev/ttyO4 done 2: for ((x=0;x100;x++)); do read -n 1 -t 1 /dev/ttyO4 done Number 1 is sending and I receive the 0xAA at number 2. Now I try to combine these two files: for ((x=0;x100;x++)); do echo -en '\xAA' /dev/ttyO4 read -n 1 -t 1 /dev/ttyO4 done This does not work. So I write one byte and I am to late to receive this byte. When I use the bash script reading parallel it works again. The 0xAA received at the RX, where does it go? Why isn't it in the Beaglebones (hardware) buffer? Is there some linux process reading these bytes before my own read (from the bash file) is ready to read? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Future of BeagleBone (Black)?
If small is a relative term, and BBB cape compatibility is not on the table, can you aim for slim? By which I mean - no double height USB connectors, etc. Apple have a lot to answer for, making laptops and phone thinner every year. The problem is, customers start to want thin even when there's no real need. Using a folded cable to put an LCD on the back of a Dev board helps, and side-mount expansion sockets help too. --Alan Campbell -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Losing bytes in RX buffer?
Thanks Nikolaus, tonight I will give it a try. But where do I place the echo? Without an echo to write some character there is nothing to read. for ((x=0;x100;x++)); do echo -en '\xAA' /dev/ttyO4 read -n 1 -t 1 /dev/ttyO4 done /dev/ttyO4 Something like this? Just add the /dev/ttyO4 at the bottom to hold the file descriptor open? Op maandag 18 mei 2015 17:18:00 UTC+2 schreef Dr. H. Nikolaus Schaller: read /dev/ttyO4 opens the file and after the command is done it is closed. The UART throws away characters received while the tty is closed. What you can do is for … do read done /dev/ttyO4 Am 18.05.2015 um 15:18 schrieb ralphvann...@gmail.com javascript:: I have a problem with ttyO4. It looks like something is emptying the uarts buffer. When is run two bash scripts at the same time I can send characters and receive characters at the same time. The two files running parallel look like this (simplified): 1: for ((x=0;x100;x++)); do echo -en '\xAA' /dev/ttyO4 done 2: for ((x=0;x100;x++)); do read -n 1 -t 1 /dev/ttyO4 done Number 1 is sending and I receive the 0xAA at number 2. Now I try to combine these two files: for ((x=0;x100;x++)); do echo -en '\xAA' /dev/ttyO4 read -n 1 -t 1 /dev/ttyO4 done This does not work. So I write one byte and I am to late to receive this byte. When I use the bash script reading parallel it works again. The 0xAA received at the RX, where does it go? Why isn't it in the Beaglebones (hardware) buffer? Is there some linux process reading these bytes before my own read (from the bash file) is ready to read? -- 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 javascript:. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] CrossCompile OpenCV with Qt4
Hi everybody! I'm new to Angstrom and the BBB (and, I admit it, to Linux too...). I'm trying to create a Qt app using OpenCV with QtCreator. Without OpenCV, all is alright: I crosscompile on my Ubuntu VM and I deploy on the BBB. Now, when OpenCV is used, the project compiles and runs well on Ubuntu, but when I switch the kit to the BBB one, it doesn't build at all! (the classical opencv2/imgproc/imgproc.hpp: No such file or directory, etc). I did compile OpenCV for an ARM achitecture, but I'm really not sure about my command (done in the directory openCV/releaseBBB/ ): cmake -DSOFTFP=ON -DMAKE_TOOLCHAIN_FILE=../platforms/linux/arm-gnueabi. toolchain.cmake ../ And, after a *make* and a *sudo make install*, I don't even know what to do to link that stuff with Qt! Do you have any help on my command or to match OpenCV for ARM with Qt? Thanks! Arnaud -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Extracting eMMC contents using FAT formatted card
First of all, thank you for this post, it works great on my latest BBBs
(REV C). However, I cannot get it to work with my older BBBs (REV A6). We
have quite a few of the older versions laying around and would like to use
those for some KIOSKs we are setting up in house. Unfortunately, the script
does not want to work on these boards. The script is booting to the SD card
but it does not appear to recognize (or mount) the eMMC. I added `ls /dev
/mnt/dev.txt` to the bash script so I could see the device list, and there
is only mmcblk0, there is not a mmcblk1. I am powering the device with a
5V, 2A power supply and have disconnected all other cables (as suggested in
other posts) and still no luck. The device goes straight to a solid LED and
writes the dev.txt and a 1KB img.gz file. I have tried running it on
multiple boards and am unsure what to try next. Any thoughts as to why the
eMMC is not being loaded/mounted?
On Thursday, September 26, 2013 at 12:16:54 PM UTC-5, Jason Kridner wrote:
There are lots of ways to extract the contents of the eMMC to save off and
reuse. I'm proposing a method using Buildroot and an initramfs such that
you can simply drop a few files from a .zip onto a normal, FAT-formatted SD
card to perform the extraction. There are several things really handy here,
such as the ability to edit autorun.sh to be whatever script you want to
run on your board at boot. In the archive, I only have the necessary
autorun.sh for *saving* your eMMC content. The flip-side is provided here
in the text such that you need to go through a couple of steps before you
trash your eMMC.
The steps for saving off your eMMC contents to a file:
* Get a 4GB or larger uSD card that is FAT formatted.
* Download https://s3.amazonaws.com/beagle/beagleboneblack-save-emmc.zip
and extract the contents onto your uSD card.
* Eject uSD card from your computer, insert into powered-off BeagleBone
Black and apply power to your board.
* You'll notice USR0 (the LED closest to the S1 button in the corner) will
(after about 20 seconds) start to blink steadily, rather than the
double-pulse heartbeat pattern that is typical when your BeagleBone Black
is running the typical Linux kernel configuration.
* It'll run for a bit under 10 minutes and then USR0 will stay ON steady.
That's your cue to remove power, remove the uSD card and put it back into
your computer.
* You should see a file called BeagleBoneBlack-eMMC-image-X.img, where
X is a set of random numbers. Save off this file to use for restoring
your image later.
Because the date won't be set on your board, you might want to adjust the
date on the file to remember when you made it. Delete the file if you want
to make room for a new backup image. For storage on your computer, these
images will typically compress very well, so use your favorite compression
tool.
To restore the file, make sure there is a valid
BeagleBoneBlack-eMMC-image-.img file on the uSD card and edit
autorun.sh with your favorite text editor to contain the following:
#!/bin/sh
echo timer /sys/class/leds/beaglebone\:green\:usr0/trigger
dd if=/mnt/BeagleBoneBlack-eMMC-image-X.img of=/dev/mmcblk1 bs=10M
sync
echo default-on /sys/class/leds/beaglebone\:green\:usr0/trigger
*NOTE*: Be certain to replace the 'X' above with the proper name of
your image file.
This image was built using Buildroot. The sources are at
https://github.com/jadonk/buildroot with tag save-emmc-0.0.1. Download
via https://github.com/jadonk/buildroot/releases/tag/save-emmc-0.0.1 or
clone the git repo. It is a small fork from git://
git.buildroot.net/buildroot tag e9f6011617528646768e69203e85fe64364b7efd.
To build, 'make beagleboneblack_defconfig; make; ./mkuimage.sh'. Output
files (am335x-boneblack.dtb, MLO, u-boot.img and uImage) will be in the
output/images subdirectory. The following files were created manually.
uEnv.txt:
bootpart=0:1
bootdir=
fdtaddr=0x81FF
optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
uenvcmd=load mmc 0 ${loadaddr} uImage;run loadfdt;setenv bootargs
console=${console} ${optargs};bootm ${loadaddr} - ${fdtaddr}
autorun.sh:
#!/bin/sh
echo timer /sys/class/leds/beaglebone\:green\:usr0/trigger
dd if=/dev/mmcblk1 of=/mnt/BeagleBoneBlack-eMMC-image-$RANDOM.img bs=10M
sync
echo default-on /sys/class/leds/beaglebone\:green\:usr0/trigger
The kernel is based on
https://github.com/beagleboard/kernel/commit/9fdb452245a58158a4bea787cdc663c17681bcfe,
but I applied the patches, added firmware and uploaded it to
https://github.com/beagleboard/linux/commit/ddd36e546e53d3c493075bbebd6188ee843208f9
to pull down in the Buildroot makefile. The link to the source for the
firmware is in the commit.
I've applied to join the Buildroot mailing list to send these patches
upstream. The power management firmware is not yet loading properly, but
that is something I can
[beagleboard] 2.2 TFT SPI LCD pwm polarity change
Hello there, I am using this dts with an Adafruit 2.2 TFT SPI LCD screen: https://pastebin.com/vrUZ0Wde To drive backlit, pwm is used. My problem is that it is not inverted and BeagleBone Black pins cant give/ sink to much current, not enough for backlit. So in order to drive not inverted pwm i have to use 2 FETS (N driving P) instead of one P one: https://lh3.googleusercontent.com/-ml820OohPBI/VVyAfOQCmMI/Ahw/DcKyKvfL2BM/s1600/fets.png https://lh3.googleusercontent.com/-ml820OohPBI/VVyAfOQCmMI/Ahw/DcKyKvfL2BM/s1600/fets.png BL - BeagleBone Black pin for backlit BL_P - LCD backlit pin If I could invert the pwm signal in the dts, then i could use BSS84P directly, without BSS123. I Would aprichiate all help in this matter! -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Future of BeagleBone (Black)?
There is not a better processor available from TI that can fit into the Altoids box sized BBB. We have a processor that is much better but will not fit on the baoad. So we are doing the X15. Not sure how else to say it. We will be building the BBB for a very long time. Gerald On Wed, May 20, 2015 at 4:10 AM, sa_Penguin soupi...@gmail.com wrote: If small is a relative term, and BBB cape compatibility is not on the table, can you aim for slim? By which I mean - no double height USB connectors, etc. Apple have a lot to answer for, making laptops and phone thinner every year. The problem is, customers start to want thin even when there's no real need. Using a folded cable to put an LCD on the back of a Dev board helps, and side-mount expansion sockets help too. --Alan Campbell -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Gerald ger...@beagleboard.org http://beagleboard.org/ http://circuitco.com/support/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Future of BeagleBone (Black)?
2015-05-20 15:12 GMT+02:00 Gerald Coley ger...@beagleboard.org: We will be building the BBB for a very long time. This is good news. To give it some numbers, will it be 3, 4, 5 or more years? Karl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Future of BeagleBone (Black)?
As long as there are processors. I would say at least 5 to 10. But that is TI's call. You might ask Jason what TI's plans are for availability. Gerald On Wed, May 20, 2015 at 8:27 AM, Karl Karpfen karlkarpfe...@gmail.com wrote: 2015-05-20 15:12 GMT+02:00 Gerald Coley ger...@beagleboard.org: We will be building the BBB for a very long time. This is good news. To give it some numbers, will it be 3, 4, 5 or more years? Karl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Gerald ger...@beagleboard.org http://beagleboard.org/ http://circuitco.com/support/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Future of BeagleBone (Black)?
On Wed, May 20, 2015 at 9:27 AM, Karl Karpfen karlkarpfe...@gmail.com wrote: 2015-05-20 15:12 GMT+02:00 Gerald Coley ger...@beagleboard.org: We will be building the BBB for a very long time. This is good news. To give it some numbers, will it be 3, 4, 5 or more years? The general plan is to continue shipping a BeagleBoard.org product 10 years after launch. BeagleBone Black launched in 2013. Karl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Future of BeagleBone (Black)?
*That's a real problem if the interface doesn't stay compatible in the future. When I look at Arduino, capes are compatible with previous versions. Same goes with the Raspberry Pi. Version 1 to version 2 adds features, but generally keeps compatibility between them. With the Beagle's, each version has had a radically different form factor and support. White's started with an extra header, removed for the blacks, breaking some capes.* But we're not talking about an Arduino, or an rPI. We're talking about: a) a beagleBOARD class of system b) Then trying to compare it to the beagleBONE class of system. They're not the same. Also, if cape compatibility is the true motivation for this discussion. See this as an opportunity, not a hindrance. On Wed, May 20, 2015 at 8:04 AM, Gerald Coley ger...@beagleboard.org wrote: BeagleBone Black needed to be cheap. something had to go. Rest of the expansion signals are the same and those signals are still there on the board.. I disagree that the changes were radical. I fact, we lowered the cost and added features. If we change to another processor, the pin muxing changes. To comply with your desire to keep them all the same, you have just made my case. Gerald On Wed, May 20, 2015 at 9:42 AM, Walter Schilling schill...@msoe.edu wrote: That's a real problem if the interface doesn't stay compatible in the future. When I look at Arduino, capes are compatible with previous versions. Same goes with the Raspberry Pi. Version 1 to version 2 adds features, but generally keeps compatibility between them. With the Beagle's, each version has had a radically different form factor and support. White's started with an extra header, removed for the blacks, breaking some capes. On Tuesday, May 19, 2015 at 9:30:37 AM UTC-5, RobertCNelson wrote: On Tue, May 19, 2015 at 9:24 AM, Philip philip@gmail.com wrote: On Tuesday, May 19, 2015 at 10:14:20 AM UTC-4, Gerald wrote: If I knew that, I would have mentioned that. I would say maybe late September. We hope to have a few beta boards in about 6 weeks. Jason is handling who gets those boards. Right now, we are going back into layout to fix yet another TI feature. Will the cape interface stay the same? Nope, and don't mention stuff like that, we don't want to give Gerald a heart attack.. Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Gerald ger...@beagleboard.org http://beagleboard.org/ http://circuitco.com/support/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Future of BeagleBone (Black)?
Isn't 10 years just the total life of the chip/product line? This doesn't say TI is going to be advancing that processor line. Consider that right now the Pi2 has a quad core processor. If TI isn't going to be keeping up with that kind of pace of processor development for the AM335x line (or maybe its the am3xxx line?) is a single core 1GHz processor going to be relevant in a year or five? Is it staying relevant right now given the other SBCs at a similar price/capabilities standpoint? I can say that internal to where I work we've been eyeing the quad core ARM processor boards that have appeared. We like the BBB a ton and we'd love to see it go quad core and double up on the ram for a similar price point. Maintaining cape/software compatibility would be a big win imo. Chris On Wed, May 20, 2015 at 11:43 AM, William Hermans yyrk...@gmail.com wrote: Also, we're talking 10 years down the road here. Whose to say what will happen by then. Take a look at the MSP430 line of MCUs for example. I do not know the exact history of the MCU line, but it became popular, and it is still with us . . . refreshes have been made, changes / variations have been made. Now we have many different classes of MSP430 MCUs for different use cases. Lately TI even extended the MSP430 line by mixing in the M4F processor . For high end applications. Is it truly an MSP430 though ? Here, I think the more important question should be: Does it even matter ? On Wed, May 20, 2015 at 8:30 AM, William Hermans yyrk...@gmail.com wrote: That's a real problem if the interface doesn't stay compatible in the future. When I look at Arduino, capes are compatible with previous versions. Same goes with the Raspberry Pi. Version 1 to version 2 adds features, but generally keeps compatibility between them. With the Beagle's, each version has had a radically different form factor and support. White's started with an extra header, removed for the blacks, breaking some capes. But we're not talking about an Arduino, or an rPI. We're talking about: a) a beagleBOARD class of system b) Then trying to compare it to the beagleBONE class of system. They're not the same. Also, if cape compatibility is the true motivation for this discussion. See this as an opportunity, not a hindrance. On Wed, May 20, 2015 at 8:04 AM, Gerald Coley ger...@beagleboard.org wrote: BeagleBone Black needed to be cheap. something had to go. Rest of the expansion signals are the same and those signals are still there on the board.. I disagree that the changes were radical. I fact, we lowered the cost and added features. If we change to another processor, the pin muxing changes. To comply with your desire to keep them all the same, you have just made my case. Gerald On Wed, May 20, 2015 at 9:42 AM, Walter Schilling schill...@msoe.edu wrote: That's a real problem if the interface doesn't stay compatible in the future. When I look at Arduino, capes are compatible with previous versions. Same goes with the Raspberry Pi. Version 1 to version 2 adds features, but generally keeps compatibility between them. With the Beagle's, each version has had a radically different form factor and support. White's started with an extra header, removed for the blacks, breaking some capes. On Tuesday, May 19, 2015 at 9:30:37 AM UTC-5, RobertCNelson wrote: On Tue, May 19, 2015 at 9:24 AM, Philip philip@gmail.com wrote: On Tuesday, May 19, 2015 at 10:14:20 AM UTC-4, Gerald wrote: If I knew that, I would have mentioned that. I would say maybe late September. We hope to have a few beta boards in about 6 weeks. Jason is handling who gets those boards. Right now, we are going back into layout to fix yet another TI feature. Will the cape interface stay the same? Nope, and don't mention stuff like that, we don't want to give Gerald a heart attack.. Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Gerald ger...@beagleboard.org http://beagleboard.org/ http://circuitco.com/support/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an
Re: [beagleboard] Future of BeagleBone (Black)?
Pin muxing is something that can very easily be controlled in software / managed with software changes and routing on the board. However, if the physical interface is different, you end up throwing out all of the peripherals you have. Think of it this way: how standard would USB be if each version used a different physical interconnect? They haven't. There's a few standard interfaces out there for the hardware. Walt On Wednesday, May 20, 2015 at 10:05:15 AM UTC-5, Gerald wrote: BeagleBone Black needed to be cheap. something had to go. Rest of the expansion signals are the same and those signals are still there on the board.. I disagree that the changes were radical. I fact, we lowered the cost and added features. If we change to another processor, the pin muxing changes. To comply with your desire to keep them all the same, you have just made my case. Gerald On Wed, May 20, 2015 at 9:42 AM, Walter Schilling schi...@msoe.edu javascript: wrote: That's a real problem if the interface doesn't stay compatible in the future. When I look at Arduino, capes are compatible with previous versions. Same goes with the Raspberry Pi. Version 1 to version 2 adds features, but generally keeps compatibility between them. With the Beagle's, each version has had a radically different form factor and support. White's started with an extra header, removed for the blacks, breaking some capes. On Tuesday, May 19, 2015 at 9:30:37 AM UTC-5, RobertCNelson wrote: On Tue, May 19, 2015 at 9:24 AM, Philip philip@gmail.com wrote: On Tuesday, May 19, 2015 at 10:14:20 AM UTC-4, Gerald wrote: If I knew that, I would have mentioned that. I would say maybe late September. We hope to have a few beta boards in about 6 weeks. Jason is handling who gets those boards. Right now, we are going back into layout to fix yet another TI feature. Will the cape interface stay the same? Nope, and don't mention stuff like that, we don't want to give Gerald a heart attack.. Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- Gerald ger...@beagleboard.org javascript: http://beagleboard.org/ http://circuitco.com/support/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Future of BeagleBone (Black)?
Also, we're talking 10 years down the road here. Whose to say what will happen by then. Take a look at the MSP430 line of MCUs for example. I do not know the exact history of the MCU line, but it became popular, and it is still with us . . . refreshes have been made, changes / variations have been made. Now we have many different classes of MSP430 MCUs for different use cases. Lately TI even extended the MSP430 line by mixing in the M4F processor . For high end applications. Is it truly an MSP430 though ? Here, I think the more important question should be: Does it even matter ? On Wed, May 20, 2015 at 8:30 AM, William Hermans yyrk...@gmail.com wrote: *That's a real problem if the interface doesn't stay compatible in the future. When I look at Arduino, capes are compatible with previous versions. Same goes with the Raspberry Pi. Version 1 to version 2 adds features, but generally keeps compatibility between them. With the Beagle's, each version has had a radically different form factor and support. White's started with an extra header, removed for the blacks, breaking some capes.* But we're not talking about an Arduino, or an rPI. We're talking about: a) a beagleBOARD class of system b) Then trying to compare it to the beagleBONE class of system. They're not the same. Also, if cape compatibility is the true motivation for this discussion. See this as an opportunity, not a hindrance. On Wed, May 20, 2015 at 8:04 AM, Gerald Coley ger...@beagleboard.org wrote: BeagleBone Black needed to be cheap. something had to go. Rest of the expansion signals are the same and those signals are still there on the board.. I disagree that the changes were radical. I fact, we lowered the cost and added features. If we change to another processor, the pin muxing changes. To comply with your desire to keep them all the same, you have just made my case. Gerald On Wed, May 20, 2015 at 9:42 AM, Walter Schilling schill...@msoe.edu wrote: That's a real problem if the interface doesn't stay compatible in the future. When I look at Arduino, capes are compatible with previous versions. Same goes with the Raspberry Pi. Version 1 to version 2 adds features, but generally keeps compatibility between them. With the Beagle's, each version has had a radically different form factor and support. White's started with an extra header, removed for the blacks, breaking some capes. On Tuesday, May 19, 2015 at 9:30:37 AM UTC-5, RobertCNelson wrote: On Tue, May 19, 2015 at 9:24 AM, Philip philip@gmail.com wrote: On Tuesday, May 19, 2015 at 10:14:20 AM UTC-4, Gerald wrote: If I knew that, I would have mentioned that. I would say maybe late September. We hope to have a few beta boards in about 6 weeks. Jason is handling who gets those boards. Right now, we are going back into layout to fix yet another TI feature. Will the cape interface stay the same? Nope, and don't mention stuff like that, we don't want to give Gerald a heart attack.. Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Gerald ger...@beagleboard.org http://beagleboard.org/ http://circuitco.com/support/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Future of BeagleBone (Black)?
On Wed, May 20, 2015 at 11:43 AM, William Hermans yyrk...@gmail.com wrote: Lately TI even extended the MSP430 line by mixing in the M4F processor . For high end applications. Is it truly an MSP430 though ? Here, I think the more important question should be: Does it even matter ? You are talking about MSP432; I wrote a Wikipedia article about it https://en.wikipedia.org/wiki/TI_MSP432 In short, they used a Cortex M4F core just like their existing Tiva chips, but added MSP430-like peripherals and a built-in ROM with compatible peripheral library. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Future of BeagleBone (Black)?
Not if it takes 5 pins to equal the peripheral mix needed by one standard BBB pin. Gerald On Wed, May 20, 2015 at 12:09 PM, Walter Schilling schill...@msoe.edu wrote: Pin muxing is something that can very easily be controlled in software / managed with software changes and routing on the board. However, if the physical interface is different, you end up throwing out all of the peripherals you have. Think of it this way: how standard would USB be if each version used a different physical interconnect? They haven't. There's a few standard interfaces out there for the hardware. Walt On Wednesday, May 20, 2015 at 10:05:15 AM UTC-5, Gerald wrote: BeagleBone Black needed to be cheap. something had to go. Rest of the expansion signals are the same and those signals are still there on the board.. I disagree that the changes were radical. I fact, we lowered the cost and added features. If we change to another processor, the pin muxing changes. To comply with your desire to keep them all the same, you have just made my case. Gerald On Wed, May 20, 2015 at 9:42 AM, Walter Schilling schi...@msoe.edu wrote: That's a real problem if the interface doesn't stay compatible in the future. When I look at Arduino, capes are compatible with previous versions. Same goes with the Raspberry Pi. Version 1 to version 2 adds features, but generally keeps compatibility between them. With the Beagle's, each version has had a radically different form factor and support. White's started with an extra header, removed for the blacks, breaking some capes. On Tuesday, May 19, 2015 at 9:30:37 AM UTC-5, RobertCNelson wrote: On Tue, May 19, 2015 at 9:24 AM, Philip philip@gmail.com wrote: On Tuesday, May 19, 2015 at 10:14:20 AM UTC-4, Gerald wrote: If I knew that, I would have mentioned that. I would say maybe late September. We hope to have a few beta boards in about 6 weeks. Jason is handling who gets those boards. Right now, we are going back into layout to fix yet another TI feature. Will the cape interface stay the same? Nope, and don't mention stuff like that, we don't want to give Gerald a heart attack.. Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Gerald ger...@beagleboard.org http://beagleboard.org/ http://circuitco.com/support/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Gerald ger...@beagleboard.org http://beagleboard.org/ http://circuitco.com/support/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Future of BeagleBone (Black)?
I guess I should mention why, at least to me, it does matter. We use the Beagle in coursework on campus, teaching students how to develop real time systems. We first started out with the XM, and a set of peripherals. However, right as we were ready to gear up for the course, the XM peripherals became unavailable. So we switched to the bone, which was being supported at the time. But then as the class was rolling out, after we had designed the course to run with the BB Blacks, the Blacks disappeared from inventory (not to repeat that at all..) So we had to downgrade to the whites. But about the same time, access to the Angstrom distribution essentially vanished for a while as well. So we were somewhat stuck. This year things went smoother, as everything was available. But the challenge is, to do the course, we've got probably $400-$500 worth of equipment per student enrolled in the course. That's about $25-30K in equipment that needs to be amortized out over multiple years. So I guess, that's why I'm a bit concerned about incompatible formats being developed. On Wednesday, May 20, 2015 at 10:43:53 AM UTC-5, William Hermans wrote: Also, we're talking 10 years down the road here. Whose to say what will happen by then. Take a look at the MSP430 line of MCUs for example. I do not know the exact history of the MCU line, but it became popular, and it is still with us . . . refreshes have been made, changes / variations have been made. Now we have many different classes of MSP430 MCUs for different use cases. Lately TI even extended the MSP430 line by mixing in the M4F processor . For high end applications. Is it truly an MSP430 though ? Here, I think the more important question should be: Does it even matter ? On Wed, May 20, 2015 at 8:30 AM, William Hermans yyr...@gmail.com javascript: wrote: *That's a real problem if the interface doesn't stay compatible in the future. When I look at Arduino, capes are compatible with previous versions. Same goes with the Raspberry Pi. Version 1 to version 2 adds features, but generally keeps compatibility between them. With the Beagle's, each version has had a radically different form factor and support. White's started with an extra header, removed for the blacks, breaking some capes.* But we're not talking about an Arduino, or an rPI. We're talking about: a) a beagleBOARD class of system b) Then trying to compare it to the beagleBONE class of system. They're not the same. Also, if cape compatibility is the true motivation for this discussion. See this as an opportunity, not a hindrance. On Wed, May 20, 2015 at 8:04 AM, Gerald Coley ger...@beagleboard.org javascript: wrote: BeagleBone Black needed to be cheap. something had to go. Rest of the expansion signals are the same and those signals are still there on the board.. I disagree that the changes were radical. I fact, we lowered the cost and added features. If we change to another processor, the pin muxing changes. To comply with your desire to keep them all the same, you have just made my case. Gerald On Wed, May 20, 2015 at 9:42 AM, Walter Schilling schi...@msoe.edu javascript: wrote: That's a real problem if the interface doesn't stay compatible in the future. When I look at Arduino, capes are compatible with previous versions. Same goes with the Raspberry Pi. Version 1 to version 2 adds features, but generally keeps compatibility between them. With the Beagle's, each version has had a radically different form factor and support. White's started with an extra header, removed for the blacks, breaking some capes. On Tuesday, May 19, 2015 at 9:30:37 AM UTC-5, RobertCNelson wrote: On Tue, May 19, 2015 at 9:24 AM, Philip philip@gmail.com wrote: On Tuesday, May 19, 2015 at 10:14:20 AM UTC-4, Gerald wrote: If I knew that, I would have mentioned that. I would say maybe late September. We hope to have a few beta boards in about 6 weeks. Jason is handling who gets those boards. Right now, we are going back into layout to fix yet another TI feature. Will the cape interface stay the same? Nope, and don't mention stuff like that, we don't want to give Gerald a heart attack.. Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- Gerald ger...@beagleboard.org javascript: http://beagleboard.org/ http://circuitco.com/support/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe
Re: [beagleboard] Future of BeagleBone (Black)?
That is a question for Jason. He is the TI guy. Gerald On Wed, May 20, 2015 at 11:15 AM, Chris Morgan chmor...@gmail.com wrote: Isn't 10 years just the total life of the chip/product line? This doesn't say TI is going to be advancing that processor line. Consider that right now the Pi2 has a quad core processor. If TI isn't going to be keeping up with that kind of pace of processor development for the AM335x line (or maybe its the am3xxx line?) is a single core 1GHz processor going to be relevant in a year or five? Is it staying relevant right now given the other SBCs at a similar price/capabilities standpoint? I can say that internal to where I work we've been eyeing the quad core ARM processor boards that have appeared. We like the BBB a ton and we'd love to see it go quad core and double up on the ram for a similar price point. Maintaining cape/software compatibility would be a big win imo. Chris On Wed, May 20, 2015 at 11:43 AM, William Hermans yyrk...@gmail.com wrote: Also, we're talking 10 years down the road here. Whose to say what will happen by then. Take a look at the MSP430 line of MCUs for example. I do not know the exact history of the MCU line, but it became popular, and it is still with us . . . refreshes have been made, changes / variations have been made. Now we have many different classes of MSP430 MCUs for different use cases. Lately TI even extended the MSP430 line by mixing in the M4F processor . For high end applications. Is it truly an MSP430 though ? Here, I think the more important question should be: Does it even matter ? On Wed, May 20, 2015 at 8:30 AM, William Hermans yyrk...@gmail.com wrote: That's a real problem if the interface doesn't stay compatible in the future. When I look at Arduino, capes are compatible with previous versions. Same goes with the Raspberry Pi. Version 1 to version 2 adds features, but generally keeps compatibility between them. With the Beagle's, each version has had a radically different form factor and support. White's started with an extra header, removed for the blacks, breaking some capes. But we're not talking about an Arduino, or an rPI. We're talking about: a) a beagleBOARD class of system b) Then trying to compare it to the beagleBONE class of system. They're not the same. Also, if cape compatibility is the true motivation for this discussion. See this as an opportunity, not a hindrance. On Wed, May 20, 2015 at 8:04 AM, Gerald Coley ger...@beagleboard.org wrote: BeagleBone Black needed to be cheap. something had to go. Rest of the expansion signals are the same and those signals are still there on the board.. I disagree that the changes were radical. I fact, we lowered the cost and added features. If we change to another processor, the pin muxing changes. To comply with your desire to keep them all the same, you have just made my case. Gerald On Wed, May 20, 2015 at 9:42 AM, Walter Schilling schill...@msoe.edu wrote: That's a real problem if the interface doesn't stay compatible in the future. When I look at Arduino, capes are compatible with previous versions. Same goes with the Raspberry Pi. Version 1 to version 2 adds features, but generally keeps compatibility between them. With the Beagle's, each version has had a radically different form factor and support. White's started with an extra header, removed for the blacks, breaking some capes. On Tuesday, May 19, 2015 at 9:30:37 AM UTC-5, RobertCNelson wrote: On Tue, May 19, 2015 at 9:24 AM, Philip philip@gmail.com wrote: On Tuesday, May 19, 2015 at 10:14:20 AM UTC-4, Gerald wrote: If I knew that, I would have mentioned that. I would say maybe late September. We hope to have a few beta boards in about 6 weeks. Jason is handling who gets those boards. Right now, we are going back into layout to fix yet another TI feature. Will the cape interface stay the same? Nope, and don't mention stuff like that, we don't want to give Gerald a heart attack.. Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Gerald ger...@beagleboard.org http://beagleboard.org/ http://circuitco.com/support/ -- 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
[beagleboard] Re: no acces to UART* anymore after flashing new Debian version
I may have misunderstood but have a look here on how to enable UARTs for Jessie. https://theunemployablekoder.wordpress.com/ On Wednesday, May 20, 2015 at 1:10:00 PM UTC+1, Harke Smits wrote: I recently had to re-install Debian. After some trials it flashed correctly. But now I have no access to the UARTs anymore. Not via uEnv.txt (located in /boot and not in /boot/uboot, for this version), nor via Python. Both have worked fine before. Do I also need a newer version of Adafruit, maybe? Or something else I have overlooked? I hope one of you can help me out. Cheers, Harke -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: HDMI audio truncated
Someone have any suggestion? On Saturday, May 16, 2015 at 11:49:38 PM UTC+2, Matteo Guallini wrote: Hello, If I do aplay /usr/share/sounds/alsa/Front_Right.wav from SSH and from command line the audio is truncated or missing. Truncated signify that the played sound is like right or ight. The strange thing is that the sound is good if I open PCMANFM and i go to /usr/share/sounds/alsa/ then I select the Front_Right.wav with the right mouse button and I open the file wiith alsagui. Youtube video don't play sound 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/d/optout.
Re: [beagleboard] Re-flashing an Angstrom EMMC with Debian Latest from beagleboard, fail
On Monday, May 18, 2015 at 8:40:03 PM UTC-7, William Hermans wrote: I can still put the full version on Debian on an SD and load from that right? Yes. But you would use one of the standalone images, instead of a flasher image. I just don't really want to have two different versions of doing things for two boards, but kind of too late for that. I recall reading that the default behavior at boot-up is now to boot off an SD if it is present, is that correct? Or is it configurable? The default behavior as I understand it is that the board will load the first, a stage bootloader ( MLO ) off of the eMMC. *Unless* you press the boot switch button, where then it would load the first stage bootloader from the sdcard. In either above case, the board would then attempt to boot off the sdcard. Starting with u-boot, and finally booting Linux. This is why some have issues with trying to boot a newer image off of sdcard, when they're using an older BBB. The first stage bootloader on the eMMC is too old. Anyway, with all that said. Yes, you can configure this behavior somewhat through uEnv.txt. You'll still load the first stage bootloader off the eMMC, but depending on how key variables are set in uEnv.txt, you can automagically load files. and / or linux images choosing your specific boot medium. Now, we're straying off onto a topic that is fairly large. A topic that I spent nearly 2 weeks reading about before I could even think of a question to ask. I would suggest if you need to know more that you search the web for anything / everything u-boot, MLO ( and perhaps even x-loader ) in regards to the beaglebone black. Thanks William, You stopped I think at just the right time...even if you tried to go further my head would probably explode right now. I will take the long course as you suggest and build that knowledge up at the logical rate. I will work on my BB-View issues now and count myself lucky so far. Again, thanks for your timely and thorough help! You and Robert. Regards, Jack -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] BBB LCD3 Cape and inactivity
https://lh3.googleusercontent.com/-NW_qX1Cz0Vk/VVzTguPp-RI/DKs/NIVwCCQ1PLM/s1600/Screen%2BShot%2B2015-05-21%2Bat%2B02.25.52.jpeg Hi there folks, The CircuitCo LCD3 cape version A2 basically pulls up the backlight supply enable line via R126. By removing R126, and adding a 0R resistor (or a blob of solder) on the pads for R123, you enable use of the EHRPWM1A line to control the backlight. The caveat is that when you power up the BBB, you should issue a echo 50 /sys/class/backlight/backlight/brightness to have anything come up on the BBB LCD3. Cheers! - Antonio On Friday, 30 May 2014 02:43:06 UTC+8, john3909 wrote: From: Colin Bester bester...@gmail.com javascript: Reply-To: beagl...@googlegroups.com javascript: Date: Thursday, May 29, 2014 at 6:45 AM To: beagl...@googlegroups.com javascript: Subject: Re: [beagleboard] BBB LCD3 Cape and inactivity I just managed to get around to looking a little deeper into this and connected an oscilloscope to EHRPWM1A (which I figure is pin P9_14) and confirm that when writing a zero to brightness (using echo 0 /sys/class/backlight/backlight.11/brightness) that the pin is low. Likewise write a ’50’ sets a 50% duty cycle and LCD brightens. I haven’t set up environment to compile and test using ‘c’ files yet. With low on pin P9_14 the LCD is still visible. In that case this is a hardware issue. P9_14 is connected to the enable pin of the LED backplane driver so the leds should turn off. Regards, John With debian version I now have running, I have not seen the LCD goto sleep yet - still have to look into this. ~C On May 26, 2014, at 8:03 PM, John Syn john...@gmail.com javascript: wrote: From: Colin Bester bester...@gmail.com javascript: Reply-To: beagl...@googlegroups.com javascript: Date: Monday, May 26, 2014 at 4:54 PM To: beagl...@googlegroups.com javascript: Subject: Re: [beagleboard] BBB LCD3 Cape and inactivity Was wondering if you have come up with any further solution? I can write '0' to backlight brightness but while this dims the display significantly it doesn't switch if off. Have you checked that EHRPWM1A is low when you dim the display? Here are two files that will control the backlight. /driver/video/backlight/pwm_bl.c /driver/pwm/pwm-tiehrpwm.c Regards John -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] BBB LCD3 Cape and inactivity
Thanks! On May 20, 2015, at 1:33 PM, aahila...@gmail.com wrote: https://lh3.googleusercontent.com/-NW_qX1Cz0Vk/VVzTguPp-RI/DKs/NIVwCCQ1PLM/s1600/Screen%2BShot%2B2015-05-21%2Bat%2B02.25.52.jpegHi there folks, The CircuitCo LCD3 cape version A2 basically pulls up the backlight supply enable line via R126. By removing R126, and adding a 0R resistor (or a blob of solder) on the pads for R123, you enable use of the EHRPWM1A line to control the backlight. The caveat is that when you power up the BBB, you should issue a echo 50 /sys/class/backlight/backlight/brightness to have anything come up on the BBB LCD3. Cheers! - Antonio On Friday, 30 May 2014 02:43:06 UTC+8, john3909 wrote: From: Colin Bester bester...@gmail.com javascript: Reply-To: beagl...@googlegroups.com javascript: Date: Thursday, May 29, 2014 at 6:45 AM To: beagl...@googlegroups.com javascript: Subject: Re: [beagleboard] BBB LCD3 Cape and inactivity I just managed to get around to looking a little deeper into this and connected an oscilloscope to EHRPWM1A (which I figure is pin P9_14) and confirm that when writing a zero to brightness (using echo 0 /sys/class/backlight/backlight.11/brightness) that the pin is low. Likewise write a ’50’ sets a 50% duty cycle and LCD brightens. I haven’t set up environment to compile and test using ‘c’ files yet. With low on pin P9_14 the LCD is still visible. In that case this is a hardware issue. P9_14 is connected to the enable pin of the LED backplane driver so the leds should turn off. Regards, John With debian version I now have running, I have not seen the LCD goto sleep yet - still have to look into this. ~C On May 26, 2014, at 8:03 PM, John Syn john...@gmail.com javascript: wrote: From: Colin Bester bester...@gmail.com javascript: Reply-To: beagl...@googlegroups.com javascript: Date: Monday, May 26, 2014 at 4:54 PM To: beagl...@googlegroups.com javascript: Subject: Re: [beagleboard] BBB LCD3 Cape and inactivity Was wondering if you have come up with any further solution? I can write '0' to backlight brightness but while this dims the display significantly it doesn't switch if off. Have you checked that EHRPWM1A is low when you dim the display? Here are two files that will control the backlight. /driver/video/backlight/pwm_bl.c /driver/pwm/pwm-tiehrpwm.c Regards John -- For more options, visit http://beagleboard.org/discuss 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 javascript:. For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/d_6HC6ps2RU/unsubscribe https://groups.google.com/d/topic/beagleboard/d_6HC6ps2RU/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com mailto:beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Future of BeagleBone (Black)?
2015-05-20 18:15 GMT+02:00 Chris Morgan chmor...@gmail.com: Isn't 10 years just the total life of the chip/product line? This doesn't say TI is going to be advancing that processor line. Plesse chek out this thread, there is a link to a TI-statement where they say it will be available for a bit more than nine years at least (from now on). Consider that right now the Pi2 has a quad core processor. If TI isn't going to be keeping up with that kind of pace of processor development for the AM335x line (or maybe its the am3xxx line?) is a single core 1GHz processor going to be relevant in a year or five? It may not be relevant for hobbyists that always want to have the latest hardware and replace their board every month, but it is HIGHLY relevant for all kinds of industry usage where a hardware needs to stay available and stable over a longer period. There it does not matter when the device itself is a bit outdated, it would be much more expensive for companies to change a whole machine just because a simple controller board is no longer available. And when BBB will be avilable for more than 5 years, this is really very good for this area. And from my feeling that's where BBB goes to: many companies are already using it for professional purposes while RasPi and the others are more or less for hobbyists. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Future of BeagleBone (Black)?
BeagleBone Black needed to be cheap. something had to go. Rest of the expansion signals are the same and those signals are still there on the board.. I disagree that the changes were radical. I fact, we lowered the cost and added features. If we change to another processor, the pin muxing changes. To comply with your desire to keep them all the same, you have just made my case. Gerald On Wed, May 20, 2015 at 9:42 AM, Walter Schilling schill...@msoe.edu wrote: That's a real problem if the interface doesn't stay compatible in the future. When I look at Arduino, capes are compatible with previous versions. Same goes with the Raspberry Pi. Version 1 to version 2 adds features, but generally keeps compatibility between them. With the Beagle's, each version has had a radically different form factor and support. White's started with an extra header, removed for the blacks, breaking some capes. On Tuesday, May 19, 2015 at 9:30:37 AM UTC-5, RobertCNelson wrote: On Tue, May 19, 2015 at 9:24 AM, Philip philip@gmail.com wrote: On Tuesday, May 19, 2015 at 10:14:20 AM UTC-4, Gerald wrote: If I knew that, I would have mentioned that. I would say maybe late September. We hope to have a few beta boards in about 6 weeks. Jason is handling who gets those boards. Right now, we are going back into layout to fix yet another TI feature. Will the cape interface stay the same? Nope, and don't mention stuff like that, we don't want to give Gerald a heart attack.. Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Gerald ger...@beagleboard.org http://beagleboard.org/ http://circuitco.com/support/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Future of BeagleBone (Black)?
That's a real problem if the interface doesn't stay compatible in the future. When I look at Arduino, capes are compatible with previous versions. Same goes with the Raspberry Pi. Version 1 to version 2 adds features, but generally keeps compatibility between them. With the Beagle's, each version has had a radically different form factor and support. White's started with an extra header, removed for the blacks, breaking some capes. On Tuesday, May 19, 2015 at 9:30:37 AM UTC-5, RobertCNelson wrote: On Tue, May 19, 2015 at 9:24 AM, Philip philip@gmail.com javascript: wrote: On Tuesday, May 19, 2015 at 10:14:20 AM UTC-4, Gerald wrote: If I knew that, I would have mentioned that. I would say maybe late September. We hope to have a few beta boards in about 6 weeks. Jason is handling who gets those boards. Right now, we are going back into layout to fix yet another TI feature. Will the cape interface stay the same? Nope, and don't mention stuff like that, we don't want to give Gerald a heart attack.. Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
