Re: [riot-devel] Atxmega Port with RIOT OS - Where to put abundance of new driver features?

[Madison McCarthy]

Hi Hauke and Arndt,

*Hauke:* your answer is sufficient for me to progress forward, thanks a
bunch! My main concern has about adding additional functionality such as
interrupts, slave mode, etc. into already defined RIOT peripheral headers.
I'll locate the new features that are not encapsulated within the RIOT-core
or RIOT-drivers as device-specific functionality for now.

*Arndt:* I'll message you directly about collaborating on an Atxmega port
that can be pushed to the RIOT repository. I'll finish my port first (1-2
days hopefully) before I examine your port so we can blend the two products
together into something worth sharing :)

Thanks again!

Madison McCarthy



On Tue, Dec 12, 2017 at 6:35 AM, Hauke Petersen  wrote:

> Hi Madison,
>
> awesome to hear about your port, it will be very nice to have ATxmega
> support in RIOT. I will try to answer your questions inline below.
>
> On 11.12.2017 22:04, Madison McCarthy wrote:
>
>> Hi Everyone,
>>
>> I'm nearing completion of a port for RIOT OS to the ATxmega family of
>> devices (targeting the atxmega128). The Atxmega is feature rich when
>> contrasted against the Atmega counterpart which I am using as a porting
>> guideline.
>>
>> 1) Since I would like to contribute my port to the git repository, how
>> should I go about implementing new CPU features not found in the core RIOT
>> OS functionality (enhanced TWI, USART, etc.)?
>>
> I don't quite get the question. TWI (i2c) and UART are interfaces provided
> by RIOT, which are simply implemented by the specific CPU implementations,
> hence their implementation code should reside in the corresponding cpu
> folder (as in /cpu/atxmega_common/periph/uart.c, etc.).
>
>>
>> 2) How should I implement the addition of both Master and Slave
>> functionality to my peripheral interfaces?
>>
> For the master mode of SPI and I2C (TWI) there are interfaces designed by
> RIOT (-> drivers/include/periph/[spi|i2c].h). So simply implement them
> for the ATxmega and you should be good to go.
>
> Currently there are no interfaces for the slave mode of these buses, so my
> proposal would be that you include slave interfaces together with the CPU
> code (so to make the slave implementations CPU specific for now), and adapt
> the code at a later point in time once we introduce slave interfaces to
> RIOT.
>
>>
>> 3) How should I go about adding interrupt functionality for these
>> peripherals?
>>
> Not sure what you mean: peripheral specific interrupts should be handled
> inside the corresponding periph drivers. The global interrupt handling is
> abstracted by the core/include/irq.h interface, which needs to be
> implemented for the CPU family.
>
> Hope this information helps, let me know where clarification is needed!
>
> Cheers,
> Hauke
>
>
>>
>> Currently I am just smashing these extra features right into the driver's
>> .C files as I am trying to preserve the OS-Core files.
>>
>> Any suggestions would be appreciated!
>>
>> Madison McCarthy
>>
>>
>> ___
>> 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

Re: [riot-devel] Atxmega Port with RIOT OS - Where to put abundance of new driver features?

[Hauke Petersen]

Hi Madison,

awesome to hear about your port, it will be very nice to have ATxmega 
support in RIOT. I will try to answer your questions inline below.


On 11.12.2017 22:04, Madison McCarthy wrote:

Hi Everyone,

I'm nearing completion of a port for RIOT OS to the ATxmega family of 
devices (targeting the atxmega128). The Atxmega is feature rich when 
contrasted against the Atmega counterpart which I am using as a 
porting guideline.


1) Since I would like to contribute my port to the git repository, how 
should I go about implementing new CPU features not found in the core 
RIOT OS functionality (enhanced TWI, USART, etc.)?
I don't quite get the question. TWI (i2c) and UART are interfaces 
provided by RIOT, which are simply implemented by the specific CPU 
implementations, hence their implementation code should reside in the 
corresponding cpu folder (as in /cpu/atxmega_common/periph/uart.c, etc.).


2) How should I implement the addition of both Master and Slave 
functionality to my peripheral interfaces?
For the master mode of SPI and I2C (TWI) there are interfaces designed 
by RIOT (-> drivers/include/periph/[spi|i2c].h). So simply implement 
them for the ATxmega and you should be good to go.


Currently there are no interfaces for the slave mode of these buses, so 
my proposal would be that you include slave interfaces together with the 
CPU code (so to make the slave implementations CPU specific for now), 
and adapt the code at a later point in time once we introduce slave 
interfaces to RIOT.


3) How should I go about adding interrupt functionality for these 
peripherals?
Not sure what you mean: peripheral specific interrupts should be handled 
inside the corresponding periph drivers. The global interrupt handling 
is abstracted by the core/include/irq.h interface, which needs to be 
implemented for the CPU family.


Hope this information helps, let me know where clarification is needed!

Cheers,
Hauke




Currently I am just smashing these extra features right into the 
driver's .C files as I am trying to preserve the OS-Core files.


Any suggestions would be appreciated!

Madison McCarthy


___
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

Re: [riot-devel] Atxmega Port with RIOT OS - Where to put abundance of new driver features?

