Hi Jonas,
On 20.03.2015 18:02, Jonas Remmert wrote:
1. Both, the upper layer and the current implementations of the
ng_netdev radio drivers use task messages to signalize an event
(Packet to be sent or Packet to receive waiting). Both message
mechanisms send their messages to the mac_pid and therefore use the
same message queue. If the mac-layer and the transceiver is busy with
sending a message out or waiting for an ACK it might wait for a signal
from the driver (RX-ready, ACK-received...). In the same time there
might also be messages from the upper layers that can not be handled
until the previous packet is sent out.
- I handled this problem in using the drivers call-back function in
combination with different task lock mechanisms for upper layer
(msg_receive) and for driver events 2x(mutex_lock), which causes in
TASK_BLOCKED state. That method worked very well, even if I fired the
mac-layer continously with upper layer messages.
Though this probably works fine, this is not quite how the concept was
meant. The problem is of course there: when the MAC layer is getting
spammed by upper layer messages, the reaction time for device driver
messages might be not as fast... Though the messages should not be los
(as they are queued...). The concept is based on the assumption, that
the time needed for handling incoming messages in the MAC layer is very
short. Also so far we basically assumed, that the MAC layer has a higher
priority then the upper layers. This way, the MAC layer will always
finish processing all it's queued messages before the upper layers get
scheduled again.
2. The drivers send function builds the IEEE 802.15.4 MAC header on
its own. The alternative would be to let the MAC layer do this job.
This would avoid code duplication and make it easier to implement new
radio drivers. Is there any reason to do this in the driver
implementation?
I don't really understand the code duplication issue here... The MAC
layer should actually not know anything about the radio frame format or
the like, as the idea behing the MAC layer in the current form is to
make them interchangable and usable with different network devices (not
only 802.15.4 devices)... So to answer your question: yes!
3. Introduction of PHY dependant constants: The constants (e.g.
SYMBOL_LENGTH used in backoff intervall, MAX_BE, MIN_BE,
TURNAROUND_TIME, MAC_ACK_WAIT_DURATION, MAX_RETRIES..). As these
constants are different for each type of PHY (2,5 Ghz, subGhz and also
Modulation specific) we could put them in a struct that would be
linked to the device descriptor.
Actually, these constants should not be constants :-) The way I would
implement them is by naming these defines something like
xx_DEFAULT_MAX_BE, xx_DEFAULT_TURNAROUND_TIME, etc. The you include
fields in your device descriptor for these values and initialize them
with these values. This way you can change them during runtime and
define different values if you run more then 1 device concurrently...
4. Generally, a successfull TX of a packet is not signalized to upper
layers. But how do we handle a packet that could not be sent to the
channel (e.g. channel busy)? Should upper layer be informed about the
failure?
So far the packets are just silently dropped. The plain netapi_send()
does not support feedback to upper layers on the success of the send
process - this we did to avoid deadlock scenarios and synchronization
issues...
Cheers,
Hauke
A WIP state of the ng_kw2xrf-driver that I used for testing can be
found in my repo [2].
a nice Weekend,
Jonas
[1] - https://github.com/RIOT-OS/RIOT/pull/2467
[2] - https://github.com/jremmert-phytec-iot/RIOT/tree/wip%40kw2xrf_ng
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
