Which embedded system would you use? - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Which embedded system would you use?
Quoted text here. Click to load it

Well, as for bus structure with "many wires' you might take a look at
GPIB (IEEE-488) and SCSI.

Re: Which embedded system would you use?
Quoted text here. Click to load it

Well, as for bus structure with "many wires' you might take a look at
GPIB (IEEE-488)  (and SCSI 2 or 3.)

******HS488, a higher-speed GPIB transfer protocol, scales the maximum
data transfer rate of ANSI/IEEE Standard 488.1-1987 up to 8 Mbytes/s
by removing delays in the 3-wire IEEE 488.1 handshake. HS488 is
implemented in hardware as a feature of the TNT4882C GPIB controller
ASIC, and thus imposes no additional software overhead during HS488
transfers. Because HS488 is implemented at the hardware level, your
application code requires no modification to take advantage of high-
speed GPIB. Using the HS488 protocol, the GPIB Controller hardware can
automatically detect compatible devices capable of using the HS488
handshake to transfer data. If the Controller does not detect an HS488
capable device, it automatically defaults to the standard IEEE 488.1 3-
wire handshake to complete the data transfer. The HS488 protocol
employs the same proven, high-speed, data streaming techniques used in
VME, PCI, and Fast SCSI.  ******

from; http://zone.ni.com/devzone/cda/tut/p/id/4552


Re: Which embedded system would you use?
Quoted text here. Click to load it


I know you were wanting to brainstorm alternatives, but, it seems your
sense about ethercat is not at all unreasonable. Twincat/EtherCAT (or
even Power over EthercCAT) don't seem to have downsides, it 'may' be
overkill, and there probably are alternatives that would work, but I
think your first choice here certainly hasn't been convincingly shot
down.

found this(perhaps you know of it already?);

http://www.youtube.com/watch?v3D%zrxHMOW67FM&list3D%PL93A1D8E195356D90


Re: Which embedded system would you use?
Sorry got very busy on past few days.. back to the discussion.
Concentrators are a reasonable idea.. but i am trying to avoid intermediate
systems due to latency between some signal and systems response. Thats very
critical. Something different from star or Bus is not acceptable due the
cable numbers.. and thats another critical part. Just a better
representation of the complexity of the system. Somthing comaprable would
be this: http://bleex.me.berkeley.edu/Publication/ICRA06Kazsteger.pdf but
with more complex sensores, and with more flexibility in general (theis
system in specifc, uses a fixed sensor node and none biosensor). It is an
old article, so maybe Berkeleys actual devices like HULC are using a
different solution. The whole problem of the system is not bandwith itself,
but as i saied before, the lattency. Bus speed is just to reduce that.
There is another article with a better explanation of the communication
system. As you can see on the end of the article.. you can see that they
can transmit 140 bytes on 20us. Thats the whole point. Thats very different
of transmiting 1400 bytes on 200us (if you consider a bulk transmission).
The solution used at Bleex have 2 problems.. the cypress chip is too old
(probably close to be dicontinued), and very very expensive (close to 100
USD e.u). A system that is using a solution closo to what i am developing
so far is the Robounaut II.
http://www-robotics.cs.umass.edu/~rplatt/papers/robonaut_overview_icra2010.pdf .
There are a few articles with more detailed technical description but they
are on IEExplore... Any way they are using M-LVDS.. but on a more specific
way becouse an FPGA placed on central processor is doing a lot of the
control processing. Any way, any other suggestions?


Thank you!      
                    
---------------------------------------        
Posted through http://www.EmbeddedRelated.com

Re: Which embedded system would you use?
Quoted text here. Click to load it

If all the nodes are within 10 feet, you can just USB and HUB them.
You might want to have multiple USB Host chips to balance the
traffic.  USB can do 64 bytes in less than 20us.

Re: Which embedded system would you use?
Quoted text here. Click to load it



Just wondering, is there a fiber-optic network/LAN protocol that could
work?

Re: Which embedded system would you use?
We probably going to use fiber on further versions, but as none on the team
has experience with fiber, we are going to use copper for now. Back to USB.
How can i use 1 usb cable to go through all nodes? Use a hub on each node?


And how can i get 20us with an RT Linux?
thnks

Quoted text here. Click to load it
intermedia=

Quoted text here. Click to load it
ve=

Quoted text here. Click to load it
the

Quoted text here. Click to load it
would

Quoted text here. Click to load it
an

Quoted text here. Click to load it
itsel=

Quoted text here. Click to load it
they

Quoted text here. Click to load it
differe=

Quoted text here. Click to load it
transmission).

Quoted text here. Click to load it
old

Quoted text here. Click to load it
100

