Alexander Smirnov | 20 May 2013 11:38
Picon

Federated Conference On Computer Science And Information Systems

Dear Alan,

due to you are a WSN expert, you probably will be interested in the following event: http://fedcsis.org/

Even if it's not interesting for you, could you please share this with your WSN contacts.

Thank you,
Alex
------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@...
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
David Hauweele | 9 May 2013 17:19
Favicon
Gravatar

[PATCH 1/2] mrf24j40: Avoid transmission while receiving a frame

The transceiver may fail under heavy traffic when a frame is transmitted
while receiving another frame.

This patch uses a mutex to separate the transmission and reception of
frames along with a secondary working queue to avoid a deadlock while
waiting for the transmission interrupt.

Signed-off-by: David Hauweele <david@...>
---
 drivers/net/ieee802154/mrf24j40.c |   22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ieee802154/mrf24j40.c b/drivers/net/ieee802154/mrf24j40.c
index ede3ce4..1e3ddf3 100644
--- a/drivers/net/ieee802154/mrf24j40.c
+++ b/drivers/net/ieee802154/mrf24j40.c
 <at>  <at>  -82,8 +82,10  <at>  <at>  struct mrf24j40 {
 	struct ieee802154_dev *dev;

 	struct mutex buffer_mutex; /* only used to protect buf */
+	struct mutex txrx_mutex; /* avoid transmission while receiving a frame */
 	struct completion tx_complete;
 	struct work_struct irqwork;
+	struct work_struct rxwork;
 	u8 *buf; /* 3 bytes. Used for SPI single-register transfers. */
 };

 <at>  <at>  -353,6 +355,8  <at>  <at>  static int mrf24j40_tx(struct ieee802154_dev *dev, struct sk_buff *skb)
 	/* Set TXNACKREQ if the ACK bit is set in the packet. */
 	if (skb->data[0] & IEEE802154_FC_ACK_REQ)
 		val |= 0x4;
+
+	mutex_lock(&devrec->txrx_mutex);
 	write_short_reg(devrec, REG_TXNCON, val);

 	INIT_COMPLETION(devrec->tx_complete);
 <at>  <at>  -361,6 +365,9  <at>  <at>  static int mrf24j40_tx(struct ieee802154_dev *dev, struct sk_buff *skb)
 	ret = wait_for_completion_interruptible_timeout(
 						&devrec->tx_complete,
 						5 * HZ);
+
+	mutex_unlock(&devrec->txrx_mutex);
+
 	if (ret == -ERESTARTSYS)
 		goto err;
 	if (ret == 0) {
 <at>  <at>  -535,6 +542,8  <at>  <at>  static int mrf24j40_handle_rx(struct mrf24j40 *devrec)
 	int ret = 0;
 	struct sk_buff *skb;

+	mutex_lock(&devrec->txrx_mutex);
+
 	/* Turn off reception of packets off the air. This prevents the
 	 * device from overwriting the buffer while we're reading it. */
 	ret = read_short_reg(devrec, REG_BBREG1, &val);
 <at>  <at>  -575,6 +584,8  <at>  <at>  out:
 	val &= ~0x4; /* Clear RXDECINV */
 	write_short_reg(devrec, REG_BBREG1, val);

+	mutex_unlock(&devrec->txrx_mutex);
+
 	return ret;
 }

 <at>  <at>  -616,12 +627,19  <at>  <at>  static void mrf24j40_isrwork(struct work_struct *work)

 	/* Check for Rx */
 	if (intstat & 0x8)
-		mrf24j40_handle_rx(devrec);
+		schedule_work(&devrec->rxwork);

 out:
 	enable_irq(devrec->spi->irq);
 }

