EmbDev.net

Forum: µC & Digital Electronics Possible BUS Implementations


Author: Jakob Holderbaum (holderbaum)
Posted on:

Rate this post
0 useful
not useful
Hi EmbDev.net/uC.net board!

I am currently working on my mastersthesis, developing a virtual 
prototype of a distributes measurement system.

One of the core topics will be the distributed data acquisition between 
the different nodes, rather than building concrete measurement sensors.

After conducting a requirement analysis, I am now at the point to begin 
the planning for the first virtual prototype implementation.

Basically, I need a deterministic BUS system, on which a master 
sequentially reads out data from different measurement nodes (slaves).

The main requirement is a high precision on timing constraints. The BUS 
should not stall because of arbitration or other blocking operations.

Another requirement I would like to propose is the extendability for 
(passive) read-only clients, like persistant storage devices or realtime 
displays. Those clients should be able to read every occuring BUS frame, 
independent of the designated receiver.

For now, I am thinking about two directions:

MODBUS on a serial shared BUS. There exist several libraries for ARM and 
other architectures, which eliminates the need to implement a self-baked 
protocol. The read-only client could became a problem with this 
solution, I have to check whether the existing lib support this.

An implementation of a Token Ring BUS. This has the main advantage, that 
less overhad for BUS protokol and stuff like that is used. Instead, 
every node gets its position on the Token Frame which is periodically 
sent by the master. Advantage I see here is also, that read-only clients 
are dead simple to integrate. Main disadvantages can be reliability and 
there is perhaps a lot more to implement by hand.


I do not want a solution to my problem, instead I am interested in 
BUS-Systems, you have used before. Any specific problems or positive 
experiences with star or ring wiring or event specific protocols? :)

Thanks for your interest,
have a nice day

Jakob

Author: A. K. (prx)
Posted on:

Rate this post
0 useful
not useful
If there only is a single master with no slave sending messages while 
not being polled, even a bus built for multi master use results in a 
strictly deterministic timing, provided transmission errors are less of 
a concern.

So you might consider other criteria, like hardware and software 
overhead and node complexity.

Whats your "token ring bus" anyway? I know of token buses, being shared 
media buses with a logical ring topology built on top of it by passing 
software tokens from node to node. And I know of real physical rings 
(cabling pattern is a different issue, you can have a physical ring 
cabled as a star) passing tokens on the links between the nodes - but 
this is traditionally not called a bus.

Physical ring topologies have a few nice attributes, but unless it is 
UART based, you may end up making the required transceiver modules 
yourself. Also if you have to cope with powered down or dead nodes, a 
ring topology requires considerably more effort than a bus topology.

Both token based schemes however do not make a lot of sense in a single 
master environment where the master simply can poll addressed nodes 
sequentially, as can be easily implemented in RS485 based networks.

: Edited by User
Author: A. K. (prx)
Posted on:

Rate this post
0 useful
not useful
Also note that arbitration based networks having multiple masters do not 
necessarily result in nondeterministic timing of essential messages. 
While  non-switched ethernet is the traditional example of completely 
nondeterministic timing, the arbitration scheme of the CAN bus is 
strictly priority based without the necessity of re-arbitration by the 
winner.

Author: A. K. (prx)
Posted on:

Rate this post
0 useful
not useful
Jakob Holderbaum wrote:
> The read-only client could became a problem with this solution

This is the first time I've ever heard that a simple shared media bus 
could have problem with some of the nodes being read-only. ;-)

Author: Jakob Holderbaum (holderbaum)
Posted on:

Rate this post
0 useful
not useful
Thank you for the replies.

The idea for the token implementation was relatively simple. The devices 
are connected in a physical ring, the master sends a token. Every node 
has a specific slot in the token, which implements logically some kind 
of multiplexing on the shared medium, triggered by the master.

But your arguments about simplicity in a single-master topology are 
truly valid.

With a RS485 bus topology, there can be a relatively simple solution 
utilizing e.g. MODBUS. Are you aware of other simple protocols which I 
should take in consideration for this bus aproach?

One problem I see with this, is the probably larger RTT. For every node 
in the system, one request package and one response package has to be 
sent.

In a ring would this become more efficient regarding to the consumed bus 
capacity per value. Or am I missing something here?

Of course, down-time of a node could have a drastical impact on the 
whole measurement process in such topologies. I hold this as a strong 
argument against a ring, whereas the subjective lean bandwidth 
consumption could make this a bit up.

