From wk at gnupg.org  Sat Aug 13 21:56:36 2011
From: wk at gnupg.org (Werner Koch)
Date: Sat, 13 Aug 2011 21:56:36 +0200
Subject: [ebus-dev] A new list for the Elektor Bus development
Message-ID: <877h6haxvv.fsf@vigenere.g10code.de>

Hi,

it seems there is no mailing list for the Elektor magazine's bus
project.  Instead the advise is to send mails to redaktion at elektor.de.
For a community project this is not fully optimal.  Thus I took the
freedom to set up this list.

This is an open list, everyone is able to subscribe without any
moderator approval.  The language should be English.  If it turns out
that there are more German users we may change the rule.

Please don't post HTML parts, don't top post and strip quotes to a few
lines.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Mon Aug 22 11:59:58 2011
From: wk at gnupg.org (Werner Koch)
Date: Mon, 22 Aug 2011 11:59:58 +0200
Subject: [ebus-dev] CSMA/CD test code
Message-ID: <87liul22ch.fsf@vigenere.g10code.de>

Hi!

I tinkered a bit with the Elektor Bus hardware and after some
experiments with a Modbus alike protocol I now implemented a CSMA
protocol.  It still uses the 16 byte fixed message size but uses an
explicit framing similar to PPP to ease synchronization and to convey
the messages transparently.

The advantage of CMSA for my domotik installation is that it is more
reliable in case of a failed node, does not require a master and sensor
only nodes may fall asleep until a new sensor value shall be sent
(e.g. every few minutes for room temperatures).

The code is written in C using avr-gcc.  As an Emacs adept I don't use a
Makefile for this simple code but put the build instructions at the end
of the file.  I am currently using 5 nodes for my test; if you use more
you may want to adjust ebusdump.c.

You may checkout the code from a git repo or download the latest version
using these URLS:

The node code:

  <http://git.gnupg.org/cgi-bin/gitweb.cgi?p=wk-misc.git;a=blob_plain;f=ebusnode1.c;hb=HEAD>

A utility to show/log what's going on on the bus:

  <http://git.gnupg.org/cgi-bin/gitweb.cgi?p=wk-misc.git;a=blob_plain;f=ebusdump.c;hb=HEAD>

Here is the blurb from the file:

   Build instructions are at the end of this file.  Please make sure
   to set the FUSE bits correctly and assign a different node-id to
   each node by storing them in the EEPROM.

   The tool ebusdump.c may be used on a Unix hosts to display the
   stats.  Assuming the RS-485 converter is attached to /dev/ttyUSB1
   you would do this:

     stty </dev/ttyUSB1 speed 9600 raw
     ./ebusdump </dev/ttyUSB1 --top

   Instead of of showing the stats page, ebusdump may also be used to
   dump the activity by usingit without the --top option.

   This code sends status information to allow analyzing the bus
   behaviour under load.  The keys S2 and S3 are used to change the
   send interval of those messages in discrete steps.  With 9600 baud
   you will notice many collisions in particular if the interval has
   been set down to 25 by pressing the S3 button 4 times; the interval
   is shown in the ebusdump output.

   In contrast to the original Elektor Bus protocol, this version uses
   implements a CSMA/CD protocol with an explicit framing similar to
   PPP (RFC-1662).  The original 0xAA byte has been replaced by a
   protocol ID to allow the use of several protocols on the same bus.

   Future work:
   - Detect collisions more reliable by adding a CRC to the framing.
   - Use correct timings.
   - Add a framework to register actual applications.
   - Use a simple send queue to allow receiving urgent data.




Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Mon Aug 22 16:02:54 2011
From: wk at gnupg.org (Werner Koch)
Date: Mon, 22 Aug 2011 16:02:54 +0200
Subject: [ebus-dev] CSMA/CD test code
In-Reply-To: <87liul22ch.fsf@vigenere.g10code.de> (Werner Koch's message of
	"Mon, 22 Aug 2011 11:59:58 +0200")
References: <87liul22ch.fsf@vigenere.g10code.de>
Message-ID: <871uwd1r3l.fsf@vigenere.g10code.de>

Hi!

The latest version includes a CRC; the CRC is part of the frame and not
of the payload.  Thus the frame forma is now:

    +-----------+--------+---------------------+---------+----------+
    |SYNC(0x7e) | PROTID | PAYLOAD (15 octets) | CRC(msb)| CRC(lsb) |
    +-----------+--------+---------------------+---------+----------+

Except for the SYNC byte all other octets are byte stuffed and masked so
that the sync byte value always indicates the start of a frame.  The CRC
is computed over PROTID and PAYLOAD after de-stuffing.  In contrast to
PPP we don't need a trailing flag to indicate the end of the frame
because we use a fixed length payload.  The CRC uses the polynom
x^16+x^12+x^5+1 and an initial value of 0xfff (CRC-CCID).  The CRC is
sent in network byte order.


Salam-Shalom,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Mon Aug 22 18:07:11 2011
From: wk at gnupg.org (Werner Koch)
Date: Mon, 22 Aug 2011 18:07:11 +0200
Subject: [ebus-dev] CSMA/CD test code
In-Reply-To: <871uwd1r3l.fsf@vigenere.g10code.de> (Werner Koch's message of
	"Mon, 22 Aug 2011 16:02:54 +0200")
References: <87liul22ch.fsf@vigenere.g10code.de>
	<871uwd1r3l.fsf@vigenere.g10code.de>
Message-ID: <87fwktzaz4.fsf@vigenere.g10code.de>

On Mon, 22 Aug 2011 16:02, wk at gnupg.org said:

> because we use a fixed length payload.  The CRC uses the polynom
> x^16+x^12+x^5+1 and an initial value of 0xfff (CRC-CCID).  The CRC is

Of course I meant 0xffff and CRC-CCIT instead of the smartcard spec.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Mon Aug 22 21:46:53 2011
From: wk at gnupg.org (Werner Koch)
Date: Mon, 22 Aug 2011 21:46:53 +0200
Subject: [ebus-dev] CSMA/CD test code
In-Reply-To: <DB16030CD88F4EA6B114C01942543079@asus> (John Dammeyer's message
	of "Mon, 22 Aug 2011 07:51:00 -0700")
References: <DB16030CD88F4EA6B114C01942543079@asus>
Message-ID: <87y5ylxm8i.fsf@vigenere.g10code.de>

On Mon, 22 Aug 2011 16:51, johnd at autoartisans.com said:

> This is a great example of why I insist people comment their code.  Even
> just the quick and dirty programs.  The comments either say what the

I did:

/* The sync byte which indicates the start of a new message.  If this
   byte is used inside the message it needs to be escaped and ORed
   with the escape mask.  This ensures that a sync byte will always be
   the start of a new frame.  Note that this is similar to the PPP
   (rfc-1662) framing format.  */
#define FRAMESYNCBYTE 0x7e
#define FRAMEESCBYTE  0x7d
#define FRAMEESCMASK  0x20

Need to fix the bug which confused you: s/ORed/XORed/ 


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.