Hi, @Baptiste: I am currently working with a Remote and a Firefly, so implementing the CC1350 won't do me much good for now. But I will consider it once I am finished ;-).
@Peter: Okay I will see how far I'll get by extending the CC110X driver and will switch to standalone driver if it gets too tedious. An other question concerning the RIOT SPI implementation. According to the CC1101 and CC1200 datasheet, both chips require the chip-select line to wait for the MISO line to go low, before switching back to high, when a reset command is issued. I tried implementing it by having the driver wait for the MISO line after calling spi_transfer_byte(...), but my logic analyzer shows, that chip select is set after calling the function and before the MISO line is back to low, even though It should be busy waiting. I have tried an isolated SPI test, but the symptoms are the same. Also when I just stop the code after clearing the chip-select but before spi_transfer_byte(...) my logic analyzer shows, that the chip-select is not triggered at all. Is there some deeper connection between the chip select and the SPI driver I don't know? I believe that clearing and setting the chip select would be my responsibility, while transferring data over the bus is done by the SPI driver. Hopefully I could explain my problem understandable enough Cheers, Anon > Date: Thu, 12 Jan 2017 12:55:28 +0100 > From: Peter Kietzmann <peter.kietzm...@haw-hamburg.de> > To: RIOT OS kernel developers <devel@riot-os.org> > Subject: Re: [riot-devel] CC1200 Sub-GHz Transceiver > Message-ID: <94c91607-4dd7-3e72-7af3-507aee8e3...@haw-hamburg.de> > Content-Type: text/plain; charset="utf-8" > > Hi, > > @Baptiste: How did the CC1350 get into this round :-)? Is it similar to > the other mentioned radios? In any way, I would be pretty happy to see > support for that radio in RIOT. It would enhance the current SensorTag > support significantly. > > @Anon: I have no idea about the differences between CC1101 and CC1200 > (and CC1350). Whenever possible we try to avoid code duplication so if > you think it's easily 'possible' so extend the CC1101 driver, you should > go that way. If that means `#ifndef CC1200` in every second code line, > you should probably avoid it and write a standalone driver. > > Cheers > Peter > > > > Am 10.01.2017 um 19:14 schrieb Baptiste Clenet: >> Anon, you should try to work on CC1350 which is the last one ;-) >> >> Cheers, >> >> 2017-01-10 11:32 GMT+01:00 Anon Mall <anon.m...@gt-arc.com>: >>> Dear all, >>> >>> thanks for the reply >>> >>> >>> >>> @Peter: I will then put it into the driver section, as you have suggested. >>> >>> >>> >>> @Antonio: Thanks for the offer. I will surely take you up on that. >>> >>> >>> >>> Also a small question concerning the location of the driver. The CC1200 uses >>> >>> the same command strobes on the SPI like the CC1101. As there is already a >>> >>> CC110X driver implemented, should the CC1200 be added to that implementation >>> >>> and transceiver specific code just capsuled as defines or would a standalone >>> driver >>> >>> make more sense? >>> >>> >>> >>> Cheers, >>> >>> Anon >>> >>> >>> >>>> Hello Anon! >>>> If you need help (as in devices with the CC1200 on board) drop me a line >>>> Cheers, >>>> --Antonio >>>>> Hi Anon, >>>>> it seems no one is working on this driver so please go ahead :-)! As >>>>> long as the CC1200 is not part of the CC2538 I agree with you the the >>>>> driver should be implemented stand alone. Compare e.g. the at86rf2xx >>>>> driver. >>>>> Best >>>>> Peter >>>>> Am 21.12.2016 um 18:41 schrieb Anon Mall: >>>>>> Hi all, >>>>>> I wanted to ask if someone is currently working on a driver for the >>>>> CC1200 transceiver? Otherwise I would try my luck. >>>>>> Also in the readme of the Remote is noted, that the CC1200 is a >>>>>> matter >>>>> of the CC2538 base. As the transceiver is not included in the CC2538, >>>>> I would think that the driver should rather be implemented stand alone >>>>> or am I mistaken? >>>>>> Cheers and happy Holidays, >>>>>> Anon >>> >>> >>> >>> _______________________________________________ >>> devel mailing list >>> devel@riot-os.org >>> https://lists.riot-os.org/mailman/listinfo/devel >>> >> >> ? _______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
