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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: Ada for Automation
Date: Tue, 18 Nov 2014 14:24:28 +0100
Organization: cbb software GmbH
Message-ID: <vpxvksgecwo4$.1kt24yph3k6gb.dlg@40tude.net>
References: <3e877e3f-c9ad-48a5-941d-08a7f5c3f317@googlegroups.com>
 <m4f190$hhq$1@dont-email.me> <18cxzhton11yu.1s3cu5zea772b.dlg@40tude.net>
 <m4f7p3$7lt$1@dont-email.me> <1uhe64g68og8k.16z0icy3wfdhu.dlg@40tude.net>
 <m4fdt8$tfc$1@dont-email.me>
Reply-To: mailbox@dmitry-kazakov.de
NNTP-Posting-Host: nyHeW7QjJmC1odUjK4LkDA.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: 40tude_Dialog/2.0.15.1
X-Notice: Filtered by postfilter v. 0.8.2
Xref: news.eternal-september.org comp.lang.ada:23521
Date: 2014-11-18T14:24:28+01:00
List-Id: <comp.lang.ada>

On Tue, 18 Nov 2014 13:27:49 +0100, Björn Lundin wrote:

> However, what I meant was that the OP's library would be very
> interesting if I
> 
>>>> .... was given the opportunity to do conveyor system logic
>>>>in say a raspberry pi, I'd definitely would look closer to you
>>>>project.
> 
> That is if I was to control motors and read inputs myself.
> But there seem to be no market for that, unless you supply the
> hardware - as in conveyors/cranes/AGV ets - yourself.

Actually market exists, but it demands a tool chain based rather on models
like SIMULINK than on programming in a decent language.

I know that AdaCore has a product that allows Ada code generation from
SIMULINK models. Together with a middleware to access the hardware and
providing a protocol to communicate the outer world that would get you a
product wich many would buy, since existing alternatives are very expensive
and oriented on hardware vendor lock.

The drawback of such approaches is that they target series products, while
major customers come from R&D. For R&D guys code generation is a very
heavy-weight thing. It requires compiler-linker-uploader tool chain on the
host side and it is too slow for rapid tests and prototyping. Performance
on the controller side is not so critical as portability and speed. If the
controller is portable everything could be done first on a fat i7 and only
then transferred to the board. Thus a far better solution would be some
binary code target uploaded directly into the controller over the network
protocol. Not Java binary code, of course, but something much simpler.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de