Quoted text here. Click to load it
developing

Quoted text here. Click to load it
II.http://www-robotics.cs.umass.edu/~rplatt/paper =

Quoted text here. Click to load it
the=

Quoted text here. Click to load it
specifi=

Quoted text here. Click to load it
                    
---------------------------------------        
Posted through http://www.EmbeddedRelated.com

Re: Which embedded system would you use?
Quoted text here. Click to load it

I thought they are mounted on humans, not giants.

Quoted text here. Click to load it

One hub per 4 to 8 sensors.  4 to 5 layers of hubs.  255 sensors max.

Quoted text here. Click to load it

Use dedicated USB host chips, fully interrupt driven stack.  Offload
your control FSM onto the dedicated chips, only store and forward bulk
data on Linux.



Re: Which embedded system would you use?
The reason to use fiber would be noise imunity. But a shilded twisted pair
for now is ok for now. But i could not get.. You say to use a hub for node
groups.. but they are aligned.. imagin an pearson's arm and nodes
distribuited over the arm. So if we use a hub... there are on cable from
each nod going to the hub.. thats a lot.. and finally.. you told me it is
possible to send 64B with a 20us time with USB. That would be ok if i could
address many nodes with one message. But 20us for each node for the request
and answer would be something like 120us of lattency for 3 nodes on a
channel for data transmission. WHat is the reliability on this number? And
are you including the Linux response time?
Thank you!
      
                    
---------------------------------------        
Posted through http://www.EmbeddedRelated.com

Re: Which embedded system would you use?
Quoted text here. Click to load it

No, just raw USB data transfer.

12,000,000 bits per sec
3D% 4,000,000 bytes per sec
3D% 80 bytes per 20 uSec

But USB frames are limited to 64 bytes, perhaps a little bit less.

Re: Which embedded system would you use?
Quoted text here. Click to load it

What is the minimum USB polling interval these days ?

In the UHCI days, it used to be 1ms, then it dropped to 125us for USB 2.0.

Since people here are talking about 20us been achievable, it's obviously
dropped further but a quick search online only found the EHCI era 125us
specs.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Which embedded system would you use?

Quoted text here. Click to load it

Since the distances are that short, have you looked at for instance
PCI Express ? This is of course point to point, but at x1, the cable
consumption would not be that bad.

Are all data actually used in real time (e.g. in a PID controller) or
is most used for later analysis, in which case it would make sense to
collect a few samples and send it in a single longer message.

If there are a large number of nodes physically close to each other,
but far away from the master controller, using direct wire connection
to concentrators near the nodes and then use some CAN/Ethernet
protocol to the master controller.

I guess you also need some clock distribution system, so having direct
wire connections between the nodes and concentrator is not that bad
idea.

As you said EtherCat might be an option even direct connection to each
node, but the total cost might be quite high.
  

Re: Which embedded system would you use?
Quoted text here. Click to load it

Should be fine in either case.  Even real time PID controller can
adjust with a few delayed samples.

Quoted text here. Click to load it

That's why I suggested data collection agents between master and
slaves.  The agents collect and time stamp the data before following
to the master.  The system would have to time-sync them and/or keep
track of time differences.  Several samples can be packed in a single
packet before transmission.

Quoted text here. Click to load it

Full speed USB is cheap and good enough for this.

Re: Which embedded system would you use?
On May 18, 10:55A0%am, Simon Clubley <clubley@remove_me.eisner.decus.org-
Earth.UFP> wrote:
Quoted text here. Click to load it

You must have fully interrupt driven bulk transfer, not polling, and
not running on window.  The polling interval defines how often window
polls the controller, but you can get better response time by
interrupts.

Re: Which embedded system would you use?
Quoted text here. Click to load it

Yes, I've now looked through the EHCI spec itself and found the async
capability in the spec although I have not found anything about the minimum
latency achievable yet.

Up until now, my detailed (register/data structure level) knowledge was
restricted to the UHCI spec although I was aware of some (but not all as
it turns out :-)) of the additional features available with EHCI
controllers.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Which embedded system would you use?
On May 19, 12:05A0%pm, Simon Clubley <clubley@remove_me.eisner.decus.org-
Earth.UFP> wrote:
Quoted text here. Click to load it

The minimum latency is a reasonable compromise of all universal
devices; namely, all devices must meet this requirement.  Furthermore,
it specify the max. polling overheads on the host side.  These are
general rules, but more like guidelines anyway.  However, if you know
your hosts and devices, you can push beyond that.  Of course, it would
not be universal anymore, but who cares.

In our case, we are using one host to one device pair.  So, our host
controller has nothing better to do then to poll the device constantly
anyway.


Site Timeline