Comments (6)
I am able to reproduce the issue with this Python script:
import time
import spidev
def init_spi(device):
spi = spidev.SpiDev()
spi.open(0, device)
spi.max_speed_hz = 500000
spi.mode = 0
return spi
spi0 = init_spi(0)
spi1 = init_spi(1)
def read_reg(spi, reg):
return spi.xfer([reg, 0x00])[1]
print("/dev/spidev0.0: 0x%02x" % read_reg(spi0, 0x10)) // 0x10 is the version register on sx1231
print("/dev/spidev0.1: 0x%02x" % read_reg(spi1, 0x10))
spi0.close()
spi1.close()
Prints:
/dev/spidev0.0: 0x24
/dev/spidev0.1: 0x00
from rust-radio-sx127x.
so you're right on all counts, you can't drive the radios from different places (on different SPI bus) because of the lack of bus synchronisation, and you can't run them on the same bus because we don't (currently) have a mechanism to synchronise SPI over transactions (this was dropped from shared-bus
due to unsoundness pending the PRs mentioned below).
the reason the integration test kindof worked is that if you're running both radios from one thread, on one SPI bus, you know there's no pre-emption so the SPI transactions should be both exclusive and in order. i think it should be possible to get this to work, usually 0x00
versions mean there's something wrong with the CS/RST
signals (and a logic analyser is a huuge help here). i haven't dug into the integration tests in some time but, have applications that share the bus in this way reliably enough.
to properly solve this we need to a) be able to express whether a CS pin is managed by the SPI driver (or manually) rust-embedded/embedded-hal#245, and b) to be able to group operations into a single bus operation to ensure consistent ordering rust-embedded/embedded-hal#191, but we haven't quite got to landing these.
wrt. the python script, do bare in mind that you need to explicitly drive CS (or, to configure CS to be driven correctly in the OS / SPI driver), i tend towards the latter as this is more realisable on most embedded devices / works with the above approach more smoothly.
an interim solution would be to implement embedded_spi::Transactional
and embedded_spi::ManagedCS
from here over a newtype containing an Arc<Mutex<(linux_embedded_hal::Spidev, linux_embedded_hal::Pin)>>
, then to use those bounds in the driver (as i have with the sx127/8x ones). i apologise that embedded-spi
is undergoing a bit of flux at the moment as i rework it to be a more generic basis for rust drivers / utilities.
The reason I care is that I want to reuse this great idea of having an integration test for a new sx1231 driver
oh that's exciting~! i've been hoping to need one of these in the near future, and to try and standardise on the configuration of the utilities / tests / etc. for the radio drivers. feel free to ping me with PRs/MRs/anything if it's useful to do so (or you would like a collaborator with a somewhat unfortunate breadth of rf experience) ^_^
from rust-radio-sx127x.
I decided to try something different, and replaced spidev
with bitbang_hal::spi
. Surprisingly, it works like a charm. Maybe something is off with my spidev kernel driver?
from rust-radio-sx127x.
so you're right on all counts, you can't drive the radios from different places (on different SPI bus) because of the lack of bus synchronisation, and you can't run them on the same bus because we don't (currently) have a mechanism to synchronise SPI over transactions (this was dropped from
shared-bus
due to unsoundness pending the PRs mentioned below).the reason the integration test kindof worked is that if you're running both radios from one thread, on one SPI bus, you know there's no pre-emption so the SPI transactions should be both exclusive and in order. i think it should be possible to get this to work, usually
0x00
versions mean there's something wrong with theCS/RST
signals (and a logic analyser is a huuge help here). i haven't dug into the integration tests in some time but, have applications that share the bus in this way reliably enough.to properly solve this we need to a) be able to express whether a CS pin is managed by the SPI driver (or manually) rust-embedded/embedded-hal#245, and b) to be able to group operations into a single bus operation to ensure consistent ordering rust-embedded/embedded-hal#191, but we haven't quite got to landing these.
wrt. the python script, do bare in mind that you need to explicitly drive CS (or, to configure CS to be driven correctly in the OS / SPI driver), i tend towards the latter as this is more realisable on most embedded devices / works with the above approach more smoothly.
The problem I had is that the CS pins are owned by the spidev driver in python so I had to use the hardware support for it.
an interim solution would be to implement
embedded_spi::Transactional
andembedded_spi::ManagedCS
from here over a newtype containing anArc<Mutex<(linux_embedded_hal::Spidev, linux_embedded_hal::Pin)>>
, then to use those bounds in the driver (as i have with the sx127/8x ones). i apologise thatembedded-spi
is undergoing a bit of flux at the moment as i rework it to be a more generic basis for rust drivers / utilities.
This is very cool, definitely will make these things less of an issue in the future. Is the plan to eventually fold in embedded-spi
into embedded-hal
or are there parts that do not fit?
The reason I care is that I want to reuse this great idea of having an integration test for a new sx1231 driver
oh that's exciting~! i've been hoping to need one of these in the near future, and to try and standardise on the configuration of the utilities / tests / etc. for the radio drivers. feel free to ping me with PRs/MRs/anything if it's useful to do so (or you would like a collaborator with a somewhat unfortunate breadth of rf experience) ^_^
I would be happy to include you there, I have previous experience with embedded c++ but is new to both radios and Rust.
Some things can definitely be extracted from the current library, for example it would be nice to have a single util tool for all the rust-radio-hal
drivers to limit the amount of code duplication.
Are there already any MAC/APP layers implemented on top of rust-radio-hal
? I have to build something for my sx1231 radios and it would be nice to have something to reuse/start from.
from rust-radio-sx127x.
This is very cool, definitely will make these things less of an issue in the future. Is the plan to eventually fold in embedded-spi into embedded-hal or are there parts that do not fit?
the intent is that Transactional
and ManagedCS
bits will be replaced by those in embedded-hal, which means a bunch of the other internal traits there could go away, then embedded-spi
will probably become driver-pal
or something and keep / expand on the common stuff for writing drivers and driver utilities w/ support for UART and I2C as well.
Some things can definitely be extracted from the current library, for example it would be nice to have a single util tool for all the rust-radio-hal drivers to limit the amount of code duplication.
hmm, i have been working to extract commonality between the helpers here. it's a wee bit tricky to combine it all because the operation of radios can be pretty different, and it means you now have to update the util every time you ship a new driver, but, it'd also be pretty neat to have.
Are there already any MAC/APP layers implemented on top of rust-radio-hal? I have to build something for my sx1231 radios and it would be nice to have something to reuse/start from.
it is extremely rough and at the moment there's only one rather non-compliant 802.15.4 MAC, but, i've been playing with rust-lpwan with the goal of one day having a standard 802.15.4/6LoWPAN and LoRAWAN stack there.
from rust-radio-sx127x.
heads up i've moved embedded-spi
over to driver-pal
, though we're still stacking too many patches to publish just yet, and the transactional SPI PR has landed to hopefully be released in [email protected]
which should resolve p much all of these.
from rust-radio-sx127x.
Related Issues (18)
- `sx127x-util gfsk tx` hangs indefinitely
- no_std newbie questions HOT 8
- impl Transmit HOT 15
- embedded-hal-1.0.0 examples update HOT 1
- lora_check_receive restart argument HOT 4
- RFM95 enable frontend TX / RX support HOT 5
- embedded-hal version conflicts HOT 12
- Type issue with stm32l1xx_hal HOT 2
- example cannot find its own crate HOT 3
- LoRa examples and testing HOT 18
- dependencies on version of radio confuse embedded-hal-compat HOT 25
- TX_DONE interrupt not firing. HOT 4
- sharing spi? HOT 2
- cargo build --no-default-features fails HOT 4
- README badges needs updating after move to rust-iot
- Question: SPI settings Raspberry Pi 3 B+ Lora HAT HOT 2
- Licensing terms? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rust-radio-sx127x.