From: Thomas F. <th0...@gm...> - 2013-08-22 03:42:04
|
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 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 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?) 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. |
From: Andy W. <an...@si...> - 2013-08-22 12:23:22
|
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. |
From: Peter A. B. <pa...@pa...> - 2013-08-22 13:04:02
|
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 |
From: Adam R. <sui...@gm...> - 2013-08-22 16:30:05
|
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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Scott E. <sc...@ju...> - 2013-08-22 20:13:17
|
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*/\ -- View this message in context: http://gumstix.8.x6.nabble.com/Newbie-Problems-Cross-Compilation-and-McBSP-with-Overo-Waterstorm-and-Alcatraz-Board-tp4967756p4967774.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2013-08-22 20:29:58
|
> 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? -- View this message in context: http://gumstix.8.x6.nabble.com/Newbie-Problems-Cross-Compilation-and-McBSP-with-Overo-Waterstorm-and-Alcatraz-Board-tp4967756p4967773.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Peter A. B. <pa...@pa...> - 2013-08-22 20:54:01
|
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 |
From: Thomas F. <th0...@gm...> - 2013-08-23 10:16:19
|
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 |
From: Adam R. <sui...@gm...> - 2013-08-23 15:13:38
|
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. > > 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Thomas F. <th0...@gm...> - 2013-08-23 16:44:23
|
On 23.08.2013 22:13, Adam Reynolds wrote: > 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 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 |
From: Thomas F. <th0...@gm...> - 2013-08-27 10:09:49
|
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 |
From: Scott E. <sc...@ju...> - 2013-08-27 10:58:57
|
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" -- View this message in context: http://gumstix.8.x6.nabble.com/Newbie-Problems-Cross-Compilation-and-McBSP-with-Overo-Waterstorm-and-Alcatraz-Board-tp4967756p4967813.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Thomas F. <th0...@gm...> - 2013-08-28 06:45:02
|
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" > The pepper recipe pulls from the am335x-32 branch and not from the omap-3.2 branch and what about the defconfig? |
From: Thomas F. <th0...@gm...> - 2013-08-28 07:35:18
|
By accident, I read the Introduction to Cross Compilation <http://gumstix.org/basic-cross-compilation.html> again and took Sakoman's kernel configuration from there. The kernel from the omap-3.2 branch compiled :) |
From: Scott E. <sc...@ju...> - 2013-08-28 08:42:20
|
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. -- View this message in context: http://gumstix.8.x6.nabble.com/Newbie-Problems-Cross-Compilation-and-McBSP-with-Overo-Waterstorm-and-Alcatraz-Board-tp4967756p4967823.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Thomas F. <th0...@gm...> - 2013-09-06 04:42:24
|
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 leave every pin as IEN (input enable). My first guess would be to disable input if the pin is only an output pin. |
From: Thomas F. <th0...@gm...> - 2013-10-07 10:05:23
|
Hi, I am confused about the built-in mcbsp driver. In the Linux kernel source for version 3.2-r1, there are mcbsp.c files at following locations: arch/arm/plat-omap arch/arm/mach-omap1 arch/arm/mach-omap2 What is difference and the purpose of the these files? Best Regards, Thomas |
From: Scott E. <sc...@ju...> - 2013-10-07 12:51:38
|
arch/arm/plat-omap/mcbsp.c is the main low-level driver your driver will be interacting with. The header for this is arch/arm/plat-omap/include/plat/mcbsp.h arch/arm/mach-omap2 /mcbsp.c is some board specific initialization. I've never had to directly use or modify any of the code here. arch/arm/mach-omap1 is not applicable. -- View this message in context: http://gumstix.8.x6.nabble.com/Newbie-Problems-Cross-Compilation-and-McBSP-with-Overo-Waterstorm-and-Alcatraz-Board-tp4967756p4968064.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2013-09-06 08:52:22
|
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) -- View this message in context: http://gumstix.8.x6.nabble.com/Newbie-Problems-Cross-Compilation-and-McBSP-with-Overo-Waterstorm-and-Alcatraz-Board-tp4967756p4967877.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Thomas F. <th0...@gm...> - 2013-09-09 05:04:23
|
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: cmx981 gumstix connection via mcbsp Is that possible? |
From: Scott E. <sc...@ju...> - 2013-09-09 13:53:17
|
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. -- View this message in context: http://gumstix.8.x6.nabble.com/Newbie-Problems-Cross-Compilation-and-McBSP-with-Overo-Waterstorm-and-Alcatraz-Board-tp4967756p4967908.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: the s. e. <sui...@gm...> - 2013-09-09 15:17:17
|
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. -- View this message in context: http://gumstix.8.x6.nabble.com/Newbie-Problems-Cross-Compilation-and-McBSP-with-Overo-Waterstorm-and-Alcatraz-Board-tp4967756p4967911.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: the s. e. <sui...@gm...> - 2013-09-09 22:56:29
|
I see no reason why your diagram combining McBSP3 and 5 couldn't work, the only issue is earlier you said the CMX has a requirement that the transmit and receive words only be 10-12 clock cycles apart? I don't know if you're going to be able to coordinate the two McBSPs to that level of accuracy with a 2+ MHz clock. You may consider sticking a small CPLD between the Overo and CMX to handle the FS, timing, and synchronization. Just a thought. -- View this message in context: http://gumstix.8.x6.nabble.com/Newbie-Problems-Cross-Compilation-and-McBSP-with-Overo-Waterstorm-and-Alcatraz-Board-tp4967756p4967913.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Andy W. <an...@si...> - 2013-09-16 13:27:09
|
On Mon, 2013-09-16 at 14:33 +0700, Thomas Frank wrote: > On 10/09/2013 05:55, the suicidal eggroll wrote: > > I see no reason why your diagram combining McBSP3 and 5 couldn't work, the > > only issue is earlier you said the CMX has a requirement that the transmit > > and receive words only be 10-12 clock cycles apart? I don't know if you're > > going to be able to coordinate the two McBSPs to that level of accuracy with > > a 2+ MHz clock. > > > > You may consider sticking a small CPLD between the Overo and CMX to handle > > the FS, timing, and synchronization. Just a thought. > > > The CPLD solution doesn't sound so complicated since I have a bit of > experience with VHDL programming of CPLDs and FPGAs. I will keep that in > mind. The CMX981 sends 16 bit words, but has a 32bit mode for the RX > path. Maybe this setting will change effect the distance between the > incoming and outgoing transmission. Additionally, the only indication of > this distance is the signal diagram I showed earlier ( > https://dl.dropboxusercontent.com/u/207133/cml_cmx981_fsb_operation.png > ). I found the datasheet here: http://www.datasheetcatalog.com/datasheets_pdf/C/M/X/9/CMX981.shtml Look at "Figure 7d Non bi-dir Command Read Operation". It indicates the exact same thing. CmdDat has 16 bits (1 low bit, 7 address bits, followed by 8 junk bits) CmdRd/RxFS goes high some time during those 8 junk bits. CmdRd/RxDat starts sending 15 bits (8 junk bit followed by 8 bits of data) So it appears some time in the 8 junk bits of CmdDat, the CMX981 is going to start responding. That would be the 10-12 bits indicated in Figure 5 FSB operation. I guess it can, because the 8 bits with the register address has been clocked in on CmdDat by then. > I don't really know how tolerable the CMX981 really is because the > documentation is not as detailed as one might want it to be. I know for the C-BUS CML has some application notes on how to use a SPI interface to drive that. You might want to contact CML and see if they have an application note for the FSB. Regards, Andy |
From: Andy W. <an...@si...> - 2013-09-17 12:01:12
|
On Tue, 2013-09-17 at 15:27 +0700, Thomas Frank wrote: > Andy, thank you for the hint! I was somehow under the impression that > I need to adhere the 10 to 12 bits distance in both ways which seems > kinda silly, because it would introduce a unnecessary gap between > transmission to the CMX981. I guess this simplifies my life a > little :) You're welcome. > Concerning FSB vs. CBUS: I already have a CML (PE0002) device > connected via CBUS to CMX981 which supplies the transmission clock > signal. The connection is not reliable for clock speed greater than > 2Mhz. Hmm. The CMX981 should be able to handle a C-BUS CCLK rate of MCLK/2 = 4.581 MHz. > Additionally, I always have to give the address before sending data or > receiving data. On plus side, it is SPI compatible. Later I may use > the gumstix SPI port to connect to the CBUS port and use it simply for > configuration. Yeah, for low bandwidth control and status, C-BUS using McSPI will probably be easier than FSB with McBSP. I guess it depends on how rapidly you need to read interrupt status registers or run external control loops using the AuxADCs and AuxDACs. I've got a Gumstix Water/Tobi McSPI talking to a CMX device at 3 MHz with no problem. (I designed for up to 5 MHz, but OMAP 3530 standard FCLK rates make that a pain to set up. The next higher normal rate from the OMAP McSPI is 6 MHz, given that it is divided down by powers of 2 from the 48 MHz FCLK for McSPI.) If you do use the McSPI interface to talk C-BUS, then you'll need this patch for the omap2-mcspi driver (set dummy_data to 0xffffffff for the SPI slave corresponding to the CMX device): diff --git a/arch/arm/plat-omap/include/plat/mcspi.h b/arch/arm/plat-omap/include/plat/mcspi.h index a357eb2..931510f 100644 --- a/arch/arm/plat-omap/include/plat/mcspi.h +++ b/arch/arm/plat-omap/include/plat/mcspi.h @@ -18,6 +18,7 @@ struct omap2_mcspi_dev_attr { struct omap2_mcspi_device_config { unsigned turbo_mode:1; + unsigned int dummy_data; }; #endif diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c index d9848fe..63c258c 100644 --- a/drivers/spi/spi-omap2-mcspi.c +++ b/drivers/spi/spi-omap2-mcspi.c @@ -923,8 +923,8 @@ static void omap2_mcspi_work(struct omap2_mcspi *mcspi, struct spi_message *m) /* RX_ONLY mode needs dummy data in TX reg */ if (t->tx_buf == NULL) - __raw_writel(0, cs->base - + OMAP2_MCSPI_TX0); + __raw_writel(cd ? cd->dummy_data : 0, + cs->base + OMAP2_MCSPI_TX0); if (m->is_dma_mapped || t->len >= DMA_MIN_BYTES) count = omap2_mcspi_txrx_dma(spi, t); There are lots of other little details about using SPI to talk to C-BUS devices, but this patch covers the detail the Linux kernel doesn't have built in support for configuring: ensuring the CMD data line is held high while reading data from the CMX device. [snip] > > So I am off reading Linux Device Drivers. Have fun. Regards, Andy |