> From: [email protected] [mailto:[email protected]] On > Behalf Of Dennis Lee Bieber > On Fri, 21 May 2021 09:39:34 -0700, in gmane.comp.hardware.beagleboard.user > "John Dammeyer" <[email protected]> wrote: > > >static const char *device = "/dev/spidev1.0"; > > fd = open(device, O_RDWR); > > if (fd < 0) > > pabort("can't open device"); > > > >One of two things happen. Either It opens the SPI bus which includes > >everything that config-pin does or it fails because config-pin > wasn't done. > > Hypothesis: The "device" (driver) is loaded -- but the pin-mux does not > have the pins connected to the internal port(s) used by the driver... So > the driver is basically dumping output into the "bit-bucket". > > It can't really take control -- since the same pins are used by I2C > mode, if opening the "device" did the pin-mux one could really mess up data > transfers (open "I2C" start transfer, then open SPI using the same pins). > Hmmm. The open() function returns a handle. If it's open already I don't believe the OS allows (or should allow) another task to open the same file. So a hardware device is not like a read only file that can be opened more than once. It's an _exclusive_ r/w phantom file that uses specific code to access it.
This is a standard requirement for any sort of RTOS that requires access to a scarce resource. Since the hardware is a scarce resource both the SPI and I2C and even GPIO need to be 'acquired'. Pascal has a technique for that called assignfile() https://smartpascal.github.io/help/assets/assignfile.htm Let's call it AssignIO(). This requests and locks the scarce resource in prep for an open. Odds are unless you have some fancy hardware multiplexing it would stay assigned for the entire program. But nothing stops you from doing a ReleaseIO() and then setting a GPIO bit to mux in the I2C logic and then an AssignIO() for the I2C. This is all fairly standard RTOS stuff. John > >> debian@beaglebone:~$ cat /sys/module/spidev/parameters/bufsiz > >> 4096 > >> debian@beaglebone:~$ > > > >How did you know to look at this file to determine the SPI buf size? > > https://www.kernel.org/doc/Documentation/spi/spidev > """ > - There's a limit on the number of bytes each I/O request can transfer > to the SPI device. It defaults to one page, but that can be changed > using a module parameter. > > - Because SPI has no low-level transfer acknowledgement, you usually > won't see any I/O errors when talking to a non-existent device. > """ > > along with the source for the Python spidev module, which explicitly > mentions that parameter... Though just doing > > sudo find / -iname "spidev" > > and exploring what each result contains (or to bypass one layer) > > debian@beaglebone:~$ ls -R `sudo find / -iname "spidev"` > /sys/bus/spi/drivers/spidev: > bind module spi0.0 spi0.1 spi1.0 spi1.1 uevent unbind > > /sys/class/spidev: > spidev0.0 spidev0.1 spidev1.0 spidev1.1 > > /sys/devices/platform/ocp/48030000.spi/spi_master/spi0/spi0.0/spidev: > spidev0.0 > > /sys/devices/platform/ocp/48030000.spi/spi_master/spi0/spi0.0/spidev/spidev0.0: > dev device power subsystem uevent > > /sys/devices/platform/ocp/48030000.spi/spi_master/spi0/spi0.0/spidev/spidev0.0/power: > async runtime_active_kids runtime_status > autosuspend_delay_ms runtime_active_time runtime_suspended_time > control runtime_enabled runtime_usage > > /sys/devices/platform/ocp/48030000.spi/spi_master/spi0/spi0.1/spidev: > spidev0.1 > > /sys/devices/platform/ocp/48030000.spi/spi_master/spi0/spi0.1/spidev/spidev0.1: > dev device power subsystem uevent > > /sys/devices/platform/ocp/48030000.spi/spi_master/spi0/spi0.1/spidev/spidev0.1/power: > async runtime_active_kids runtime_status > autosuspend_delay_ms runtime_active_time runtime_suspended_time > control runtime_enabled runtime_usage > > /sys/devices/platform/ocp/481a0000.spi/spi_master/spi1/spi1.0/spidev: > spidev1.0 > > /sys/devices/platform/ocp/481a0000.spi/spi_master/spi1/spi1.0/spidev/spidev1.0: > dev device power subsystem uevent > > /sys/devices/platform/ocp/481a0000.spi/spi_master/spi1/spi1.0/spidev/spidev1.0/power: > async runtime_active_kids runtime_status > autosuspend_delay_ms runtime_active_time runtime_suspended_time > control runtime_enabled runtime_usage > > /sys/devices/platform/ocp/481a0000.spi/spi_master/spi1/spi1.1/spidev: > spidev1.1 > > /sys/devices/platform/ocp/481a0000.spi/spi_master/spi1/spi1.1/spidev/spidev1.1: > dev device power subsystem uevent > > /sys/devices/platform/ocp/481a0000.spi/spi_master/spi1/spi1.1/spidev/spidev1.1/power: > async runtime_active_kids runtime_status > autosuspend_delay_ms runtime_active_time runtime_suspended_time > control runtime_enabled runtime_usage > > /sys/module/spidev: > coresize holders initstate parameters sections uevent > drivers initsize notes refcnt taint > > /sys/module/spidev/drivers: > spi:spidev > > /sys/module/spidev/holders: > > /sys/module/spidev/notes: > > /sys/module/spidev/parameters: <<<<< > bufsiz > <<<<< > > /sys/module/spidev/sections: > __jump_table __mcount_loc __param __verbose > debian@beaglebone:~$ > > > > -- > Dennis L Bieber > > -- > 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/v2pgag101omfhqgj1h5p4o03b3ilskegli%404ax.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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/00da01d74eb3%244a31a900%24de94fb00%24%40autoartisans.com.
