[riot-devel] Netdev2 - mechanism for building transmit frames

Peter Kietzmann peter.kietzmann at haw-hamburg.de
Mon Aug 29 11:50:16 CEST 2016


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



Am 18.08.2016 um 21:22 schrieb Neo:
> 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
>
> _______________________________________________
> devel mailing list
> devel at 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


More information about the devel mailing list