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.kietzmann@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-507aee8e3da4@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
Anon, you should try to work on CC1350 which is the last one
Cheers,
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
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
?
