Hello,
Some month ago, I made an experiment to make my personal robot work with RIOT. I should have done this sooner, but I just made a small document that describes how I did that : https://github.com/astralien3000/test_riot_buggybot/wiki/From-AversivePlusPlus-to-RIOT
I was wondering if it was worth adding this to the RIOT's wiki. Maybe it is not complete enough. What do you think ?
Cheers,
Loïc
Helle to all developers, I'm at the moment debugging a new netdev2-radio-module driver and while debugging I have seen a mysterious behaviour - maybe it's that I have not a complete understanding about the netdev2 structur. As far as I've seen the transmission of a frame ist done in the <driver-name>_send(..) function (e.g. at86rf2xx_send(..)). The process is splitt into three phases .._tx_prepare(dev), .._tx_load(dev, data, len,0) and .._tx_exec.
The phase of interest for me is at the moment the .._tx_load(..) step. In the function _send we see that the .._tx_load(..) is involked inside the for-look to build the transmit frame date.
Now my thought: the loop fills the transmit buffer. Logically for me the frame will be filled step by step - second part of the frame following the first part without address overlapping or gap - is this correct.
The mysterious thing I see is as follows: The second loop pass is overwriting the end of the first "loop-data" . The third loop access is overwriting the end of the second FIFO-access and so on......
Could this be a valid behaviour?
Best regards, Neo
Hi Loïc,
your experiment to substitute Aversive++ with RIOT as HW abstraction looks great to me. Its nice to see an example of coordinated actuators steered by a remote wireless RIOT node. Actually I would love to see your robot running on the ground. I think its a really nice example for a one hop and one way communication between nodes, and It might give a good impression of the RIOT hardware abstraction possibilities (Similar to the RC car example of @haukepetersen [1]).
> I was wondering if it was worth adding this to the RIOT's wiki. Maybe it is not complete enough. What do you think ?
IMHO I think the RIOT wiki would not be the right place for it. Some time ago we also made an example project [2] which is also not present in the wiki pages of RIOT. One reason why its not there is that it "just" uses a bunch of documented and described features provided by RIOT, such as RPL, CoAP etc. The other and even more important reason is that the blog offers a lot of additional and, regarding the RIOT wiki, redundant information which could confuse a new user searching for specific help on a topic.
I think if you could give more details on migrating from Aversive++ to RIOT, like give a step by step guide for someone that wants to move to RIOT but does not know how to begin, it could perfectly fit in the RIOT wiki. Maybe something comparable to [3].
Best regards,
Martin
[1] https://github.com/haukepetersen/Petabot [2] http://watr.li/ [3] https://github.com/RIOT-OS/RIOT/wiki/How-to-install-6LoWPAN-Linux-Kernel-on-Raspberry-Pi
Hi Neo,
has it already clarified? I'm not sure I got the problem, but let's have a look at the following code lines.
https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx.c#L202
at86rf2xx_tx_load() is called with an offset parameter and it writes the SRAM at position offset+1. The function returns the offset plus the written data length. In the next iteration (in _send()) where the load function is called, the previous return value (aka start point) is used as offset parameter for at86rf2xx_tx_load() and inside this function, the SRAM access will start at offset+1 again.
https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx_netdev.c#L119
So I don't see how the last byte can get overwritten in a second iteration. Am I mistaken?
Best Peter