[Arndt, Josua]

I just pushed it to my repo as it is, so you can have a look.

https://github.com/Josar/RIOT_XMEGA

I would suggest to implement the common functionality in the atxmega_common 
folder.
I have done the gpio, timer anf the uart but spi is still hard coded to my 
platform.

Von: devel [mailto:devel-boun...@riot-os.org] Im Auftrag von Arndt, Josua
Gesendet: Dienstag, 12. Dezember 2017 11:00
An: RIOT OS kernel developers 
Betreff: Re: [riot-devel] Atxmega Port with RIOT OS - Where to put abundance of 
new driver features?

I have a working port of an atxmega256a3u

I started to port it to a common folder maybe we could work something out
Von: devel [mailto:devel-boun...@riot-os.org] Im Auftrag von Madison McCarthy
Gesendet: Montag, 11. Dezember 2017 22:04
An: devel@riot-os.org
Betreff: [riot-devel] Atxmega Port with RIOT OS - Where to put abundance of new 
driver features?

Hi Everyone,

I'm nearing completion of a port for RIOT OS to the ATxmega family of devices 
(targeting the atxmega128). The Atxmega is feature rich when contrasted against 
the Atmega counterpart which I am using as a porting guideline.

1) Since I would like to contribute my port to the git repository, how should I 
go about implementing new CPU features not found in the core RIOT OS 
functionality (enhanced TWI, USART, etc.)?

2) How should I implement the addition of both Master and Slave functionality 
to my peripheral interfaces?

3) How should I go about adding interrupt functionality for these peripherals?


Currently I am just smashing these extra features right into the driver's .C 
files as I am trying to preserve the OS-Core files.

Any suggestions would be appreciated!

Madison McCarthy
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Whether RIOT can achieve wireless ICN communication

[Emmanuel Baccelli]

Hi there,

RIOT supports CCN-lite and NDN stacks, which are both offering ICN
capabilities over low-power wireless networks as demonstrated in [1][2][3]
among others.

For preliminary instructions/tutorial on how to use these stacks see [4]
[5].

The boards supported by RIOT are listed there [6]. Obviously, pick a board
that has a radio.
For starters you could use open access testbeds such as IoT-lab [7] [8].

Cheers,

Emmanuel

[1] https://arxiv.org/pdf/1406.6608.pdf
[2] https://named-data.net/wp-content/uploads/2017/03/ndn-
0043-2-ndn-riot.pdf
[3] https://pdfs.semanticscholar.org/768f/ead874324f3d1d5179ce42ad5b8c80
7710b8.pdf
[4] see task 8 in https://github.com/RIOT-OS/Tutorials
[5] https://github.com/named-data-iot/ndn-riot
[6] https://github.com/RIOT-OS/RIOT/tree/master/boards
[7] https://www.iot-lab.info
[8] https://www.researchgate.net/profile/Emmanuel_Baccelli/
publication/282667659_FIT_IoT-LAB_A_large_scale_open_
experimental_IoT_testbed/links/569d138608ae78356e563f23.pdf

On Tue, Dec 12, 2017 at 9:05 AM, 侯 宁博  wrote:

> Hi，I start to learn RIoT just now.
>
> I want to apply it in real environment. So I want to know whether RIOT can
> achieve wireless ICN communication.
>
> Besides,what hardware RIoT support? Do I need configure the
> hardware clock on my own when I develop programs, or just need write C
> program like in linux?
>
> Thanks a lot.
>
>
>
>
>
> 发送自 Windows 10 版邮件 应用
>
>
>
> ___
> 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

Re: [riot-devel] Atxmega Port with RIOT OS - Where to put abundance of new driver features?

[Arndt, Josua]

I have a working port of an atxmega256a3u

I started to port it to a common folder maybe we could work something out
Von: devel [mailto:devel-boun...@riot-os.org] Im Auftrag von Madison McCarthy
Gesendet: Montag, 11. Dezember 2017 22:04
An: devel@riot-os.org
Betreff: [riot-devel] Atxmega Port with RIOT OS - Where to put abundance of new 
driver features?

Hi Everyone,

I'm nearing completion of a port for RIOT OS to the ATxmega family of devices 
(targeting the atxmega128). The Atxmega is feature rich when contrasted against 
the Atmega counterpart which I am using as a porting guideline.

1) Since I would like to contribute my port to the git repository, how should I 
go about implementing new CPU features not found in the core RIOT OS 
functionality (enhanced TWI, USART, etc.)?

2) How should I implement the addition of both Master and Slave functionality 
to my peripheral interfaces?

3) How should I go about adding interrupt functionality for these peripherals?


Currently I am just smashing these extra features right into the driver's .C 
files as I am trying to preserve the OS-Core files.

Any suggestions would be appreciated!

Madison McCarthy
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Whether RIOT can achieve wireless ICN communication

[侯 宁博]

Hi，I start to learn RIoT just now.
I want to apply it in real environment. So I want to know whether RIOT can 
achieve wireless ICN communication.
Besides,what hardware RIoT support? Do I need configure the hardware clock on 
my own when I develop programs, or just need write C program like in linux?
Thanks a lot.


发送自 Windows 10 版邮件应用

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