+static void mrf24j40_rxwork(struct work_struct *work)
+{
+	struct mrf24j40 *devrec = container_of(work, struct mrf24j40, rxwork);
+
+	mrf24j40_handle_rx(devrec);
+}
+
 static int mrf24j40_probe(struct spi_device *spi)
 {
 	int ret = -ENOMEM;
 <at>  <at>  -648,8 +666,10  <at>  <at>  static int mrf24j40_probe(struct spi_device *spi)
 		spi->max_speed_hz = MAX_SPI_SPEED_HZ;

 	mutex_init(&devrec->buffer_mutex);
+	mutex_init(&devrec->txrx_mutex);
 	init_completion(&devrec->tx_complete);
 	INIT_WORK(&devrec->irqwork, mrf24j40_isrwork);
+	INIT_WORK(&devrec->rxwork, mrf24j40_rxwork);
 	devrec->spi = spi;
 	spi_set_drvdata(spi, devrec);

--

-- 
1.7.10.4

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
Tony Cheneau | 1 May 2013 21:54
Favicon
Gravatar

[PATCH v3 0/2] Enable izattach to change the baudrate

This is a small patch for the izattach (part of the linux-zigbee userspace
tools). It enables the user to select the baudrate when communicating with
their IEEE 802.15.4 serial device.

This is the 3rd version of these patches. Here is the list of changes since the
previous version:
- add "usage" text for the "-v" argument as well as the long argument "--version"
- fix indenting in a switch/case
- fix an issue where the "-v" argument would not be parsed properly

Thanks Alex for your review.

Regards,
    Tony

Tony Cheneau (2):
  izattach: remove extra whitespace
  izattach: enable custom baudrate

 src/serial.c | 109 ++++++++++++++++++++++++++++++++++++++++++++++-------------
 1 file changed, 86 insertions(+), 23 deletions(-)

--

-- 
1.8.1.5

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
Werner Almesberger | 30 Apr 2013 03:27
Favicon
Gravatar

[RFC] at86rf230: add support for platform-specific reset function

The AT86RF231-based ATBEN board does not connect the /RST line and
uses power cycling to reset the transceiver. For this, I added a
platform-specific reset function to the at86rf230 driver.

Does this look okay ?

There are more parts involved in properly supporting that board.
I've described them in the following thread:
http://lists.en.qi-hardware.com/pipermail/discussion/2013-April/010123.html

- Werner

--------------------------------- cut here ---------------------------------

Some platforms may not connect the /RST line directly to a GPIO, or they
may not connect it at all and instead use power cycling to reset the
transceiver.

An example of the latter type is the ATBEN board on the Ben NanoNote.

This patch adds support for a platform-specific reset function to the
AT86RF230/1 driver. If the platform provides a reset function, "rstn"
is ignored and no GPIO is allocated for it.
---
 drivers/net/ieee802154/at86rf230.c |   45 +++++++++++++++++++++++++------------
 include/linux/spi/at86rf230.h      |    9 ++++++-
 2 files changed, 39 insertions(+), 15 deletions(-)

diff --git a/include/linux/spi/at86rf230.h b/include/linux/spi/at86rf230.h
index aa327a8..9fd1b29 100644
--- a/include/linux/spi/at86rf230.h
+++ b/include/linux/spi/at86rf230.h
 <at>  <at>  -23,7 +23,7  <at>  <at> 
 #define AT86RF230_H

 struct at86rf230_platform_data {
-	int rstn;
+	int rstn;	/* only used if "reset" (below) is NULL */
 	int slp_tr;
 	int dig2;

 <at>  <at>  -40,6 +40,13  <at>  <at>  struct at86rf230_platform_data {
 	 * of the device to high active (the default value).
 	 */
 	int irq_type;
+
+	/* Platform-specific transceiver reset function, e.g., to use
+	 * power cycling instead of the reset line. If "reset" is NULL,
+	 * the driver resets the transceiver through the "rstn" GPIO.
+	 */
+	void (*reset)(void *reset_data);
+	void *reset_data;
 };

 #endif
diff --git a/drivers/net/ieee802154/at86rf230.c b/drivers/net/ieee802154/at86rf230.c
index 6f10b49..7fa32f2 100644
--- a/drivers/net/ieee802154/at86rf230.c
+++ b/drivers/net/ieee802154/at86rf230.c
 <at>  <at>  -834,6 +834,21  <at>  <at>  static void at86rf230_fill_data(struct spi_device *spi)
 	lp->dig2 = pdata->dig2;
 }

+static void at86rf230_reset(struct at86rf230_local *lp)
+{
+	struct at86rf230_platform_data *pdata = lp->spi->dev.platform_data;
+
+	if (pdata->reset) {
+		pdata->reset(pdata->reset_data);
+	} else {
+		msleep(1);
+		gpio_set_value(lp->rstn, 0);
+		msleep(1);
+		gpio_set_value(lp->rstn, 1);
+	}
+	msleep(1);
+}
+
 static int at86rf230_probe(struct spi_device *spi)
 {
 	struct at86rf230_platform_data *pdata;
 <at>  <at>  -888,9 +903,11  <at>  <at>  static int at86rf230_probe(struct spi_device *spi)

 	at86rf230_fill_data(spi);

-	rc = gpio_request(lp->rstn, "rstn");
-	if (rc)
-		goto err_rstn;
+	if (!pdata->reset) {
+		rc = gpio_request(lp->rstn, "rstn");
+		if (rc)
+			goto err_rstn;
+	}

 	if (gpio_is_valid(lp->slp_tr)) {
 		rc = gpio_request(lp->slp_tr, "slp_tr");
 <at>  <at>  -898,9 +915,11  <at>  <at>  static int at86rf230_probe(struct spi_device *spi)
 			goto err_slp_tr;
 	}

-	rc = gpio_direction_output(lp->rstn, 1);
-	if (rc)
-		goto err_gpio_dir;
+	if (!pdata->reset) {
+		rc = gpio_direction_output(lp->rstn, 1);
+		if (rc)
+			goto err_gpio_dir;
+	}

 	if (gpio_is_valid(lp->slp_tr)) {
 		rc = gpio_direction_output(lp->slp_tr, 0);
 <at>  <at>  -908,12 +927,7  <at>  <at>  static int at86rf230_probe(struct spi_device *spi)
 			goto err_gpio_dir;
 	}

-	/* Reset */
-	msleep(1);
-	gpio_set_value(lp->rstn, 0);
-	msleep(1);
-	gpio_set_value(lp->rstn, 1);
-	msleep(1);
+	at86rf230_reset(lp);

 	rc = at86rf230_read_subreg(lp, SR_MAN_ID_0, &man_id_0);
 	if (rc)
 <at>  <at>  -985,7 +999,8  <at>  <at>  err_gpio_dir:
 	if (gpio_is_valid(lp->slp_tr))
 		gpio_free(lp->slp_tr);
 err_slp_tr:
-	gpio_free(lp->rstn);
+	if (!pdata->reset)
+		gpio_free(lp->rstn);
 err_rstn:
 	spi_set_drvdata(spi, NULL);
 	mutex_destroy(&lp->bmux);
 <at>  <at>  -995,6 +1010,7  <at>  <at>  err_rstn:

 static int at86rf230_remove(struct spi_device *spi)
 {
+	struct at86rf230_platform_data *pdata = spi->dev.platform_data;
 	struct at86rf230_local *lp = spi_get_drvdata(spi);

 	ieee802154_unregister_device(lp->dev);
 <at>  <at>  -1004,7 +1020,8  <at>  <at>  static int at86rf230_remove(struct spi_device *spi)

 	if (gpio_is_valid(lp->slp_tr))
 		gpio_free(lp->slp_tr);
-	gpio_free(lp->rstn);
+	if (!pdata->reset)
+		gpio_free(lp->rstn);

 	spi_set_drvdata(spi, NULL);
 	mutex_destroy(&lp->bmux);

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
João Paulo Bodanese | 25 Apr 2013 10:43
Picon

Netfilter and 6LowPan

Hello,

Is it possible to use Netfilter to hook the packets on 6LowPan?

I tryied 2 different configurations:

1)
netfilter_ops.hook              =       main_hook;
netfilter_ops.pf                    =       PF_INET6;
netfilter_ops.hooknum       =       NF_IP6_PRE_ROUTING;
netfilter_ops.priority           =       NF_IP6_PRI_FIRST;

In this case no packet is hooked.

2) 

       netfilter_ops.pf  = PF_IEEE802154

I got a crash on loading the module

...
[   28.608943] [<c047a908>] (nf_register_hook+0x38/0x84) from [<bf0da050>] (filter_init+0x50/0x70 [netfilter])
[   28.619396] [<bf0da050>] (filter_init+0x50/0x70 [netfilter]) from [<c0008878>] (do_one_initcall+0x90/0x160)
[   28.629827] [<c0008878>] (do_one_initcall+0x90/0x160) from [<c008822c>] (load_module+0x1948/0x1bf8)
[   28.639496] [<c008822c>] (load_module+0x1948/0x1bf8) from [<c00885a8>] (sys_init_module+0xcc/0xec)
[   28.649083] [<c00885a8>] (sys_init_module+0xcc/0xec) from [<c000d8c0>] (ret_fast_syscall+0x0/0x30)


Thanks a lot,
João Paulo

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@...
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Tony Cheneau | 24 Apr 2013 16:49
Favicon
Gravatar

[PATCH v2 0/2] Enable izattach to change the baudrate

This is a small patch for the izattach (part of the linux-zigbee userspace
tools). It enables the user to select the baudrate when communicating with
their IEEE 802.15.4 serial device.

This is the 2nd version of these patches. Here is the list of changes since the
previous version:
- split the initial patch in two, extra whitespace fix has now its separate patch
- fix the issue where my text editor replaced the tab to 4 spaces

Thanks Alan for your review.

Regards,
    Tony

Tony Cheneau (2):
  izattach: remove extra whitespace
  izattach: enable custom baudrate

 src/serial.c | 107 ++++++++++++++++++++++++++++++++++++++++++++++-------------
 1 file changed, 84 insertions(+), 23 deletions(-)

--

-- 
1.8.1.5

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
Tony Cheneau | 17 Apr 2013 23:23
Favicon
Gravatar

[PATCH 0/1] Enable izattach to change the baudrate

This is a small patch for the izattach (part of the linux-zigbee userspace
tools). It enables the user to select the baudrate when communicating with
their IEEE 802.15.4 serial device. To the best of my knowledge, the only device
making use of the izattach tool for the moment is the Redbee Econotag (whose
default speed is the same as the default speed of the izattach).  However is
easy to modify the Econotag firmware to increase the baudrate of the UART.
When that happens, izattach must also communicate at the same speed.

Comments are welcomed.

Regards,
    Tony

Tony Cheneau (1):
  izattach: enable custom baudrate

 src/serial.c | 109 ++++++++++++++++++++++++++++++++++++++++++++++-------------
 1 file changed, 85 insertions(+), 24 deletions(-)

--

-- 
1.8.1.5

------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
George Nychis | 16 Apr 2013 19:15
Picon

status of CCA / Energy Detect

I sent a mail to the list 2 years ago (eep! time flies) about whether CCA is enabled and/or working on the Econotag boards:


It seemed like Mariano had done some work to sort out CCA through work on ContikiMAC.  I was wondering what the status of this was now.

I also went through the mc1322x development document (http://mc1322x.devl.org/files/MC1322xRM-r0.pdf) and 6.7.2 shows access to registers to control energy detection and CCA.  Ultimately, I want the board I have to perform both energy detection and CCA.  It is possible to set the energy detection threshold, but I can't find any exposure to read the current energy values from the board.  So, I'm not sure how to ballpark the threshold.

I'd greatly appreciate any heads up to working code before I set out to try and work on this.

Thanks!
George
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@...
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Ralph Droms (rdroms | 12 Apr 2013 17:46
Picon
Favicon

Re: [PATCH 0/3] Patches to 6lowpan.c to fix link-local address uncompression

I neglected to cc linux-zigbee-devel@... in my
original reply.

- Ralph

> 
> Le 11.04.2013 18:59, Ralph Droms (rdroms) a écrit :
>> 
>> On Apr 11, 2013, at 10:33 AM 4/11/13, Christophe Aeschlimann <c.aeschlimann@...>
>> wrote:
>> 
>>> Hi Ralph,
>>> 
>>> Le 11.04.2013 13:51, Ralph Droms a écrit :
>>>> 
>>>> These patches fix link-local address uncompression, for both source
>>>> and destination addresses.
>>>> 
>>>> - Ralph
>>>> 
>>>> Ralph Droms (3):
>>>> net/ieee802154: 6lowpan.c: Fixes for stateless address decompression
>>>>   to use MAC address
>>>> net/ieee802154: 6lowpan.c: This patch fixes source address
>>>>   uncompression to send the MAC address to lowpan_uncompress_addr
>>>> net/ieee802154: 6lowpan.c: This patch fixes destination address
>>>>   uncompression to send the MAC address to lowpan_uncompress_addr
>>>> 
>>>> net/ieee802154/6lowpan.c |   53 +++++++++++++++++++++++++++------------------
>>>> 1 files changed, 32 insertions(+), 21 deletions(-)
>>> 
>>> The patches fix the "ICMPv6 checksum failed" I was getting when using
>>> SLAAC addresses.
>>> 
>>> The patches content look ok for me apart from a few minor typos (RFC
>>> number and "contex" which is missing a "t". I would also suggest making
>>> the patch title a bit less verbose.
>> 
>> OK, thanks.  I know of at least one diagnostic "pr_debug" that should be fixed, as well.
>> 
>> I'll take a look at some other patches and update the titles for these patches.
>> 
>>> 
>>> Please note that this patch doesn't allow me to use fragmented packets
>>> when using SLAAC addresses. e.g.
>>> 
>>> $ping6 -s 4 fe80::200:0:0:1%lowpan0   => WORKS OK
>>> $ping6 -s 200 fe80::200:0:0:1%lowpan0 => DOESN'T WORK
>>> 
>>> But if I add another "link-local" address to the 6lowpan interface on
>>> each system:
>>> 
>>> system 1 : $ip -6 addr add dev lowpan0 fe80::1
>>> system 2 : $ip -6 addr add dev lowpan0 fe80::2
>>> 
>>> Then  from system 2 :
>>> 
>>> $ping6 -s 4 fe80::1%lowpan0    => WORKS OK
>>> $ping6 -s 200 fe80::1%lowpan0  => WORKS OK
>>> 
>>> I don't have the hardware to test contiki's interoperability.
>> 
>> Fragmentation in 6lowpan.c is not RFC 4944 compliant.  Fragmentation may work between linux systems
using 6lowpan.c, but those implementations won't interoperate with other implementations and
wireshark flags these packets as in error.
>> 
>> In this particular case, lowpan_alloc_new_frame doesn't copy the MAC addresses from the received
fragment into the reassembly skb, so the link-local uncompression code can't reconstruct the
link-local address.
>> 
>> I have a fix for this problem in a patch I hope to publish for review soon.  This patch also fixes the code so
the offset is handled in compliance with RFC 4944.
>> 
>> - Ralph
> 
> 
> -- 
> Christophe Aeschlimann
> 
> Embedded Software Engineer & IT Manager
> ACN Advanced Communications Networks S.A.
> 2000 - Neuchâtel, Switzerland
> Tel. +41 32 724 74 31

------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
Ralph Droms | 11 Apr 2013 13:51
Picon
Favicon

[PATCH 0/3] Patches to 6lowpan.c to fix link-local address uncompression


These patches fix link-local address uncompression, for both source
and destination addresses.

- Ralph

Ralph Droms (3):
  net/ieee802154: 6lowpan.c: Fixes for stateless address decompression
    to use MAC address
  net/ieee802154: 6lowpan.c: This patch fixes source address
    uncompression to send the MAC address to lowpan_uncompress_addr
  net/ieee802154: 6lowpan.c: This patch fixes destination address
    uncompression to send the MAC address to lowpan_uncompress_addr

 net/ieee802154/6lowpan.c |   53 +++++++++++++++++++++++++++------------------
 1 files changed, 32 insertions(+), 21 deletions(-)

--

-- 
1.7.7.6

------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
Werner Almesberger | 10 Apr 2013 16:43
Favicon
Gravatar

Performance analysis of SPI drivers for ATBEN

[ Also posted on the qi-hardware list. No cross-post, since few
  people will be on both lists. ]

What this is all about
----------------------

The ATBEN board on the Ben NanoNote needs a bit-banging SPI driver.
There are several ways to implement this, ranging from reuse of the
generic spi-gpio driver to an optimized driver that's specific for
this platform.

I implemented several such approaches and measured their performance
in the Ben NanoNote. Below are my findings.

Comments welcome.

Cast and characters
-------------------

spi_atben_gpio: NanoNote-specific framework for setting up the
AT86RF230/1 with SPI-GPIO or one of the optimized drivers (below).
The name derives from spi_atben (see below) and should be changed
(maybe to atben_spi or atben_spi_gpio ?) since it is not an SPI
driver but merely a framework that provides configuration data and
performs miscellaneous platform setup.
https://github.com/wpwrak/ben-wpan-linux/blob/master/drivers/net/ieee802154/spi_atben_gpio.c

spi_atben: like spi_atben_gpio, but contains a highly optimized
SPI driver for the ATBEN configuration in the Ben NanoNote.
https://github.com/wpwrak/ben-wpan-linux/blob/master/drivers/net/ieee802154/spi_atben.c

spi-jz4740-gpio: SPI-GPIO driver optimized for the Jz4740. Uses the
optimized register accesses from spi_atben but pin assignment is not
restricted to ATBEN. The only limitation is that MOSI, MISO, and
SCLK must be on the same port.
https://github.com/wpwrak/ben-wpan-linux/blob/master/drivers/spi/spi-jz4740-gpio.c

spi-gpio-atben: task-specific SPI-GPIO driver using the #include
"spi-gpio.c" method. Replaces gpiolib functions with register
accesses specific to the ATBEN configuration in the Ben NanoNote.
Note that some of the code could be moved into Jz4740
architecture-specific GPIO support.
https://github.com/wpwrak/ben-wpan-linux/blob/master/drivers/spi/spi-gpio-atben.c

In the following sections, we abbreviate the stack configurations
as follows:

Abbreviation	Framework	Transport	Chip driver
---------------	---------------	---------------	-----------
spi-gpio	spi_atben_gpio	spi-gpio	at86rf230
spi-gpio-atben	spi_atben_gpio	spi-gpio-atben	at86rf230
spi-jz4740-gpio	spi_atben_gpio	spi-jz4740-gpio	at86rf230
spi_atben	spi_atben			at86rf230

Measurements
------------

Access time to AT86RF231 registers and buffer, in microseconds, on
an otherwise idle Ben NanoNote:

Driver		read from 0x51		read 120 bytes from buffer
|		|	write 0x0a to 0x15	write 1 byte to buffer (0x33)
|		|	|	read 1 byte from buffer	write 120 bytes
|		|	|	|	|	|	|
spi-gpio	 81	 85	186	1696	 97	1596
spi-gpio-atben	 63	 59	123	 498	 65	 437
spi-jz4740-gpio	 10	  8	 21	 280	 10	 231
spi_atben	 10	  7	 21	 280	 10	 230

Data rate for hypothetical buffer accesses of infinite length.
I.e., kbps = 1000*119*8/(t_write120-t_write1)

Driver		buffer read (kbps)	buffer write (kbps)
---------------	-----------------------	-------------------
spi-gpio	 630			 635			
spi-gpio-atben	2549			2559
spi-jz4740-gpio	3676			4308
spi_atben	3676			4327

At the air interface, IEEE 802.15.4 has a data rate of 250 kbps.
The AT86RF231 transceiver also supports non-standard higher data
rates up to 2 Mbps.

Driver(s)				Code size (lines)
---------------------------------------	-----------------
spi_atben_gpio				 128
spi_atben_gpio + spi-gpio-atben		 128+ 53
spi_atben_gpio + spi-jz4740-gpio	 128+416
spi_atben				 423

Computational cost
------------------

The high-level operations of sending and receiving produce the
following major low-level operations:

Operation	register	buffer		waitqueue
		read	write	read	write
---------------	-------	-------	-------	-------	---------
reception	1	-	1	-	1
transmission	9	4	-	1	1

Using the measured data from above, we get the following total
computational overhead in microseconds, without considering the
waitqueue scheduling delay:

Driver		reception		transmission
		1	120	127	1	120	125 (bytes)
---------------	-------	-------	-------	-------	-------	-------
spi-gpio	 267	1777	1866	1166	2665	2727
spi-gpio-atben	 186	 561	 583 	 868	1240	1256
spi-jz4740-gpio	  31	 290	 304 	 132	 353	 362

Note that the minimum frame length in IEEE 802.15.4 is 5 bytes.
The values for 125 (excluding CRC) and 127 (including CRC) bytes
are extrapolated.

According to [1], maximum-sized frames can be sent/received,
including CSMA/CA and acknowledgement, at a rate between one
every 4928 us and one every 7168 us.

We would therefore get the following maximum CPU load:

Driver		Reception	Transmission
---------------	---------------	------------
spi-gpio	38%		55%
spi-gpio-atben	12%		25%
spi-jz4740-gpio	 6%		 7%

Observations
------------

spi-gpio needs the smallest amount of new code but is also very
inefficient, making it questionable whether this configuration
would yield acceptable performance in regular use.

With spi-gpio-atben, only a small amount of code is added, but
buffer accesses become almost 4 times faster. Register reads and
writes are still fairly slow.

spi_atben and spi-jz4740-gpio both achieve the best performance
without significant differences between them. Both add a complete
SPI driver. Of the two, spi-jz4740-gpio is preferable, because it
uses the nearly universal spi_atben_gpio framework driver.

Conclusion
----------

I think performance trumps most other considerations in this case.
spi-gpio is clearly too inefficient. spi_atben_gpio with
spi-jz4740-gpio offers the best performance and has a low impact
on the system load (< 10%). In case this solution would be met
with strong resistance for some reason, spi-gpio-atben would offer
a compromise between performance and the amount of code.

References
----------

[1] http://www.jennic.com/files/support_files/JN-AN-1035%20Calculating%20802-15-4%20Data%20Rates-1v0.pdf

- Werner

------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter

Gmane