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.91.97 with SMTP id cd1mr2699696obb.33.1409243296609; Thu, 28 Aug 2014 09:28:16 -0700 (PDT) X-Received: by 10.50.29.13 with SMTP id f13mr145357igh.15.1409243296508; Thu, 28 Aug 2014 09:28:16 -0700 (PDT) Path: buffer2.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!r2no9272853igi.0!news-out.google.com!ef6ni1325igb.0!nntp.google.com!r2no9272849igi.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 28 Aug 2014 09:28:15 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=108.69.213.73; posting-account=qZVz2QoAAAAN9WxYp-9jYb7jORc4Zqwt NNTP-Posting-Host: 108.69.213.73 References: <60a42dc6-d8d0-4432-ae5a-86de18b82840@googlegroups.com> <5kkrv9hejn2qhdckkeo8lidkbh3bkme1gn@4ax.com> <5b91313c-acf9-4a6e-b157-6ba7c8021567@googlegroups.com> <0513ad07-6fbe-463a-be6f-097cd5113f52@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <4f1ec65a-d66a-40bf-a0d6-278fde206e70@googlegroups.com> Subject: Re: STM32F4 Discovery, communication and libraries From: Mike Silva Injection-Date: Thu, 28 Aug 2014 16:28:16 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: number.nntp.dca.giganews.com comp.lang.ada:188700 Date: 2014-08-28T09:28:15-07:00 List-Id: On Thursday, August 28, 2014 6:00:12 AM UTC-7, Dmitry A. Kazakov wrote: > On Thu, 28 Aug 2014 03:12:16 -0700 (PDT), Roy Emmerich wrote: >=20 >=20 >=20 > > I want to use a finite state machine (FSM) approach. There will be a >=20 > > supervisor module which will instantiate sub-modules which communicate >=20 > > with peripherals. Each sub-module will be a separate sub-FSM, reporting >=20 > > its state to the supervisor. Each sub-module will make use of a protoco= l >=20 > > library (e.g. MODBUS RTU) and a hardware driver library (e.g. UART over >=20 > > RS485/232) to communicate with devices. >=20 > >=20 >=20 > > That is it. No OS, no middleware. >=20 >=20 >=20 > It is difficult to imagine working. Do you know how ModBus function? It i= s >=20 > basically a client-server protocol. You send a request, e.g. F15 and then >=20 > read the response. Whether the request is a read or write request does no= t >=20 > matter. Most of ModBus end devices are half-duplex. Which means one reque= st >=20 > at a time. Many have internal cycles and interlocking which make things >=20 > much slower than the physical I/O already did. Some would crash if you >=20 > queried too frequently. >=20 >=20 >=20 > Anyway, without an OS you will have to wait for the response to come, whi= ch >=20 > in turn, will block the whole application. It will be extremely slow. >=20 >=20 >=20 > One of the responsibilities of the OS and the middleware is to perform I/= O >=20 > on things like ModBus in background without blocking the application and >=20 > other I/O. Even a very lame board is usually much faster than any ModBus >=20 > terminal. Maybe there is some confusion being caused by the term "OS" here. Ada's co= ncurrency and realtime functionality can run on top of an OS, but it can al= so run on bare metal (an "invisible" OS?). The GNAT ARM Cortex M release d= oes have Ravenscar tasking on bare metal. > In short, an OS-less design is not suitable for handling many peripheral >=20 > devices simultaneously, especially when the devices are attached over slo= w >=20 > asynchronous communication channels. How could this be reworded to remove the "OS"? A single-task or single-thr= ead design is not suitable...?