Hi David,
I just wanted to add that it would be a really easy entry point for us hackers if we could use an Atmega328p based system + nrf24L01+ modules and do some sort of communication with those.
The Atmega328p [1] apparently has 2K of RAM. After RIOT and the radio driver there won't be much space left for any application let alone a proper network stack.
The nrf is on our todo list though.
Cheers, Ludwig
1: http://www.atmel.com/devices/atmega328p.aspx?tab=parameters
Hi David,
Hi David,
I just wanted to add that it would be a really easy entry point for us hackers if we could use an Atmega328p based system + nrf24L01+ modules and do some sort of communication with those.
The Atmega328p [1] apparently has 2K of RAM. After RIOT and the radio driver there won't be much space left for any application let alone a proper network stack.
we have currently a student group working on porting RIOT to the Atmega 2560 (Arduino Mega), though. The project runs for a few more weeks but the results seem to be promising - maybe watch the incoming pull requests.
The nrf is on our todo list though.
A driver for the nrf24l01(+) is also be worked on, stay tuned...
Cheers, Hauke
The Atmega328p [1] apparently has 2K of RAM.
That much? 
But I think the main consideration is program flash area which is 32K if I'm not mistaken.
After RIOT and the radio driver there won't be much space left for any application let alone a proper network stack.
Well, these days that's common and one solution that seems to be often used is to have an mcu on the radio-transmitter and connect over with serial/spi link. In Bluetooth, it's done a lot like that.
The nrf is on our todo list though.
Excellent.
Any idea's on Bluetooth?
Regards
David
Hi,
since I am one of the students from the group porting RIOT to AVR (in our case the Arduino Mega 2560 (Atmega2560). Right now we have task switching and our next step will be to get most of the driver interfaces implemented (UART is nearly done, proper timers, GPIO and LPM are still missing). The task switching part should be usable on other Atmegas too. If you want to take a look at the (work in progress) code you can check out the develop branch
https://github.com/N8Fear/RIOT.git
You should keep in mind that the code as a whole isn't in a ready to use state, the branch will be subject to rebases on the official RIOT master and so on... So consider it a sneak peak if you like.
WKR, Hinnerk
Nice! Keep up the good work.
Regards
David
Hi,
since I am one of the students from the group porting RIOT to AVR (in our case the Arduino Mega 2560 (Atmega2560). Right now we have task switching and our next step will be to get most of the driver interfaces implemented (UART is nearly done, proper timers, GPIO and LPM are still missing).
If it worked for other people, I'd gently suggest the following work order:
1) - Arduino Mega 2560 core port 2) - Transceiver module 3) - nrf24L01 (driver) 4) - serial 5) - gpio 6) - task-switching.
As a project follower, I can only suggest a work-order like this.
The main reason for suggesting this order is to focus on having something that could be quickly utilised by a typical user.
A user could quickly send/receive a packet and make the LED go on/off. That would be well on the way to more useful applications.
The only reason I'm suggesting the nrf24L01+ is that they are widely available and inexpensive.
Regards
David
Hi,
Hi,
since I am one of the students from the group porting RIOT to AVR
(in
our case the Arduino Mega 2560 (Atmega2560). Right now we have task switching and our next step will be to get
most
of the driver interfaces implemented (UART is nearly done, proper timers, GPIO and LPM are still missing).
If it worked for other people, I'd gently suggest the following work order:
1) - Arduino Mega 2560 core port 2) - Transceiver module 3) - nrf24L01 (driver) 4) - serial 5) - gpio 6) - task-switching.
As a project follower, I can only suggest a work-order like this.
As a developer I can only suggest otherwise.
6 is part of 1. RIOT is not called an OS for the lulz. Without threads there's no application. Also, it's already done...
2 is part of RIOT, no need to implement.
Without 4, testing 3 could prove very tiresome.
BTW: What about SPI?
Cheers, Ludwig
Hey guys,
maybe it's time to introduce myself after the last discussions about SPI and nRF24L01 drivers. I'm the new employees at HAW Hamburg and I'm going to implement the low-level SPI driver with the interface proposed by Hauke Petersen one or two weeks ago. The platform I'm working with is stm32f4 board. When the SPI stuff works I can develope the driver for tranceiver module nRF24L01.
Best regards, Peter
Hi Peter,
maybe it's time to introduce myself after the last discussions about SPI and nRF24L01 drivers. I'm the new employees at HAW Hamburg and I'm going to implement the low-level SPI driver with the interface proposed by Hauke Petersen one or two weeks ago. The platform I'm working with is stm32f4 board. When the SPI stuff works I can develope the driver for tranceiver module nRF24L01.
welcome aboard! Cool, that you're working on the SPI driver for this board. That will open a bunch of new possibilities for RIOT on this board.
Looking forward to see the PR.
Cheers, Oleg
Hi Oleg,
Peter hatte Dich nach Deiner (super ?) Bezugsquelle f�r die Dinger gefragt ... magst Du uns die ASAP schicken? Ich w�rde n�mlich gerne die Bestellung heute noch hochgeben, da ich morgen weg bin ...
DANKE!
Thomas