CC1200 Sub-GHz Transceiver


@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



Date: Thu, 12 Jan 2017 12:55:28 +0100 From: Peter Kietzmann <> To: RIOT OS kernel developers <> Subject: Re: [riot-devel] CC1200 Sub-GHz Transceiver Message-ID: <> Content-Type: text/plain; charset="utf-8"


@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 :wink:


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?



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


@Peter: Because we should up to date with transceiver driver if we want RIOT on new product @Anon: I didn't see that you worked on a specific device, thanks for considering it. Since you'll have skills and knowledge about CC1200, it will be easy for you to port CC1350 :slight_smile:

Hi Anon,

yes, according to the "old" (current) SPI architecture the CS handling should be up to you. I'm not sure I completely understood your problem.

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

Does that mean CS is not set to low until the data is shifted to the bus? Does hardware CS exist for the cc2538? Did you prove the GPIO implementation in RIOT (RIOT/tests/periph_gpio)?

FYI this PR will be merged soon:

Best Peter