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.182.246.73 with SMTP id xu9mr1928238obc.17.1424854123064; Wed, 25 Feb 2015 00:48:43 -0800 (PST) X-Received: by 10.140.104.174 with SMTP id a43mr26442qgf.2.1424854122962; Wed, 25 Feb 2015 00:48:42 -0800 (PST) Path: border2.nntp.dca1.giganews.com!nntp.giganews.com!hl2no29203072igb.0!news-out.google.com!c1ni195qar.1!nntp.google.com!j7no6409043qaq.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 25 Feb 2015 00:48:42 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=105.210.0.209; posting-account=orbgeAkAAADzWCTlruxuX_Ts4lIq8C5J NNTP-Posting-Host: 105.210.0.209 References: <8e30f54c-81c4-4861-897c-bb6c563c76e8@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: silly ravenscar question From: jan.de.kruyf@gmail.com Injection-Date: Wed, 25 Feb 2015 08:48:42 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: number.nntp.giganews.com comp.lang.ada:192335 Date: 2015-02-25T00:48:42-08:00 List-Id: On Tuesday, February 24, 2015 at 3:38:17 PM UTC+2, Dmitry A. Kazakov wrote: >=20 > It is OK for most applications, but might be not OK for the transport > layer. It depends on the protocol architecture. If you have it synchronou= s, > chained, triggered in a way EtherCAT is, then latencies of the terminals > tend to accumulate and you need much tighter cycles to come at 1ms of > overall performance. If it is asynchronous, that solves a lot of issues, > but becomes non-real-time. >=20 Let me mess around for a bit before I shoot off my mouth . . . > It is a mess regardless. If I ran the circus I would throw everything abo= ve > the PDU level. >=20 Its a code museum, something like windows or linux, i386 - today, nothing c= an be thrown away, but everybody had clever ideas along the way. >=20 > I understood your question as if somebody would be interested in an open > platform to design terminals.=20 I was just in a sharing mood, since it helps to find the bugs, and get more= ideas. Customer pays, otherwise no specific business plan as yet. > Yes, there are some of terminals we could > develop and sell to our customers - special signal generators, incrementa= l > decoders, oversampling ADC (Beckhoff's have systematic design flaw). >=20 > This one >=20 > http://www.secureplugandwork.de/servlet/is/10291/ >=20 > could take use of such a platform. Presently it is BeagleBone. >=20 I read through it, I would be very interested in any of that. But I am a pr= ophet of a different age though. "strip it to the bone and see what we real= ly need" otherwise no realtime stuff will ever be build. So if you could bear with all my questioning accepted wisdom then, yes. As a bit of background many years ago I did a multi-threaded system on one = of the early pic controllers. there was the soft-stepping of 2 steppermotor= s, the display and keyboard (in software off course), path calculation, cal= culating the s-curve for accel/decel and what not. All in assembly. did the= hardware and the software. All in 16 MHz. clock. There have been many more interesting and challenging projects off course, = just that then I also did a reasonable size project alone, and well beyond = the accepted wisdom of the day. I remember then already also you saw those = big eproms in embedded boxes full of bloatware. > No. Our system deploys full Ada 2005 (e.g. on a BeagleBone). I cannot > imagine EtherCAT master or the middleware data distribution layer in > Ravenscar. It is beyond my feeble imagination... >=20 I think I have a plan for my immediate problem, but if you could let me see= some spec with data volumes and timing restraints, I would be in a better = position to comment. What I would say though is that Ada has quite a few rather expensive constr= ucts (timewise) that can be done simpler with little overhead. When steppin= g through a new piece of code I have a habit of keeping the assembly window= open. It is quite an education. cheers jan.