From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.52.236.196 with SMTP id uw4mr7114260vdc.2.1424940481929; Thu, 26 Feb 2015 00:48:01 -0800 (PST) X-Received: by 10.140.37.113 with SMTP id q104mr112384qgq.0.1424940481854; Thu, 26 Feb 2015 00:48:01 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!i13no8052774qae.0!news-out.google.com!c1ni200qar.1!nntp.google.com!j7no7378521qaq.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 26 Feb 2015 00:48:01 -0800 (PST) In-Reply-To: <14r7a7x3kyv4t.13luzs6ukxqiq$.dlg@40tude.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=105.236.75.241; posting-account=orbgeAkAAADzWCTlruxuX_Ts4lIq8C5J NNTP-Posting-Host: 105.236.75.241 References: <8e30f54c-81c4-4861-897c-bb6c563c76e8@googlegroups.com> <14r7a7x3kyv4t.13luzs6ukxqiq$.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <647ebb7f-61fd-4e36-b047-3207ea789807@googlegroups.com> Subject: Re: silly ravenscar question From: jan.de.kruyf@gmail.com Injection-Date: Thu, 26 Feb 2015 08:48:01 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:25042 Date: 2015-02-26T00:48:01-08:00 List-Id: On Wednesday, February 25, 2015 at 7:55:59 PM UTC+2, Dmitry A. Kazakov wrot= e: >=20 > Normally, high-speed channels are not used for control, it means that we > don't need to react each 0.1ms, but we must catch each value, stamp it an= d > pass further, e.g. to the data logger or to the software oscilloscope. >=20 > > in any case to focus the thinking, I did some quick sums: > > A packet with a payload of 50 bytes, according to the theory should be > > able to do the roundtrip (100 m cable, 1 switchbox, no packet contentio= n) > > in 25 usecs through an stm34 board, with time to spare. that includes D= MA > > and offloading and onloading of data. >=20 > > So that makes 40 packets per msec. Leave some space for syncframes, arp > > frames and data loss, then 20 roundtrip packets /msec should be doable, > > provided the jitter is strictly controlled.=20 > > An individual terminal has all the time in the world to handle the data > > between commframes, but I bet that, depending on what you want out of t= he > > system, the pc might feel the strain at that rate. (and the rt scheme m= ust > > be up to scratch in the pc) >=20 > We managed 0.2ms with 4 channels without oversampling, transported over X= CP > under VxWorks. XCP is a UDP-based protocol. The data were coalesced into > one frame. >=20 what processor, what clockspeed, what net topology? But it is probably as good as it gets with prefab software.=20 openPowerlink was reported to have a latency up to 450usecs Sync to 1st. Re= sponse between 2 VIA Nehemiah processors running at 1GHz with linux-RT. The= main reason I dropped it. Off course modern boards are better, but I also = have to deal with STM running at 168MHz >=20 > This is one case when you trade latencies for throughout. In other cases > latencies are more important, e.g. for control and for time > synchronization. The latter is the weakest spot of all existing field > buses. Most of them do not have any, others have a garbage clock > synchronization, like EtherCAT's distributed clock is. >=20 STM implements the hardware for Precision time protocol IEEE1588 PTP. So its up to me to implement the software properly. It promises precision i= n the sub usec range. Personally I think its quite doable, provided the lat= ency from packet arrival through software has little or no jitter. Otherwise I do not see great problems getting your data collection issue so= rted out. But we might forgo on CAN and the like until we really need it (i= .e at the interfacing with the data-digesting software. The numbers I gave you are definitely squeezable, that was just a budget. The pc side is another kettle of fish though. There is a software stack aro= und that promises things like 10usec cycletime on RTAI but there is no indi= cation of the packet size or the net topology.=20 But then there is still the digesting of the data. Do you plan to store a s= ample in memory for some time? any hardrive activity will most likely bug t= he cycle response, unless you have a dual port plugin that does nothing but= comms and temp storage, until it can get DMA'ed to the main board. Ok time for some real work, cheers, j.