Re: silly ravenscar question

[jan.de.kruyf@gmail.com]

On Tuesday, February 24, 2015 at 3:38:17 PM UTC+2, Dmitry A. Kazakov wrote:

> 
> 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 synchronous,
> 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.
> 

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 above
> the PDU level.
> 

Its a code museum, something like windows or linux, i386 - today, nothing can be thrown away, but everybody had clever ideas along the way.

> 
> I understood your question as if somebody would be interested in an open
> platform to design terminals. 

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, incremental
> decoders, oversampling ADC (Beckhoff's have systematic design flaw).
> 
> This one
> 
>    http://www.secureplugandwork.de/servlet/is/10291/
> 
> could take use of such a platform. Presently it is BeagleBone.
> 

I read through it, I would be very interested in any of that. But I am a prophet of a different age though. "strip it to the bone and see what we really 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 steppermotors, the display and keyboard (in software off course), path calculation, calculating 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...
> 

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 constructs (timewise) that can be done simpler with little overhead. When stepping through a new piece of code I have a habit of keeping the assembly window open. It is quite an education.

cheers

jan.