> > *Well, I have gotten it working before using mmap() calls because I had a > very specific need for it for a proprietary project that I can't share the > code for, but I was informed (in no uncertain terms) that using mmap() for > SPI comms in user space is a bad idea and that I am not a smart person:* >
Isnt it funny how when you *may* ask these people who responded to you post they would not offer any assistance. But as soon as you put up working code for something that works for you, Suddenly everyone is offering their "help" Personally, I can see several flaws with using mmap in any situation. But if it works for you, and works well. I say to hell with what anyone else says. So long as it's abstracted, and no one else has to maintain it. I keep seeing the same text from the same person "how very unlinix like of you" or some such garbage. Sorry, I can not disagree more. First of all, mmap was created for a reason. This reason has nothing to do with critiques on user implementation while using it. Secondly, Linux is about freedom, not one individuals "dictatorship" or misconception of what Linux should be. Also, I've seen some implementations many of the commentators of the post you linked to and . . . yeah let us just say that some of the stuff I have seen is far from perfect. So many of them do not have a leg to stand on when it comes to criticizing someone else's implementation. Andrew, anyway you're probably smart enough to not need my encouragement, but I'd encourage you to keep using mmap, while thinking of alternate methods of achieving the same end goal. While again thinking which method might be better and why. Software development is great for constantly keeping our minds busy while learning new techniques, and technologies. There is always something new to learn, and no one amongst us started off by knowing *everything*. On Wed, Oct 8, 2014 at 12:50 PM, Andrew Henderson <[email protected]> wrote: > Well, I have gotten it working before using mmap() calls because I had a > very specific need for it for a proprietary project that I can't share the > code for, but I was informed (in no uncertain terms) that using mmap() for > SPI comms in user space is a bad idea and that I am not a smart person: > > https://plus.google.com/109402916922772242647/posts/YUpRgyD1HME > > Offhand, I'm guessing that you're loading a device tree overlay for SPI > that specifies the driver "spidev" to be in control of the SPI channels. > You're probably hitting the registers correctly in user space, but the > spidev driver is having the power management in the kernel shut down SPI > because the spidev driver hasn't sent a message within the last 2 seconds. > In the kernel source, the drivers/spi/spi-omap2-mcspi.c file has the > function omap2_mcspi_probe(). This function sets up some power management > at the end: > > pm_runtime_use_autosuspend(&pdev->dev); > pm_runtime_set_autosuspend_delay(&pdev->dev, SPI_AUTOSUSPEND_TIMEOUT); > pm_runtime_enable(&pdev->dev); > > As for an example of doing the transfer, you'll want to mimic the code in > the omap2_mcspi_txrx_pio() function in that same file. Ignore the > OMAP2_MCSPI_CHCONF_TURBO paths, as you won't be hitting any of those. > You'll also need to completely avoid mentioning the spidev in the overlay > (only mux the pins) and set all the registers up yourself. Or, you can > shut off the power management in the SPI driver (comment out the > pm_runtime_enable() call), set up SPI via ioctls() to /dev/spidev from > userspace, and then bitbang the registers via mmap(). Either way, > mmap()-ing SPI is possible, but you REALLY need to make sure that there > isn't another way to do what you need to do. > > In short, you should not be doing it this way. But, if you really want to > experiment and learn about the spidev driver in the process, go for it. > > Andrew > > > On Wednesday, October 8, 2014 3:14:28 PM UTC-4, Patrick Sheridan wrote: >> >> Hi Andrew, >> >> I know this is an old forum, but I've been stuck trying approach 2, using >> an mmap to /dev/mem to control the SPI device. Do you know of any working >> examples? >> >> Specifically, I'm trying to write to SPI0[MCSPI_TX0] with SPI0.D0 >> configured for output without using a FIFO, but I typically get nothing--no >> error, but no SPI CLK action either. The CH0STAT register is showing TX to >> be full, but I don't know why the system does not initiate the transfer. >> >> Any example configuration code you have would be greatly appreciated. >> >> Thanks, >> Patrick >> >> On Tuesday, October 15, 2013 9:58:54 PM UTC-4, Andrew Henderson wrote: >>> >>> For SPI, mux the pins in the device tree to enable the SPI0 and or SPI1 >>> interfaces, then reference the Linux kernel documentation: >>> >>> https://www.kernel.org/doc/Documentation/spi >>> https://github.com/piranha32/IOoo/blob/master/src/SPI.cpp >>> >>> I suspect that the "spidev_test.c" file in the kernel or the SPI.cpp is >>> what you are interested in, though the "spidev" file is the documentation >>> on how all each of the pieces work. >>> >>> For GPIO, there are a few places to look: >>> >>> http://www.youtube.com/watch?v=wui_wU1AeQc >>> https://github.com/piranha32/IOoo/blob/master/src/BeagleGoo.cpp >>> http://www.armhf.com/index.php/using-beaglebone-black-gpios/ >>> >>> PWM has been discussed here on the forums: >>> >>> https://groups.google.com/forum/#!category-topic/ >>> beagleboard/beaglebone-black/wjbOVE6ItNg >>> >>> When controlling any of the "built-in" features of the BBB, there are >>> generally one of three approaches that you can take: >>> >>> 1. You can use a kernel device driver to speak directly to the control >>> registers and then control the driver via an ioctl() call on the exposed >>> /dev/* device file(s) for the driver. >>> 2. You can mmap() /dev/mem into your process's memory space and change >>> those registers directly. For bare-metal programming, you would talk >>> directly to the memory-mapped registers this way (but without the mmap()). >>> 3. You can "echo" into and "cat" out of the files in the file system >>> that export out device functionality. For example /sys/device/*, >>> /sys/class/gpio/*, etc. >>> >>> If you have a more specific question as to what exactly you want to do, >>> I'm sure someone here can point you to an appropriate discussion on it that >>> has already happened in the BeagleBoard group. A lot of this material has >>> been discussed quite a bit. But, to answer your original question, I have >>> not heard of a single library that does everything. But, there are a lot >>> of examples of each piece that you can certainly stick together to make one. >>> >>> Andrew >>> >>> >>> On Monday, October 14, 2013 8:15:44 AM UTC-4, Satz Klauer wrote: >>>> >>>> Hi, >>>> >>>> with its (freely programmable) expansion connector BeagleBoard Black >>>> seems to be a perfect thingy for embedded applications. Since I did not >>>> find anything suitable (only a Python library or some JavaScript-based >>>> things which all seem to be way to slow for my usage): >>>> >>>> Is there a (realtime-capable) library available that gives the >>>> possibility to access the expansion header and utilitise it's SPIs, digital >>>> IOs and PWM outputs? With "library" of course every piece of code is meant >>>> whatever is out there (so it can be kernel driver based for existing Linux >>>> variants, bare-metal code, whatever...) >>>> >>>> Thanks! >>>> >>>> -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
