[beagleboard] Re: libpruio adc pruio_config help
Thanks- You have been very helpful. Another question I have is about precise timing; Does the PRU have access to any high precision timers / a way for the cpu to know down to the microsecond how long between 2 data points --- Even if they are very far apart say for example- sampling only AIN-0 with averaging set to 24 and the tmr set @ 100,000-- could the time between the first point and the last point be accurate to 50 +/- microsecond across multiple hours ? The ideal solution would allow for the pru to send back a 32/64 bit timer every X samples. On Tuesday, August 25, 2015 at 12:02:20 AM UTC-6, TJF wrote: Hi! Am Dienstag, 25. August 2015 00:44:22 UTC+2 schrieb 180bob.we.had.a...@gmail.com: or is something I using out-of-date? Yes, outdated. In the new (unpublished) code in file src/pruio/pruio_adc.bas at line 128 d *= (Conf-ADC_CLKDIV + 1) * 417 '417 ≈ 100 / 2400 (= 1 GHz / 2.4 MHz) d += 30 ' PRU cycles for restart [GHz] IF Tmr = d THEN .Errr = @sample rate too big : RETURN .Errr is replaced by d = (d * (Conf-ADC_CLKDIV + 1) * 1000) \ 24 IF Tmr = d ORELSE Tmr 5000 THEN _ .Errr = @sample rate too big : RETURN .Errr BTW: The example triggers.bas http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_examples.html#SubSecExaTriggers may give you an idea how to use MM mode. BR -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to 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] Enable UART1 in Jessie BBB.
Robert, Please disregard the last post. All I had to do was stty! It works!!! It works!!! So, I owe you a few drinks and/or dinner. How do I pay up? M On Tuesday, August 25, 2015 at 1:55:44 PM UTC-7, RobertCNelson wrote: On Tue, Aug 25, 2015 at 3:51 PM, Robert Nelson robert...@gmail.com javascript: wrote: On Tue, Aug 25, 2015 at 3:26 PM, michael...@mac.com javascript: wrote: Robert, I just bought a Circuit Co RS-232 cape. It is revision B1. Does this install work for that cape or do I need to do something different? I am using a very recent Debian installation. Everything works great except for this cape! The jessie lxqt image's should work out of the box with that.. dmesg | grep bone Oh wait, B1 doesn't have eeprom, so we can't detect it... Depending on what jumper you have it set for: /boot/uEnv.txt: cape_enable=bone_capemgr.enable_partno=BB-UART0 cape_enable=bone_capemgr.enable_partno=BB-UART1 cape_enable=bone_capemgr.enable_partno=BB-UART2 cape_enable=bone_capemgr.enable_partno=BB-UART4 #hdmi must be disabled 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] Re: shutdown procedure required for beaglebone black ??
Hi Robert, My apologies to you and the Forum for how I question every e-mail, but no, I'm neither a troll nor a lawyer. I'm actually a software engineer with a physics background. Thank you for showing me the chain of events that occur when the power button is pushed. I now understand what Gerald meant: systemd was the SW he was referring to, and depending on the image, the SW might not support this chain. According to the cat /etc/dogtag command, our image is BeagleBoard.org BeagleBone Debian Image 2014-04-23 And according to the SparkFun Electronics https://www.sparkfun.com/products/12857 website where my team HW lead bought our BBB, the rev is Rev C - DEV-12857 Since the Beagleboard:BeagleBoneBlack - eLinux.org http://elinux.org/Beagleboard:BeagleBoneBlack#Revision_A5A wikipage says the power button was added in Rev A6A, then our BBB should be able to execute the chain. I tried it, and it works. I also ran the shutdown command (actually, shutdown -h now, based on what I read in the other Forum topics), and it worked. The wikipage also recommends issuing the halt command to power off the board; I tried that, too, and it also worked. I have instructed my teammates to use the halt command, as it entails less typing and avoids the problem of fat fingers pushing the wrong component on the board. However, not fifteen minutes after I told the HW lead, he unceremoniously pulled the USB cable out without issuing the halt command. Sigh... In any case, we now know the required shutdown procedure for the BBB. Thank you, Robert, Gerald, and cmbaker3, for your assistance. We really appreciate it. Best regards, Lawrence On Monday, August 24, 2015 at 4:24:13 PM UTC-7, RobertCNelson wrote: On Sat, Aug 22, 2015 at 12:50 AM, lmje...@gmail.com javascript: wrote: Hi Gerald, Do you mean the Linux umount command to un-mount the drive(s)? In an earlier post, you said, Assuming that the SW supports the power button function. Were you saying that the umount command is assumed to support the function of the power button? Lawrence Lawrence, are you a troll or lawyer? Based on how you question every email... With the current images.. Push button - signal to systemd - systemd starts standard shutdown... If your image doesn't do that, it's not current... 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] how to fix cross compiling ftrace error for 4.1.2 kernel
Which version of gcc? And did you use the default bb.org_defconfig? On Aug 26, 2015 1:41 PM, thomas...@googlemail.com wrote: I run into this error when trying to cross compile: crelloc@neoGenerationwork ~/omap/linux $ make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- ... ... ... arch/arm/kernel/ftrace.c: In function ‘ftrace_arch_code_modify_post_process’: arch/arm/kernel/ftrace.c:93:2: error: implicit declaration of function ‘flush_tlb_all’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[1]: *** [arch/arm/kernel/ftrace.o] Error 1 make: *** [arch/arm/kernel] Error 2 I grabbed the kernel from https://github.com/beagleboard/linux: git clone -b 4.1.2-ti-r4 https://github.com/beagleboard/linux --depth=1 How do I fix this error to successfully cross compile my custom kernel? Any suggestions would greatly help, Thanks -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. 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] CBB-Serial Cape: Problems with RS-485
YOU FORGOT A GROUND WIRE On 8/26/2015 1:07 AM, benjamin.meie...@gmail.com wrote: Hello, I have a BeagleBone Black with a Serial Cape (http://www.logicsupply.com/eu-en/cbb-serial/). This cape supports RS-485 which i'm interested in. Before i had this cape, i used a RS-485-to-USB-converter. My problem: I try to read some data from an external device. It's very simple: The request is just /?!\r\n and then i get the data. With the RS485-to-USB-Stick i used this serial port configuration (with ser2net): /dev/ttyUSB0 9600 7DATABITS EVEN 1STOPBIT With the cape i tried this configuration: /dev/ttyO4 9600 7DATABITS EVEN 1STOPBIT Unfortunately this first try didn't work. I didn't get any response. I also tried this configuration: /dev/ttyO4 9600 7DATABITS EVEN 1STOPBIT RTSCTS I set the jumpers on the cape like this: J8: RS485 J7: UART4 RTS The RS485+ wire is connected to the RS485B port, and the RS485- wire is connected to the RS485A port. (https://docs.google.com/document/d/1sgurQ-7gLyn7g-Kg983NRM0aDkYEqHqy9dmrieX_RUM/edit page7) To get a better overview i made a photo: https://lh3.googleusercontent.com/-DGOBBHIo6sM/Vd1xuVsgc_I/AEE/JS4oAhPYoOk/s1600/IMG_20150826_091607_mod.jpg At the bottom of the picture there is the RS485-to-USB converter. It just has two ports which i used to connect the RS485 wires. I think the board itself should work, because if i execute cat /sys/devices/bone_capemgr.*/slots i can see it. My question: Do i do something wrong? Maybe someone else has used this cape with RS485? I thought it should be almost as easy as with the USB converter? Thank you for any help Best regards Benj -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com mailto:beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] BBB and LCD7 under Ubuntu in my own applications: is it practical?
No, not really. The touch screen is so jittery (holding a stylus in one place has the pointer bouncing around about +/- 4 pixels no matter what) that it is almost impossible to select small items on screen. I never got Ubuntu to work. But given the issue with the touchscreen (can it be fixed? I don't know), and the sharing of pins problem with the LCD Cape, I have decided to stick with HDMI-input touchscreens. I have a few which have none of those problems. Prices are much better, too. Bruce -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to 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] how to fix cross compiling ftrace error for 4.1.2 kernel
A couple of the patches aren't fully 'random' config safe.. On Aug 26, 2015 1:54 PM, Robert Nelson robertcnel...@gmail.com wrote: Which version of gcc? And did you use the default bb.org_defconfig? On Aug 26, 2015 1:41 PM, thomas...@googlemail.com wrote: I run into this error when trying to cross compile: crelloc@neoGenerationwork ~/omap/linux $ make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- ... ... ... arch/arm/kernel/ftrace.c: In function ‘ftrace_arch_code_modify_post_process’: arch/arm/kernel/ftrace.c:93:2: error: implicit declaration of function ‘flush_tlb_all’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[1]: *** [arch/arm/kernel/ftrace.o] Error 1 make: *** [arch/arm/kernel] Error 2 I grabbed the kernel from https://github.com/beagleboard/linux: git clone -b 4.1.2-ti-r4 https://github.com/beagleboard/linux --depth=1 How do I fix this error to successfully cross compile my custom kernel? Any suggestions would greatly help, Thanks -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. 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 OpenSuse 13.2 no video output
Hi, The HDMI output is working. No I'm trying to use the LCD output using the 4DCAPE-70T LCD http://www.4dsystems.com.au/product/4DCAPE_70T/ I found 2 threads who described the same issue BBB and LCD7 under Ubuntu in my own applications: is it practical? BBB Debian 4.1 Jessie and 4DCAPE-43T I created the file uEnv.txt *linux:~ # cat /boot/uEnv.txt* *dtb=am335x-boneblack-emmc-overlay.dtb* When I restart the system opensuse i booting but the LCD is OFF *linux:~ # dmesg | fgrep cape* *[ 21.997114] bone_capemgr bone_capemgr: Baseboard: 'A335BNLT,000C,2115BBBK1190'* *[ 22.258657] bone_capemgr bone_capemgr: compatible-baseboard=ti,beaglebone-black - #slots=4* *[ 22.401764] bone_capemgr bone_capemgr: slot #0: '4D 7.0 LCD CAPE- 4DCAPE-70T ,00A3,4D SYSTEMS ,BB-BONE-LCD7-01'* *[ 22.887737] bone_capemgr bone_capemgr: slot #1: No cape found* *[ 23.157726] bone_capemgr bone_capemgr: slot #2: No cape found* *[ 23.367720] bone_capemgr bone_capemgr: slot #3: No cape found* *[ 23.437515] bone_capemgr bone_capemgr: initialized OK.* *[ 25.542558] bone_capemgr bone_capemgr: loader: failed to load slot-0 BB-BONE-LCD7-01:00A3 (prio 0)* *linux:~ # lsblk* *NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT* *mmcblk1boot0 179:16 0 1M 1 disk* *mmcblk1boot1 179:24 0 1M 1 disk* *mmcblk0 179:00 14.9G 0 disk* *├─mmcblk0p1 179:10 209M 0 part /boot* *├─mmcblk0p2 179:20 14.1G 0 part /* *└─mmcblk0p3 179:30 493.5M 0 part* *mmcblk1 179:80 3.7G 0 disk* *├─mmcblk1p1 179:9096M 0 part* *└─mmcblk1p2 179:10 0 3.6G 0 part* *linux:~ # uname -r* *4.1.6* Best regards, Matthieu Le mardi 25 août 2015 20:01:00 UTC+2, matthieu claire a écrit : I have tried something which is working. I used the original u-boot.img from the opensuse 13.2 instead of using the one I created with the command #*make uImage dtbs LOADADDR=0x80008000 -j4* But I used the zImage and initrd I have generated when I install the 4.1.6 [image: Images intégrées 1] I booted succesfully on opensuse 13.2 with the kernel 4.1.6 *linux:~ # cat /proc/version* *Linux version 4.1.6 (r...@linux.site) (gcc version 4.8.3 20140627 [gcc-4_8-branch revision 212064] (SUSE Linux) ) #1 SMP PREEMPT Sun Aug 23 16:43:56 UTC 2015* *linux:~ # cat /etc/os-release* *NAME=openSUSE* *VERSION=13.2 (Harlequin)* *VERSION_ID=13.2* *PRETTY_NAME=openSUSE 13.2 (Harlequin) (armv7hl)* *ID=opensuse* *ANSI_COLOR=0;32* *CPE_NAME=cpe:/o:opensuse:opensuse:13.2* *BUG_REPORT_URL=https://bugs.opensuse.org https://bugs.opensuse.org* *HOME_URL=https://opensuse.org/ https://opensuse.org/* *ID_LIKE=suse* Now I will go back check the video output and let you know the result. Best regards, 2015-08-25 17:13 GMT+02:00 Robert Nelson robertcnel...@gmail.com: On Tue, Aug 25, 2015 at 10:06 AM, matthieu claire mclaire@gmail.com wrote: Here is the serial boot log *U-Boot SPL 2014.10 (Oct 20 2014 - 20:57:40)* *spl_register_fat_device: fat register err - -1* *spl_register_fat_device: fat register err - -1* *spl_load_image_fat: error reading image u-boot.img, err - -1* *spl: ext4fs_open failed* *spl_load_image_ext_os: error reading image args, err - 0* If that's it... You have 'other' issues to fix first.. before we even talk about telling u-boot which kernel file to load.. Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] BBB OpenSuse 13.2 no video output
dmesg | fgrep bone shows the same as fgrep cape. i will check the dtc I need to find how to apply it on opensuse I'm really not familiar with this part. 2015-08-26 20:12 GMT+02:00 Robert Nelson robertcnel...@gmail.com: On Wed, Aug 26, 2015 at 1:07 PM, mclaire@gmail.com wrote: Hi, The HDMI output is working. No I'm trying to use the LCD output using the 4DCAPE-70T LCD http://www.4dsystems.com.au/product/4DCAPE_70T/ I found 2 threads who described the same issue BBB and LCD7 under Ubuntu in my own applications: is it practical? BBB Debian 4.1 Jessie and 4DCAPE-43T I created the file uEnv.txt *linux:~ # cat /boot/uEnv.txt* *dtb=am335x-boneblack-emmc-overlay.dtb* When I restart the system opensuse i booting but the LCD is OFF *linux:~ # dmesg | fgrep cape* *[ 21.997114] bone_capemgr bone_capemgr: Baseboard: 'A335BNLT,000C,2115BBBK1190'* *[ 22.258657] bone_capemgr bone_capemgr: compatible-baseboard=ti,beaglebone-black - #slots=4* *[ 22.401764] bone_capemgr bone_capemgr: slot #0: '4D 7.0 LCD CAPE- 4DCAPE-70T ,00A3,4D SYSTEMS ,BB-BONE-LCD7-01'* *[ 22.887737] bone_capemgr bone_capemgr: slot #1: No cape found* *[ 23.157726] bone_capemgr bone_capemgr: slot #2: No cape found* *[ 23.367720] bone_capemgr bone_capemgr: slot #3: No cape found* *[ 23.437515] bone_capemgr bone_capemgr: initialized OK.* *[ 25.542558] bone_capemgr bone_capemgr: loader: failed to load slot-0 BB-BONE-LCD7-01:00A3 (prio 0)* How about: dmesg | grep bone (cape doesn't show everything.) Make sure you used the new dtc https://github.com/beagleboard/bb.org-overlays Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] BBB and LCD7 under Ubuntu in my own applications: is it practical?
Hi Bruce, Robert Have you been able to have the LCD output working ? On my side I have install opensuse 13.2 on µSD and update the kernel to the latest version 4.1.6 The HDMI outpout is working. When I plugge the LCD 4DCAPE-70T https://www.google.fr/url?sa=trct=jq=esrc=ssource=webcd=2cad=rjauact=8sqi=2ved=0CDQQFjABahUKEwiO4pvS_cbHAhUKvRoKHWhFCIIurl=http%3A%2F%2Fwww.4dsystems.com.au%2Fproduct%2F4DCAPE_70T%2Fei=NdDdVc7zKIr6auiKoZAIusg=AFQjCNG8A2SmbC6F0LFCVwAz2JiRFYu-Wgsig2=8GxtJzmwtd-KAe_xBKDdyg the capemgr found the LCD but it failed to load the slot same issue as Bruce. On my side I do not have any uEnv.txt in my boot folder it seems opensuse is using the boot.scr I create it and add only the line below and of course I copied the file am335x-boneblack-emmc-overlay.dtb in /boot/dtb dtb=am335x-boneblack-emmc-overlay.dtb But it still have the same issue. Best regards, Matthieu Le vendredi 17 juillet 2015 22:52:36 UTC+2, Bruce Boyes a écrit : On the other hand, Angstrom goes off in the weeds quite easily, leaving selected menus on the screen with these errrors: beaglebone login: [ 504.326720] mmcblk0: error -84 transferring data, sector 2571625, nr 128, cmd response 0x900, card status 0xb00 [ 504.408042] mmcblk0: error -84 transferring data, sector 2589489, nr 128, cmd response 0x900, card status 0xb00 [ 504.496869] mmcblk0: error -84 transferring data, sector 2589617, nr 128, cmd response 0x900, card status 0xb00 [ 504.645162] mmcblk0: error -84 transferring data, sector 2560001, nr 128, cmd response 0x900, card status 0x0 I'm not sure why it would be writing to eMMC as part of a menu/window selection routine... maybe coincidence and better put into another thread since this one is about ubuntu accessing LCD7. Bruce -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to 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: libpruio adc pruio_config help
Hi! The PRUSS have access to various timers. libpruio uses the PRU intern IEP timer (100 MHz, no OCP latency) to start the ADC measurements. It should be possible to achieve the specified accuracy (in MM or RB mode). There is no 64 bit timer for the PRUSS. The IEP timer resets after each period, so it doesn't make sense to send the value after X samples. It is not possible to set avaraging to 24. Possible values are 16, 8, 4, 2 and 1 (= no avaraging). When you specify 24 for the Av parameter in the AdcUdt::setStep() call, libpruio will adapt it to 16. BR -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to 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] Uncompressing Linux... done, booting the kernel.
Thank you. I used this command to get the repository. git clone https://github.com/Angstrom-distribution/meta-ti.git I see meta-ti/tree/master/recipes-kernel/linux/linux-3.0 meta-ti/tree/master/recipes-kernel/linux/linux-3.0.bb I do not see meta-ti/blob/master/recipes-kernel/linux/linux_3.0.bb Well, yeah blob is just part of the github web interface... 1) Is linux-3.0.bb a script used with 'patch'? 2) Do I cd to top level of kernel tree and run patch with this script? 3) How is this script executed? It's a *.bb script... so either use bitbake, or write a script to manually patch -p1 file in the order shown in the *.bb file. I'd personally write a script.. Using bitbake requires more other un-related work.. 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] Enable UART1 in Jessie BBB.
WOW, it loaded. dmesg says so any way. The echo test /dev/ttyO1...ttyS1 does not fail, but the output is not showing up in my terminal window. Using another BB and a debug cable does send data to UART0. Do I need to apply this change? http://www.berriman.co.uk/beaglebone-black-with-rs232-cape/ M On Tuesday, August 25, 2015 at 1:55:44 PM UTC-7, RobertCNelson wrote: On Tue, Aug 25, 2015 at 3:51 PM, Robert Nelson robert...@gmail.com javascript: wrote: On Tue, Aug 25, 2015 at 3:26 PM, michael...@mac.com javascript: wrote: Robert, I just bought a Circuit Co RS-232 cape. It is revision B1. Does this install work for that cape or do I need to do something different? I am using a very recent Debian installation. Everything works great except for this cape! The jessie lxqt image's should work out of the box with that.. dmesg | grep bone Oh wait, B1 doesn't have eeprom, so we can't detect it... Depending on what jumper you have it set for: /boot/uEnv.txt: cape_enable=bone_capemgr.enable_partno=BB-UART0 cape_enable=bone_capemgr.enable_partno=BB-UART1 cape_enable=bone_capemgr.enable_partno=BB-UART2 cape_enable=bone_capemgr.enable_partno=BB-UART4 #hdmi must be disabled Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] CBB-Serial Cape: Problems with RS-485
Hello, I have a BeagleBone Black with a Serial Cape (http://www.logicsupply.com/eu-en/cbb-serial/). This cape supports RS-485 which i'm interested in. Before i had this cape, i used a RS-485-to-USB-converter. My problem: I try to read some data from an external device. It's very simple: The request is just /?!\r\n and then i get the data. With the RS485-to-USB-Stick i used this serial port configuration (with ser2net): /dev/ttyUSB0 9600 7DATABITS EVEN 1STOPBIT With the cape i tried this configuration: /dev/ttyO4 9600 7DATABITS EVEN 1STOPBIT Unfortunately this first try didn't work. I didn't get any response. I also tried this configuration: /dev/ttyO4 9600 7DATABITS EVEN 1STOPBIT RTSCTS I set the jumpers on the cape like this: J8: RS485 J7: UART4 RTS The RS485+ wire is connected to the RS485B port, and the RS485- wire is connected to the RS485A port. (https://docs.google.com/document/d/1sgurQ-7gLyn7g-Kg983NRM0aDkYEqHqy9dmrieX_RUM/edit page7) To get a better overview i made a photo: https://lh3.googleusercontent.com/-DGOBBHIo6sM/Vd1xuVsgc_I/AEE/JS4oAhPYoOk/s1600/IMG_20150826_091607_mod.jpg At the bottom of the picture there is the RS485-to-USB converter. It just has two ports which i used to connect the RS485 wires. I think the board itself should work, because if i execute cat /sys/devices/bone_capemgr.*/slots i can see it. My question: Do i do something wrong? Maybe someone else has used this cape with RS485? I thought it should be almost as easy as with the USB converter? Thank you for any help Best regards Benj -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to 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 OpenSuse 13.2 no video output
On Wed, Aug 26, 2015 at 1:38 PM, matthieu claire mclaire@gmail.com wrote: dmesg | fgrep bone shows the same as fgrep cape. i will check the dtc I need to find how to apply it on opensuse I'm really not familiar with this part. If it's not dtc 1.4.1-gXXX then: build this version: https://github.com/pantoniou/dtc branch: dt-overlays5 hopefully it'll hit dtc master at some point. ;) Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] BBB OpenSuse 13.2 no video output
On Wed, Aug 26, 2015 at 1:07 PM, mclaire@gmail.com wrote: Hi, The HDMI output is working. No I'm trying to use the LCD output using the 4DCAPE-70T LCD http://www.4dsystems.com.au/product/4DCAPE_70T/ I found 2 threads who described the same issue BBB and LCD7 under Ubuntu in my own applications: is it practical? BBB Debian 4.1 Jessie and 4DCAPE-43T I created the file uEnv.txt *linux:~ # cat /boot/uEnv.txt* *dtb=am335x-boneblack-emmc-overlay.dtb* When I restart the system opensuse i booting but the LCD is OFF *linux:~ # dmesg | fgrep cape* *[ 21.997114] bone_capemgr bone_capemgr: Baseboard: 'A335BNLT,000C,2115BBBK1190'* *[ 22.258657] bone_capemgr bone_capemgr: compatible-baseboard=ti,beaglebone-black - #slots=4* *[ 22.401764] bone_capemgr bone_capemgr: slot #0: '4D 7.0 LCD CAPE- 4DCAPE-70T ,00A3,4D SYSTEMS ,BB-BONE-LCD7-01'* *[ 22.887737] bone_capemgr bone_capemgr: slot #1: No cape found* *[ 23.157726] bone_capemgr bone_capemgr: slot #2: No cape found* *[ 23.367720] bone_capemgr bone_capemgr: slot #3: No cape found* *[ 23.437515] bone_capemgr bone_capemgr: initialized OK.* *[ 25.542558] bone_capemgr bone_capemgr: loader: failed to load slot-0 BB-BONE-LCD7-01:00A3 (prio 0)* How about: dmesg | grep bone (cape doesn't show everything.) Make sure you used the new dtc https://github.com/beagleboard/bb.org-overlays Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] after short boot, all LED off
Hello, I have one BBB with this problem: no boot, just Power LED, no console info When I insert a microSD and hold Button S2, he start to boot: \nU-Boot SPL 2013.04 (Sep 25 2013 - 00:49:30)\r \nmusb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)\r \nmusb-hdrc: MHDRC RTL version 2.0 \r \nmusb-hdrc: setup fifo_mode 4\r \nmusb-hdrc: 28/31 max ep, 16384/16384 memory\r \nUSB Peripheral mode controller at 47401000 using PIO, IRQ 0\r \nmusb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)\r \nmusb-hdrc: MHDRC RTL version 2.0 \r \nmusb-hdrc: setup fifo_mode 4\r \nmusb-hdrc: 28/31 max ep, 16384/16384 memory\r \nUSB Host mode controller at 47401800 using PIO, IRQ 0\r \nOMAP SD/MMC: 0\r \nreading u-boot.img\r \nreading u-boot.img\r \n\r \n\r \nU-Boot 2013.04 (Sep 25 2013 - 00:49:30)\r \n\r \nI2C: ready\r \nDRAM: 512 MiB\r \nWARNING: Caches not enabled\r \nNAND: No NAND device found!!!\r \n0 MiB\r \nMMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1\r \n*** Warning - readenv() failed, using default environment\r \n\r \nmusb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)\r \nmusb-hdrc: MHDRC RTL version 2.0 \r \nmusb-hdrc: setup fifo_mode 4\r \nmusb-hdrc: 28/31 max ep, 16384/16384 memory\r \nUSB Peripheral mode controller at 47401000 using PIO, IRQ 0\r \nmusb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)\r \nmusb-hdrc: MHDRC RTL version 2.0 \r \nmusb-hdrc: setup fifo_mode 4\r \nmusb-hdrc: 28/31 max ep, 16384/16384 memory\r \nUSB Host mode controller at 47401800 using PIO, IRQ 0\r \nNet: ethaddr not set. Validating first E-fuse MAC\r \ncpsw, usb_ether\r \nHit any key to stop autoboot: 1 \b\b\b 0 \r \nmmc0 is current device\r \nSD/MMC found on device 0\r \nreading uEnv.txt\r \n236 bytes read in 4 ms (57.6 KiB/s)\r \nLoaded environment from uEnv.txt\r \nImporting environment from mmc ...\r \nRunning uenvcmd ...\r \nreading uImage\r \n11748096 bytes read in 1343 ms (8.3 MiB/s)\r \nreading /am335x-boneblack.dtb\r \n24884 bytes read in 9 ms (2.6 MiB/s)\r \n## Booting kernel from Legacy Image at 8020 ...\r \n Image Name: Linux-3.8.13\r \n Image Type: ARM Linux Kernel Image (uncompressed)\r \n Data Size:11748032 Bytes = 11.2 MiB\r \n Load Address: 80008000\r \n Entry Point: 80008000\r \n Verifying Checksum ... OK\r \n## Flattened Device Tree blob at 81ff\r \n Booting using the fdt blob at 0x81ff\r \n Loading Kernel Image ... OK\r \nOK\r \n Using Device Tree in place at 81ff, end 81ff9133\r \n\r \nStarting kernel ...\r \n\r \nUncompressing Linux... done, booting the kernel.\r \n[1.368852] omap2_mbox_probe: platform not supported\r \n[1.379733] tps65217-bl tps65217-bl: no platform data provided\r \n[1.455970] bone-capemgr bone_capemgr.9: slot #0: No cape found\r \n[1.493077] bone-capemgr bone_capemgr.9: slot #1: No cape found\r \n[1.530185] bone-capemgr bone_capemgr.9: slot #2: No cape found\r \n[1.567294] bone-capemgr bone_capemgr.9: slot #3: No cape found\r \n[1.594043] omap_hsmmc mmc.5: of_parse_phandle_with_args of 'reset' failed\r \n[1.659479] pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by 44e10800.pinmux; cannot claim for gpio-leds.8\r \n[1.671182] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status -22\r \n[1.678494] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single\r \n\0 and then all LED off, ALSO the power LED. Normally my revC version booting from microSD when I press NO button. But with this, I have to hold S2 Button and then he write the infos above. Failure of the BBB? Thank you! -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] metaldetector
hi i am trying to build a special type of metal detector called a constant current metal detector. i need to use 7 gpio's to and turn some on transistors and some off in a repeating pattern. i will show a table at the bottom to make things more easier understand what iam trying to do each of the 7 gpio's are responsible for turning on transistor or turning it off switch s57,s58,s59,s60,s61,s62,s63 to s64 are each equivalent to one gpio all the logic states are repeated after the whole cycle has finished. as i see it i can look at it this way if i chose s57 which was gpio60 i would have to put a if statement so it would not just turn the gpio60 on again before the first iteration had finished S57 S58 S59 S60 S61 S62 S63 S64 onoffoffonn/aonn/aoff onoffoffonn/aoffn/aon offononoffonn/aoffn/a offononoffoffn/aonn/a. offoffononononoffoff offoffonononoffoffon offoffononoffononoff -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to 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] flashing eMMC are not working
Hello Robert, so many thanks for your help. I try now again with: http://elinux.org/BeagleBone_Black_Extracting_eMMC_contents and now it works. I has to set manual in windows the partition as active and generate the folder dtbs. Now I can made the backup and restore Thanks -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] BBB wifi setup
I have a OURLINK wifi adapter I can see the wifi, and it has a inet6 address, but not an ip address. I can't figure out why not? I am using a wpa_supplicant.conf file which I know works (because it is the same file that works on my raspberry pi. Can someone who knows what my problem is, tell me what I need to do? lsusb output is: us 001 Device 002: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter ifconfig looks like this: eth0 Link encap:Ethernet HWaddr 6c:ec:eb:ac:78:45 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:40 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) usb0 Link encap:Ethernet HWaddr e6:0b:5a:a8:76:94 inet addr:192.168.7.2 Bcast:192.168.7.3 Mask:255.255.255.252 inet6 addr: fe80::e40b:5aff:fea8:7694/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:190 errors:0 dropped:0 overruns:0 frame:0 TX packets:39 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:54027 (52.7 KiB) TX bytes:10046 (9.8 KiB) wlan0 Link encap:Ethernet HWaddr 00:e0:4c:0b:f3:ab inet addr:10.0.1.19 Bcast:10.0.1.255 Mask:255.255.255.0 inet6 addr: fe80::2e0:4cff:fe0b:f3ab/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:282 errors:0 dropped:0 overruns:0 frame:0 TX packets:106 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:39482 (38.5 KiB) TX bytes:14832 (14.4 KiB) My interfaces file looks like this: auto lo iface lo inet loopback allow-hotplug wlan0 iface wlan0 inet manual wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf iface default inet dhcp # The primary network interface #allow-hotplug eth0 #iface eth0 inet dhcp # Example to keep MAC address between reboots #hwaddress ether DE:AD:BE:EF:CA:FE # The secondary network interface #allow-hotplug eth1 #iface eth1 inet dhcp # WiFi Example #iface wlan0 inet dhcp #wpa-ssid essid #wpa-psk password # Ethernet/RNDIS gadget (g_ether) # ... or on host side, usbnet and random hwaddr # Note on some boards, usb0 is automaticly setup with an init script iface usb0 inet static address 192.168.7.2 netmask 255.255.255.0 network 192.168.7.0 gateway 192.168.7.1 Thank you kindly, Jerry -- Extra Ham Operator: K7AZJ Registered Linux User: 275424 Raspberry Pi and Arduino developer *The most exciting phrase to hear in science - the one that heralds new discoveries - is not Eureka! but That's funny*- Isaac. Asimov *I* *f you give someone a program, you will frustrate them for a day; if you teach them how to program, you will frustrate them for a lifetime. *- Anonymous *If writing good code requires very little comments, then writing really excellent code requires no comments at all!*- Ken Thompson -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to 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: ADC generic_buffer.c issues || Accessing ADC from own kernel module
To answer a question asked: the generic_buffer.c works fine with 4.1.5-ti-r10. The only thing I found is that the scale is not implemented (it's 1.0) so where you should be getting a value in Volts, you still get the 12 bit value from ADC (0 - 4095). Otherwise it pretty much works out of the box. On Thursday, 13 August 2015 06:51:22 UTC+8, Maro wrote: Hoping you guys can help me out on this: Goal: High sample rate of one ADC line via a kernel module and a corresponding user space app Now I know the PRU would be great for this- and I plan on also writing a pru version to bench mark the diff but I'm currently trying to get it done with a kernel module and its turned into one of those annoying obsessions that should work and damn it-- I am going to make it work So the goal is almost identical to the generic_buffer.c application referenced on this wiki [ http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide] but I've been fight it for awhile with no results. Current version: Linux beaglebone 3.8.13-bone70 1: pulled there git repo 2: applied the patch to get rid of the trigger stuff found here 3: compiled: gcc --static generic_buffer.c -o generic_buffer 4: Issues happen now because sysfs seem to be so different, I'm not sure contionous mode can be turned on? ./generic_buffer -n tiadc -l 256 -c 1 iio device number being used is 0 Problem reading scan element information diag /sys/bus/iio/devices/iio:device0 5: This error leads down the rabbit hole to this semi unhelpful blog post: https://e2e.ti.com/support/arm/sitara_arm/f/791/t/365886 yielding an errata about `Continuous capture mode is not supported in the 3.12 kernel`; great we are still rocking a 3.8.13 kernel thus should be fine? -- Couple questions: 1: Is there bbb kernel version that plays nice with the iio driver that will allow this generic_buffer.c to work? if so details please 2: if not has anyone modified this demo app to make things work? I've seen a couple posts about it here 2: Is there any information to say screw it and read the adc values directly in my own ko? I've seen instructions on gpio but not the adc lines. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to 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: Good small (e.g. 7 to 10 inch) displays for BBB
William Hermans yyrk...@gmail.com wrote: [-- text/plain, encoding quoted-printable, charset: UTF-8, 68 lines --] Ah, be wary of that monitor you're looking at on aliexpress . . Resolution:960x240Resolution:1024*RGB*600 Which is it ? Both ? I don't really care all that much! :-) -- Chris Green · -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Wl12xx
Hi, When i add wl12xx module, none of the functions from wl12xx and wlcore are getting called. logs: root@arm:~# modprobe wlcore_sdio [ 48.682409] [ 48.682409] ** wl1271_init [ 48.690385] [ 48.690385] ** sdio_register_driver [ 48.708615] [ 48.708615] ** sdio_register_driver : wl1271_sdio root@arm:~# modprobe wl12xx [ 57.901415] [ 57.901415] ** Country : COUNTRY=00 * [ 57.908006] cfg80211: Calling CRDA to update world regulatory domain [ 58.061324] [ 58.061324] ** ieee80211_init [ 58.067658] [ 58.067658] ** ieee80211_init 1 [ 58.076820] [ 58.076820] ** ieee80211_init 2 [ 58.086826] [ 58.086826] ** ieee80211_init 3 root@arm:~# [ 58.207791] cfg80211: World regulatory domain updated: [ 58.213206] cfg80211: DFS Master region: unset [ 58.217588] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 58.229554] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [ 58.237609] cfg80211: (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [ 58.246721] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 mBm), (N/A) [ 58.255431] cfg80211: (517 KHz - 525 KHz @ 8 KHz, 16 KHz AUTO), (N/A, 2000 mBm), (N/A) [ 58.265659] cfg80211: (525 KHz - 533 KHz @ 8 KHz, 16 KHz AUTO), (N/A, 2000 mBm), (0 s) [ 58.275796] cfg80211: (549 KHz - 573 KHz @ 16 KHz), (N/A, 2000 mBm), (0 s) [ 58.284697] cfg80211: (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 2000 mBm), (N/A) [ 58.293341] cfg80211: (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 0 mBm), (N/A) root@arm:~# lsmod Module Size Used by wl12xx 64379 0 wlcore213095 1 wl12xx mac80211 631232 2 wl12xx,wlcore cfg80211 518978 2 mac80211,wlcore rfkill 20618 1 cfg80211 wlcore_sdio 8050 0 snd_soc_evm 7798 0 omap_rng5144 0 rng_core8712 1 omap_rng tilcdc 31000 0 snd_soc_tlv320aic32x416689 1 snd_soc_davinci_mcasp18424 2 snd_soc_edma1166 1 snd_soc_davinci_mcasp uio_pdrv_genirq 3625 0 uio 9898 1 uio_pdrv_genirq root@arm:~# On Thu, Aug 20, 2015 at 4:18 PM, Iain Hunter drhunte...@gmail.com wrote: Hi, As a follow up I agree with the previous statement that wl127x drivers have no device tree support. So you'll need to merge device tree support from wl18xx drivers. As far as I can remember there are no major changes to parameters passed by device tree to WiFi driver from wl127x to wl18xx. As long as you successfully pass the wl12xx probe function without an error you should be ok. Caveat is that I've not done this exercise. Iain On 19 Aug 2015 15:56, drhunte...@gmail.com wrote: Hi, Which wilink device are you building for? The wl18xx family is now fully supported in 4.1 kernel. There is a device tree file for the wl1835 cape in the kernel that is best place to look. If you are looking at wl127x or wl128x then device tree will be similar but you'll need to build the Wi-Fi drivers out of tree. For the wl1835 cape look at the ti processor wiki for a page to describe full build and configuration on 4.1 kernel. Iain -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/_Edxe-s1MxQ/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/_Edxe-s1MxQ/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Time to start of execution
Yes, sorry for being unclear - I'm indeed referring to a bonescript through Nodejs. That's interesting - that would seem to support my guess - many thanks! Cheers, Daniel onsdag 26 augusti 2015 skrev William Hermans yyrk...@gmail.com: I'm assuming you're referring to a bonescript running through Nodejs ? So, I can not tell you why, but I had my own custom image for which I built my own version of Nodejs from sources. I experienced the exact same thing. Nodejs apps took like you say around 3+ seconds to start up, but seem reasonably responsive afterwords. Anyway, that, and a couple other reasons is why I recently chose to use C with libmongoose for web server / websocket duties. On Tue, Aug 25, 2015 at 5:37 PM, Daniel Sundström dan...@sykewarrior.com javascript:_e(%7B%7D,'cvml','dan...@sykewarrior.com'); wrote: Hi, This might be a very stupid question, in which case I apologise - but I've read through all the source code I can find without understanding why. So, when using the pre-installed image on a Rev C BBB and running one of the examples - say demo_blinkled, the board responds more or less immediately. But, when running the exact same program manually from the CLI over SSH, it takes at least 3-5 seconds before the board reacts. My conclusion is that this time is basically the board loading the node-environment on script start when running from the CLI, but that the page presenting demos on the pre-installed image are already running within this environment and thus, of course doesn't need to start it. Is it this simple or is there some kind of optimisation I just can't find in source code anywhere? Many thanks, Daniel -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com javascript:_e(%7B%7D,'cvml','beagleboard%2bunsubscr...@googlegroups.com'); . For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/-CM-lUJNpT4/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com javascript:_e(%7B%7D,'cvml','beagleboard%2bunsubscr...@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.
[beagleboard] Robopeak USB Display Help
Hello Beaglebone Black community. I've been playing around lately with a Robopeak USB Display which I managed to get working on my Cubieboard before, so then I though I could do the same on my beagleboard. I followed section number 4 in the user's manual (http://www.dfrobot.com/image/data/DFR0275/RPUD02-rpusbdisp_usermanual-enUS.1.0.pdf), the one that says Advanced Usage , and after completing each step no errors were reported by the operating system. I rebooted the board, pluged in the USB Display and no image shows up. It seems like it tries to get an image because the usual salt-and-pepper display doesn't appear, but in the end, there is just a black screen. If anyone has worked with this display on the beagleboard I would tremendously appreciate some recommendations. Thanks beforehand. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to 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: CBB-Serial Cape: Problems with RS-485
The BeagleBone's omap-serial driver doesn't support RS-485 DE/RE control with the RTS flow control signal. Instead it has an RS-485 mode using a GPIO pin for DE/RE control, and has a modified serial_rs485 struct from the standard serial driver. You have to use ioctl on the corresponding /dev/ttyOx file to put the serial driver in RS-485 mode and tell it which pin to use, and you also have to take care of muxing the pin to GPIO mode. So with the jumper in the RTS position that would be the GPIO signal that shares the pin with the UART4 RTS signal, so that's GPIO0_9 on P8.33. Or you can put it to the GPIO1_16 position and use GPIO1_16 instead. (I believe GPIO1_16 There's a tutorial here: http://inspire.logicsupply.com/2014/09/beaglebone-rs-485-communication.html Also, I believe RS485B is the inverting output, so you have your +/- swapped. On Wednesday, August 26, 2015 at 2:41:49 PM UTC-4, benjamin...@gmail.com wrote: Hello, I have a BeagleBone Black with a Serial Cape ( http://www.logicsupply.com/eu-en/cbb-serial/). This cape supports RS-485 which i'm interested in. Before i had this cape, i used a RS-485-to-USB-converter. My problem: I try to read some data from an external device. It's very simple: The request is just /?!\r\n and then i get the data. With the RS485-to-USB-Stick i used this serial port configuration (with ser2net): /dev/ttyUSB0 9600 7DATABITS EVEN 1STOPBIT With the cape i tried this configuration: /dev/ttyO4 9600 7DATABITS EVEN 1STOPBIT Unfortunately this first try didn't work. I didn't get any response. I also tried this configuration: /dev/ttyO4 9600 7DATABITS EVEN 1STOPBIT RTSCTS I set the jumpers on the cape like this: J8: RS485 J7: UART4 RTS The RS485+ wire is connected to the RS485B port, and the RS485- wire is connected to the RS485A port. ( https://docs.google.com/document/d/1sgurQ-7gLyn7g-Kg983NRM0aDkYEqHqy9dmrieX_RUM/edit page7) To get a better overview i made a photo: https://lh3.googleusercontent.com/-DGOBBHIo6sM/Vd1xuVsgc_I/AEE/JS4oAhPYoOk/s1600/IMG_20150826_091607_mod.jpg At the bottom of the picture there is the RS485-to-USB converter. It just has two ports which i used to connect the RS485 wires. I think the board itself should work, because if i execute cat /sys/devices/bone_capemgr.*/slots i can see it. My question: Do i do something wrong? Maybe someone else has used this cape with RS485? I thought it should be almost as easy as with the USB converter? Thank you for any help Best regards Benj -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to 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: Can't seem to enable SPI0 on Beaglebone Black on Debian Jessie with 4.1.6 kernel
Well, I still don't know why the overlays aren't working, but I seem to
have gotten the clocks toggled correctly to avoid a SIGBUS Bus Error.
This code turns on the clocks and waits for them to become stable. Then it
reads the SPI0 version register for confirmation.
#include stdint.h
#include unistd.h
#include fcntl.h
#include sys/mman.h
#include stdio.h
#include assert.h
// Hunt these addresses down from ls -al /sys/devices/platform/ocp | grep
gpio
// You can also pull them from the TI manual (spruh73l.pdf)
#define CM_PER_BASE 0x44E0
#define CM_PER_SIZE 0x4000
#define CM_PER_SPI0_CLKCTRL 0x4C
#define CM_PER_L4LS_CLKCTRL 0x60
#define MCSPI0_BASE 0x4803
#define MCSPI0_SIZE 0x1000
#define MCSPI_REVISION (0x000)
#define MCSPI_SYSCONFIG (0x110)
#define MCSPI_SYSSTATUS (0x114)
#define MCSPI_SYST (0x124)
#define MCSPI_MODULCTRL (0x128)
#define MCSPI_CH0CONF (0x12C)
#define MCSPI_CH0STAT (0x130)
#define MCSPI_CH0CTRL (0x134)
int main(int argc, char *argv[])
{
uint8_t volatile * bbCM_PERMap = NULL;
uint8_t volatile * bbMCSPI0Map = NULL;
uint32_t ui32tmp = 0;
uint32_t volatile * ppui32tmp = NULL;
int fd = open(/dev/mem, O_RDWR);
bbCM_PERMap = mmap(0, CM_PER_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED,
fd, CM_PER_BASE);
assert(bbCM_PERMap != MAP_FAILED);
*(uint32_t volatile *)(bbCM_PERMap+CM_PER_L4LS_CLKCTRL) = 0x0002;
// Enable L4LS_CLK
do {
ui32tmp = *(uint32_t volatile *)(bbCM_PERMap+CM_PER_SPI0_CLKCTRL);
sleep(1);
} while (((ui32tmp 16) 0x0003) != 0); // Wait for L4LS_CLK to
come up
*(uint32_t volatile *)(bbCM_PERMap+CM_PER_SPI0_CLKCTRL) = 0x0002;
// Enable SPI0 CLK
do {
ui32tmp = *(uint32_t volatile *)(bbCM_PERMap+CM_PER_SPI0_CLKCTRL);
sleep(1);
} while (((ui32tmp 16) 0x0003) != 0); // Wait for module to
come up
bbMCSPI0Map = mmap(0, MCSPI0_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED,
fd, MCSPI0_BASE);
assert(bbMCSPI0Map != MAP_FAILED);
ppui32tmp = (uint32_t volatile *)bbMCSPI0Map;
assert(bbMCSPI0Map == ppui32tmp);
ui32tmp = *ppui32tmp; // Read the revision register
printf(SPI0 Revision: 0x%08x\n, ui32tmp);
close(fd);
return 0;
}
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to 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: operating temperature range of Beaglebone Black
I have a BBB that works fine in the den but when I move it the garage it eventually fails to maintain connectivity and by the looks of the lights, it is failing internally - but there's no way to see. The garage does get up to the 90s F. could that be the problem? On Tuesday, May 14, 2013 at 9:56:29 AM UTC-5, George Lu wrote: Hi, I could not find in SRM discussion of the rated operating temperature of the BBB as a whole. Is this information available somewhere? In SRM Rev A5A I see that the AM3359 processor is rated for -40 to 90 degrees C. Micro's page http://www.micron.com/parts/nand-flash/managed-nand/mtfc2gmtea-wt says mtfc2gmtea-wt is rated for -25 to 85 degrees C. I suppose there might be tighter constraints from other components. Thanks in advance! George -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to 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: operating temperature range of Beaglebone Black
It should not be. But you need to capture what the failure is by monitoring the terminal output continuously... It could be the power supply. Current rating? Is it in a box? Is it running from a SD card? What is the connectivity method, RJ45? WIFI? Is there a cape? More information will help. Gerald On Wed, Aug 26, 2015 at 6:01 PM, keener9...@gmail.com wrote: I have a BBB that works fine in the den but when I move it the garage it eventually fails to maintain connectivity and by the looks of the lights, it is failing internally - but there's no way to see. The garage does get up to the 90s F. could that be the problem? On Tuesday, May 14, 2013 at 9:56:29 AM UTC-5, George Lu wrote: Hi, I could not find in SRM discussion of the rated operating temperature of the BBB as a whole. Is this information available somewhere? In SRM Rev A5A I see that the AM3359 processor is rated for -40 to 90 degrees C. Micro's page http://www.micron.com/parts/nand-flash/managed-nand/mtfc2gmtea-wt says mtfc2gmtea-wt is rated for -25 to 85 degrees C. I suppose there might be tighter constraints from other components. Thanks in advance! George -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to 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/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to 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.
