Re: [beagleboard] Re: Announcement: Debian 8.6 released for all boards
Thank you, I'll try with IoT version for I do not need to use GUI or something. Than you again for your great work. On Wed, Jan 18, 2017 at 8:17 AM Robert Nelson wrote: > On Tue, Jan 17, 2017 at 4:51 PM, wrote: > > It seems that there are only 4GB images, are there any way of installing > new > > Debian 8.6 into old 2GB EMMC model? > > "untested" --- it might fit in 2gb... > > https://rcn-ee.net/rootfs/bb.org/testing/2017-01-15/lxqt-2gb/ > > Otherwise the console/iot: > > https://rcn-ee.net/rootfs/bb.org/testing/2017-01-15/ > > (the iot says 4gb, but it should flash a 2gb eMMC).. > > Regards, > > -- > Robert Nelson > https://rcn-ee.com/ > > -- > 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/yCKzPy54a7Q/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > beagleboard+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/CAOCHtYiVeSeCG12txp0FUmL8GnbU0XrV5rDqF7vG2N5SA0Q5Jw%40mail.gmail.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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CANhta7Zi0wxPL-0y7XOig0VpigRLXdgaJq7aF9NqPj-9w%3DNANQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Updating PinMux setting via /dev/mem has no effect
You have to be in privileged mode to change pinmux. My approach is creating a kernel module for it like this ( https://github.com/chunsj/nxctrl/tree/master/nxpmx) Or you can use PRU for this, I've heard that someone really do this in his library (I cannot remember its name). However to control PRU you might need to be in privileged mode to enable PRU and others... Last but most official method is use of device tree and reboot. If your kernel is 3.8.16, you can use device tree overlay. I hope this can help you. On Wed, Nov 5, 2014 at 1:46 AM, Nic Cyn wrote: > I have attempted to adjust the pinmux settings for a gpio programatically > using mmap() and a write out to the appropriate register. This does not > throw exception or any other error however no changes are made. Reading the > mmap()'ed location returns pretty reasonable and believable results so I > know I am hitting the right location. > > For example, on my BBB GPIOs 50 and 51 are currently in mux mode 6 > (ehrpwm1A_mux1 and ehrpwm1B_mux1) and the pinmux control registers for > these are at offsets 0x848 and 0x84c from the 0x44e1000 control register. I > can read the memory at these positions just fine and the return values are > 0x06 (mux mode 6). Attempting to write a 0x07 to either of these locations > to enable mux mode 7 does not error but the value at that memory location > remains 0x06. > > Is there any reason why this should not work? After all the capemanager > and cape universal drivers seem to be able to change these settings at > runtime. > > I would very much appreciate any advice and insights anybody has into this > issue. > > Oh yeah, before anybody goes to the trouble of beating me up about it, I > am aware that the Device Tree is the recommended way of changing this sort > of pinmuxing and for my project I could, and probably will, do it that way. > Nevertheless, is there a reason the ocp muxing cannot be adjusted at > runtime (as root) by writing to the appropriate GPIO control register > location? > > > -- > 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.
[beagleboard] How can I enable SPI in 3.17?
After upgrading kernel to 3.17, my working program and test program does not work. And I think that this is related to SPI device. How can I properly enable SPI0 in 3.17? -- 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: RFC: Add mode setting to bone-pinmux-helper
Thank you. I've just changed state of hdmi in /boot/dtbs/am335x-boneblack.dtb as disabled, however, which might not be a correct way of disabling HDMI, so I asked. On Wed, Sep 17, 2014 at 7:57 AM, Charles Steinkuehler < char...@steinkuehler.net> wrote: > On 9/16/2014 5:43 PM, Sungjin Chun wrote: > > Maybe somewhat off topic, however I cannot help but to ask this; > > > > "How can we disable HDMI in kernel version >= 3.14?" where we do not > > have capemgr? > > Load a different device tree. There's probably an easier way (there are > several available device trees already installed), but I would: > > cd /opt/source/dtb-3.14-ti > vi src/arm/am335x-boneblack.dts > > > > make > sudo make install > sudo reboot > > -- > Charles Steinkuehler > char...@steinkuehler.net > > -- > 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] Re: RFC: Add mode setting to bone-pinmux-helper
Maybe somewhat off topic, however I cannot help but to ask this; "How can we disable HDMI in kernel version >= 3.14?" where we do not have capemgr? On Wed, Sep 17, 2014 at 7:37 AM, Jason Kridner wrote: > On Tue, Sep 16, 2014 at 6:06 PM, Charles Steinkuehler > wrote: > > On 9/16/2014 4:55 PM, Joshua Datko wrote: > >> > >> I've been trying to follow along with these changes and I admit, I > >> haven't been able to keep up. > >> > >> Some questions: > >> > >> 1. My Cape DTS does not explicitly call out for i2c2 [1], with this > >> change does that, and all capes using i2c2, need to be fixed? > > > > The i2c2 is typically defined by the base BeagleBone device tree (or > > more specifically, am335x-bone-common-pinmux.dtsi in Robert's latest > > device trees for 3.14). The cape dtsi files (or overly files for 3.8) > > generally only include things that need to be changed to support the > > cape, so unless you were intentionally trying to modify the i2c2 > > hardware, you wouldn't reference it in you cape file. > > > > Your cape file simply adds some target entries for the i2c2 bus, which > > would work as expected and need no changes regardless of whether the > > i2c2 pinmux is handled directly or by using the bone-pinmux-helper (the > > device tree compiler will merge the main i2c2 definitions with your > > additions). By way of similar example, you're also not specifying the > > base address of the i2c2 hardware, the interrupt(s) it uses, etc, but > > that all works since it's pulled in from common dts files before your > > cape file is included. > > > >> 2. Is the default mode of pins P_19/20, once user space is reached, GPIO > >> or i2c2? > > > > The purpose of this change is to allow the pinmux-helper to be in > > control of the pin, but have it come up in the desired mode (i2c in this > > case) instead of the default gpio mode, which is what would have > > happened previously. > > Just going along to state the obvious... > > eMMC and HDMI will be equally interesting tests and more practically > useful for more capes. > > It will only be a matter of time before someone damages a board by: > A) setting an HDMI pin to a output without disabling the HDMI > B) driving an eMMC pin into conflict without putting the eMMC in reset > > I don't think there is a simple way for the current pinmux helper to > check for these conditions, but it wouldn't hurt if any config-pin > sort of utility would check the state of those hardware control bits > before helping someone screw things up. :-) > > Any way you can imagine a way to keep the current uEnv.txt lines to > disable both of those working without breaking compatibility? > > > > > -- > > Charles Steinkuehler > > char...@steinkuehler.net > > > > -- > > For more options, visit http://beagleboard.org/discuss > > --- > > You received this message because you are subscribed to the Google > Groups "BeagleBoard" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to beagleboard+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Sensor Driver Pin Muxing
If the only thing you want is using SPI in usermode, then just use Linux SPI driver with proper device tree setting; google enable Beaglebone Black SPI. But what you want is proper pinmuxing - not limited to SPI device - during runtime, then you have to write some kernel module so that it can write control register in privileged mode; to write on control register for pinmuxing, you have to be in privileged mode, refer technical reference manual or TRM on this. Reading your message agin, It seems that you already have linux driver code then you don't have to mind privileged mode thing for you already in it. I'm afraid that I can provide any meaningful help on your driver code, however. Sent from my iPad > On Sep 1, 2014, at 6:22 AM, Cristian Mitu wrote: > > Could you elaborate on the being privileged part i am new to this and don't > know a lot. As i know the old drivers have been made for the 3.3 kernel and > didn't use device tree overlays. I was thinking that since the function calls > are reallly standard (iowirte16 and ioremap etc) that the only changes would > be done to the values of pinmuxing themselves. I would just like to know what > exactly i would have to change. If you want i can send you the hole code > pertaining to the sensors. As far as i can see this SPI driver they made is > actually handling the adding of multiple spi devices and writing and reading > to them but somewhere they also use a header file from > which makes me think that there is another driver that handles the > communication itself (timing, sending receiving data etc). Am i wrong in > thinking this? Please tell if it is not too much trouble and sorry if this is > too nooby :-) > . > > > 2014-08-27 1:45 GMT+02:00 Sungjin Chun : >> As far as I know you have to be in the priviledged mode to change mux value >> of pins (or you can use PRU to do this) which means >> you have to write kernel module like this >> (https://github.com/chunsj/nxctrl/blob/master/nxpmx/nxpmx.c). >> >> >>> On Wed, Aug 27, 2014 at 12:40 AM, Cristian Mitu >>> wrote: >>> Hello guys, >>> >>> >>> I have a pig problem concerning a driver used for communicating with some >>> MEMS components via SPI. The driver was developed for a Gumstix platform >>> with OMAP34... processor running a 3.3 kernel. The driver muxes the pins >>> using "iowrite16" functions. Some sample code can be seen below: >>> >>> ###Mux values sample : >>> #define SPI_OE_MUX_OFFSET(0x48002A1A - OMAP34XX_PADCONF_START) >>> #define SPI_CLK_MUX_OFFSET(0x480021C8 - OMAP34XX_PADCONF_START) >>> . >>> ## >>> >>> ### Pin mode sample: >>> #define OE_ENABLE_MUX0x010C/* IEN | PTD | EN | M4 */ >>> #define SPI_ENABLE_MUX0x0100/* IEN | PTD | DIS | M0 */ >>> ## >>> >>> >>> // Multiplexing the pins code sample: >>> base = ioremap(OMAP34XX_PADCONF_START, OMAP34XX_PADCONF_SIZE); >>> >>> if (!base) >>> return -ENOMEM; >>> >>> old_spi_mux.oe_offset = ioread16(base + SPI_OE_MUX_OFFSET); >>> iowrite16(OE_ENABLE_MUX, base + SPI_OE_MUX_OFFSET); >>> ## >>> >>> Now i understand how the offsets are calculated and how the I/O memory is >>> beeing used. What i want to know is if i can reuse this code for the >>> BeagleBone Black ( of course i know that i have to modify the mux values >>> and pin modes to match to the BBB). My BBB is running a 3.8 kernel and as i >>> know there is the major change with switching to the Device Tree system. >>> >>> Also if i use this method will i still need to write a device tree overlay >>> setting the pins up there or is this done directly by using this code ( i >>> feel this is a stupid question seeing as the DT is used specifically for >>> setting up the pins so this code should do that instead but asking just so >>> i know for sure). I thank you in advance for the response. >>> -- >>> 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
Re: [beagleboard] Sensor Driver Pin Muxing
As far as I know you have to be in the priviledged mode to change mux value of pins (or you can use PRU to do this) which means you have to write kernel module like this ( https://github.com/chunsj/nxctrl/blob/master/nxpmx/nxpmx.c). On Wed, Aug 27, 2014 at 12:40 AM, Cristian Mitu wrote: > Hello guys, > > > I have a pig problem concerning a driver used for communicating with some > MEMS components via SPI. The driver was developed for a Gumstix platform > with OMAP34... processor running a 3.3 kernel. The driver muxes the pins > using "iowrite16" functions. Some sample code can be seen below: > > ###Mux values sample : > #define SPI_OE_MUX_OFFSET(0x48002A1A - OMAP34XX_PADCONF_START) > #define SPI_CLK_MUX_OFFSET(0x480021C8 - OMAP34XX_PADCONF_START) > . > ## > > ### Pin mode sample: > #define OE_ENABLE_MUX0x010C/* IEN | PTD | EN | M4 */ > #define SPI_ENABLE_MUX0x0100/* IEN | PTD | DIS | M0 */ > ## > > > // Multiplexing the pins code sample: > base = ioremap(OMAP34XX_PADCONF_START, OMAP34XX_PADCONF_SIZE); > > if (!base) > return -ENOMEM; > > old_spi_mux.oe_offset = ioread16(base + SPI_OE_MUX_OFFSET); > iowrite16(OE_ENABLE_MUX, base + SPI_OE_MUX_OFFSET); > ## > > Now i understand how the offsets are calculated and how the I/O memory is > beeing used. What i want to know is if i can reuse this code for the > BeagleBone Black ( of course i know that i have to modify the mux values > and pin modes to match to the BBB). My BBB is running a 3.8 kernel and as i > know there is the major change with switching to the Device Tree system. > > Also if i use this method will i still need to write a device tree overlay > setting the pins up there or is this done directly by using this code ( i > feel this is a stupid question seeing as the DT is used specifically for > setting up the pins so this code should do that instead but asking just so > i know for sure). I thank you in advance for the response. > > -- > 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] Why use C/C++ file I/O to access GPIO pins?
Or you can always access them with /dev/mem mmap without dumping Linux. Sent from my iPhone > On Aug 19, 2014, at 9:32 PM, karlkarpfe...@gmail.com wrote: > > Am Dienstag, 19. August 2014 04:40:43 UTC+2 schrieb john3909: >> >> Well, that is because you are trying to access the GPIO from user space. If >> you wanted to access the GPIO from kernel space, you would use a similar >> approach to what you did on your smaller processors. The only difference >> would be that each pin supports several functions which are defined by Mode >> 0 through 7. To use a pin for GPIO, you would use Mode 7. Also, the >> processor has a set register and a clear register so that you don't have to >> disable interrupts during a real/modify/write. One other approach is to use >> mmap so that you can access the processor registers in user space for GPIO >> operations or as others have proposed, use the PRU to control GPIO. > An other approach would be to drop Linux OS completely and to have your own > (StarterWare-based) firmware running on the board. With it's standard timers > you can have a output frequency of up to 2 MHz (when doing it out of an ISR > with some bit-banging code) or up to 100 MHz (when bit-banging using > PRU-code). > > -- > 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] [Q] Any project like PiFM, GPIO only FM transmission on BeagleBone Black?
In fact, what I am interested is not tramsmission of audio, instead, other signals like morse code. If this could be done using PRU then I would try to find how could I make "PRU cleverness" :-) On Fri, Aug 1, 2014 at 10:56 PM, Przemek Klosowski < przemek.klosow...@gmail.com> wrote: > > 2014-08-01 6:34 GMT+08:00 Sungjin Chun : > I'd like to create similar thing like PiFM in BeagleBone Black. Can anyone > provide me reference on this? > > On Thu, Jul 31, 2014 at 9:21 PM, liyaoshi wrote: > >> Its impossible . >> bcm2835 have flex pwm and dma transfer for fm turning . >> while am335x pwm is only for fixed clock div . >> >> > Well, technically, you could probably do this with some PRU cleverness, > running a tight loop multivibrator and dithering its output from a slow > loop in the other PRU or the CPU. > > -- > 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] [Q] Any project like PiFM, GPIO only FM transmission on BeagleBone Black?
Oh, sad.. thank you for kind and detailed explanation :-) On Fri, Aug 1, 2014 at 10:21 AM, liyaoshi wrote: > Its impossible . > bcm2835 have flex pwm and dma transfer for fm turning . > while am335x pwm is only for fixed clock div . > > > 2014-08-01 6:34 GMT+08:00 Sungjin Chun : > >> I'd like to create similar thing like PiFM in BeagleBone Black. Can >> anyone provide me reference on this? >> >> Thanks in advance. >> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to beagleboard+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] [Q] Any project like PiFM, GPIO only FM transmission on BeagleBone Black?
I'd like to create similar thing like PiFM in BeagleBone Black. Can anyone provide me reference on this? Thanks in advance. -- 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] PRUSS uart to read from ADAFRUIT Ultimate GPS
Though I have not yet tested your code, thank you for your great example. :-) -Original Message- From: "jstam...@gmail.com" Sent: 7/15/2014 4:52 PM To: "beagleboard@googlegroups.com" Subject: [beagleboard] PRUSS uart to read from ADAFRUIT Ultimate GPS Example of reading data with PRUSS Uart. Full code at: https://github.com/jstampfl/Pruuart / pu.p V1 // Use PRUSS uart to read data from ADAFRUIT Ultimate GPS // reads data to nl, put in buffer and signal linux side. .setcallreg r2.w0 // Going to use r31 for interrupt .origin 0 .entrypoint TB TB: ldi r20,0 ldi r21,0 ldi r22,0 mov r0,0 sbbo r0,r20,r21,4 zero &r0,64 //zero 16 registers TB05: sbbo r0,r20,r21,64 //zero some of pru0 local memory add r21,r21,64 // for linux string functions add r22,r22,1 qbgt TB05,r22,20 TB1: ldi r3,4 //Uart divisor =1250 = 0x04E2 sbco r3,c7,0x24,4 // 9600 at 16x ldi r3,0xE2 //in DLL & DLH sbco r3,c7,0x20,4 ldi r3,0x3 //LCR = 3, 8 none & 1 sbco r3,c7,0x0C,4 // mov r3,0x6001 //Power & sbco r3,c7,0x30,4 // = tx on, rx on & Free ot enable ldi r4,0 ldi r5,0 ldi r3,0 ldi r20,0 ldi r21,0 TB2: // r5 points to start of buffer // r4 is offset into buffer lbco r3,c7,0x14,4 //check LSR for date ready qbbc TB2,r3.t0 lbco r3,c7,0,4 //data is ready, get from RBR sbbo r3,r5,r4,1 // and put in buffer add r4,r4,1 qbne TB2,r3,0xA // do until nl received sbbo r20,r5,r4,1 // put null to terminate ldi r4,0 // zero buffer pointer mov r31.b0,35 // signal linux jmp TB2 TB9: mov r31.b0,35 ldi r4,0x ldi r5,0 TB10: add r5,r5,1 qbgt TB10,r5,r4 HALT -- 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.
[beagleboard] [Q] Best Bluetooth USB Dongle/Breakout for communication with Bluetooth LE device?
Hi, I'd like to connect to my TI SensorTag which uses Bluetooth LE. BBB has just one USB port so I'd like to use Bluetooth Breakout board or something which uses GPIO port other than USB, however if there's no solution then recommend me Good USB dongle for Bluetooth. Thanks in advance. -- 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: set up PADCONF for am33xx from userspace
They can be written only in privileged mode; if you're using Linux, this means that you have to be in kernel space to write. Refer https://github.com/chunsj/nxctrl/blob/master/nxpmx/nxpmx.c which my approach or you can use PRU code. -Original Message- From: "serge.ns...@gmail.com" Sent: 7/4/2014 12:35 PM To: "beagleboard@googlegroups.com" Subject: [beagleboard] Re: set up PADCONF for am33xx from userspace Control module registers are write protected. -- 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] Re: PRU GPIO and voltage levels
Thank you for your answer; I've used my own kernel module for pinmuxing, now, instead, I have another option for this task. On Wed, Jul 2, 2014 at 2:47 PM, TJF wrote: > > > Am Mittwoch, 2. Juli 2014 00:34:11 UTC+2 schrieb Sungjin Chun: > >> "Can I pinmux in PRU?" The TRM says I have to be in privileged mode to >> write pinmux register. >> > > You need to be in priviged mode to switch on the PRUSS (ie echo PRUSSDRV > > /sys/devices/bone_capemgr.9/slots). > > Once the PRUSS is running, there's no kernel software between the PRU and > the pinmux registers. So the answer is yes, the PRU can do pinmuxing in > privileged or unprivileged user mode. > > Test the examples in libpruio to see this happen on your system > >- *button* configures an GPIO input pin with high resistor >- *stepper* configures four output pins >- *sos* unlocks the user LED3 to control this GPIO pin > > -- > 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] Re: PRU GPIO and voltage levels
Slightly off topic from original question, however I cannot help but asking
this question;
"Can I pinmux in PRU?" The TRM says I have to be in privileged mode to write
pinmux register.
Sent from my iPad
> On Jul 2, 2014, at 1:33 AM, TJF wrote:
>
> Hi cowboy!
>
> I confirm, GPIO high is 3.3V. Unconnected pins (input pins without resistor)
> have about 0.8V.
>
> Why don't you use the PWM devices for that task?
>
> Anyway, P8_11 isn't connected to the PRUSS. This pin only works in GPIO mode
> (mode 7) and I'm not sure if you can reach 50MHz that way.
>
> The faster way is to use a PRU register pin and for that you have to choose
> another pin (ie. P8_15 = GPIO-1/15 = PRU-0:r30.t15).
>
> And why are you doing the pinmuxing by the device tree overlay? Instead do it
> from your PRUSS code! Compile a minimal device tree overlay like
>
> /*
> * pru dts file BB-BONE-PRU-00A0.dts
> */
>
> /dts-v1/;
> /plugin/;
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black";
>
> /* identification */
> part-number = "BB-BONE-PRU";
> version = "00A0";
> exclusive-use =
> "P8.15";
>
> fragment@0{
> target = <&pruss>;
> __overlay__ {
> status = "okay";
> };
> };
> };
>
>
>
> Then add to your PRUSS code (OCP master port must be enabled)
>
> MOV r1, 0x44E10800 // CM pinmux address
> LDI r2, 0b1110 // mode 6, no resistor
> SBBO r2, r1, 0x3C, 1 // set pinmuxing @ball 15 (= GPIO-1/15)
>
> That's all. You'll have all your code in single source and you're much faster
> in doing any testing.
>
> Good luck!
> --
> 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] How to install a custom PRU
Ah, and here is my code you can refer ;-) https://github.com/chunsj/nxctrl/blob/master/pru-test.c https://github.com/chunsj/nxctrl/blob/master/pru-test.p C code is for loading pru program. Sent from my iPad > On Jun 3, 2014, at 4:49 PM, bo.ham...@gmail.com wrote: > > I have been researching on how to load a custom pru on a beagle bone black. > Is there somewhere for some guidance or a site that may have a tutorial or > even a book on this topic. > > Thanks > Bo > -- > 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] How to install a custom PRU
If you mean loading custom firmware/program by "custom pru", just search prussdrv in google and you can find many docs. Sent from my iPad > On Jun 3, 2014, at 4:49 PM, bo.ham...@gmail.com wrote: > > I have been researching on how to load a custom pru on a beagle bone black. > Is there somewhere for some guidance or a site that may have a tutorial or > even a book on this topic. > > Thanks > Bo > -- > 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] Some GPIOs don't work ?
Not every pin is muxed as GPIO/Mode 7. You have to pinmux them if you want to use it as GPIO pin. And even some pins cannot be pin muxed as GPIO; they are GND, 5V, 3V3, and analog input pins. Sent from my iPad > On Jun 3, 2014, at 4:25 AM, papin.timot...@gmail.com wrote: > > Hello guys, > I'm working on BBB for a school project. I need to control 6 motors with my > BBB. > But it seems that some gpios don't work. When I test them with an > oscilloscope as output they aren't all detected and some of them don't change > from 0V to 3.3V when I change value from 0 to 1. > Could it be the pin mode who affects it ? > I'm completly lost, could you help me ? > Thank you in advance. > -- > 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] PRU prussdrv_open gives Bus error, Custom PREEMPT_RT Linux kernel 3.14
In my case, I solved similar problem with enabling clock and power domain
configuration, refer
https://github.com/chunsj/nxctrl/blob/master/NXCTRL.c#L223
Sent from my iPad
> On May 15, 2014, at 5:36 AM, henrikff...@gmail.com wrote:
>
>
> Hi,
> I'm currently running a 3.14 PREEMPT_RT build based of Robert C Nelsons
> repository. I've got GPIO and uart up and running. And now my attention has
> turned to the PRU. The 3.14 build does not have a capemanager so i setup my
> device trees at build.
> I based my PRU work of the old PRU patch:
> https://github.com/beagleboard/kernel/blob/3.12/patches/pru/0001-These-are-the-patches-necessary-for-enabling-the-PRU.patchh
> Now, booting gives me no error messages from uio_pruss. And uio0-7 appears in
> /dev/. However, when running a test project (which ran perfectly fine under
> non-modified 3.8 kernel) prussdrv_open() failes: Bus error
>
> This happens every time prussdrv_open tries to read from its memory mapped
> areas like:
> if (pruss_io[(AM18XX_INTC_PHYS_BASE - AM18XX_DATARAM0_PHYS_BASE) >> 2]
> == AM18XX_PRUSS_INTC_REV)
>
>
> Now the pruss is defined in am33xx.dtsi:
>
> pruss: pruss@4a30 {
> compatible = "ti,pruss-v2";
> ti,hwmods = "pruss";
> ti,deassert-hard-reset = "pruss", "pruss";
> reg = <0x4a30 0x08>;
> ti,pintc-offset = <0x2>;
> interrupt-parent = <&intc>;
> status = "okay";
> interrupts = <20 21 22 23 24 25 26 27>;
> };
>
> And one of my dtsi include files to the am335x-boneblack.dts enables it:
>
>&pruss{
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <&pru_gpio_pins>;
>};
>
> I then modprobe uio_pruss before running the test application.
>
> I have little clue how to fix this, so any pointers or help would be much
> appreciated:)
>
> --
> 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.
[beagleboard] Re: PWM period
If you are using device tree based approach, then refer this link https://groups.google.com/forum/#!topic/beagleboard/4R91_v9WBEY I hope this can help you. On Tuesday, April 22, 2014 9:02:11 AM UTC+9, Dorian Levy wrote: > > I want to use two servos with pins 8_13 and 8_19. How can I change the > period? I tried editing the dts file and compiling with > dtc -O dtb -o bone_pwm_P8_13-00A0.dtbo -b 0 -@ bone_pwm_P8_13-00A0.dts, but > the period remains the same. Is there something else that need to be done? > I not sure it actually compiles, because the command line returns instantly. > -- 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] [Q] No More Default uio_pruss in 3.14.X kernel?
Up to 3.13.X kernel package, there is uio_pruss module in kernel package, both in debian and arch linux. However in arch linux it is not, and it seems that RobertCNelson's kernel package in http://rcn-ee.net/deb/sid-armhf/v3.14.1-bone2/ does not have uio_pruss. Does this module, uio_pruss, is removed because it does not work (even if it be compiled) on 3.14.X or because default kernel config is changed so that it does not have uio_pruss? Thank you in advance. -- 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: ArchLinux SD card boot
Did you tried the method described here?
http://archlinuxarm.org/platforms/armv7/ti/beaglebone-black
I copy the part here.
Installing to eMMC
1. After booting into Arch Linux ARM, ensure you have wget and
dosfstools installed:
pacman -Syu wget dosfstools
2. Follow the above steps 4 through 7 using the device
/dev/mmcblk1p[1|2]. Repartitioning is not required since the eMMC is
already partitioned correctly.
3. Power down the system, waiting until all the LEDs go out:poweroff
4. Remove power, remove the micro SD card, then reapply power. The
system will boot into eMMC. If an SD card created with the above steps is
still in the system when it boots, it will boot to the SD card instead of
eMMC.
5. To use the micro SD slot for general storage, simply partition and
format the device as a normal drive. Also note that the card must be
inserted at boot for it to be recognized.
On Sat, Apr 19, 2014 at 10:41 AM, Doug wrote:
> Well the option I took was to nuke mmcblk1 which worked. I have no reason
> to have anything there anyhow. I am running a headless system in ArchLinux.
> I don't have time to fool around with why it isn't working when I am not
> going to use it. None of the options suggested worked other than dd'ing the
> eMMC.
>
> On Friday, April 18, 2014 10:47:57 AM UTC-4, Doug wrote:
>>
>> I have ArchLinux installed and it reboots fine - shutdown -r now - but if
>> I power down and restart it goes to four LED's and stops. If I hold down
>> the boot button and power it will then boot.
>>
>> How do I get it to boot at power up always from the SD card? My boot
>> partition has the following files -
>>
>> 102 -rwxr-xr-x 1 root root 104212 Aug 10 2013 MLO
>> 354 -rwxr-xr-x 1 root root 361488 Aug 10 2013 u-boot.img
>> 2 -rwxr-xr-x 1 root root603 Oct 18 2013 uEnv.txt
>>
>> and uEnv.txt has -
>>
>> [root@BBBdoug mnt]# cat uEnv.txt
>> uenvcmd=run findmmc1; run findmmc0; if run loaduimage; then run loadfdt;
>> run mmcboot; fi;
>> findmmc1=if test $board_name = A335BNLT; then setenv mmc1 1; else setenv
>> mmc1 0; fi
>> findmmc0=setenv mmcdev 0; mmc dev ${mmcdev}; if mmc rescan; then setenv
>> mmc0 1; else setenv mmc0 0; fi
>> mmcroot=/dev/mmcblk0p2 rw
>> loadfdt=ext4load mmc ${mmcdev}:2 ${fdtaddr} /boot/dtbs/${fdtfile}
>> loaduimage=if ext4load mmc 0:2 ${loadaddr} /boot/zImage; then setenv
>> mmcdev 0; else setenv mmcdev 1; if test $mmc0 = 1; then setenv mmcroot
>> /dev/mmcblk1p2 rw; fi; ext4load mmc 1:2 ${loadaddr} /boot/zImage; fi
>> optargs=coherent_pool=1M
>>
>> As far as I can tell this is the latest code.
>>
>> What do I need to do to get it to always boot without intervention from
>> the micoSD card?
>>
>> --
> 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] Re: PWM in the 3.13 Kernel
If properly enabled in dtb file during booting, you can always use any peripherals in AM335X SoC. Refer https://github.com/chunsj/nxctrl/blob/master/pwm-test.c, which uses /dev/mem for control pwm. Of course this code does not provide sysfs interface. Sent from my iPad > On Apr 18, 2014, at 9:12 PM, halhe...@gmail.com wrote: > > I retried accessing PWM in the latest 3.13 kernel.with no luck. Is PWM > still not supported in 3.13 (under /sys/devices/ocp.#/pwm_test_P9_14.#/) or > is there simply a new way to access PWM that I'm not aware of ? > > Hussam > >> On Tuesday, March 25, 2014 5:29:03 PM UTC-4, halh...@gmail.com wrote: >> I'm having problems with PWM under the latest 3.13 kernel (built as per the >> instructions provided @ >> http://www.eewiki.net/display/linuxonarm/BeagleBone+Black) with a Debian >> root filesystem.The Device tree seems to support 3 PWM channels on P9_14, >> P9_16 (ehprwm1a&b) & P9_42 (ecap0). But when i take a peek at the contents >> of the "/sys/devices/ocp.#/pwm_test_P9_14.#/" directory I do not see the >> 'period', 'duty', 'run' or 'polarity' files needed to control the PWM >> channels. >> >> Is PWM supported in the 3.13 Kernel yet? >> >> Thanks! >> Hussam > > -- > 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] ome problem when I get update
Did you generate locale data? For example, in arch linux (which I'm using),
after configuration of /etc/locale.conf I should execute
locale-gen
so that configured locale data be generated.
On Thu, Apr 17, 2014 at 12:57 PM, Yanlong Mu wrote:
> Hi Everybody
>
> I just get the new image boot on the BBB 12.04.2 LTS
>
> When I put the sudo apt-get update and upgrade, it showed some warning as
> below
>
> locale: Cannot set LC_CTYPE to default locale: No such file or directory
> locale: Cannot set LC_MESSAGES to default locale: No such file or directory
> locale: Cannot set LC_ALL to default locale: No such file or directory
>
>
> And When I was going to install a desktops (xface)
>
> it showed
>
> perl: warning: Falling back to the standard locale ("C").
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
> LANGUAGE = (unset),
> LC_ALL = (unset),
> LC_TIME = "en_GB.UTF-8",
> LC_MONETARY = "en_GB.UTF-8",
> LC_ADDRESS = "en_GB.UTF-8",
> LC_TELEPHONE = "en_GB.UTF-8",
> LC_NAME = "en_GB.UTF-8",
> LC_MEASUREMENT = "en_GB.UTF-8",
> LC_IDENTIFICATION = "en_GB.UTF-8",
> LC_NUMERIC = "en_GB.UTF-8",
> LC_PAPER = "en_GB.UTF-8",
> LANG = "en_GB.UTF-8"
> perl: warning: Falling back to the standard locale ("C").
>
> Anyone can help me to solve that problem?
>
> Kind Regards
>
> Ian
>
> --
> 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] Re: beaglebone, PREEMPT-RT and low latency ADC/DAC
>From http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver%27s_Guide , ADC in AM335x can sample in 200KSPS(Kilo Samples Per Second) so 44K could be possible. However I think you have to do this with faster interface which means you cannot use sysfs; instead you have to use /dev/mem or PRU. I have very simple example of using ADC in these manner. 1. Using /dev/mem https://github.com/chunsj/nxctrl/blob/master/adc-test.c 2. Using PRU https://github.com/chunsj/nxctrl/blob/master/adcpru-test.p Though I'm not sure on your exact needs, I hope this can help you. On Wed, Apr 16, 2014 at 10:52 PM, wrote: > Hi all people here. > > I must to say im newbie in BB and RT data. > > So, im going to ask simple: > I need to acquire in ADC of the BB in RT over 44khz, only read, i dont > need to process it in RT > is it possible to use the ADC of the BB to do it and DMA..? > > If it possible, can you show me some sample code to start with, or where > to look at? (some link).. > > Really thanks > > El lunes, 10 de septiembre de 2012 07:29:55 UTC-4:30, Evan Thomas escribió: >> >> >> Hello, >> >> embedded/real time/hardware newbie here. I have an requirement to read an >> ADC, perform some simple FP calculations and write to DAC. It needs to be >> at least 20KHz but importantly the latency on the DAC/ADC needs to less >> than 10us. Low jitter is also important. Is the beaglebone up to it? I see >> this asked many times but not answered so I am not really expecting an >> answer now :) >> >> I have two specific questions >> >> 1) This might be naive but I thought I would try the PREEMPT_RT patch. In >> particular, I wanted to combine it with Robert Nelson's patches and build >> process. After many hours of random git commands, patch and modifying >> scripts I came to the conclusion that the current PREEMPT_RT patch is for >> 3.4 whereas Robert's patches are for 3.6. Firstly, does it even make sense >> to try PREEMPT_RT on BB? If so, what is the best way to proceed? Use 3.4 >> versions of Robert's patches and risk bugs and missing features? Wait >> for PREEMPT_RT patch against 3.6? >> >> 2) What is the best way to do low latency (<10us) 14bit ADC and DAC on >> the BB? I assume it would have to be over the SPI bus, but beyond that I'm >> clueless. If someone can point me in the right direction I would really >> appreciate it. >> >> Thanks, >> Evan. >> > -- > 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] High(er) level language for PRU programming available.
I also am interested in C compiler for PRU. Can you let me know how to contact Jason Kridner? Sent from my iPhone > On Apr 15, 2014, at 5:39 AM, Charles Steinkuehler > wrote: > >> On 4/14/2014 3:34 PM, John Silvia wrote: >> >> I've implemented a forth language for the PRU to facilitate one of my own >> projects. It is available for others to use on github in hopes that >> someone may find it useful. >> >> https://github.com/biocode3D/prufh > > You are my hero! I love Forth and figured the PRU would be perfect for > a small Forth environment! :) > >> Yes, of course, a C compiler would be useful to more people; but I'm not >> capable of writing a C compiler in ~500 lines of perl ;-) > > ...and there's already a C compiler available. You just have to e-mail > Jason Kridner and ask to get the "beta" copy since it hasn't been > officially released for some reason. > > -- > Charles Steinkuehler > char...@steinkuehler.net > > -- > 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] Kernel 3.14, I cannot find uio_pruss module.
No, I have used binary package which seems to be built with config file at here https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-am33x/config I've managed to compile uio_pruss as module separately however, even if I load this module uio_pruss.ko, I cannot get /dev/uioX or /sys/class/uio/*. I also changed my dtb in boot/dtbs directory (which arch linux uses) like this https://github.com/chunsj/nxctrl/blob/master/am335x-boneblack-3.14-mine.dts where I added pruss section and changed status from disabled to okay. On Thu, Apr 10, 2014 at 10:53 AM, Robert Nelson wrote: > On Wed, Apr 9, 2014 at 7:36 PM, Sungjin Chun wrote: > > After upgrade to Kernel 3.14 (Arch Linux ARM) which uses > > http://rcn-ee.net/deb/sid-armhf/v3.14.0-bone0/ > > I cannot find uio_pruss kernel driver. > > > > How can I fix this? > > Did you enable it in the config? > > > -- > Robert Nelson > http://www.rcn-ee.com/ > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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] Kernel 3.14, I cannot find uio_pruss module.
After upgrade to Kernel 3.14 (Arch Linux ARM) which uses http://rcn-ee.net/deb/sid-armhf/v3.14.0-bone0/ I cannot find uio_pruss kernel driver. How can I fix this? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Engine RPM Sensor
Programmable Realtime Unit. http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_Subsystem You can use this processors for realtime tasks. On Mon, Apr 7, 2014 at 10:14 AM, Stacy Cottles wrote: > Eric, I apologize for my ignorance but what is the pru? > > On Sunday, April 6, 2014 6:18:27 PM UTC-5, Eric wrote: >> >> I might be inclined to use the pru for this and just setup the pru as >> escentially a hardware counter. There are likely ways to do so with timers >> and interrupts and such but being more of a hardware guy than software I'm >> inclined to use a more hardware approach and use the pru as a counter that >> gets read every so often. the software for that then is escentially a >> driver that creates /dev/rpm. >> >> Eric >> >> >> On Sun, Apr 6, 2014 at 3:43 PM, Stacy Cottles wrote: >> >>> Thanks Eric for the suggestion. I'll have to figure out the inductive >>> circuit to use. Do I have to use interrupts or is there something better >>> for capturing the signal from the pickup? >>> >>> >>> On Sunday, April 6, 2014 1:51:07 PM UTC-5, Eric wrote: >>> an inductive pickup around the sparkplug wire should get you a nice pulse each time the spark plug fires but remember the phases of a 4 stroke engine (intake - piston down intake valve open, compression - piston up valves closed, power - piston down valves closed, exhaust - piston up exhaust valve open). The spark plug only fires every other revolution. Once you have the pulse from the inductive pickup it should be buffered to provide a nice square wave pulse of uniform voltage such that it's easy for the processor to use and not a potential hazard to the processor due to spurious high voltages (cooking the buffer circuit while in development, sorta ok cooking the processor, well not so much!) . from there it's just software and the incrementing of a counter with each pulse. On Sun, Apr 6, 2014 at 6:33 AM, Stacy Cottles wrote: > I am building a web-controlled lawn-mower. I would like to be able to > read the RPM off the gas-engine. I would prefer to piggy-back off of the > spark-plug if possible since it fires faster as the engine spins faster. > Just started on this but would love suggestions. I have a Beaglebone Black > running Angstrom and I am using NodeJS to control GPIOs. > > -- > 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. > -- 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] Where did /sys/bus/iio/devices/iio\:device0/in_voltage[0-3]_raw go in saucy 3.13.X kernels?
As far as I know, the default am33x-boneblack.dtb which is read from kernel during boot does have only 3 pin addresses for analog inputs, you can modify this by referring TRM or other dts files. I do not have my file now sorry, I cannot post here. Sent from my iPad > On Apr 5, 2014, at 12:36 AM, John Amidon wrote: > > Starting with a brand-new, out of the box BBB, I flashed it with > https://rcn-ee.net/deb/flasher/saucy/BBB-eMMC-flasher-ubuntu-13.10-2014-03-27-2gb.img.xz > which is of course the 3.8.13-bone40 kernel. The analog inputs were enabled > once the > > # echo cape-bone-iio > /sys/devices/bone_capemgr.*/slots > > command was given. The raw analog inputs were then readable at > /sys/bus/iio/devices/iio\:device0/in_voltage[0-7]_raw. However, after > reading the inputs over a period of time, I started seeing errors reading the > inputs, the "Resource temporarily unavailable" others have reported. Know > the support for iio was updated in later kernels. I decided to update the > kernel to see if that made a difference. > > Using the update script at > https://rcn-ee.net/deb/saucy-armhf/v3.13.8-bone8/install-me.sh, I updated to > the latest pre-built kernel. Now, I see analog inputs with no additional > prodding required (perhaps the magic is now buried in the boot sequence?), > but I don't see all the inputs, just 3: > /sys/bus/iio/devices/iio\:device0/in_voltage[4-6]_raw. > > What am I missing? Is there something I need to enable/disable in the > /boot/uboot/uEnv.txt? > > Thanks. > > -- jda > -- > 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.
[beagleboard] Re: [Q] Why I cannot mmap this region in 3.13 kernel?
I found solution. I have to use interface function provided by pruss (which I had not known). prussdrv_map_extmem This function solves my problem. On Friday, April 4, 2014 4:23:39 PM UTC+9, Sungjin Chun wrote: > > I'm using BeagleBone Black. > > PRU example code PRU_memAccess_DDR_PRUsharedRAM in PRU sw package > does not run on 3.13.6 kernel. And I found where it does stop working; > > mmap(0, 0x0FFF, PROT_WRITE | PROT_READ, MAP_SHARED, nFDMem, > DDR_BASEADDR); > > where DDR_BASEADDR is 0x8000. > > This code works in old, 3.8.13 kernel. Do anyone let me know why I cannot > mmap this area > in new Kernel 3.13 > -- 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] [Q] Why I cannot mmap this region in 3.13 kernel?
I'm using BeagleBone Black. PRU example code PRU_memAccess_DDR_PRUsharedRAM in PRU sw package does not run on 3.13.6 kernel. And I found where it does stop working; mmap(0, 0x0FFF, PROT_WRITE | PROT_READ, MAP_SHARED, nFDMem, DDR_BASEADDR); where DDR_BASEADDR is 0x8000. This code works in old, 3.8.13 kernel. Do anyone let me know why I cannot mmap this area in new Kernel 3.13 -- 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: [Q] How can I use P9 14 as PWM?
Thanks, first cat /sys/kernel/debug/pwm -- platform/48304100.ecap, 1 PWM device pwm-0 ((null) ): platform/48304200.ehrpwm, 2 PWM devices pwm-0 ((null) ): pwm-1 (PWM_P8_13 ): requested enabled platform/48302200.ehrpwm, 2 PWM devices pwm-0 (PWM_P9_14 ): requested enabled pwm-1 (PWM_P9_16 ): requested enabled platform/48300100.ecap, 1 PWM device pwm-0 ((null) ): platform/48300200.ehrpwm, 2 PWM devices pwm-0 ((null) ): pwm-1 ((null) ): --- next cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins --- registered pins: 142 pin 0 (44e10800) 0031 pinctrl-single pin 1 (44e10804) 0031 pinctrl-single pin 2 (44e10808) 0031 pinctrl-single pin 3 (44e1080c) 0031 pinctrl-single pin 4 (44e10810) 0031 pinctrl-single pin 5 (44e10814) 0031 pinctrl-single pin 6 (44e10818) 0031 pinctrl-single pin 7 (44e1081c) 0031 pinctrl-single pin 8 (44e10820) 0027 pinctrl-single pin 9 (44e10824) 0004 pinctrl-single pin 10 (44e10828) 0027 pinctrl-single pin 11 (44e1082c) 0027 pinctrl-single pin 12 (44e10830) 0027 pinctrl-single pin 13 (44e10834) 0027 pinctrl-single pin 14 (44e10838) 0027 pinctrl-single pin 15 (44e1083c) 0027 pinctrl-single pin 16 (44e10840) 0027 pinctrl-single pin 17 (44e10844) 0027 pinctrl-single pin 18 (44e10848) 0006 pinctrl-single pin 19 (44e1084c) 0006 pinctrl-single pin 20 (44e10850) 0017 pinctrl-single pin 21 (44e10854) 0007 pinctrl-single pin 22 (44e10858) 0017 pinctrl-single pin 23 (44e1085c) 0007 pinctrl-single pin 24 (44e10860) 0017 pinctrl-single pin 25 (44e10864) 0027 pinctrl-single pin 26 (44e10868) 0027 pinctrl-single pin 27 (44e1086c) 0027 pinctrl-single pin 28 (44e10870) 0037 pinctrl-single pin 29 (44e10874) 0037 pinctrl-single pin 30 (44e10878) 0037 pinctrl-single pin 31 (44e1087c) 0037 pinctrl-single pin 32 (44e10880) 0032 pinctrl-single pin 33 (44e10884) 0032 pinctrl-single pin 34 (44e10888) 0037 pinctrl-single pin 35 (44e1088c) 0027 pinctrl-single pin 36 (44e10890) 0037 pinctrl-single pin 37 (44e10894) 0037 pinctrl-single pin 38 (44e10898) 0037 pinctrl-single pin 39 (44e1089c) 0037 pinctrl-single pin 40 (44e108a0) 002f pinctrl-single pin 41 (44e108a4) 002f pinctrl-single pin 42 (44e108a8) 002f pinctrl-single pin 43 (44e108ac) 002f pinctrl-single pin 44 (44e108b0) 002f pinctrl-single pin 45 (44e108b4) 002f pinctrl-single pin 46 (44e108b8) 002f pinctrl-single pin 47 (44e108bc) 002f pinctrl-single pin 48 (44e108c0) 002f pinctrl-single pin 49 (44e108c4) 002f pinctrl-single pin 50 (44e108c8) 002f pinctrl-single pin 51 (44e108cc) 002f pinctrl-single pin 52 (44e108d0) 002f pinctrl-single pin 53 (44e108d4) 002f pinctrl-single pin 54 (44e108d8) 002f pinctrl-single pin 55 (44e108dc) 002f pinctrl-single pin 56 (44e108e0) 0027 pinctrl-single pin 57 (44e108e4) 0027 pinctrl-single pin 58 (44e108e8) 0027 pinctrl-single pin 59 (44e108ec) 0027 pinctrl-single pin 60 (44e108f0) 0030 pinctrl-single pin 61 (44e108f4) 0030 pinctrl-single pin 62 (44e108f8) 0030 pinctrl-single pin 63 (44e108fc) 0030 pinctrl-single pin 64 (44e10900) 0030 pinctrl-single pin 65 (44e10904) 0030 pinctrl-single pin 66 (44e10908) 0027 pinctrl-single pin 67 (44e1090c) 0027 pinctrl-single pin 68 (44e10910) 0020 pinctrl-single pin 69 (44e10914) pinctrl-single pin 70 (44e10918) 0020 pinctrl-single pin 71 (44e1091c) pinctrl-single pin 72 (44e10920) pinctrl-single pin 73 (44e10924) pinctrl-single pin 74 (44e10928) pinctrl-single pin 75 (44e1092c) 0020 pinctrl-single pin 76 (44e10930) 0020 pinctrl-single pin 77 (44e10934) 0020 pinctrl-single pin 78 (44e10938) 0020 pinctrl-single pin 79 (44e1093c) 0020 pinctrl-single pin 80 (44e10940) 0020 pinctrl-single pin 81 (44e10944) 0027 pinctrl-single pin 82 (44e10948) 0030 pinctrl-single pin 83 (44e1094c) 0010 pinctrl-single pin 84 (44e10950) 0037 pinctrl-single pin 85 (44e10954) 0037 pinctrl-single pin 86 (44e10958) 0062 pinctrl-single pin 87 (44e1095c) 0062 pinctrl-single pin 88 (44e10960) 002f pinctrl-single pin 89 (44e10964) 0027 pinctrl-single pin 90 (44e10968) 0037 pinctrl-single pin 91 (44e1096c) 0037 pinctrl-single pin 92 (44e10970) 0030 pinctrl-single pin 93 (44e10974) pinctrl-single pin 94 (44e10978) 0073 pinctrl-single pin 95 (44e1097c) 0073 pinctrl-single pin 96 (44e10980) 0037 pinctrl-single pin 97 (44e10984) 0037 pinctrl-single pin 98 (44e10988) 0070 pinctrl-single pin 99 (44e1098c) 0070 pinctrl-single pin 100 (44e10990) 0027 pinctrl-single pin 101 (44e10994) 0027 pinctrl-single pin 102 (44e10998) 0027 pinctrl-s
Re: [beagleboard] Re: [Q] How can I use P9 14 as PWM?
Thank you for your help. pwmchip0 and pwmchip1 2 files are there. Weird thing is that after echo "pwm-test-P9.." and echo "pwm-test-P8...", though there are pwm-test-P9_14 and pwm-test-P8_13, and contents of the directores are same, only P8_13 does show result in oscilloscope but P9_14 does not show result. On Wed, Apr 2, 2014 at 12:06 AM, Cody Lacey wrote: > what are the contents of /sys/class/pwm > > > On Tue, Apr 1, 2014 at 4:25 AM, Sungjin Chun wrote: > >> Ah, I'm using 3.8.13 kernel on BeagleBone Black >> >> >> On Tuesday, April 1, 2014 6:07:50 PM UTC+9, Sungjin Chun wrote: >>> >>> echo "am33x-pwm" > ...slots >>> echo "pwm-test-P9_14" > ...slots >>> (yes, I'm not rewrite those file names correctly here) >>> >>> Above does not make PWM work for P9_14 pin. Though there are period_ns >>> and duty_ns, if I >>> echo "1" > run >>> nothing happens. If I do this on P8_13, it works. Why does this not work >>> for me? >>> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to beagleboard+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: [Q] How can I use P9 14 as PWM?
Ah, I'm using 3.8.13 kernel on BeagleBone Black On Tuesday, April 1, 2014 6:07:50 PM UTC+9, Sungjin Chun wrote: > > echo "am33x-pwm" > ...slots > echo "pwm-test-P9_14" > ...slots > (yes, I'm not rewrite those file names correctly here) > > Above does not make PWM work for P9_14 pin. Though there are period_ns and > duty_ns, if I > echo "1" > run > nothing happens. If I do this on P8_13, it works. Why does this not work > for me? > -- 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] [Q] How can I use P9 14 as PWM?
echo "am33x-pwm" > ...slots echo "pwm-test-P9_14" > ...slots (yes, I'm not rewrite those file names correctly here) Above does not make PWM work for P9_14 pin. Though there are period_ns and duty_ns, if I echo "1" > run nothing happens. If I do this on P8_13, it works. Why does this not work for me? -- 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] Read GPIO Through /dev/mem on BeagleBoneBlack?
Though you cannot avoid searching TRM, Technical Reference Manual, you can get some help on this site. http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/ Sent from my iPad > On Mar 28, 2014, at 9:08 PM, Charles Steinkuehler > wrote: > >> On 3/28/2014 6:47 AM, Dacobi wrote: >> I'm trying to speed up some PWM IO code by reading/writing straight through >> /dev/mem >> >> I found an example that toggles a led, but non that read GPIO as input. >> >> Can anyone point me to an example or some documentation of the GPIO's >> physical memory addresses? > > You want the AM335x Technical Reference Manual from TI. > > -- > Charles Steinkuehler > char...@steinkuehler.net > > -- > 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] Driving servos with face position detected from OpenCV?
How about using node.js OpenCV bindings such as; https://github.com/peterbraden/node-opencv Though I'm not sure on the OpenCV functionalities implemented in this package. On Thu, Mar 27, 2014 at 2:55 PM, Shanshan Zhou wrote: > Hey guys! > I'm just getting started with my BBB, and the possibility to integrate > camera vision in robotic project is what I'm most looking forward to get > from BBB. > > Appologise first, I'm not very experienced with Linux and c++ at all -- > and I guess this is why I found it so hard to get started with OpenCV for > BBB, even though there are a lot of examples online already. > Ok, let me try my best to explain the issue. > > According to beaglebone.org, we can use BoneScript to control PWM pins > allowing us to drive servos. > On the other hand, we can use OpenCV c++ to detect face positions. > The question is, what should I do if I want to drive the servos based on > the face detected with OpenCV? > > Does that mean I have to write the entire application in c++? > Or is there a way to just pass data from the c++ program with OpenCV (only > the face position) into a servo driving application written in BoneScript? > > I guess my options are: > > 1. c++ face detect position with OpenCV + BoneScript application driving > servo. > > 2. Python: OpenCV in python + Python IO BBIO + driving servo with py > application > > 3. c++: c++ OpenCV, c++ drive servo > > I have NO experience with c++, little bit experience with python, ok with > Javascript and java? > > What do you guys think? Which options are more feasible? > Any better suggestions? > > Sorry I'm not a computer scientist so I apologies if anything I'm saying > sounds silly or doesn't make sense. > Thank you guys in advance! > Shanshan > > -- > 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] eMMC data corruption due to power removal?
How about making system partition be mounted as read-only and data partition be mounted after booting and checking? In this case, only data partition has possibility of corruption. Sent from my iPad > On Mar 26, 2014, at 9:53 PM, Yiling Cao wrote: > > Hi I have some my products deployed with am335x with Micron eMMC 2GB, but my > products allow users to unplug power as they wish. > > My linux app very rarely writes to the eMMC. and my /etc/fstab specifies > /var/log and /tmp to tempfs; fstab mount all partitions with "noatime" > properties. > > But around 2 months of deployment, I found that around 1-2% am335x machines, > have some sort of data corruption, resulting fail to boot up. > > Can anyone share some thoughts/ experience about how to resolve this issue? > In real life product, whats the best practice? > -- > 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.
[beagleboard] Re: [Q] Enabling ADC without Device Tree file
Though no one is interested in this subject, anyway I found one solution; Set CM_WKUP_ADC_TSC_CLKCTRL in privileged mode, which I mean in the kernel module. I cannot figure out why this register is not modified in mmaped /dev/mem, however, in kernel module or kernel space, I can modify this register as |= 0x2. Can anyone let me know why I encountered this problem? As far as I know only GPIO control registers need privileged mode to modify their values... On Wednesday, March 26, 2014 12:57:06 PM UTC+9, Sungjin Chun wrote: > > Can anyone let me know what register should I use for this? > > I just tried to read following register value > > 0x44E0D000 > > where REVISION (12.5.1.1 of TRM) register is. But without > slotting BB_ADC to capemgr, what I've got is following error: > > Unhandled fault: external abort on non-linefetch (0x1018) at 0xb6f11000 > > This kind of error, I have experienced with GPIO3 register and I found that > turning on clock using CM_PER_GPIO3_CLKCTRL(8.1.12.1.31 of TRM) > solves. > > However I cannot figure out what register should I turn on, I've tried with > CM_WKUP_ADC_TSC_CLKCTRL but it does not solve my problem. > > Thanks in advance. > > PS) > Sorry for reposting, I have not assigned board before. > -- 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] PRUSS and accessing ADC registers on Beaglebone Black
Did you find how to enable ADC without device tree? I have the same problem like you. On Wednesday, February 26, 2014 11:05:12 PM UTC+9, Nhan Nguyen wrote: > > Hi John, > > Is there a way to enable ADC without using device tree? I couldn't find a > way to do it in the reference manual. Thank you. > > Regards, > Nhan > > On Sunday, February 23, 2014 3:05:39 AM UTC+1, john3909 wrote: >> >> >> >> From: Nhan Nguyen >> Reply-To: >> Date: Saturday, February 22, 2014 at 5:40 PM >> To: >> Subject: Re: [beagleboard] PRUSS and accessing ADC registers on >> Beaglebone Black >> >> Hi Charles, >> >> Thank you very much for your answer. I manage to access it after enable >> ADC using 'echo BB-ADC > /sys/devices/bone.capemgr.*/slots' . Though I >> could only do it in kernel 3.8, later kernel (3.12) gives an error saying >> symbol ocp could not be found. I do not really know how to change the .dts >> to get it working . Anyhow, I will work with 3.8 for now. >> >> There is no cape manager in V3.12 >> >> Regards, >> John >> >> >> Sincere, >> Nhan Nguyen >> >> On Wednesday, February 19, 2014 2:57:31 PM UTC+1, Charles Steinkuehler >> wrote: >>> >>> On 2/19/2014 7:43 AM, Nhan Nguyen wrote: >>> > Hi everyone, >>> > >>> > I have been trying to use PRU to read multiple ADC inputs. >>> Unfornately, I >>> > am stuck at accessing to the ADC registers (chapter 12 on AM335x >>> technical >>> > reference manual). I set the OCP registers, checked the PMAO registers >>> on >>> > PRU to ensure access to external host. For example, I read the ADC >>> REVISION >>> > as below: (tried to write to STEPCONFIG and STEPENABLE, etc.) >>> > >>> >MOV r13, 0x44E0D000 //ADC REVISION >>> >LBBO r5, r13, 0, 4 >>> >SBCO r5, C28, 4, 4 //store REVISION to shared memory to show with >>> C >>> > program >>> > >>> > .. but everything returns 0. >>> > >>> > I install Ubuntu 13.04 on Beaglebone Black, tried kernels 3.8, 3.12. >>> PRU >>> > worked with shared memory accessing, and GPIO1 registers (I am not >>> sure >>> > what to try next) . I haven't tried it on the official Angstrom image, >>> > because I still couldn't get PRU to work right away on it. >>> >>> I suggest you remove the PRU from the setup temporarily and try directly >>> reading the memory from C. This will be a lot easier to debug, and the >>> PRU has no chance of reading ADC values if you can't read them from the >>> ARM. >>> >>> As a guess, I suspect you don't have the ADC hardware setup properly and >>> are getting bus faults when reading. This will show up as an error if >>> you try to read the memory location from the ARM (making it easier to >>> debug). Make sure you have loaded a device tree overlay that enables >>> the TSC hardware (Touch Screen Controller = ADC) and populates an >>> appropriate state-machine instruction table to digitize the values you >>> are interested in. Unlike simpler microcontrollers, each major >>> subsystem in the AM335x can be powered up or shut down, and by default >>> most systems (ADC, PWM, etc) are powered down with their clocks disabled >>> until you explicitly enable them. >>> >>> Once you can properly read the values from a raw memory location using >>> the ARM, the PRU should be able to read them as well. >>> >>> -- >>> Charles Steinkuehler >>> cha...@steinkuehler.net >>> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to beagleboard...@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] [Q] Enabling ADC without Device Tree file
Can anyone let me know what register should I use for this? I just tried to read following register value 0x44E0D000 where REVISION (12.5.1.1 of TRM) register is. But without slotting BB_ADC to capemgr, what I've got is following error: Unhandled fault: external abort on non-linefetch (0x1018) at 0xb6f11000 This kind of error, I have experienced with GPIO3 register and I found that turning on clock using CM_PER_GPIO3_CLKCTRL(8.1.12.1.31 of TRM) solves. However I cannot figure out what register should I turn on, I've tried with CM_WKUP_ADC_TSC_CLKCTRL but it does not solve my problem. Thanks in advance. PS) Sorry for reposting, I have not assigned board before. -- 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] [Q] Enabling ADC without Device Tree file
Can anyone let me know what register should I use for this? I just tried to read following register value 0x44E0D000 where REVISION (12.5.1.1 of TRM) register is. But without slotting BB_ADC to capemgr, what I've got is following error: Unhandled fault: external abort on non-linefetch (0x1018) at 0xb6f11000 This kind of error, I have experienced with GPIO3 register and I found that turning on clock using CM_PER_GPIO3_CLKCTRL(8.1.12.1.31 of TRM) solves. However I cannot figure out what register should I turn on, I've tried with CM_WKUP_ADC_TSC_CLKCTRL but it does not solve my problem. Thanks in advance. -- 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: porting kernel 3.13.6 to beaglebone black
Though I'm not sure on the current linux distro you are using on BBB, my choice is Arch Linux and it already has 3.13.6 kernel. I managed to install & run on my BeagleBone Black(yes, arch linux), however, this version of kernel does not have cape manager (/sys/devices/capemgr.*) and I cannot figure out how to change/apply device tree file. In short, 3.13.6 is already ported to BBB, and there is no capemgr (unlike 3.8.13). On Friday, March 7, 2014 10:44:55 PM UTC+9, prashanth@gmail.com wrote: > > Dear all, > I am very beginner to embedded linux. > I have Beagle bone black board. Let me know how can we port the linux > kernel 3.13.6 to BBB. > Please help me to start > > Thanks > Prashanth > -- 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] [Q] Any pinmuxing method in 3.13 kernel?
Hi, I've been using 3.8 (arch linux) on my BBB, and want to try 3.13 version of kernel. However, it seems that there is no cape manager support on 3.13 version. Now here is my question: Are there any pinmuxing (without rebooting) method in 3.13 kernel? I've used device tree/cape manager just for pinmuxing, for other things like pin reading, I've always been used /dev/mem. Thanks in advance. -- 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.
