This post was updated on .
Hello Gumstix Community,
I happy to see such an active and helpful user group because I really need help :) At first, my intention: I want to implement a simple transmission protocol called "Fast Serial Bus" (FSB) with which I want to handle the data from another device (CMX981 by CML Microcircuits). The CMX981 supplies the clock signal, the words are 16 or 32 bits and there are frame sync signals for each direction marking the beginning of a word. Here is an illustration of the protocol: https://dl.dropboxusercontent.com/u/207133/cml_cmx981_fsb_operation.png . CML suggested the use of McBSP. Afterwards, I need to implement a Pi/4 DQPSK Demodulator because the RX path delivers only pairs of I/Q constellation data. Right now, I am struggling with a lot of newbie problems since my experience with embedded systems is rather limited. Also for now, I don't have a SD card, so I have only the stock Angstrom and probably need a cross compilation environment which would be my first problem. I am stuck with windows on my working PC but have Arch Linux (private laptop) and Ubuntu (VM) at my disposal. I have seen tutorials setting up an Open Embedded environment and the Gumstix introduction to cross-compilation (http://gumstix.org/basic-cross-compilation.html) is just compiling a kernel with gcc-arm-linux-gnueabi. The next problem is McBSP pinout. There are now dedicated pins for this on the Alcatraz, but searching through your mailing list I read that certain pins can configured as McBSP signals. Searching through the documentation, I didn't find a way that explains this feature. In Summary: 1. Do I need a Open Embedded ? If yes, how to set it up correctly and on what system? (up-to-date tutorial?) 2. How to get McBSP signals on pins of the Alcatraz board ? I don't mind RTFMs at all if you can point my to the right manuals or tutorials. ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ gumstix-users mailing list gumstix-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gumstix-users |
On Thu, 2013-08-22 at 10:41 +0700, Thomas Frank wrote: > Hello Gumstix Community, [snip] > Right now, I am struggling with a lot of newbie problems since my > experience with embedded systems is rather limited. Also for now, I > don't have a SD card, so I have only the stock Angstrom and probably > need a cross compilation environment which would be my first problem. I > am stuck with windows on my working PC but have Arch Linux (private > laptop) and Ubuntu (VM) at my disposal. I have seen tutorials setting up > an Open Embedded environment and the Gumstix introduction to > cross-compilation (http://gumstix.org/basic-cross-compilation.html) is > just compiling a kernel with gcc-arm-linux-gnueabi. > > The next problem is McBSP pinout. There are now dedicated pins for this > on the Alcatraz, but searching through your mailing list I read that > certain pins can configured as McBSP signals. Searching through the > documentation I have, I didn't find a way that explains this feature. > > In Summary: > 1. Do I need a Open Embedded ? If yes, how to set it up correctly and on > what system? (up-to-date tutorial?) You're likely going to need a customized U-Boot and/or kernel to get the pin-mux set up properly and to make use of the McBSP for something other than sound/audio. I'd recommend a Yocto build. The learning curve can be high, but in the end, keeping up to date with the latest features is easier. http://gumstix.org/software-development/yocto-project.html https://github.com/gumstix/Gumstix-YoctoProject-Repo Skipping ahead some steps... To build the image files: $ bitbake gumstix-console-image (Takes about 2.5 hours for me on my 4-core laptop. A VM will take much longer.) To build a cross compilation toolchain, that only uses headers and libraries that are installed in the target image: $ bitbake gumstix-console-image -c populate_sdk > 2. How to get McBSP signals on pins of the Alcatraz board ? You will need to consult the TI OMAP Technical Reference Manual (freely available from TI), the Gumstix Overo Reference document, and the Alcatraz schematic (freely available from Gumstix) to understand the pin-mux and what pins you can use. If your electrical design needs pins configured ASAP, you will probably need to modify u-boot source files: board/overo/overo.c board/overo/overo.h If not, you can defer configuration of the pin mux to the linux kernel: arch/arm/mach-omap2/board-overo.c or in a custom kernel module, or maybe from user space using debugfs. When setting the pin mux, to avoid frying hardware you must *avoid*: floating CMOS inputs bus fights on outputs driving the OMAP I/O pins before the SYSEN signal is asserted Regards, Andy > I don't mind RTFMs at all if you can point my to the right manuals or > tutorials. ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ gumstix-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gumstix-users |
On 08/22/2013 07:23 AM, Andy Walls wrote:
> You're likely going to need a customized U-Boot and/or kernel to get the > pin-mux set up properly and to make use of the McBSP for something other > than sound/audio. > > I'd recommend a Yocto build. The learning curve can be high, but in the > end, keeping up to date with the latest features is easier. > > http://gumstix.org/software-development/yocto-project.html > https://github.com/gumstix/Gumstix-YoctoProject-Repo Keep in mind http://gumstix.8.x6.nabble.com/McBSP-Driver-td4967321.html which ultimately leads to http://comments.gmane.org/gmane.linux.ports.arm.omap/91842 which explains that much of the McBSP support for anything other than audio was removed starting with Linux 3.3. You'd need to review that to determine whether you need to use Linux 3.2, or would need to make significant customizations to the kernel. I believe 3.2 is still technically an option in dylan (Yocto 1.4), but expect it to be dropped from Yocto 1.5 coming out in October. Peter ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ gumstix-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gumstix-users |
The OE Angstrom build still uses the 3.2 kernel and works well for
McBSP. I'm currently using that build with the Overo STORM modules and a custom expansion board to interface with a TI DSP via McBSP3, and soon to a CPLD on another board via McBSP5. Thomas - see the following links for some additional assistance: Setting up the OE Angstrom build environment: http://gumstix.8.x6.nabble.com/Building-the-stable-Overo-Angstom-image-td4967694.html Gumstix McBSP kernel module example (for an old kernel, but still helpful): http://gumstix.8.x6.nabble.com/DMA-McBSP-help-td667552.html u-boot pin muxing is pretty straight forward, basically just edit overo-oe/tmp/work/overo-angstrom-linux-gnueabi/u-boot*/git/board/overo/overo.h and change the input enable flag, pull up/down direction, pull up/down enable, and "mode" to what you need for the pins you're interested in (see Gumstix schematics for what pins you have available to you) and then rebuild. For permanent changes you'll need to make a patch file and incorporate that into your bitbake recipe. jumpnowtek used to have a page on that, but it looks like it's been converted to yocto. Still might be of some use: http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=55&Itemid=61 For more on the "mode" see the OMAP TRM: http://www.ti.com/lit/ug/sprugn4r/sprugn4r.pdf (section 7.4.4.3 pages 773 to 783) The OMAP chips on OVERO have 5 McBSPs, but only two of them are available on the 70-pins (3 and 5), both of which are 4 pin McBSPs (DR, DX, and a common CLK and FS). It sounds like you might need a 6-pin McBSP, unless you can configure the CMX981 to synchronize the input and output clock and FS? Something to look into. See more in the above linked TRM, chapter 21. -Adam On 08/22/2013 07:03 AM, Peter A. Bigot wrote: > On 08/22/2013 07:23 AM, Andy Walls wrote: >> You're likely going to need a customized U-Boot and/or kernel to get the >> pin-mux set up properly and to make use of the McBSP for something other >> than sound/audio. >> >> I'd recommend a Yocto build. The learning curve can be high, but in the >> end, keeping up to date with the latest features is easier. >> >> http://gumstix.org/software-development/yocto-project.html >> https://github.com/gumstix/Gumstix-YoctoProject-Repo > Keep in mind http://gumstix.8.x6.nabble.com/McBSP-Driver-td4967321.html > which ultimately leads to > http://comments.gmane.org/gmane.linux.ports.arm.omap/91842 which > explains that much of the McBSP support for anything other than audio > was removed starting with Linux 3.3. You'd need to review that to > determine whether you need to use Linux 3.2, or would need to make > significant customizations to the kernel. I believe 3.2 is still > technically an option in dylan (Yocto 1.4), but expect it to be dropped > from Yocto 1.5 coming out in October. > > Peter > > ------------------------------------------------------------------------------ > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > gumstix-users mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gumstix-users ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ gumstix-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gumstix-users |
In reply to this post by Peter A. Bigot
> I believe 3.2 is still technically an option in dylan (Yocto 1.4), but expect it to be dropped
> from Yocto 1.5 coming out in October. Where are you getting that information from? I know for sure that 3.2 kernels are supported by Yocto 1.4, it's what I use. How would Yocto restrict the kernel recipe used anyway? Are they changing the kernel bb classes? |
In reply to this post by the suicidal eggroll
u-boot recipe bbappend and mux patch for McBSP3 use off the expansion board.
Only CLKX, FSX and DR are muxed. I'm not using the DX line for this project. scott@hex:~/fit-overo/meta-fit-overo/recipes-bsp/u-boot$ cat u-boot_2013.07.bbappend FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:" PRINC := "${@int(PRINC) + 1}" SRC_URI += " \ file://mcbsp3-mux.patch \ file://minimal-boot-args.patch \ " scott@hex:~/fit-overo/meta-fit-overo/recipes-bsp/u-boot$ cat u-boot-2013.07/mcbsp3-mux.patch diff --git git/board/overo/overo.h-orig git/board/overo/overo.h index b984a54..eaa3069 100644 --- git/board/overo/overo.h-orig +++ git/board/overo/overo.h @@ -224,9 +224,9 @@ const omap3_sysinfo sysinfo = { MUX_VAL(CP(MCBSP3_CLKX), (IDIS | PTD | DIS | M1)) /*UART2_TX*/\ MUX_VAL(CP(MCBSP3_FSX), (IEN | PTD | DIS | M1)) /*UART2_RX*/\ MUX_VAL(CP(UART2_CTS), (IEN | PTD | DIS | M4)) /*GPIO_144 - LCD_EN*/\ - MUX_VAL(CP(UART2_RTS), (IEN | PTD | DIS | M4)) /*GPIO_145*/\ - MUX_VAL(CP(UART2_TX), (IEN | PTD | DIS | M4)) /*GPIO_146*/\ - MUX_VAL(CP(UART2_RX), (IEN | PTD | DIS | M4)) /*GPIO_147*/\ + MUX_VAL(CP(UART2_RTS), (IEN | PTD | DIS | M1)) /*MCBSP3_DR*/\ + MUX_VAL(CP(UART2_TX), (IEN | PTD | DIS | M1)) /*MCBSP3_CLKX*/\ + MUX_VAL(CP(UART2_RX), (IEN | PTD | DIS | M1)) /*MCBSP3_FSX*/\ MUX_VAL(CP(UART1_TX), (IDIS | PTD | DIS | M0)) /*UART1_TX*/\ MUX_VAL(CP(UART1_RTS), (IEN | PTU | DIS | M4)) /*GPIO_149*/ \ MUX_VAL(CP(UART1_CTS), (IEN | PTU | DIS | M4)) /*GPIO_150-MMC3_WP*/\ |
In reply to this post by Scott Ellis
On 08/22/2013 01:26 PM, Scott Ellis wrote:
>> I believe 3.2 is still technically an option in dylan (Yocto 1.4), but > expect it to be dropped >> from Yocto 1.5 coming out in October. > Where are you getting that information from? > > I know for sure that 3.2 kernels are supported by Yocto 1.4, it's what I > use. > > How would Yocto restrict the kernel recipe used anyway? > > Are they changing the kernel bb classes? I was speaking of Yocto specifically with reference to linux-yocto, the kernel recipes that are used by the Yocto developers and supposedly supported and tested within each release across multiple platforms. The linux-yocto_3.2 recipe has been removed from oe-core master, so it won't be tested in 1.5. Of course, one can always make it work in an external layer with a forked recipe like linux-gumstix, but it'll get harder and harder as the overall infrastructure keeps up with current package releases which will expect features from newer kernels. Device trees are becoming standard (see, for example, BeagleBone Black), and I expect that to have a significant effect on the infrastructure including kernel bb classes. For Dylan the preferred kernel was 3.8; from what I've seen I expect 3.10 to be the standard in Yocto 1.5, though I haven't personally built with the current Yocto master branch yet. Much of what I'm doing now is trying to get some baseline validation of Gumstix capabilities with the 3.5 kernel used in meta-gumstix so I can move ASAP to 3.10 and be prepared for the new Yocto release in September/October. I'm doing that using the linux-yocto recipe framework instead of the linux-gumstix one, because the former is much more suited to customization and documentation of kernel options across similar (and dissimilar) machines. Peter ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ gumstix-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gumstix-users |
In reply to this post by the suicidal eggroll
Thank you all for providing so much information.
On 22.08.2013 23:29, Adam Reynolds wrote: > The OMAP chips on OVERO have 5 McBSPs, but only two of them are > available on the 70-pins (3 and 5), both of which are 4 pin McBSPs (DR, > DX, and a common CLK and FS). It sounds like you might need a 6-pin > McBSP, unless you can configure the CMX981 to synchronize the input and > output clock and FS? Something to look into. See more in the above > linked TRM, chapter 21. > > -Adam For transmitting and receiving, I have to use the clock supplied by the CMX981 and feed it to the input clock for all McBSPs (mcbsp_clks). Since there is no receiving frame sync signal (from the overo perspective) on McBSP{2,3,4,5}, do you think I could use another (non-mcbsp) signal for this purpose? I have to detect the falling edge of the frame sync to know when the word began on the receiving data stream. Additionally, I probably have to adhere to the distance between receiving and transmitting data words of 10 to 12 clock cycles. It seems like there is no setting for the CMX981 changing that. Best Regards, Thomas ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ gumstix-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gumstix-users |
Does the CMX981 pulse its output CLK
and FS during the receive cycle, or does it only pulse them during
transmit and then silently wait for a reply? From your message it
sounds like it's always running the clock, but only pulses the FS
on transmit and it's up to the Overo to pulse its own FS when it
replies.
You might be able to use a GPIO to act as an FS, however I don't know if you'd be able to do it within that 10-12 clock cycle window. What speed is the CMX981's clock running? This page has some info about controlling a GPIO from the kernel: http://jumpnowtek.com/index.php?option=com_content&view=article&id=54&Itemid=60 -Adam On 8/23/2013 4:15 AM, Thomas Frank wrote: Thank you all for providing so much information. ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ gumstix-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gumstix-users |
On 23.08.2013 22:13, Adam Reynolds
wrote:
Thanks for the link Adam. The serial clock (SCLK) of the CMX981 is always running and can be set to 2.2815, 4.563 or 9.126 MHz. And you are completely right, the CMX981 only sends data and the according framesync. The Overo has to generate a the active-high FS (1 SCLK cycle) and then send the data. Best regards, Thomas ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ gumstix-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gumstix-users |
Hello,
I didn't get the openembedded environement to compile so I tried yocto and succeed in building the gumstix-console-image with default configuration (linux kernel 3.5). I tried to change the linux-kernel by in including PREFERRED_VERSION_linux-gumstix = "3.2" in the conf/local.conf in the build directory, because there is a linux-gumstix_3.2 recipe in meta-gumstix. Unfortunately, the recipe is restricted to the MACHINE="pepper" and will not be build for the overo. How do I get the overo recipe ? Best regards, Thomas ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ gumstix-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gumstix-users |
You can go into the linux-gumstix_3.2.bb recipe and modify the compatible machine line
COMPATIBLE_MACHINE = "pepper|overo" Or add your own customization layer and add it in a kernel bbappend recipe COMPATIBLE_MACHINE .= "|overo" or COMPATIBLE_MACHINE_overo = "overo" |
On 27.08.2013 17:58, Scott Ellis wrote:
> You can go into the linux-gumstix_3.2.bb recipe and modify the compatible > machine line > > COMPATIBLE_MACHINE = "pepper|overo" > > Or add your own customization layer and add it in a kernel bbappend recipe > > COMPATIBLE_MACHINE .= "|overo" > or > COMPATIBLE_MACHINE_overo = "overo" > omap-3.2 branch and what about the defconfig? ------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk _______________________________________________ gumstix-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gumstix-users |
By accident, I read the Introduction
to Cross Compilation again and took Sakoman's kernel
configuration from there. The kernel from the omap-3.2 branch
compiled :)
------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk _______________________________________________ gumstix-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gumstix-users |
Right. Sorry about that.
I also override the SRC_URI in my bbapend. The layer I'm using is here. https://github.com/Pansenti/meta-pansenti/tree/master/recipes-kernel/linux Gumstix kernels are pulled from the gumstix repo. |
This post was updated on .
In reply to this post by Scott Ellis
On 23.08.2013 01:33, Scott Ellis wrote:
> u-boot recipe bbappend and mux patch for McBSP3 use off the expansion board. > > Only CLKX, FSX and DR are muxed. I'm not using the DX line for this project. > > scott@hex:~/fit-overo/meta-fit-overo/recipes-bsp/u-boot$ cat > u-boot_2013.07.bbappend > FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:" > > PRINC := "${@int(PRINC) + 1}" > > SRC_URI += " \ > file://mcbsp3-mux.patch \ > file://minimal-boot-args.patch \ > " > > scott@hex:~/fit-overo/meta-fit-overo/recipes-bsp/u-boot$ cat > u-boot-2013.07/mcbsp3-mux.patch > diff --git git/board/overo/overo.h-orig git/board/overo/overo.h > index b984a54..eaa3069 100644 > --- git/board/overo/overo.h-orig > +++ git/board/overo/overo.h > @@ -224,9 +224,9 @@ const omap3_sysinfo sysinfo = { > MUX_VAL(CP(MCBSP3_CLKX), (IDIS | PTD | DIS | M1)) /*UART2_TX*/\ > MUX_VAL(CP(MCBSP3_FSX), (IEN | PTD | DIS | M1)) /*UART2_RX*/\ > MUX_VAL(CP(UART2_CTS), (IEN | PTD | DIS | M4)) /*GPIO_144 - LCD_EN*/\ > - MUX_VAL(CP(UART2_RTS), (IEN | PTD | DIS | M4)) /*GPIO_145*/\ > - MUX_VAL(CP(UART2_TX), (IEN | PTD | DIS | M4)) /*GPIO_146*/\ > - MUX_VAL(CP(UART2_RX), (IEN | PTD | DIS | M4)) /*GPIO_147*/\ > + MUX_VAL(CP(UART2_RTS), (IEN | PTD | DIS | M1)) /*MCBSP3_DR*/\ > + MUX_VAL(CP(UART2_TX), (IEN | PTD | DIS | M1)) /*MCBSP3_CLKX*/\ > + MUX_VAL(CP(UART2_RX), (IEN | PTD | DIS | M1)) /*MCBSP3_FSX*/\ > MUX_VAL(CP(UART1_TX), (IDIS | PTD | DIS | M0)) /*UART1_TX*/\ > MUX_VAL(CP(UART1_RTS), (IEN | PTU | DIS | M4)) /*GPIO_149*/ \ > MUX_VAL(CP(UART1_CTS), (IEN | PTU | DIS | M4)) /*GPIO_150-MMC3_WP*/\ Why did you set every pin as IEN (input enable). My first guess would be to disable input if the pin is only an output pin. gumstix-users mailing list gumstix-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gumstix-users |
The clocks for McBSP (and SPI) need to be inputs.
Here's a working system with an McBSP3 driver (I just happened to be working on one) === MCBSP3_CLKX mux root@overo:~# devmem2 0x48002178 h /dev/mem opened. Memory mapped at address 0x4015c000. Read at address 0x48002178 (0x4015c178): 0x0101 === MCBSP3_FSX mux root@overo:~# devmem2 0x4800217a h /dev/mem opened. Memory mapped at address 0x40157000. Read at address 0x4800217A (0x4015717a): 0x0101 === The driver root@overo:~# lsmod Module Size Used by ads1278 8677 0 === A userland test program root@overo:~# ./adswatch ===== Driver config ===== block_size: 8192 state: MCBSP_REQUESTED | MCBSP_CONFIG_SET mode: HIGH SPEED mcbsp_clkdiv 16 trigger_duration: 10 us flash_delay: 1000 us flash_duration: 5000 us cycle_duration: 100 ms ========================= (use ctrl-c to stop) Total: 157 Blocks: 9 Elapsed: 101 Samples/sec: 22811 ^C (GETTING DATA) === Remux MCBSP3_CLKX as an output root@overo:~# devmem2 0x48002178 h 0x0001 /dev/mem opened. Memory mapped at address 0x400b9000. Read at address 0x48002178 (0x400b9178): 0x0101 Write at address 0x48002178 (0x400b9178): 0x0001, readback 0x0001 === Test the driver root@overo:~# ./adswatch ===== Driver config ===== block_size: 8192 state: MCBSP_REQUESTED mode: HIGH SPEED mcbsp_clkdiv 16 trigger_duration: 10 us flash_delay: 1000 us flash_duration: 5000 us cycle_duration: 100 ms ========================= (use ctrl-c to stop) (NO DATA) === Put the mux for CLKX back to input root@overo:~# devmem2 0x48002178 h 0x0101 /dev/mem opened. Memory mapped at address 0x40162000. Read at address 0x48002178 (0x40162178): 0x0001 Write at address 0x48002178 (0x40162178): 0x0101, readback 0x0101 === Test the driver root@overo:~# ./adswatch ===== Driver config ===== block_size: 8192 state: MCBSP_REQUESTED | MCBSP_CONFIG_SET mode: HIGH SPEED mcbsp_clkdiv 16 trigger_duration: 10 us flash_delay: 1000 us flash_duration: 5000 us cycle_duration: 100 ms ========================= (use ctrl-c to stop) Total: 111 Blocks: 10 Elapsed: 101 Samples/sec: 25346 ^C (GETTING DATA) === Remux MCBSP3_FSX as an output root@overo:~# devmem2 0x4800217a h 0x0001 /dev/mem opened. Memory mapped at address 0x400a4000. Read at address 0x4800217A (0x400a417a): 0x0101 Write at address 0x4800217A (0x400a417a): 0x0001, readback 0x0001 === Test the driver root@overo:~# ./adswatch ===== Driver config ===== block_size: 8192 state: MCBSP_REQUESTED | MCBSP_CONFIG_SET mode: HIGH SPEED mcbsp_clkdiv 16 trigger_duration: 10 us flash_delay: 1000 us flash_duration: 5000 us cycle_duration: 100 ms ========================= (use ctrl-c to stop) (NO DATA) === Put the FSX mux back to inpu root@overo:~# devmem2 0x4800217a h 0x0101 /dev/mem opened. Memory mapped at address 0x4005e000. Read at address 0x4800217A (0x4005e17a): 0x0001 Write at address 0x4800217A (0x4005e17a): 0x0101, readback 0x0101 === Test the driver root@overo:~# ./adswatch ===== Driver config ===== block_size: 8192 state: MCBSP_REQUESTED | MCBSP_CONFIG_SET mode: HIGH SPEED mcbsp_clkdiv 16 trigger_duration: 10 us flash_delay: 1000 us flash_duration: 5000 us cycle_duration: 100 ms ========================= (use ctrl-c to stop) Total: 407 Blocks: 10 Elapsed: 101 Samples/sec: 25346 ^C (GETTING DATA) |
That seems greats, I did not know that those connections are so
flexible. Does it mean that every signal ending with an "X" like FSX
can be used bidirectional? For my problem, I am thinking about
following connection scheme:
![]() Is that possible? ------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk _______________________________________________ gumstix-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gumstix-users |
The docs say the CLKX and FSX can be used in either direction, but I've
never tried it. My guess is it will work. In all my drivers so far, the McBSP has been the source for both the clock and frame sync lines. |
I'm running the McBSPs on my system in slave mode. CLK and FS are generated by the external device, the only output from the Overo is DX.
|
Free forum by Nabble | Edit this page |