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.42.90.209 with SMTP id l17mr856158icm.34.1409330872963; Fri, 29 Aug 2014 09:47:52 -0700 (PDT) X-Received: by 10.140.94.34 with SMTP id f31mr26590qge.11.1409330872919; Fri, 29 Aug 2014 09:47:52 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!r2no10036977igi.0!news-out.google.com!q8ni3qal.1!nntp.google.com!i13no4177149qae.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 29 Aug 2014 09:47:52 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=77.8.91.83; posting-account=Fmp50goAAAA9sbkA2aX-X9YQy6-lkg3J NNTP-Posting-Host: 77.8.91.83 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> <4f1ec65a-d66a-40bf-a0d6-278fde206e70@googlegroups.com> <1cjwzr30b24xy.11kpydntxhfo5$.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <929e9226-e4aa-474e-843c-68ed800eefad@googlegroups.com> Subject: Re: STM32F4 Discovery, communication and libraries From: Roy Emmerich Injection-Date: Fri, 29 Aug 2014 16:47:52 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:21989 Date: 2014-08-29T09:47:52-07:00 List-Id: On Friday, 29 August 2014 15:06:07 UTC+2, Dennis Lee Bieber wrote: > It works if the entire system including the "user application" level is > built "as one". It is NOT a very dynamic arrangement wherein you may plug > in a new sensor and have it magically install itself to some list of > sensors to be reported. My requirements for dynamic behaviour don't extend so far as to be plug and= play ready. What I do want, being a modular hardware platform, is to defin= e, in a configuration file, which hardware modules are plugged into which s= ocket. At start up the supervisor will read this file and instantiate the r= elevant software modules. To get an idea of what the hardware I am using looks like, take a look at t= his image: http://www.mikroe.com/img/development-tools/arm/stm32/stm32f4-discovery-shi= eld/gallery/stm32f4_discovery_shield_04.png On Friday, 29 August 2014 17:59:49 UTC+2, Niklas Holsti wrote: > Even within Ravenscar constraints, one can build > very dynamic task interactions, which is nice for implementing stuff in > a Ravenscar system, but which makes schedulability analysis difficult. Keep in mind too what I intend to use this device for and the competition I= am up against. Here is a short elevator pitch: I am a renewable energy engineer and I want, initially, to use this device = as a data aggregator/controller in off-grid energy systems (also called hyb= rid systems). These systems are normally powered by more than one renewable= source (e.g. wind/solar) and often include a backup generator. They consis= t of many different power electronic devices which often stem from differen= t manufacturers (read different communication protocols). This device will = effectively aggregate the data from all of these devices into one, unified = format and send control signals to the generator/inverters. Systems range f= rom a few kilowatts to hundreds of kilowatts. It is naturally feasible to c= onsider connecting up meteorological equipment to the same logger as well a= s other devices I probably haven't thought of yet. Modular is the operative= word here. As these systems are often remote it is important for my aggregator to be r= eliable and able to function even when the off-grid system is not. For that= reason I want to independently power it, making it important for it to be = a low power device (e.g. much less than say a beaglebone black embedded Lin= ux board), able to run on a battery for at least 3 days, preferably much mo= re and be connected to its own solar panel. It must keep accurate time (syn= cing once a day via GPS) and (periodically/in emergency) make the data avai= lable remotely (via GPRS). My competitors are: * Low end - The Arduino gang (cheap, anything is possible, professionalism = is normally lacking but wires not) * In the middle - A myriad of small to medium companies providing domain sp= ecific solutions (functionality normally too limited, hardware not extendib= le) * High end - PLC manufacturers (normally too expensive) Let's be frank. This is not a satellite. I WON'T be doing any schedulabilit= y analyses. My Ada learning journey continued today. Quoting once again from: Guide for the use of the Ada Ravenscar Profile in high integrity systems=20 http://www.sigada.org/ada_letters/jun2004/ravenscar_article.pdf=20 =3D=3D=3D=3D=3D=3D=3D=3D Extract start =3D=3D=3D=3D=3D=3D=3D=3D 5. Examples of Use ... In the first eight sections of this chapter we give examples that illustrat= e the straightforward use of Ravenscar. After that, in sections 5.9 to 5.12= , we show how Ravenscar can deal with requirements that would appear to lie= outside the scope of what is supported by the Profile. ... 5.12 Further Expansions to the Expressive Power of Ravenscar If static timing analysis is not of interest to the application program and= a more general model of tasks and interrupts is required, this can still b= e achieved with reasonable expressive power within the subset definition. H= owever, as noted earlier, Ravenscar is not a substitute for the full langua= ge when that level of expressive power is needed. * Dynamic creation and termination of tasks can be simulated by declaring a= pool of event-triggered tasks at program start-up, each containing an infi= nite loop which has a suspending operation as its first statement, such tha= t its execution can be invoked dynamically by one of the task synchronizati= on primitives. Thus, by changing the settings of suspension objects and ent= ry barriers, it is possible for certain tasks to have their execution disab= led whilst others have execution enabled. =3D=3D=3D=3D=3D=3D=3D=3D Extract end =3D=3D=3D=3D=3D=3D=3D=3D Today Ada seems like a very good fit, no?