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

[Anon Mall]

Hi Peter,

the problem was, that I had to wait for the CC1200 MISO pin to go low, 
after a reset strobe, before setting the chip select pin high again.
I was kind of copying the approach from the CC110X driver 
implementation, where it configures the MISO pin as GPIO, waiting it to 
go low and then configuring the SPI pins again.
Now the problem was, that I could not set and clear the chip select as I 
wanted, due to the problem, that the CC110X driver was doing the chip 
select in software, while configuring the SPI pins would force the 
CC2538 to do the chip select, as you suggested, in hardware. I now 
commented out the reconfiguration of the chip select as hardware, but 
will have to adjust it when the PR is merged. Thanks for the heads-up.

Cheers,
Anon



Date: Mon, 23 Jan 2017 08:36:14 +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: <75435deb-8026-b5b5-3e7b-265f3edb8...@haw-hamburg.de>
> Content-Type: text/plain; charset="utf-8"
>
> 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:
> https://github.com/RIOT-OS/RIOT/pull/4780.
>
> Best
> Peter
>
> Am 16.01.2017 um 13:58 schrieb 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 <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,
>>>>
>>>> 20

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 <anon.m...@gt-arc.com>:
> 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

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

[Peter Kietzmann]

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
>>
> 
> 
> 

-- 
Peter Kietzmann

Hamburg University of Applied Sciences
Dept. Informatik, Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49-40-42875-8426
Web: http://www.haw-hamburg.de/inet
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[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

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

[Antonio Linan]

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