Hello, Pierre-emmanuel Goudet wrote:
> Hi Dmitry, all, > > As you said you will work in serial ZB protocol evolutions to allow > better management of hardware capabilities of transceiver, would it be > possible to add these kind of 'ops' in serial driver (hence protocol) > and link them to specific 'ops' in the corresponding kernel device: > > ==> For global ACK capabilities (as you discussed with Andrew) > .set_auto_ack_(on/off) > .set_auto_crc_(on/off) > .set_mac_address (u64) > .set_short_address (u16) > .set_panid (u16) > > ==> For 802.15.4 CSMA/CA tx capabilities: .set_auto_retry (on/off) > .set_nb_csma_retries(u8) > .set_nb_retries(u8) > .set_min_backoff_exponent (u8) > > Maybe all this and existing '.set' would also necessitate a 'get' > capability also ? I'd prefere to have one (or two) calls: .config_aack(struct aack_config *, u32 valid) .config_csma(struct csma_config *, u32 valid) with valid args being bitfields telling which fields inside respective XXX_config structure are valid. You can see the same approach inside mac80211/cfg80211 > I think these kind of ops are quite common to many hardware transceiver > implementing time constrained services of Mac (802.15.4) layer. So the > ability to configure all these across serial driver would be very > useful. > > Best regards, > > Pierre-emmanuel > > PS: I would be very happy to contribute but i'm not really aware about > the way to do it, and i don't think i've enough knowledge in Linux > Kernel programming, but do not hesitate to tell me the way i could ... > The road starts from one single small step. So, go with it, if you want to. And most of kernel hackers will (at least somehow) support you :) > Dmitry Eremin-Solenikov a écrit : >> Andrew Webster wrote: >> >> >>> I've been trying to see if I can set up a 802.15.4 network and have >>> other 802.15.4 compliant devices join the network. I however am >>> noticing that when the other device expects to get an ACK, it only >>> waits 50ms before retransmitting. Now I don't have the ACK working >>> yet, but in my system, due to scheduling and so on with the serial >>> port data, I don't even start processing the incoming message until >>> 30-40 ms after it has arrived. By the time the CCA, TX, and DATA >>> messages have been sent I'm up to about 120ms. At this rate, my >>> system gets tied up processing the message and the retransmits so it >>> won't be able to send out an ACK before the other side gives up >>> entirely. >>> >>> Does this sound right compared to what others are seeing on PCs? >>> >>> >> Yes. That's why I'd dropped all software ACK generation and moved CCA >> calls to tx driver callback: they should be done either by HW or by >> firmware running on the dongle. Otherwise we won't get timing >> accurately. >> >> >>> I was thinking of trying to eliminate some of the waiting between PHY >>> messages by combining them into one message so it only has to be acked >>> once. This would at least eliminate the 20-30ms of waiting for the >>> response to each message. >>> >>> >> >> Moreover It seems that to support necessary timing the packet should be >> received in stream mode (to be analyzed in the same time, as it's >> received). >> >> I have an implementation of working STREAM mode of MC13192, however no >> work to completely debug things was done. >> >> I hope to get at least few days during two next weeks to write a draft >> of the next generation of serial protocol and to dump the code I have >> here into usable external project repo. -- With best wishes Dmitry ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
