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.