But as I read yout replies correctly, the overall tendency goes toward a 
bus topology?

Cheers
Jakob

Author: Kamajii (Guest)
Posted on:

Rate this post
0 useful
not useful
So basically, you are re-inventing one of
. GPIB,
. VXI,
. PXI or
. VME.

Jakob Holderbaum wrote:
> Or am I missing something here?
That's probably one of the issues you could work out in your thesis...



Jakob Holderbaum wrote:
> mastersthesis
Du darfst übrigens auch auf Deutsch schreiben. Im englischsprachigen 
Raum heißts dann übrigens meistens "master's thesis".

Author: A. K. (prx)
Posted on:

Rate this post
0 useful
not useful
Jakob Holderbaum wrote:
> With a RS485 bus topology, there can be a relatively simple solution
> utilizing e.g. MODBUS. Are you aware of other simple protocols which I
> should take in consideration for this bus aproach?

You may use standard protocols, but you could also define your own, if 
permitted.

> One problem I see with this, is the probably larger RTT. For every node
> in the system, one request package and one response package has to be
> sent.

Do you plan to operate at the throughput/latency limit of the network in 
the first place?

> In a ring would this become more efficient regarding to the consumed bus
> capacity per value.

Hardware based token ring, where the token is not forwarded by software 
but by hardware, has a lower overhead. But this is far from being easily 
implemented and may require programmed logic in each of the nodes.

As soon as the token passing is done by software, ring or bus, I cannot 
see a big difference to a polled scheme, as the receive/transmit token 
processing time does not differ significantly to the request/response 
processing time of a single master polling its slaves.

Unless the distances are so big that the wire latency and the total 
number of bits stored on the wires are significant. So if you intend to 
run a many megabit network along the roads of a city, this might be a 
big deal. If all of the nodes are in a lab however...

> But as I read yout replies correctly, the overall tendency goes toward a
> bus topology?

Have you seen a physical ring of some kind being still alive? In general 
networking there was FDDI and IBM Token Ring, as well as IBM SSA and 
Fibre Channel loops in storage networking, all of them being dead or 
close to. And both of them were fairly complicated to implement.

My overview of all the industrial networks is somewhat limited though. 
Yet I've got the impression that most of them are pretty old. The "never 
change a running system" kind of old - well, I saw a fresh yet classic 
coaxial ARCNET installation for industrial control just a few years ago 
(a token bus invented in the late 70s).

Todays tendency in high thruput / low latency networking appears to be, 
to not try to reach near 100% utilization capability for small frames, 
but instead to make the network faster before you approach the limit.

: Edited by User
Author: besupreme (Guest)
Posted on:

Rate this post
0 useful
not useful
Old time Interbus for example was logically a FIFO ring. Little 
overhead. All bus modules write their status in the FIFO registers, then 
all data including new data from the master is shifted through. After 
the end of shifting, all data is written into the modules, and status is 
written into the FIFO registers again.

I think this is one of the fastest methods of data transfer for a given 
bandwidth, when data size is fixed.

Interbus added some diag and configuration info (about 2 bytes per bus 
module) and ran on 250kbps-2mbps over cheap fiber or twisted pair and 
was built for industrial environment. We usually had bus cycles below 
10ms for welding stations with a lot of robots and modules, even with 
the then-standard 500kbps.

--

Now, I often see Profinet in newer installations, which basically is 
ethernet with managed switches and defined response times. It is faster 
due to much higher bandwidth, but requires an ethernet controller and a 
configuration interface in every module.

Author: A. K. (prx)
Posted on:

Rate this post
0 useful
not useful
Jakob Holderbaum wrote:
> But as I read yout replies correctly, the overall tendency goes toward a
> bus topology?

Actually to switched point to point links, if the capacity of simple 
buses is exceeded. Ethernet interfaces are dirt cheap and well 
integrated in controllers and systems, so everything which needs the 
speed of it and can be done with some specifically tuned ethernet 
hardware likely is done that way, sooner or later.

: Edited by User
Author: Jakob Holderbaum (holderbaum)
Posted on:

Rate this post
0 useful
not useful
Thank you very much for participation, this discussion gave me quite a 
few interesting views, topics and insights on which I can base my 
further research.

I would consider this thread as solved, does the board engine give such 
possibilities? I could't find such thing.

Cheers
Jakob

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.