search

dsvensson / cc1101

A platform agnostic driver to interface with the CC1101 (Sub-1GHz RF Transceiver)
Apache License 2.0
30 stars 16 forks source link

Wip stuff works #1

Closed dsvensson closed 6 years ago

dsvensson commented 6 years ago

Not really a serious pull request, but src/lib.rs stuff could perhaps be merged sooner or later. any ideas?

I don't like the set_defaults() part, but it seems pretty common that CC1101 projects use that. Ideally it would be a number of calls to the public APIs to setup everything with some sane-isch defaults. Not sure what's best. Please comment. I'm moving on to decoding my payload that I can receive now :)

...a ton of API questions awaits.

Sample use: https://github.com/dsvensson/sparsnas-rs

Ideally the register interactions ought to be changed to something like how RTFM (or some lower lever crate) does it, which would make the set_defaults readable. Sample code from a random project:

    let cp = cortex_m::Peripherals::take().unwrap();
    let dp = stm32f103xx::Peripherals::take().unwrap();

    let mut flash = dp.FLASH.constrain();
    let mut rcc = dp.RCC.constrain();

    // Try a different clock configuration
    let clocks = rcc.cfgr.freeze(&mut flash.acr);
    // let clocks = rcc.cfgr
    //     .sysclk(64.mhz())
    //     .pclk1(32.mhz())
    //     .freeze(&mut flash.acr);

    let mut gpioc = dp.GPIOC.split(&mut rcc.apb2);

    let mut led = gpioc.pc13.into_push_pull_output(&mut gpioc.crh);
    // Try a different timer (even SYST)
    let mut timer = Timer::syst(cp.SYST, 1.hz(), clocks);
    loop {
        block!(timer.wait()).unwrap();
        led.set_high();
        block!(timer.wait()).unwrap();
        led.set_low();
    }

The stm32f103xx uses svd2rust tool to generate the code. Should investigate if TI has some similar description for CC1101, and see if it's possible to generate something useful from it. Worst case; scrape it from the PDF documentation.

To get read_burst working, I removed the first write() and passed the address in the buffer to transfer. While this works, I'm not sure if it's so nice to return the buffer like that, but at the same time, I don't want to copy the data. Input on that would be cool.

...and GDO2 needs to be passed into the constructor as well for status checks.

fmckeogh commented 6 years ago

This looks really great, the Travis CI is only failing due to the xargo -> cargo merge, I'll try and fix this asap.

I think set_defaults is sensible, and I agree, RTFM compatibility/design-in-mind is very important.

As for API structuring, I was pretty lost myself on account of the wide range of use cases of the CC1101.

For example, a remote control, live sensor data or any mono-directional setup just needs as short as possible packet send procedure, and then the receiver can worry about interrupts and message handling. However, if it was being used as a longer range network connection, needing to verify packets, and sending ack responses would also be useful.

Is write_burst working for you? The C equivalent would be initialising a new array with the first element being the command, and subsequent elements being the input array, but Rust is (obviously) very unhappy about this.

I agree about the GDO0/1/2, but I'm afraid I don't know how to do that. :(

I have my A level exams for the next few months, so I really won't have much time to contribute. Can I give you the CC1101 crates.io crate name and make your repo the default?

:)

dsvensson commented 6 years ago

I'd be happy to run it, and I hope you get some time to work on it as well later on. My use case for IKEA Sparsnäs is completly passive, so I'm not transmitting anything.