The instructions mentioned to-do-that, but not how-to-do that. So I skipped it not understanding what it was talking about. Changing Makefiles is something a new user generally refrains from doing.
I think the tuturial would be better with the 'default.elf' filename and one less step. In the advanced class, they can learn how to change the program name. Starting off I'm not sure they care. Just my opinion.
Regards
David
Hello,
Well I had fun getting my first riot program going. Now I want to connect that to the rest of the world. Well other machines.
I can see that my RIOT program can receive data.
But how would I send it from another machine that is not on TAPI? or communicate with a Linux box that's not running Linux?
Regards
David
Hi David,
Well I had fun getting my first riot program going. Now I want to connect that to the rest of the world. Well other machines.
I can see that my RIOT program can receive data.
But how would I send it from another machine that is not on TAPI? or communicate with a Linux box that's not running Linux?
In theory, the "TAP" (mind there's no trailing "I") interface could be bridged to an Ethernet interface and your program could talk to the internet. There are several pieces missing for that use case in the RIOT master tree. Most importantly there is no regular IPv6 stack but only sixlowpan as far as I know.
The use case for native so far has been: You can take the same application and build it for your real board, e.g.: make BOARD="arduino-due"
The same goes for the nativenet protocol and its use of tap interfaces. It has been designed to provide a means for network simulation that is readily available and compatible with the rest of RIOT.
I hope some of the network people will provide more information as I think there are several projects that might provide missing pieces for your use case.
Cheers, Ludwig
Hi David,
Ah ok.
Well it would be really handy to have some sort of defined packet/communication interface. Maybe it wasn't important in the past but for real projects it would be.
The way I see it as an application developer is that I would want to transfer information (lines of text work nicely) in a similar way to the way MQTT works with Publish/Subscribe channels.
Then be able to plug in the communications device, ie Bluetooth/nRF24L01/433Mhz and have that work. Optionally wifi of course.
On most embedded systems, you wouldn't get 'drivers' for these. If if you did they would be drivers to cater to the individual capabilities of the devices.
So I'm submitting that some common wifi devices be picked up, "driverfied" and a simple Mosquitto style programming interface be provided to make accessing the hardware easier so that it can be used.
It could be that this is already done to some degree. So it would only just be a matter of expanding the system here and there to make things play with others more nicely.
Regards
David
Hi David,
RIOT does support sockets, only you can't hook up a native instance to the regular internet right now.
For example: to use sixlowpan you would need a border gateway router. AFAIK there is currently none for native.
I was just looking through the code and there seems to be a lot of focus on IPV6. ie https://github.com/RIOT-OS/RIOT/blob/master/sys/net/include/sixlowpan/ip.h
What I'd suggest though is just consider using IPV4 UDP broadcasts or some other simple network protocol to get basic network functionality going with the same/similar API as you have already.
That would allow the first example shown in your docs to work across machines. Which is what people would expect to see - but keep the API that you've developed as is. I'm suggesting resist the urge (that other systems do) to add a different API for each type of transport layer.
I'm just sharing my observations as a newcomer.
Thank you for listening.
Regards
David