Re: [riot-devel] CC1200 Sub-GHz Transceiver

[Baptiste Clenet]

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

2017-01-16 13:58 GMT+01:00 Anon Mall :
> 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 
>> To: RIOT OS kernel developers 
>> 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 :
 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



-- 
Baptiste
___
devel mailing list
devel@riot-os.org

[riot-devel] Release 2017.01 status

[Peter Kietzmann]

Dear RIOTers,

we are actively working for the upcoming 2017.01 release
and since last week we already

*merged 59 pull requests, 40 of which were marked for this milestone
*closed 31 issues, 13 of which were marked for this milestone.

This is great progress in my opinion! But we also opened a couple of new
topics. Currently there are still 128 pull requests and 112 open issues
marked for this release. I'd like to motivate all of you developers,
maintainers, authors, and assignees to keep track of pull requests and
issues where you're involved. Please get your code up to date, help
reviewing and testing and move the release milestone for topics that
won't make it this time. Our planned schedule is

*Feature Freeze: Friday, January 20
*Expected Release date: Friday, January 27.

I will silently postpone each pull request/issue that doesn't show any
progress until feature freeze.

Best regards
Peter
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel