I am staring down a rabbit hole and wondering if it’s going to be worth it. I have a Dragino LORA/GPS hat. The LORA bit is SPI. There is a nice library (a fork of RadioHead) where I can just implement an SPI driver, but it’s a few notches above my pay grade. I successfully took some bbb SPI code and the spi_scan that comes with the RadioHead library to query a register and get a version off the device. That’s a far cry from cutting into the code and making a new hardware driver for the BBB.
What I’m most interested in are the ways I can access the SPI devices. I notice for the raspberry pi driver they’re using a hardware library with function calls like this:
`
bcm2835_spi_setDataMode(mode);
`
For my test I used /dev/spidev0.0 with the ioctl and SPI_IOC_MESSAGE. Will I have to write ioctl functions like these or is there a hardware library I can leverage:
`
fd = open(SPI_PATH, O_RDWR);
ioctl(fd, SPI_IOC_WR_MODE, &mode);
…
`
I am up for a challenge but I do not want to try and replicate library functions if they exist. I looked at the Adafruit-beaglebone-io-python lib as it has SPI functions (and I might just try to use that) but it seems they, too, are using ioctl.
Hi Dave,
As a possible option, see here for a combined GPIO, I2C and SPI library:
https://www.element14.com/community/community/designcenter/single-board-computers/next-genbeaglebone/blog/2019/08/15/beaglebone-black-bbb-io-gpio-spi-and-i2c-library-for-c-2019-edition
This library does not use ioctl, it uses direct register calls internally, so it is fast.
In a nutshell it exposes a function called spi_transact. You call it passing in the byte to transmit and the pointer to a byte for the received value, and it performs the SPI interaction.
It can be used in a loop to perform multiple byte tx or rx transfers.
It’s very basic, it is up to the user to store the bytes into an array or handle any conversions.
As for support for the library… I can’t support the code much, I have other work too, but if it is a quick question I can try to answer it. It’s not mega-complicated, but some C knowledge, maybe even a 'scope or logic analyzer may be needed to use and troubleshoot (not saying there will be issues to require this, but just want to pre-empt it).
Another thing is that working with radio devices can (sometimes) be non-trivial. The reason is, some radio events may occur asynchronously. Code may need to be multi-threaded to handle this. It’s sometimes not as easy as ‘fire-and-forget’ so the code needs to implement a state machine to bring up a radio module, transmit, wait for a response, maybe retransmit upon some timer expiry, and so on. I don’t know if the LoRa chip or module does that automatically or if the user is expected to implement such things in software.
Note, the code that shbaz has been pushing has not been touched for 6 years or so and has issues unresolved since 2014 so who knows what kernel it was used for.
Thus, use it at your own peril.
Here is the link to save having to look through the Element14 page for it.
https://github.com/VegetableAvenger/BBBIOlib
Jon
Thanks both of you. This gives me something to go on at least. I’m thinking if I can get something workable I can get it over to the RadioHead maintainer and maybe they can clean it up if they’ve been getting any queries.
Nonsense.
If you checked the date, you’ll see I updated it in October.
I don’t really care if you use it or not.
Hi Dave,
That’s great, looking forward to your results. I’ve LoRa board (Semtech chipset) that I’ve been trying to construct for a while, but have no code written for currently.