"Make With Ada" Competition

[Kalvin]

For those interested in [ARM] microcontrollers and the Ada programming language:

http://www.makewithada.org/

"Make with Ada is an embedded software project competition sponsored by AdaCore. It is open to individuals and small teams using the Ada or SPARK languages to develop dependable, open, inventive and collaborative projects on ARM Cortex M or R processors."

It seems that the compiler and run-time libraries support mainly the STM32F4 processors.

[Xenoamor]

Ada looks pretty awkward to optimise. What's the merrits of this over C/C++?

[Kalvin]

Ada looks pretty awkward to optimise. What's the merrits of this over C/C++?

Ada is designed to be more robust programming language compared to C/C++. Ada provides strict compile-time type checking and optionally run-time checking for variables and array boundaries, for example. The C/C++ provides very little compile-time type checking and almost no run-time checking whatsoever.  The Ada language has also a notation for a Task. Also the optional run-time exception handling is built in the language (Yes, C++ has it now too).

The SPARK is Ada subset of the language, and it is targeted for those mission critical applications that needs to be proven correct.

I am no expert in Ada by any means, but I have been paying attention to its development as I grew up in the Pascal/Modula ie. Wirth-language age.

[nctnico]

Ada has been on my radar as well for a while. IMHO a good reason for using it is for writing more robust programs without needing to think about all the traps and sinkholes C has to offer.

[tggzzz]

Ada looks pretty awkward to optimise. What's the merrits of this over C/C++?

Its designers understand their creation. The C++ designers refused to believe http://www.informit.com/articles/article.aspx?p=30667 until their faces were rubbed in the working code. If the designers don't understand their creation, what chance have mere users?

There's no equivalent of the C++ FQA http://yosefk.com/c++fqa/ because there's no need for there to be.

[rstofer]

That's a pretty good FQA!

If I use GNU Ada, I can link with ASM, C, C++ (I think) and Fortran code.  It's all in the family.  I'm not sure I get that flexibility with any other toolchain.

[dferyance]

Its designers understand their creation. The C++ designers refused to believe http://www.informit.com/articles/article.aspx?p=30667 until their faces were rubbed in the working code. If the designers don't understand their creation, what chance have mere users?

The C++ language was designed to provide tools that could be a number of ways instead of only solving one specific purpose. This is why it supports multiple inheritance while many other languages do not. It wasn't about telling you, you must do OOP, or you must program one way. The downside is that it makes it even easier to be stuck in your ways and never learn something better. It also can easily be abused, but that is one of the tradeoffs. Compare it to Java that forces you to do no more than one public class per file. Just a very different design philosophy.

There's no equivalent of the C++ FQA http://yosefk.com/c++fqa/ because there's no need for there to be.

There is plenty that frustrates me about C++ but the FQA is mostly nonsense. For an example "I don't like C++ classes.". Ok, yeah whatever.

[tggzzz]

Its designers understand their creation. The C++ designers refused to believe http://www.informit.com/articles/article.aspx?p=30667 until their faces were rubbed in the working code. If the designers don't understand their creation, what chance have mere users?

The C++ language was designed to provide tools that could be a number of ways instead of only solving one specific purpose. This is why it supports multiple inheritance while many other languages do not. It wasn't about telling you, you must do OOP, or you must program one way. The downside is that it makes it even easier to be stuck in your ways and never learn something better. It also can easily be abused, but that is one of the tradeoffs. Compare it to Java that forces you to do no more than one public class per file. Just a very different design philosophy.

None of which addresses the point: c++ is so complex that even its creators don't understand it. That's  a damning indictment. That it is still true is indicated by the preponderance of c and c++ language lawyers.

The tool has become part of the problem, rather than the solution. If c++ is the answer, then check you are asking the right question.

There's no equivalent of the C++ FQA http://yosefk.com/c++fqa/ because there's no need for there to be.

There is plenty that frustrates me about C++ but the FQA is mostly nonsense. For an example "I don't like C++ classes.". Ok, yeah whatever.

There is a very uncomfortable number of truths in that fqa.

[nctnico]

There is a very uncomfortable number of truths in that fqa.

Nobody cares because it is just an informative as saying 'you shouldn't use a hammer because you can hit your fingers'.

Lets get back to Ada: it would be nice to get some pointers towards some introductions into the Ada language.

[tggzzz]

There is a very uncomfortable number of truths in that fqa.

Nobody cares because it is just an informative as saying 'you shouldn't use a hammer because you can hit your fingers'.

That always has been a jackass statement, from those that don't want to improve.

It is about as sensible as saying "my grandfather didn't wear ear/eye protectors, so there's no need for me to".

[nctnico]

Still there is no need to bring up the disadvantages of the old tool when discussing the new tool.

[tggzzz]

Still there is no need to bring up the disadvantages of the old tool when discussing the new tool.

See the second message in this thread, https://www.eevblog.com/forum/microcontrollers/%27make-with-ada%27-competition/msg966811/#msg966811

Questioning whether it is worth learning a new tool is absolutely vital, even if you then choose to continue using the old tool.

[dferyance]

There is a very uncomfortable number of truths in that fqa.

No one should ever be uncomfortable when something they use gets criticized. I love picking out flaws in things I use and love myself.

Clearly C++ isn't for you. That's ok. I have used quite a number of different programming languages with different success. Good thing is there are plenty of alternatives.

Quite similarly, Ada isn't for me. I have done plenty of work in pascal to know that I don't enjoy languages like that. After trying haskell, I cannot help but yawn when I see something that verbose. But I respect the static type checking and trying to have things in place to verify that the application is correct. More power to people who do like it. It is always cool to see something get re-purposed.

[nctnico]

I'm not a fan of Pascal either but still I wouldn't dismiss Ada because of that without looking into it seriously. I'm also doing a reasonable amount of VHDL work and it takes some getting used to doing things in a smart way so a small amount of code does a lot. AFAIK Ada is derived from Pascal so I guess they took a lot of bad 'Pascal' things out of it. After all Pascal was invented to learn (force) people how to program in a structured manner. Pascal was never intended to be used as a programming language for large production software projects so no wonder it sucks (understatement) for that purpose.

[andersm]

The C/C++ provides very little compile-time type checking and almost no run-time checking whatsoever.

You can have both, if you want. User-defined types can prevent the automatic type conversions of the primitive types, and by not using pointers you can have all the bounds checking you want. For example, in STL the idiom for containers supporting random access is that the at() member function uses bounds checking, while operator[] does not.

[nctnico]

The C/C++ provides very little compile-time type checking

This depends largely on the compiler settings. Modern gcc and g++ (the GNU C and C++ compilers) are extremely anal when it comes to type checking. You really have to use casts to prevent at least warnings unless you use void pointers for everything but that would be poor programming practise. If you make a habit of using pointers with a specific type then gcc/g++ will catch all type mismatches.

[tggzzz]

There is a very uncomfortable number of truths in that fqa.

No one should ever be uncomfortable when something they use gets criticized. I love picking out flaws in things I use and love myself.

Clearly C++ isn't for you. That's ok. I have used quite a number of different programming languages with different success. Good thing is there are plenty of alternatives.

Oh, I've been using C since 1981, when there were precisely two books available, K&R and the Puzzle book. A great tool for some problems.

I have a great respect for C as it was originally intended - but over the decades it has mutated into a cancerous growth. When "const" was being introduced into the language, I remember the endless (and fundamentally unresolvable) dichotomy as to whether it should be possible or impossible to "cast away constness". At that point I realised the tool was becoming baroquely complex.

C++ I never liked, having first tried it in 1988. It was faster to get a more reliable product using either Objective-C or Smalltalk. When Java appeared, the depth and quality of libraries available rapidly outstripped those that hadn't become available for C++ in ~10 years.

And then I remember someone proudly announcing the release of the first full C++98 compiler about six years after the standard was produced. A big clue that something is wrong.

Quite similarly, Ada isn't for me. I have done plenty of work in pascal to know that I don't enjoy languages like that. After trying haskell, I cannot help but yawn when I see something that verbose. But I respect the static type checking and trying to have things in place to verify that the application is correct. More power to people who do like it. It is always cool to see something get re-purposed.

If I'm allowed to produce an incorrect result, then my Ada/Java/Smalltalk/bash program will be much much faster than your C++ program

[Sal Ammoniac]

Pascal was never intended to be used as a programming language for large production software projects so no wonder it sucks (understatement) for that purpose.

Back when Pascal was the only reasonable development language on the PC (Turbo Pascal circa 1983) I wrote production applications of tens of thousands of lines of code in it. I thought it was a good language at the time. I did, however, switch to Turbo C as soon as it came out.

[westfw]

It's been a long time since I've looked seriously at Ada, so my impressions may be out of date, but here they are anyway...

Ada was essentially the last of the "mainframe" languages, designed in a time where new languages "needed" to be all things for all people, potentially replace all other languages (especially proprietary languages like PL/1), meet the needs of computer scientists, business programmers, and scientific programmers, and (therefore) included vast runtime libraries amd significant dependence on OS services as part of the language definition.  Cost was no object - compilers were priced extremely high, but most often were part of multi-million-dollar deals for mainframe installations, or gifts to universities.  Personal Computers barely existed, microcontrollers were mask programmed, and either one was laughable for the disk or run-time footprint of a "real language" (You had your assembler and you had your BASIC interpreters...)

There followed a decade or so when the micro and personal computer worlds pretty much ignored anything that had been learned in the Mainframe world, and the mainframe folk seemed to believe that these newcomers were mere toys that wouldn't affect them.  Heh. :-(

Time has passed and things are different.
It's nice that Ada is appearing on PCs and in embedded environments.  It's nice that the specs have been refined so that it can.  It's nice that there's a free OSSW compiler with various targets.  I don't know that I'll ever be convinced that "big languages" are inherently better, but it's not an unreasonable experiment, and I applaud the contest.

It says in the GNAT FAQ ( http://libre.adacore.com/tools/gnat-gpl-edition/faq/ ) that the free version of the compiler/etc can ONLY be used to develop free Open Source software (compiler, runtime, and libraries all full GPL, not LGPL or anything.)  That seems ... less than attractive.
Quote>What is the license of the GNAT GPL Edition?
 Everything (tools, runtime, libraries) in the GNAT GPL Edition is licensed under the General Public License (GPL). This ensures that executables generated by the GNAT GPL Edition are Free Software and that source code is made available with the executables, giving the freedom to recepients to run, study, modify, adapt, and redistribute sources and executables under the terms of the GPL.
 I would like to release my software under the ABC license, which is incompatible with the GPL. What should I do?
 If the ABC license is a Free Software license according to the FSF, then read the following Q&A. If the ABC license is not a Free Software license then it is the intention of the GPL distribution of GNAT to restrict your freedom. For distribution of proprietary software, we suggest and recommend the use of GNAT Pro, which, while still being Free Software, comes with more liberal licensing permitting this kind of use.

[nctnico]

It says in the GNAT FAQ ( http://libre.adacore.com/tools/gnat-gpl-edition/faq/ ) that the free version of the compiler/etc can ONLY be used to develop free Open Source software (compiler, runtime, and libraries all full GPL, not LGPL or anything.)  That seems ... less than attractive.

That is a major fail in my book. Keeping libraries under GPL is the road to nowhere since nobody will use them.

[westfw]

(note that their "pro" version has a modified license...)
("Pricing for GNAT Pro subscriptions starts at $15,000" : http://www.electronicsworld.co.uk/news/archive/3087-adacore-launches-new-version-of-gnat-programming-studio- )

[nctnico]

(note that their "pro" version has a modified license...)

Yes, but no pricing information to be found. Only a form to request a quote. Usually this means they want a trillion gazillion dollars per year for a node locked time limited license. Funny that some companies still have a sales prevention team! If they release the Ada libraries etc under LGPL they could make money by selling the development tools.

[Kalvin]

Lets get back to Ada: it would be nice to get some pointers towards some introductions into the Ada language.

The competition page has some pointers to the tutorials and the getting started material:
http://www.makewithada.org/getting-started

For the historically reasons Ada has been underdog: The first compilers were very expensive, compilation time was veeeeery slow, compilers run on expensive workstations, produced not-so-optimized code, only few architectures were supported, the Ada was plagued with the military-only stigma and the first versions of the language missed some useful features. The current Ada versions and Ada profiles provide good support for the embedded design as some of the bulkier features can be removed selecting the right language profile. Object orienting programming and generic programming (quite similar to C++ templates) is are well supported.

I will take this competition as an opportunity to take a closer look at Ada, although I will not take part of the competition. Just a good excuse to try Ada out on real embedded hardware.

[nctnico]

The absence of LGPL libraries has made me lose interest completely. I think my time will be better spend on embedded Lua.

[Kalvin]

The absence of LGPL libraries has made me lose interest completely. I think my time will be better spend on embedded Lua.

Depending of where you obtain your compiler, the run-time libraries are in GPL, GNAT Modified General Public License (GMGPL) or something else. In my understanding the GMGPL is similar to the LGPL which permits the run-time library static linkage to a proprietary application.

If I understood correctly, typically the public interface of the Ada run-time library is GPL, but the code generating part or the run-time library can be GPL, GMGPL or somehing else (see above), so you may be able to perform the static linkage similar to the LGPL.

[tszaboo]

OK, let me know when  there is dynamically typed, event driven, visually programmable, subjective COBOL for ARM, than maybe I will not use C.

[Mechatrommer]

another C/C++ vs others combats, "everybody should drive automatic transmission car because manual transmission car you can give the wrong output" do you see any C/C++ embedded competition to increase awareness? nope because everybody are already well aware what C/C++ can do, except some champions in this thread. how many time do i have to tell, want a runtime checking? program in Basic!

[Xenoamor]

Is this not needlessly verbose?

Code: [Select]

package body Program is

   procedure Run is
   begin
      loop
         null;
      end loop;
   end Run;

end Program;I.e.

Code: [Select]

void run(void)
{
    for (;;)
    {
    }
}
Looking more in depth I could see why this would be appealing for industrial machinery. It seems harder to 'get wrong'. Seems a little clunky for handling memory addresses directly though
Personally I feel I wouldn't enjoy programming in such a strict language but it's not all about enjoyment

[Mechatrommer]

Code: [Select]

void run(void)
{
    for (;;)
    {
    }
}

competition sake i prefer...

Code: [Select]

void run() { for (;;) {} }

[Kalvin]

Code: [Select]

void run(void)
{
    for (;;)
    {
    }
}

competition sake i prefer...

Code: [Select]

void run() { for (;;) {} }

Way too verbose. Just use assembly:

Code: [Select]

run: ret


[nctnico]

no:

Code: [Select]

run: bra run;


[Kalvin]

no:

Code: [Select]

run: bra run;


Good catch This may be less verbose, though:

Code: [Select]

run: bra $


[tggzzz]

Is this not needlessly verbose?
...

I haven't cared about verbosity since the 1970s, when I was a 2-fingered typist on a very heavy and literally clunky ASR-33.

Since the 1990s verbosity has been a complete non-issue, given a decent language and a modern IDE. The most frequently typed character is "control-space", which often correctly inserts dozens of characters

[donotdespisethesnake]

Adacore are doing the "monetize Open Source tools" business model. To be fair, they developed the code originally, although with a large chunk of public money and on the condition that the code must be GPL.

However, they are very misleading to imply that the only choices are their versions of "GNAT Pro" or "GNAT GPL", and anything else is untrustworthy.

The third version is from FSF that is licensed with a less restrictive run-time exception which we have come to expect for GCC based compilers.

So I would steer clear of Adacore and go to http://www.getadanow.com/

[westfw]

The absence of LGPL libraries has made me lose interest completely.

And runtime environment.  Don't forget the run-time environment, which can be quite extensive in many languages.
I've come to suspect that the main reason that C has been such a success is that it has such a small (nearly non-existent) runtime environment, and minimal "required" libraries.  If you want to have a Fortran (or Ada) compiler for some system, you have to write an awful lot of relatively system-dependent code, NOT written in Fortran (ie probably written in assembler.)  If you want to implement a C compiler, you can almost get away with putting a C back end on your compiler, publishing an ABI (if none exists yet), and claiming to be done.  Some languages are pretty dependent on having their runtime and libraries NOT be written in the language itself, if you want good performance.  Meh.  Perhaps these days there is a "portable Fortran Runtime environment" written in C...

"Is this not needlessly verbose?"  ...  I haven't cared about verbosity since the 1970s

Wasn't that also about when we stopped equating verbosity with "quality" as well?   I mean, I hear lots of complaints about C and C++, and some of them I agree with and some not so much.   But "a language should really use keywords like "begin" and "end" instead of braces" has never been one of them.

[Xenoamor]

I haven't cared about verbosity since the 1970s, when I was a 2-fingered typist on a very heavy and literally clunky ASR-33.

I think the argument is less about typing speed and more about readability

[tggzzz]

I haven't cared about verbosity since the 1970s, when I was a 2-fingered typist on a very heavy and literally clunky ASR-33.

I think the argument is less about typing speed and more about readability

Oh, that's your point. Beyond a certain point I agree, but Ada hasn't reached that point. Obviously APL and COBOL represent opposite and unacceptable extremes

But in practice the number of characters isn't critical. Much more important is the way the program is structured/architected, the language's ambiguities and gotchas, the coder's personal style/ability (or lack thereof!) and the navigation/inference abilities built into the IDE. The last is ultimately constrained by the language, but the maturity of an IDE is also relevant.

[Kalvin]

Adacore are doing the "monetize Open Source tools" business model. To be fair, they developed the code originally, although with a large chunk of public money and on the condition that the code must be GPL.

However, they are very misleading to imply that the only choices are their versions of "GNAT Pro" or "GNAT GPL", and anything else is untrustworthy.

The third version is from FSF that is licensed with a less restrictive run-time exception which we have come to expect for GCC based compilers.

So I would steer clear of Adacore and go to http://www.getadanow.com/

Excellent info,  thanks for the link. From the link provided one can also find Ada for the AVR, Cortex-M3 and some other microcontroller architectures.

[Kalvin]

Ada looks quite verbose compared to C/C++ and some other languages. However, when you think about designing the software, typically you tend to spend quite a lot of time in designing phase (or at least you should be). You may also spend some time in the debugging phase, or much longer time if you didn't spend enough time in the design phase. The writing itself is only very small portion of the process, and the verbosity shouldn't be a problem.  There is a rationale behind Ada's verbosity, as the language and its syntax was designed so that detecting logical and typographical errors is easier to the compiler and the human.

[zapta]

There is a rationale behind Ada's verbosity, as the language and its syntax was designed so that detecting logical and typographical errors is easier to the compiler and the human.

This is for example why Ada doesn't have multi line block comments similar to C's   /* ... */

[Mechatrommer]

how many times do i have to tell, verbosity and all that human friendly crap, nothing better than Basic! otoh.. someone mentioned runtime environment, think Java everybody loooves Java, i just dont get the awareness, more so the resurrection of Ada...

[chickenHeadKnob]

Still there is no need to bring up the disadvantages of the old tool when discussing the new tool.

It is perhaps a small pedantic point, but to be correct ADA is the old(er) tool but not by much. It predates C++ by about 2 years or so. I first heard of ADA around 1981 at university. The comprehensive language spec came out in 1983. The first C++ pre-processor  came out around '83 but it was half-baked, the language took some extra years for the compilers and language spec to stabilize.  I would say stabilize guardedly as there has been a sporadic accumulation of cruft in the C++ spec over the the time span. ADA has also been revised but not to the same degree in my opinion. The biggest argument in favour  of ADA is its memory management, a whole class of common bugs is eliminated.
I don't much like either language.

[rstofer]

OK, I bought the StM32F7...Discovery board and, sure enough, ADAcore GNAT has support for it.  I'm just starting to look at the package but from what I can see, "Hello World" even when linked with the "small footprint" library is ginormous, on the order of 140k, if I am looking at the correct output file.

Anyway, the board will be here in a few days.  Now what?

[nctnico]

OK, I bought the StM32F7...Discovery board and, sure enough, ADAcore GNAT has support for it.  I'm just starting to look at the package but from what I can see, "Hello World" even when linked with the "small footprint" library is ginormous, on the order of 140k, if I am looking at the correct output file.

The size is probably due to the runtime library. You probably have to add lots of code yourself in order to increase the size significantly 

[westfw]

"Hello World" even when linked with the "small footprint" library is ginormous, on the order of 140k

You're not supposed to care.  You've got 1MB of flash and 16MB of QSPI flash to put your code into.  Plus RAM.

The question is: is that 140k fixed runtime overhead, or an indication of bloated code in general?  If helloWorld takes 140k, how big is a converted "real" application?  And how well does it run?

I'm also in the camp of "that's too big and too slow - it should be smaller and faster", whenever I look at "modern" languages.   But, you know, they also DO STUFF and create applications that would be nearly impossible to write in "bare C" (not to mention that you'd probably be spending all your time "supporting" the infrastructure code you had to write, instead of using those bloated libraries.)

[rstofer]

The code for "Hello World" itself is quite short - something around 60 bytes (I'm just guessing, the package is on another computer).  The rest is run time and, perhaps, the debug information.  I still need to do a lot of research on how the software is set up.

I want to learn Ada.  No particular reason, I'm not going to work for the military.  But the language is a lot like Pascal and I absolutely love Pascal.  I used it about a dozen years ago with an 8051 clone to create a small control system for a battery powered board.

I'm going to look through the library source code (it is provided).  It's all written in Ada and that's fine but my idea of 'small footprint' may be a lot smaller than the developers'.

Like all ARM devices, the startup code gets out of hand fairly quickly.  There are a number of clocks to set up, there's an FPU to initialize and the I & D caches.  All of this is written in Ada so there's a lot of example code to reference.

I have a lot of experience with bare iron chips and C so I'm not necessarily tied to the Ada runtime.  The GCC toolchain allows Ada to link with any of the other languages including ASM & C.

[EEVblog]

ADA? 
Were we transported back to the 1980's?

[tggzzz]

ADA? 
Were we transported back to the 1980's?

ADA is an improvement on many of its successors. (Old joke, first made about Algol-60).

Similar points can be made about Erlang (just look at how many new languages/libraries are trying to emulate its advantages) and Fortran (which still rules supreme in high-performance numerically-intensive computing).

[westfw]

There are a number of clocks to set up, there's an FPU to initialize and the I & D caches.  All of this is written in Ada

So ... how does that work?  I would have thought that the sort of type-checking and "safety" Ada is supposed to provide would make low-level initialization nearly impossible without resorting to non-Ada code.

[Kalvin]

There are a number of clocks to set up, there's an FPU to initialize and the I & D caches.  All of this is written in Ada

So ... how does that work?  I would have thought that the sort of type-checking and "safety" Ada is supposed to provide would make low-level initialization nearly impossible without resorting to non-Ada code.

Could you please elaborate this a bit more. What makes you think that Ada is less suitable for the low-level programming compared to C/C++?

[Kalvin]

ADA? 
Were we transported back to the 1980's?

Well, if you consider that the C was created in early 70's, one could say that Ada is a leap forward.

Ada is now more streamlined and modernized than it used to be, something like C/C++ has been improved over the years too. The compilers are now much better (for example, using the GCC compiler techniques and back-end for the code generation), the Ada Ravenscar profile is tailored for the embedded systems and more architectures are supported.

Maybe people are realizing the importance of the software robustness and correctness which needs to be addressed. It is quite obvious that C/C++ doesn't provide enough information for the human readers and the compilers / analyzers to check for the software correctness and runtime checks, for example. The MISRA C/C++ and similar guidelines just try to fix the broken C/C++ languages using a duct-tape, instead of fixing the language.

The Ada's type checking is quite similar to the process you would design analog/digital hardware. You will specify maximum and minimum voltages and current in the design, select the components so that they will meet the requirements and make sure that the signal interfaces between the components match to each other. Then, you would make a list of measurements that will determine whether your system will meet the design requirements and is ready for the production. From time to time you may need to calibrate your system and see that everything is still within the margins. If you should later change or replace a new component into the system you will need to check and test whether the new component still meets the system requirements. You would write the requirements in to the schematics or in to the design documentation. In Ada the requirements are specified directly in the source code and the compiler will check automatically that all requirements are satisfied during the compilation. In addition to this, there are [optional] run-time checks in Ada which will make constantly those "measurements" and see that the design meets it specifications and requirements and that the "voltages" and "currents" [variable values] are within the specified limits. If the system is not within the limits, the system can catch the exception and perform required action - instead of letting the things go unnotices and possibly outputting wrong results or making the device behave in an erratic way.

The C/C++ languages' type system could be improved by taking Ada's type system (or something else that makes possible to specify data types, numeric ranges, array index boundary checking etc. more thoroughly) and let the compiler check for the correctness during the compilation phase and the run-time. This would empower the static analyzers to perform better and find more potential problems which will now slip through unnotices with the existing sloppy, almost non-existing C/C++ type system.

I guess it might be possible to add optional syntax elements to C/C++ and keep the code backwards compatible so that the old "unsafe" C/C++ code can be used without problem and gradually improve the existing code base to use more better specified code. The improved language features could be switched on using some #pragmas as it is already done to invoke some extra language features. This would allow the designers to choose whether or not to use the strict checking and improved code quality . This would be a win-win situation, and would make C/C++ a bit better language. There would still be quite a few features in MISRA C/C++ recommendations which would still need addressed to make C/C++ more robust for applications requiring reliability, but fixing the type checking system would be a good start.

I am not stating that Ada is the ultimate solution for the more robust software, but it has a good set of features which make it possible to design more robust software compared to C/C++. Of course, there will be a lot of programmers saying that uint8_t, uint16_t, uint32_t, struct, and pointers are totally sufficient for the robust software.

[rstofer]

Embedded programming, the only kind I like to do, is done in C.  Not C++, not Java, not Python, just plain ordinary C usually without using any of the extensions to the language.  I get that!

But it is clearly possible to write to registers using Ada.  The run time library has the usual lines of ASM code but beyond that, all of the code is written in Ada.  Whether it is efficient or understandable I have yet to determine.

[tggzzz]

Maybe people are realizing the importance of the software robustness and correctness which needs to be addressed.

Or, as I like to put it, if it is acceptable that my application gives incorrect output, then I can create the application much faster than other people - and the application will also run much faster.

It is quite obvious that C/C++ doesn't provide enough information for the human readers and the compilers / analyzers to check for the software correctness and runtime checks, for example. The MISRA C/C++ and similar guidelines just try to fix the broken C/C++ languages using a duct-tape, instead of fixing the language.

Yes, but that omits considering SPARK.

(Other sensible points omitted)

[tggzzz]

But it is clearly possible to write to registers using Ada.  The run time library has the usual lines of ASM code but beyond that, all of the code is written in Ada.  Whether it is efficient or understandable I have yet to determine.

The key issue in understandability, extensibility and maintainabilty is the competence of the designers and programmers. That's true in all languages, but some languages make it more/less critical.

If it isn't correct, does it matter whether or not it is "efficient"?

[doobedoobedo]

I spend most of my time with Oracle's PL/SQL which is ADA based. Maybe it's just familiarity, but I love it.

[rstofer]

But it is clearly possible to write to registers using Ada.  The run time library has the usual lines of ASM code but beyond that, all of the code is written in Ada.  Whether it is efficient or understandable I have yet to determine.

The key issue in understandability, extensibility and maintainabilty is the competence of the designers and programmers. That's true in all languages, but some languages make it more/less critical.

If it isn't correct, does it matter whether or not it is "efficient"?

When I see a volatile pointer in C, I can often assume it is being used to address a register.  There will be a gigantic list of these pointers in a file somewhere and that's about all it takes to read/write registers - the address.

When I look at the Ada runtime code for writing registers, it is not immediately obvious how it works.  I'm still thinking about how obvious the volatile pointers were when I first saw them.  Maybe the Ada code is the same kind of thing.  Once I understand it I will view it about the same as the pointers.  But right now, I have not a clue how it works.  Clearly, that's my failing because it does work.

The important thing is that it is a learning experience.  It's a mental exercise to keep me thinking in my retirement.

[tggzzz]

The important thing is that it is a learning experience.  It's a mental exercise to keep me thinking in my retirement.

Yes, keeping senility at bay is important, and it helps that we can choose how to do that It is good to make new mistakes; I'm fed up and bored with my old mistakes.

[nctnico]

Embedded programming, the only kind I like to do, is done in C.  Not C++, not Java, not Python, just plain ordinary C usually without using any of the extensions to the language.  I get that!

If you program in C long enough you'll grow tired of adding trivial checks to your code. If you would go through C/C++ code I've written you'll find many checks for parameter ranges especially for pointers, indexes and hardware limits. It would be nice if that could be hidden/automated so the code would become less cluttered with stuff which is not dealing with what the program does. Some already mentioned the verbosity of Ada but sometimes more is actually less.

[tggzzz]

Embedded programming, the only kind I like to do, is done in C.  Not C++, not Java, not Python, just plain ordinary C usually without using any of the extensions to the language.  I get that!

If you program in C long enough you'll grow tired of adding trivial checks to your code. If you would go through C/C++ code I've written you'll find many checks for parameter ranges especially for pointers, indexes and hardware limits. It would be nice if that could be hidden/automated so the code would become less cluttered with stuff which is not dealing with what the program does. Some already mentioned the verbosity of Ada but sometimes more is actually less.

And tired of figuring out where you missed a check, or worse, where a library missed a check.

[rstofer]

Well, I have some REAL numbers:  The "Hello World" code itself is 40 bytes of code plus 12 bytes for the string.  Adding in the run time (and startup) code jacks that up to something like this:

Code: [Select]


Memory region         Used Size  Region Size  %age Used
            itcm:          0 GB        16 KB      0.00%
           flash:        2788 B         1 MB      0.27%
            dtcm:          0 GB        64 KB      0.00%
          sram12:        4120 B       240 KB      1.68%
[2016-06-25 15:34:35] process terminated successfully, elapsed time: 01.10s


Considering the complexity of the STM32F device, that flash size is just fine.  After all, the setup code is only run once and it won't get bigger as the project code expands.

[westfw]

What makes you think that Ada is less suitable for the low-level programming compared to C/C++?

Because a lot of "low level programming" in C consists of using user-defined constants as pointers to random areas of memory (ie IO registers), effectively bypassing even the limited checking that C would normally do.  Having a similar capability in Ada would seem to negate a lot of what makes it safer (although, I guess if add a high-level construct that explicitly allows, controls, and restricts such access, it would be better than having random numbers be usable as pointers in general.)   I didn't think that Ada had such a capability originally, though I guess one could have been added.  That's what I'm asking...

[westfw]

flash:        2788 B  ...   0.27%

That's VERY good.  Practically not believable.  (similar to the size of the SAMD10 LED Blink example, made with C and ASF.)
Why so different from the previous "140k" number?

[rstofer]

I don't have the answer to the register address question just yet.  I can see where the bits of the registers are declared and aligned and I can see where they are defined as a collection of bits.  But this occurs at a named constant memory address and I haven't found the definitions - yet.

It would be so much easier to search the directory tree if I were doing this stuff in Linux.  Another project...

[rstofer]

flash:        2788 B  ...   0.27%

That's VERY good.  Practically not believable.  (similar to the size of the SAMD10 LED Blink example, made with C and ASF.)
Why so different from the previous "140k" number?

That's an interesting question and I only guess at what I think I know... The compiler/linker produce a number of files including two .o files.  One is a wrapper for the run time and the other comes from my code.  After linking there are the two .o files (ELF files, actually) and a large file named 'main' with no file type.  This file is the important one.  It is run through objcopy to create main.bin - the file that ultimately gets loaded to the board if GDB isn't being used.  AFAIK (and I can't prove it because I don't have the board), this 'main' file includes everything GDB needs.

The b__main.* files are generated by the system.  The wrapper code...

That 'main' file after stripping out the nonsense is 135,068 bytes:

Code: [Select]


 Directory of c:\GNAT\2016\Projects

06/25/2016  06:02 PM    <DIR>          .
06/25/2016  06:02 PM    <DIR>          ..
06/25/2016  04:25 PM             1,046 b__main.adb
06/25/2016  04:25 PM             3,643 b__main.ads
06/25/2016  04:25 PM             2,080 b__main.ali
06/25/2016  04:25 PM             4,848 b__main.o
06/24/2016  04:30 PM             5,494 GNAT-TEMP-000001.TMP
06/25/2016  06:02 PM            35,840 gnatinspect.db
06/25/2016  06:02 PM               839 hello-loc.xml
06/25/2016  04:25 PM               817 hello.gpr
06/25/2016  04:25 PM           135,068 main
06/25/2016  04:23 PM                83 main.adb
06/25/2016  04:25 PM               758 main.ali
06/25/2016  04:25 PM               462 main.bexch
06/25/2016  03:55 PM             2,812 main.bin
06/25/2016  03:42 PM               382 main.lst
06/25/2016  04:25 PM             1,080 main.o
06/25/2016  03:34 PM            61,245 MAPFILE
              16 File(s)        256,497 bytes
               2 Dir(s)  440,862,416,896 bytes free

The only files I deal with directly are main.adb and hello.gpr and, ultimately, main.bin.  AFAIK, I will deal with 'main' only for debugging.
hello.gpr is the project file and this is where all the magic GNU compiler and linker options are contained.
 

[westfw]

BTW, from the Driver library git page:
https://github.com/AdaCore/Ada_Drivers_Library/blob/master/ARM/STM32/svd/stm32f429x/stm32_svd-usart.ads

Code: [Select]

   USART3_Periph : aliased USART2_Peripheral
     with Import, Address => USART3_Base;

Seems to be the equivalent of #define USART3_Periph ((struct USART2_Peripheral *)(USART3_Base))
The "record" definitions inside of USART2_Peripheral would look familiar enough to a Pascal programmer.  I hope they're generated automatically (which I guess I'd hope for C structure definitions of peripherals as well...)

Code: [Select]

   --  Status register
   type SR_Register_1 is record
      --  Read-only. Parity error
      PE            : Boolean := False;
      --  Read-only. Framing error
      FE            : Boolean := False;
      --  Read-only. Noise detected flag
      NF            : Boolean := False;
      --  Read-only. Overrun error
      ORE           : Boolean := False;
      --  Read-only. IDLE line detected
      IDLE          : Boolean := False;
      --  Read data register not empty
      RXNE          : Boolean := False;
      --  Transmission complete
      TC            : Boolean := False;
      --  Read-only. Transmit data register empty
      TXE           : Boolean := False;
      --  LIN break detection flag
      LBD           : Boolean := False;
      --  unspecified
      Reserved_9_31 : HAL.UInt23 := 16#6000#;
   end record
     with Volatile_Full_Access, Size => 32,
Bit_Order => System.Low_Order_First;

[rstofer]

All of the driver code is included with the distro for a number of targets.  What I haven't found is the definition of USART3_Base.

One of the neat things in the distro is an example of linking C and Ada and another project linking Fortran and Ada (I haven't studied the project file, they may be all part of one project.  That means I can write the hardware stuff in C and the higher level stuff in Ada.  I'm not sure when I would want to link Fortran and Ada but it seems pretty cool.  I still write Fortran IV from time to time.

[westfw]

What I haven't found is the definition of USART3_Base.

I think: https://github.com/AdaCore/Ada_Drivers_Library/blob/c45ca7e936b798814c954de06a67a710fdb64d03/ARM/STM32/svd/stm32f40x/stm32_svd.ads

[nctnico]

What makes you think that Ada is less suitable for the low-level programming compared to C/C++?

Because a lot of "low level programming" in C consists of using user-defined constants as pointers to random areas of memory (ie IO registers), effectively bypassing even the limited checking that C would normally do.

A lot? In embedded projects doing things with registers is only a few % of the code. Control of the hardware goes into a driver (tailored for the project at hand) which then offers an API to the rest. The only exception are I/O pins for which I generally use macros.

[andersm]

If you would go through C/C++ code I've written you'll find many checks for parameter ranges especially for pointers, indexes and hardware limits. It would be nice if that could be hidden/automated so the code would become less cluttered with stuff which is not dealing with what the program does.

That's the kind of behaviour you encapsulate in classes or templates. Even in C you can hide a lot of clutter behind interfaces.

[rstofer]

What I haven't found is the definition of USART3_Base.

I think: https://github.com/AdaCore/Ada_Drivers_Library/blob/c45ca7e936b798814c954de06a67a710fdb64d03/ARM/STM32/svd/stm32f40x/stm32_svd.ads

That is exactly the file I was looking for. The .svd files are used to create the various .ads and .adb files and the actual file for the 32F7 is:

c:\GNAT\2016\arm-eabi\lib\gnat\ravenscar-sfp-stm32f7disco\bsp\i-stm32.ads

Just what I was looking for!

[FabienC]

Hi I'm Fabien Chouteau, engineer at AdaCore and co-organizer of the Make with Ada competition.

It's great to see a thread about Ada and the competition here 

The file that Westfw shared was generated by a tool that we developed: https://github.com/AdaCore/svd2ada
SVD is an hardware description format defined by ARM. Here is a repository were you should find the SVD file for your favorite MCU https://github.com/posborne/cmsis-svd/tree/master/data

If you have questions about the competition, I can try to answer here.

Thanks,

[rstofer]

Hi I'm Fabien Chouteau, engineer at AdaCore and co-organizer of the Make with Ada competition.

It's great to see a thread about Ada and the competition here 

The file that Westfw shared was generated by a tool that we developed: https://github.com/AdaCore/svd2ada
SVD is an hardware description format defined by ARM. Here is a repository were you should find the SVD file for your favorite MCU https://github.com/posborne/cmsis-svd/tree/master/data

If you have questions about the competition, I can try to answer here.

Thanks,

Thanks for joining in!

[Sal Ammoniac]

When I look at the Ada runtime code for writing registers, it is not immediately obvious how it works.  I'm still thinking about how obvious the volatile pointers were when I first saw them.  Maybe the Ada code is the same kind of thing.  Once I understand it I will view it about the same as the pointers.  But right now, I have not a clue how it works.  Clearly, that's my failing because it does work.

Can you post an example of ADA code that accesses registers?

[FabienC]

Can you post an example of ADA code that accesses registers?

You can have a look here :
https://github.com/AdaCore/Ada_Drivers_Library/blob/master/ARM/STM32/drivers/stm32-dcmi.adb

and the registers are defined here:
https://github.com/AdaCore/Ada_Drivers_Library/blob/master/ARM/STM32/svd/stm32f40x/stm32_svd-dcmi.ads

[Sal Ammoniac]

Can you post an example of ADA code that accesses registers?

You can have a look here :
https://github.com/AdaCore/Ada_Drivers_Library/blob/master/ARM/STM32/drivers/stm32-dcmi.adb

and the registers are defined here:
https://github.com/AdaCore/Ada_Drivers_Library/blob/master/ARM/STM32/svd/stm32f40x/stm32_svd-dcmi.ads

Looks straightforward, if exceedingly verbose, to my eyes. The only thing that's not immediately obvious to me is "16#0#" -- is this the equivalent of C's 0x notation to denote hexadecimal?

[rstofer]

When I look at the Ada runtime code for writing registers, it is not immediately obvious how it works.  I'm still thinking about how obvious the volatile pointers were when I first saw them.  Maybe the Ada code is the same kind of thing.  Once I understand it I will view it about the same as the pointers.  But right now, I have not a clue how it works.  Clearly, that's my failing because it does work.

Can you post an example of ADA code that accesses registers?

Here is an example from the file s-textio.adb:

Code: [Select]

------------------------------------------------------------------------------
--                                                                          --
--                         GNAT RUN-TIME COMPONENTS                         --
--                                                                          --
--                       S Y S T E M . T E X T _ I O                        --
--                                                                          --
--                                 B o d y                                  --
--                                                                          --
--          Copyright (C) 1992-2016, Free Software Foundation, Inc.         --
--                                                                          --
-- GNAT is free software;  you can  redistribute it  and/or modify it under --
-- terms of the  GNU General Public License as published  by the Free Soft- --
-- ware  Foundation;  either version 3,  or (at your option) any later ver- --
-- sion.  GNAT is distributed in the hope that it will be useful, but WITH- --
-- OUT ANY WARRANTY;  without even the  implied warranty of MERCHANTABILITY --
-- or FITNESS FOR A PARTICULAR PURPOSE.                                     --
--                                                                          --
--                                                                          --
--                                                                          --
--                                                                          --
--                                                                          --
-- You should have received a copy of the GNU General Public License and    --
-- a copy of the GCC Runtime Library Exception along with this program;     --
-- see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see    --
-- <http://www.gnu.org/licenses/>.                                          --
--                                                                          --
-- GNAT was originally developed  by the GNAT team at  New York University. --
-- Extensive contributions were provided by Ada Core Technologies Inc.      --
--                                                                          --
------------------------------------------------------------------------------

--  Minimal version of Text_IO body for use on STM32F7x, using USART6.
--  Serial interface is available via the arduino port of the board:
--  PIN D0 (PC7 GPIO): USART6_RX
--  PIN D1 (PC6 GPIO): USART6_TX

with Interfaces; use Interfaces;

with Interfaces.Bit_Types;   use Interfaces.Bit_Types;
with Interfaces.STM32.RCC;   use Interfaces.STM32.RCC;
with Interfaces.STM32.GPIO;  use Interfaces.STM32.GPIO;
with Interfaces.STM32.USART; use Interfaces.STM32.USART;
with System.STM32;           use System.STM32;
with System.BB.Parameters;

package body System.Text_IO is

   Baudrate : constant := 115_200;
   --  Bitrate to use

   ----------------
   -- Initialize --
   ----------------

   procedure Initialize is
      use System.BB.Parameters;

      APB_Clock    : constant Positive := Positive (STM32.System_Clocks.PCLK2);
      Int_Divider  : constant Positive := (25 * APB_Clock) / (4 * Baudrate);
      Frac_Divider : constant Natural := Int_Divider rem 100;

   begin
      Initialized := True;

      RCC_Periph.APB2ENR.USART6EN := 1;
      RCC_Periph.AHB1ENR.GPIOCEN  := 1;

      GPIOC_Periph.MODER.Arr     (6 .. 7) := (Mode_AF,     Mode_AF);
      GPIOC_Periph.OSPEEDR.Arr   (6 .. 7) := (Speed_50MHz, Speed_50MHz);
      GPIOC_Periph.OTYPER.OT.Arr (6 .. 7) := (Push_Pull,   Push_Pull);
      GPIOC_Periph.PUPDR.Arr     (6 .. 7) := (Pull_Up,     Pull_Up);
      GPIOC_Periph.AFRL.Arr      (6 .. 7) := (AF_USART6,   AF_USART6);

      USART6_Periph.BRR :=
        (DIV_Fraction => UInt4  (((Frac_Divider * 16 + 50) / 100) mod 16),
         DIV_Mantissa => UInt12 (Int_Divider / 100),
         others => <>);
      USART6_Periph.CR1 :=
        (UE => 1,
         RE => 1,
         TE => 1,
         others => <>);
      USART6_Periph.CR2 := (others => <>);
      USART6_Periph.CR3 := (others => <>);
   end Initialize;

   -----------------
   -- Is_Tx_Ready --
   -----------------

   function Is_Tx_Ready return Boolean is
     (USART6_Periph.ISR.TC = 1);

   -----------------
   -- Is_Rx_Ready --
   -----------------

   function Is_Rx_Ready return Boolean is
     (USART6_Periph.ISR.RXNE = 1);

   ---------
   -- Get --
   ---------

   function Get return Character is (Character'Val (USART6_Periph.RDR.RDR));

   ---------
   -- Put --
   ---------

   procedure Put (C : Character) is
   begin
      USART6_Periph.TDR.TDR := Character'Pos (C);
   end Put;

   ----------------------------
   -- Use_Cr_Lf_For_New_Line --
   ----------------------------

   function Use_Cr_Lf_For_New_Line return Boolean is (True);

end System.Text_IO;


[FabienC]

Can you post an example of ADA code that accesses registers?

You can have a look here :
https://github.com/AdaCore/Ada_Drivers_Library/blob/master/ARM/STM32/drivers/stm32-dcmi.adb

and the registers are defined here:
https://github.com/AdaCore/Ada_Drivers_Library/blob/master/ARM/STM32/svd/stm32f40x/stm32_svd-dcmi.ads

Looks straightforward, if exceedingly verbose, to my eyes.

What do you find verbose? the code or the register definition?

The only thing that's not immediately obvious to me is "16#0#" -- is this the equivalent of C's 0x notation to denote hexadecimal?

Yes, 16#DEAD_CAFE# is the equivalent of 0xDEADCAFE in C.
But you can also have binary with : 2#0100_0011_1011_1000#.
(Another nice small feature of Ada IMHO)

[Sal Ammoniac]

What do you find verbose? the code or the register definition?

Both.

The only thing that's not immediately obvious to me is "16#0#" -- is this the equivalent of C's 0x notation to denote hexadecimal?

Yes, 16#DEAD_CAFE# is the equivalent of 0xDEADCAFE in C.

I prefer 0xCAFEBABE. 

[nctnico]

I could get used to the underscores to split long numbers!

[Bassman59]

The only thing that's not immediately obvious to me is "16#0#" -- is this the equivalent of C's 0x notation to denote hexadecimal?

Yes, 16#DEAD_CAFE# is the equivalent of 0xDEADCAFE in C.
But you can also have binary with : 2#0100_0011_1011_1000#.
(Another nice small feature of Ada IMHO)

That notion was one of the Ada features which was borrowed by the VHDL implementation team.

[Kalvin]

Here is a nice article of the numeric literals and numeric constants in Ada: "Gem #7: The Beauty of Numeric Literals in Ada"

http://www.adacore.com/adaanswers/gems/ada-gem-7/

There are examples on following topics:

- Showing numeric literals in different bases
- Showing exponent notation on different bases
- Explaining how numerical constants and rational numbers are evaluated during compilation time

[FabienC]

In case you missed it, I'm on embedded.fm podcast this week to talk about Ada and the competition.

http://embedded.fm/episodes/158

[C]

Check out "GNAT Programming Studio"


and where Verbose & language that allows easy parser pays you back even more,
make sure to watch the second video
GPS Demo - Smart Completion


Type more and get better programs that are easer to read while being more error free and saving time.


======
Been reading this thread and have seen some wrong info.

Some are complaining about "verbose"

Yet here you are at this site looking at, reading and using "verbose" code!!
===============

Compared to HP Pascal, Turbo Pascal was a very very poor compiler.
When you shift to a higher level language, the compiler has to get smarter.
type
  bit = [0.1]
var
 graphics_display = array[0..255,0..255] of bit;

Good compiler uses 8kb while bad compiler(turbo pascal Z80) uses 64kb. One fits in a Z80 while second is a fail. Said a second way fast used a byte and burns memory while the other requires a smarter compiler uses the binary logic instructions of CPU to do the job giving slower code with less memory use.

Most instructions on a Z80 are encoded in octal.

Type
  two_bit = [0..3]
  octal     = [0..7]
Instruction_type = packed record
 Ins_High : two_bit;
 Ins_Mid   : octal;
 ins_Low  : octal;
end;

A good compiler will pack that record to 8 bits in size while a bad will give 3 bytes.
With a good compiler you can add a case to the record for the 16 bit instructions.
The bad compiler forces you to add more code or do it a different way. The different way often is harder to read and check.

One question to ask is your compiler your friend that helps or something much less.

[CatalinaWOW]

Check out "GNAT Programming Studio"


and where Verbose & language that allows easy parser pays you back even more,
make sure to watch the second video
GPS Demo - Smart Completion


Type more and get better programs that are easer to read while being more error free and saving time.


======
Been reading this thread and have seen some wrong info.

Some are complaining about "verbose"

Yet here you are at this site looking at, reading and using "verbose" code!!
===============

Compared to HP Pascal, Turbo Pascal was a very very poor compiler.
When you shift to a higher level language, the compiler has to get smarter.
type
  bit = [0.1]
var
 graphics_display = array[0..255,0..255] of bit;

Good compiler uses 8kb while bad compiler(turbo pascal Z80) uses 64kb. One fits in a Z80 while second is a fail. Said a second way fast used a byte and burns memory while the other requires a smarter compiler uses the binary logic instructions of CPU to do the job giving slower code with less memory use.

Most instructions on a Z80 are encoded in octal.

Type
  two_bit = [0..3]
  octal     = [0..7]
Instruction_type = packed record
 Ins_High : two_bit;
 Ins_Mid   : octal;
 ins_Low  : octal;
end;

A good compiler will pack that record to 8 bits in size while a bad will give 3 bytes.
With a good compiler you can add a case to the record for the 16 bit instructions.
The bad compiler forces you to add more code or do it a different way. The different way often is harder to read and check.

One question to ask is your compiler your friend that helps or something much less.

Your definitions of good and bad compiler make assumptions about the proper figure of merit.  Small memory consumption good, no penalty for packing/unpacking bytes.  While that may be true in many cases, it is not always true.  There are many other possible figures of merit, and different applications and different people will value them differently.  Some of them include price, execution speed, error handling, coding environment, library availability, native variable types, available training and available target processors. 

One of my pet peeves about most languages as a modeler and analysis type is the lack of a complex variable type.  Fortran has it, and it can be achieved in C++ and in Ada through operator overloading.  The kludges implemented in other languages (CMUL(variable1,variable2) for example) are painful to read and difficult to decode.  Since most people don't need complex arithmetic for their applications (GUIs, bit bangers, compilers and the like) complex math is not part of most popular languages.   I have difficulty rating any of them as superior for my applications.

This is not to say that Turbo Pascal is a good compiler.  It doesn't have complex variables either, for example.   I will argue that it was the best compiler available for CP/M systems for many purposes at the time.  It was so good that I switched from another language that I was very comfortable with, to the in many ways strange Turbo Pascal because time to solution was so much faster.  It was several years before competitive options came along.

[rstofer]

Turbo Pascal is still available!  I used it a few years ago to code up, wait for it..., a maze solver!  I wanted a simple graphic display of the first and second pass.  I have a DOS style graphics window with boxes and the little robot wanders through the field.  Flood-fill is an interesting algorithm!

The videos above are excellent.  I have downloaded the Libre GNAT package twice and both times sat around wondering why I wasn't getting a download.  There is a link "GNAT Ada 2016" that doesn't look like a link and expands (see the little triangle?  I overlooked it twice!).  Then check the file boxes and you're good to go.

The IDE works well on my Win 10 desktop with Microsoft Wireless Mouse and not so well on my Surface Book with the Microsoft Arc Touch Mouse.  On the Book, I can't get the caret to place anywhere near where I want it.  I need to do some more work on this.  In any event, everything is fine on my desktop.

[C]

CatalinaWOW

Sorry typo in my last
A
  graphics_display = array[0..255,0..255] of bit;

Is compiler choice for size of array

graphics_display = packed array[0..255,0..255] of bit;

Tells compiler to make it small
Good compiler this becomes 8kb.
Bad compiler uses more and will not pack to actual size, for example turbo pascal Z80 uses 64kb

So The good compiler you have a choice, small memory at a loss of speed or large memory and gain of speed.

You have two things happening here
Memory alignment and padding of actual size.
The second example, the instruction set record shows a fail of bad compiler lack of smarts.
A forced alignment of byte size removes the need for the compiler to handle the 0 bit of a variable not being the 0 bit of a byte. Less code needed in compiler and you get three bytes for record size.
A forced size or padding to byte size again removes the need for some code in the compiler.

Removing the PACKED lets the size increase.

The good compiler gives you a choice that functions.
 
To me a good compiler gives you choices.


 

[westfw]

Compared to HP Pascal, Turbo Pascal was a very very poor compiler.

HP had a Z80 CP/M or 8086 MSDOS Pascal Compiler?  IIRC, the main competitors of Turbo Pascal involved P-code interpreters...

The videos above are excellent.

I'm not surprised.  I've run into AdaCore at several trade shows, and always been favorably impressed by their professionalism and enthusiasm (for Ada.)  Exactly the sort of compiler company I'd want to deal with, if I were using Ada, and if I could afford it...  The open source version and the contest are fine ideas.  It might be nice to have a non-viral version of the compiler be among the prizes...

16#DEAD_CAFE# is the equivalent of 0xDEADCAFE in C.

Seems reasonable; I bet it's nice and easy to parse, too :-)
One of the "shocking" things looking at Ada is that SO many modern languages have implemented relatively C-like syntax, it's really a bit disconcerting to see something so ... different.   I look at statements like:

      GPIOC_Periph.AFRL.Arr      (6 .. 7) := (AF_USART6,   AF_USART6);
      USART6_Periph.CR2 := (others => <>);

and I haven't really got a clue - they look very foreign and not at all intuitive.  But I suspect they wouldn't be bad at all once I get used to it  (cynically: "well, yeah, but at least "is begin" is much more intuitive than "{", right?")

[nctnico]

I guess that if you (like me) know your way around in VHDL then ADA is only a small step further.

[CatalinaWOW]

While Turbo Pascal had P-code interpreters for competition at the time, I was making a more general statement.  As far as I can remember, or could tell at the time, it was the best CP/M  natively hosted high level language period.  At the time I had paid hundreds of dollars (hobby/moonlight work 1980s dollars) for an IBM Fortran compiler and for the Microsoft family of compilers (Basic, Fortran, COBOL (!!!!) and the associated Assembler).   Working off of 8 inch floppy drives, the high price commercial compilers had a one hour turn around, and no IDE.  So you used your favorite editor, submitted the code, watched the lights flash for a long time, eventually got code to load and try.  There was an off ramp about a half hour in if the parser found syntax errors.  Most of an hour before you could see if your code worked.  Turbo Pascal was $39.95, had an IDE, generated executable code in well under 5 minutes and had enough extensions on the teaching language to let you get at the hardware bits if you needed to.  GCC and its ilk was more than a decade in the future, and the early incarnations of GCC were not friendly to those who didn't breath it full time.  Turbo Pascal had warts, and yes memory usage was one, but it was a bush in a field of grass.  Now there are trees and the bush looks small, but it ruled the era.

There might have been (probably were) better cross compilers running on PDP-8s, PDP-11s, HP 1000s or the IBM 370s or Burroughs 8700s, but that wasn't the real world for most people who weren't being paid to do microprocessor development.  Even for those of us who were, many of our employers didn't look fondly on doing things other than what we were paid to do, so our home fun was restricted to the compilers hosted on the one of the microcomputers of the time.

[C]

Compared to HP Pascal, Turbo Pascal was a very very poor compiler.

HP had a Z80 CP/M or 8086 MSDOS Pascal Compiler?  IIRC, the main competitors of Turbo Pascal involved P-code interpreters...

I have no idea, Think there was a HP Pascal for MSDOS.

Pascal cross compiler for about all microprocessors.
1980 HP64000 A microprocessor development system.
https://en.wikipedia.org/wiki/HP_64000
Probably created for use in one or more HP divisions internal use then sold to public starting in 1980.

I used HP Pascal on a 9826 series 200 which was 68000 based.
Pascal was foundation for all software on this series computers. From documents I have, almost no assembly source was used.


Think about that P-code a bit.
Java & .net are newer versions of P-code.
The interpreters make for easer debug while not preventing compile to native code.
 
I think a lot of people do not know how into computers HP was back then. They created CPU chips & modules and the software needed.

[boz]

Hey guys, some of use still use pascal, go and find someone elses lawn to piss on 

[Sal Ammoniac]

For embedded C development I use Eclipse+CDT and GCC. CDT is the component that ties Eclipse, GCC, and the hardware debugger interface together and makes it all work.

Is there an equivalent of CDT that would let me use Eclipse to do embedded development in Ada on Cortex-M MCUs?

[rstofer]

I don't know the right answer but Ada is compiled using GCC.  Since Eclipse usually uses a Makefile, what difference does it make what language is being written?
The AdaCore IDE is quite nice but there is a certain synergy of using Eclipse as the IDE for all kinds of projects.  I haven't tried it with Ada or Fortran but, given a Makefile, it shouldn't matter.

[nctnico]

For embedded C development I use Eclipse+CDT and GCC. CDT is the component that ties Eclipse, GCC, and the hardware debugger interface together and makes it all work.

Is there an equivalent of CDT that would let me use Eclipse to do embedded development in Ada on Cortex-M MCUs?

I've seen an Ada plugin for Eclipse on Adacore.com . I don't know if they got to debugging but I suspect GDB should understand Ada too.

[Kalvin]

Here is an overview of the tools supported by Adacore:
http://www.adacore.com/gnatpro/toolsuite/

Information about the Programming IDE:
http://www.adacore.com/gnatpro/toolsuite/gps/
- Supports at least Ada, C, C++

Information about the Visual Debugger:
http://www.adacore.com/gnatpro/toolsuite/debugger/
- Ability to debug at source and machine levels
- Multi-language support: Ada, C and C++

Debugging with GDB:
http://docs.adacore.com/gdb-docs/html/gdb.html
- Supports Ada, C, C++ and other languages

[Sal Ammoniac]

 

(note that their "pro" version has a modified license...)
("Pricing for GNAT Pro subscriptions starts at $15,000"

That's steep. And I thought Keil and IAR at around $5000 a seat were expensive...

At that price I doubt there's going to be many companies currently developing in C switching over, or even considering it. Only companies with deep pockets (like government contractors) are going to be willing to take the risk of moving to a new language and new development platform.

AdaCore would probably do better in the long run by bootstrapping their user base with a commercial product in the $1500 range. Give companies an incentive to consider switching, not a disincentive. 

[autobot]

There is a very uncomfortable number of truths in that fqa.

After trying haskell

I'm curious: in the context of embedded systems(either large mcu or mpu), do you think functional programming either in in c++(what's possible) or in haskell, are a good way to produce highly reliable code  ?

[rstofer]

I have an OPINION...  It's probably wrong but here goes:  I don't want the compiler to do anything that I don't explicitly tell it to do.  I don't want objects created and destroyed, I don't even want a heap in memory.  I want simple structures and generic C.  I absolutely do not want the advanced features of C++.  For embedded programming, they don't bring anything to the dance.

I don't know anything about Haskell or why I would want to use it.  There are probably a thousand language variants and I can't conceive of being able to check them all.  Furthermore, I'm just about of the opinion that the only compiler I want to use is GCC.  Why?  Because it's tested on millions of lines of code by thousands of programmers every single day!  Just building Linux is a huge deal!  Anything that can build a complete OS (not just a toy RTOS) is the kind of toolchain I want to use.

I might be willing to negotiate on the heap after I review the heap manager.  Garbage collection is a complicated issue!

I'm talking only about embedded programming.  If the program is intended to cure world hunger, use C++, of Java if you don't mind waiting...


I am going to try Ada and I would like to try Oberon (derived from Modula 2 which was derived from Pascal) but I am still anticipating simple, clean code.

[FabienC]

For those who wants more info on Ada for embedded, here's an article from Jerome and myself https://community.arm.com/groups/embedded/blog/2016/07/08/ada-driver-library

[rstofer]

Success!  I got the LED Demo running on my STM32 F4 Discovery board.  It pays to use the proper board when first starting up!

This is the board that works:
http://www.digikey.com/product-detail/en/stmicroelectronics/STM32F407G-DISC1/497-16287-ND/5824404

It has about 80 IO lines to play with plus another 20 assorted Vcc, Gnd and Misc. lines.

Since the ST-Link V2 adapter is built in, there is nothing else to buy.

[FrankBuss]

Success!  I got the LED Demo running on my STM32 F4 Discovery board.  It pays to use the proper board when first starting up!

This is the board that works:
http://www.digikey.com/product-detail/en/stmicroelectronics/STM32F407G-DISC1/497-16287-ND/5824404

It has about 80 IO lines to play with plus another 20 assorted Vcc, Gnd and Misc. lines.

Since the ST-Link V2 adapter is built in, there is nothing else to buy.

You should have added a LDR, then you would have won the 1st prize this year, $5000:

https://twitter.com/adaprogrammers/status/1110543238316867585

The schematic diagram of this project is at least as complex as the Ariane 5 rocket controller:

[SiliconWizard]

I wonder what the other projects looked like then... 

[JPortici]

Seriously? Because then the contest front page showcased really advaced shit

[FrankBuss]

Yes, the twitter account who announced the winner is the official contest twitter account.

[FrankBuss]

PS: the source code of the winning project:

https://github.com/guillengap/pid-lightmeter-adacore/blob/master/pid_light_control/src/pid_light_control.adb

I wonder why the first line says "BATTERY CHARGER"? Forgot to delete the comment from code copied from elsewhere?

And Ada is so verbose. I'm sure this 142 lines of Ada code could be written in less than 20 lines of Arduino code. And it would be easier to write, easier to read and easier to understand.

[FabienC]

The schematic diagram of this project is at least as complex as the Ariane 5 rocket controller:

Hi Frank,

I work for AdaCore and I am one of the organizer of the Make with Ada competition. We received similar feedback here and there, so I want to give you my point of view on the matter.

We understand that the results can seem unfair, in part because the winning project is not technically complex.

For the Make with Ada competitions we never had a criteria on the complexity of the problem addressed, the complexity of the solution, the number of lines of code or anything of that nature. The intent was to have the competition open to everyone, including beginners.
The result is that the focus is more on how well you explain your project than the complexity of the project itself.

This worked well for us in the first two editions, so we kept it that way for the third.

We are open to suggestions on how to fix this. We do have some ideas:

• Introduce a complexity factor in the judging.
• Remove this strict judging process and just have "AdaCore" pick the projects that are the most impressive/cool. But that means it is very difficult for contestants to know what will be valued in their project.
• Have more winners by spreading the prizes. e.g. 8 winners at 1000 euros instead of 5000, 2000 and 1000.

Thanks for you feedback, and let us know if you have an idea to make the next Make with Ada even better.

[ebastler]

We are open to suggestions on how to fix this. We do have some ideas:

• Introduce a complexity factor in the judging.
• Remove this strict judging process and just have "AdaCore" pick the projects that are the most impressive/cool. But that means it is very difficult for contestants to know what will be valued in their project.
• Have more winners by spreading the prizes. e.g. 8 winners at 1000 euros instead of 5000, 2000 and 1000.

I strongly feel the criteria should include some of the following:

• Interesting results or functionality (rather than the umpteenth rehash of a remote controlled light switch or such).
  
• Highlights benefits of using Ada, rather than some other language.
  
• Not overly complex, so the two benefits above can be understood by the audience.
  

[FrankBuss]

"Interesting results or functionality" and "Highlights benefits of using Ada" sounds good. I wouldn't judge for "Not overly complex". If the documentation is good, it can be complex. But if it is just a light dimmer which you can write in 20 lines of Arduino code with no benefits from Ada, it would score 0 points in the first 2 categories, even if it has a very comprehensive documentation. So maybe this would work better:

- interesting results or functionality
- highlights benefits of using Ada
- documentation

All 3 categories weighted the same, e.g. with points from 0 to 5 for each category and then a sum to get the winner. If someone is not that good at the documentation, he/she can still win with a very interesting project which uses all the features of Ada which makes it better than other languages in some cases. But light dimmers and similar boring projects would be automatically rated lower.

[NorthGuy]

The result is that the focus is more on how well you explain your project than the complexity of the project itself.

IMHO the winning engineering design is the one which provides a simple solution to a complex problem. However, it's generally language independent, so it will be difficult to make it about Ada. You're in a tough spot.

[FrankBuss]

However, it's generally language independent, so it will be difficult to make it about Ada. You're in a tough spot.

There are many features in Ada which are interesting for close to the metal programming, and safe programming, one of the main advantages of Ada. Of course, difficult to demonstrate with a project which is just a 19 lines loop plus some initialization and all the verbose overhead of Ada, but no special features are used, e.g. just Long_Float for all variables, as you would do it in C. People who see this source code wouldn't consider Ada for their own projects, because it doesn't demonstrate the advantages of Ada. And maybe extra points should be given if someone uses some formal verification of the program, like SPARK, or at least, or additionally, good test cases.

[SiliconWizard]

Agree with the remarks above.

It's fine not to emphasize overly complex projects, but too simplistic ones will just not do a favor to the contest. I'm guessing you probably got more complex projects using more advanced Ada features, and people behind those projects are likely to have gotten pretty annoyed when seeing the results. And if you didn't, maybe that's just because you already picked very simple projects in previous editions. This is just going to attract beginners in the end and push away the more advanced users. If this is your goal, fine.

Also, as already mentioned, projects that clearly show the benefits of using Ada should be favored. Otherwise the interest in Ada that your contest may spark will quickly fade away. Just my opinion of course.

[hedleyrainnie]

In my case, I used MakeWithAda 2019 to force me to get some tech finished. I needed Ada BT/BLE support so I had to start somewhere. I spent 75% of the time on that and 25% on MakeWithAda unique code +LaTeX documentation. So sunk cost is the 25%. Some of the sunk cost I can reclaim such as being able to accept 3000interrupts/sec via using BASEPRI and shoving all the Ada runtime IRQ pris up a PRI group, that may become useful to me later.

My goal was to get Ada going on the new STM32WB55x series. I am making good progress on this and am about to get my first Ada program running on that platform (it has NO SVD file!!! I've had to generate one via a RM PDF scrape!) and will use the 75% of the big lift from getting BLE up on a SensorTile to make this happen. The BT/BLE func IDs are the same between the SensorTile's BlueNRG-MS and the STM32WB55x (just the transport changed from SPI to IPCC).

A win would have been the icing on the cake but I credit MakeWithAda for getting me off sitting on my hands and getting the heavy lift done. If I did not have the contest deadline staring me in the face I think it would still be a work in progress.

I will apply again for MakeWithAda if I see a fit like I saw it here. Basically, I am shooting for a 'twofer' a project motivator for some complex piece I need first and a contest entry second.

Best,

Hedley

[FabienC]

Thanks all for the feedback 

Also don't hesitate to ping me if you have comments on the new rules when we announce the next edition.

Hedley, I love Ada theremin

[hedleyrainnie]

Thanks Fabien! If only you were the judge!

My recommendation for new contest rules might be multiple 1k$ prizes spread across multiple categories.

Also bring back a t-shirt so every entry gets some recognition 

Hedley

[FabienC]

Hello there,

We worked on new rules for the 2019 edition. The intent is to have a less strict judging process to allow for the panel to judge more from their own opinion.
We also changed the criteria to include the "wow effect".
And last but not least there are more opportunities to win a prize.

Here is a first draft, let us know what you think if these new rules:

Criteria
Projects will be evaluated using the information available either directly from the Submission or indirectly from the resources referred to by the Submission using the following criteria: 

 - Buzz effect: one of the main goals of  The Competition is to give more exposure to Ada, SPARK and related technologies. Projects will be judged in part with regards to how we think the project can have an impact in that regard: Will the project give more exposure to Ada ? Does it have a “wow effect” that will appeal to the technology community in general ? Will it show the benefits of Ada and related technologies ?

 - Open source: Does the Project have a Free Software License, as defined by the Free Software Foundation  or an open-source license, as defined by the Open Source Initiative?  Does it have  an open design?  Does it use open tools, hardware and platforms? Is the Project usable by other members of the programming community?  Does it have clearly-defined interfaces and documentation? Is it available in a public repository through a version control system such as svn or git? Does the public repository chosen supply  a bug tracking system? Can the Project be built with tools available to the community?

 - Software quality: Does the Project make use of processes and technologies that provide high confidence that the software meets its requirements (for example formal methods, SPARK, contract-based programming, testing, and coding standards)? Is its documentation accurate?
If the project has been submitted to a previous Make with Ada Competition, only the parts of the project that were not part of a previous submission or were significantly changed from the version of the project then submitted will be taken into account by the Panelists.

Prizes

The following “Prizes” will be awarded as part of the Competition:
 - Ten “Finalist Prizes”, in the amount  of 600 (six hundred) USD each;
 - The “First Prize”, in the amount of  of 2000 (two thousand) USD;
 - The “Student Prize” an Analog Discovery 2 Pro Bundle worth 299.99 USD.

Award of Prizes

The Judging Panel will select 10 finalist Projects from the pool of projects. Each finalist project will receive a “Finalist Prize”.

The Judging Panel will then select the competition winner from the 10 finalists and award it the “First Prize”.

Prize winners from previous editions of the competition are eligible  to enter but, in the event of a tie, priority will be given to those who have not previously won a prize.

A special student prize will be awarded to a Student Project either from the finalists or other participants, at the discretion of the Judging Panel.
 
The winners will  be announced in February 2019 on http://makewithada.org or possibly later  depending on the number of entries.

[FabienC]

The competition is live: https://blog.adacore.com/the-make-with-ada-competition-is-back

[donotdespisethesnake]

This might be a long shot, or even off topic. Let's say I work for a company currently doing safety critical code in C (rather badly). I would like to create a proof of concept demo project to show the advantages of using Ada. The thing is it must use our existing hardware, based on TI AM4379, a Sitara Cortex-A9 SOC.

So the question is, is there a ready to go IDE set up I can use to create a demo project for this chip? (There is a TI IDK, TMDSIDK437X, which is close enough to the hardware we use). I haven't been able to find this info by searching TI or Adacore websites. There is the usual hand wavy marketing stuff, but little information for engineers.

[FreddieChopin]

This might be a long shot, or even off topic. Let's say I work for a company currently doing safety critical code in C (rather badly). I would like to create a proof of concept demo project to show the advantages of using Ada. The thing is it must use our existing hardware, based on TI AM4379, a Sitara Cortex-A9 SOC.

So the question is, is there a ready to go IDE set up I can use to create a demo project for this chip? (There is a TI IDK, TMDSIDK437X, which is close enough to the hardware we use). I haven't been able to find this info by searching TI or Adacore websites. There is the usual hand wavy marketing stuff, but little information for engineers.

But why Ada and not Rust or Go? Looking at programming trends Ada will go in tracks of COBOL and dBase while Go is the new C.

[SiliconWizard]

But why Ada and not Rust or Go? Looking at programming trends Ada will go in tracks of COBOL and dBase while Go is the new C.

Uh huh.

[donotdespisethesnake]

But why Ada and not Rust or Go? Looking at programming trends Ada will go in tracks of COBOL and dBase while Go is the new C.

Haven't you got something more useful to do than trolling internet forums?

[ebastler]

But why Ada and not Rust or Go? Looking at programming trends Ada will go in tracks of COBOL and dBase while Go is the new C.

Haven't you got something more useful to do than trolling internet forums?

I don't think FC's post should be considered "trolling". It's a fact that Ada has declined steadily in popularity and "mindshare" since its introduction in the 1980s:
https://www.economist.com/graphic-detail/2018/07/26/python-is-becoming-the-worlds-most-popular-coding-language
https://www.tiobe.com/tiobe-index/

Obviously Ada still lives on in the niche of "safety-critical systems", and that is the area you mentioned an interest in. But even there, it's far from "Ada rules". Subsets of C and C++ are just as serious contenders as are Ada or its subsets: http://vita.mil-embedded.com/articles/when-programming-language-technology-safety/

With a view to maintaining a software package in the long run (which you typically need to do for a safety-critical system, as it won't get rewritten for a looong time), it may be a good idea to bank on a language where you are more likely to find the next generation of programmers in 10 years.

[CatalinaWOW]

Another thought.  While Ada does prevent some classes of programming mistakes, the quality of a program still depends on the quality of the coder/programmer.  I have seen some truly awful Ada code.  While formally correct it required compute resources an order of magnitude or more larger than well written code and as a bonus was difficult to understand.  If you want to write mission critical software there is some real merit in having a large pool of experienced programmers so that you have a good chance of getting some good ones.  Ada never achieved that status (although some will quibble over the definition of large), and is slipping further away from that status over time.

Competitions like this might have some impact on spreading Ada utilization, but it seems a largely lost cause. 

[nctnico]

But why Ada and not Rust or Go? Looking at programming trends Ada will go in tracks of COBOL and dBase while Go is the new C.

Haven't you got something more useful to do than trolling internet forums?

I don't think FC's post should be considered "trolling". It's a fact that Ada has declined steadily in popularity and "mindshare" since its introduction in the 1980s:
https://www.economist.com/graphic-detail/2018/07/26/python-is-becoming-the-worlds-most-popular-coding-language
https://www.tiobe.com/tiobe-index/

Obviously Ada still lives on in the niche of "safety-critical systems", and that is the area you mentioned an interest in. But even there, it's far from "Ada rules". Subsets of C and C++ are just as serious contenders as are Ada or its subsets: http://vita.mil-embedded.com/articles/when-programming-language-technology-safety/

With a view to maintaining a software package in the long run (which you typically need to do for a safety-critical system, as it won't get rewritten for a looong time), it may be a good idea to bank on a language where you are more likely to find the next generation of programmers in 10 years.

That and the need for an Ada runtime specific for a platform. If you want to avoid all the obstacles of C AND need to be able to modify the source over a long period of time then languages like Lua and Python seem like much better choices.

[tggzzz]

But why Ada and not Rust or Go? Looking at programming trends Ada will go in tracks of COBOL and dBase while Go is the new C.

Haven't you got something more useful to do than trolling internet forums?

I don't think FC's post should be considered "trolling". It's a fact that Ada has declined steadily in popularity and "mindshare" since its introduction in the 1980s:
https://www.economist.com/graphic-detail/2018/07/26/python-is-becoming-the-worlds-most-popular-coding-language
https://www.tiobe.com/tiobe-index/

Obviously Ada still lives on in the niche of "safety-critical systems", and that is the area you mentioned an interest in. But even there, it's far from "Ada rules". Subsets of C and C++ are just as serious contenders as are Ada or its subsets: http://vita.mil-embedded.com/articles/when-programming-language-technology-safety/

With a view to maintaining a software package in the long run (which you typically need to do for a safety-critical system, as it won't get rewritten for a looong time), it may be a good idea to bank on a language where you are more likely to find the next generation of programmers in 10 years.

That and the need for an Ada runtime specific for a platform. If you want to avoid all the obstacles of C AND need to be able to modify the source over a long period of time then languages like Lua and Python seem like much better choices.

For realtime multicore/multithreaded code? Last I heard Python had a GIL which ensures only one thread was active at any time.

[SiliconWizard]

Call me when you accept boarding on a plane that runs critical systems with Python or Lua.

[nctnico]

Call me when you accept boarding on a plane that runs critical systems with Python or Lua.

Well choose between a shoddy written program in Ada or a well written program in Python. I like the ideas behind Ada but if see how poorly VHDL code is written in general then I don't have much hope of people getting Ada right. OTOH nowadays everybody knows Python and Lua isn't unknown either. Both languages don't have the typicall problems you encounter if you want to program anything mission critical in C: bad pointers, buffer overflows and a large number of different types.

[legacy]

Call me when you accept boarding on a plane that runs critical systems with Python or Lua.

ATL guys in the QA team have just bought their new pocket calculators from CASIO and found ucPython installed.

You can imagine some funny pills of humor when, getting off a red-ic helicopter,  one of them pulled out of the bag her new pocket calculator claiming to her colleagues to look at collected data and calculous.

- oh, I didn't know that Python could flight - said my colleague, and the guy next replied  - CASIO must have done a great job at certifying it - so he replied - No, it's not certified to flight, there is no certified calculator for any QA guy, it's just a girl with a uCpython calculator getting off a helicopter -

LOL

[SiliconWizard]

so he replied - No, it's not certified to flight, there is no certified calculator for any QA guy, it's just a girl with a uCpython calculator getting off a helicopter -

 

[FreddieChopin]

Ada was a decent idea ruined by government funding and let's be honest, most of us aren't working on life-critical avionics. It's better to get stuff done with C instead of cocking about with hello-worlds with niche language for niche applications. C code can be pretty safe if you work with a right mindset, check out test driven development for embedded C book.

Also, I like python's "We are consenting adults" approach. Sure, I'll make my code pretty safe, tested, with clear interface but if you decide to misuse it - well it's your fault. Embedded software shouldn't be done by newbies, at least not without guidance and supervision from more experienced programmers. If you hire interns as lead developers and get burned by product that failed - blame yourself for bad business decisions (been there, done that, felt the consequences).

[legacy]

Ada was a decent idea ruined by government funding and let's be honest, most of us aren't working on life-critical avionics.

ru-in-ed-?!

[tggzzz]

Ada was a decent idea ruined by government funding and let's be honest,

Ah, politics. And inaccurate at that.

most of us aren't working on life-critical avionics.

True, but unenlightening.

It's better to get stuff done with C instead of cocking about with hello-worlds with niche language for niche applications. C code can be pretty safe if you work with a right mindset, check out test driven development for embedded C book.

Oh dear God. Another person that thinks tests (in the form of TDD) are sufficient. Yes, TDD is helpful in many cases, but as the old saying goes "you can't inspect/test quality into a product".

Anybody that doubts that should first answer the question "how do prove you have developed sufficiently good tests?".
Then they should answer the question "if you have insufficiently good staff, what leads you to believe they will develop sufficiently good tests?".

[FreddieChopin]

. Another person that thinks tests (in the form of TDD) are sufficient

Only I don't . For me it's just a helpful tool to get the job done right and somewhat ensure it stays right as the years pass.
If electronic design was just about as anal as Ada programmers are about their code we'd use 0.1% resistors and other grossly overspec'd parts for something as simple as fleshlight or TV remote.

[SiliconWizard]

Ada was a decent idea ruined by government funding and let's be honest, most of us aren't working on life-critical avionics.

ru-in-ed-?!

 

[chickenHeadKnob]

Ada was a decent idea ruined by government funding and let's be honest, most of us aren't working on life-critical avionics.

Legacy and tggzzz were being polite by not directly stating that it was US dept of Defence that funded and created the  competing development groups Ironman, tinman ect (or whatever they were called at the time). Those competing groups were in turn mostly or entirely composed of Comp. Sci academics. The result was a predictable design by committee melange. 

I had the experience of being relayed interim reports on ADA development by one of my Professors as he was either directly on one of the committees or closely connected to one. Reports which bored me to tears. The Ironic thing is that this happened while he was teaching me  Algol 68. Now I don't particularly like any imperative language but Algol 68 with its garbage collection and clean declaration syntax always struck me me as being the best of the bunch.

[tggzzz]

. Another person that thinks tests (in the form of TDD) are sufficient

Only I don't . For me it's just a helpful tool to get the job done right and somewhat ensure it stays right as the years pass.

Completely false, thereby demonstrating you really don't understand, and confirming my point.

TDD helps ensure it stays unchanged, correct or incorrect.

[tggzzz]

Ada was a decent idea ruined by government funding and let's be honest, most of us aren't working on life-critical avionics.

Legacy and tggzzz were being polite by not directly stating that it was US dept of Defence that funded and created the  competing development groups Ironman, tinman ect (or whatever they were called at the time). Those competing groups were in turn mostly or entirely composed of Comp. Sci academics. The result was a predictable design by committee melange. 

I had the experience of being relayed interim reports on ADA development by one of my Professors as he was either directly on one of the committees or closely connected to one. Reports which bored me to tears. The Ironic thing is that this happened while he was teaching me  Algol 68. Now I don't particularly like any imperative language but Algol 68 with its garbage collection and clean declaration syntax always struck me me as being the best of the bunch.

Famously Algol is regarded as an improvement on most of its successors

[SiliconWizard]

Summing it up:
"Every language after Algol 68 has been a failure, so I'm using Python."
 

Edit: an that's yet another thread on the verge of getting ruined by off-topicism.
It's a thread about an Ada competition, its organization and news about it, for heaven's sake! Not a thread to discuss the merits of Ada or anything else.
Hijacking threads in this way IS the very definition of trolling.
If people want to discuss Ada and the merits of Python or whatever language that tickles their fancy (if nothing else), they can open their own thread, preferably in the Programming section, so that threads don't get hijacked and discussions MAY actually have a chance of being interesting.

[CatalinaWOW]

Summing it up:
"Every language after Algol 68 has been a failure, so I'm using Python."
 

Edit: an that's yet another thread on the verge of getting ruined by off-topicism.
It's a thread about an Ada competition, its organization and news about it, for heaven's sake! Not a thread to discuss the merits of Ada or anything else.
Hijacking threads in this way IS the very definition of trolling.
If people want to discuss Ada and the merits of Python or whatever language that tickles their fancy (if nothing else), they can open their own thread, preferably in the Programming section, so that threads don't get hijacked and discussions MAY actually have a chance of being interesting.

A perfect demonstration of the Ada mindset.  Define everything perfectly(by your own ruleset).  If it wasn't in the definition it has no value and doesn't exist.  I apologize for any problems my posts have caused and will sully this thread no more.

[westfw]

Hmm.  A thought WRT Ada:
The development of Ada Compilers ended up being badly timed, with the compilers showing up at about the same time as personal computers.   But Ada was a BIG language, with big compilers, big runtime environments, and big resource requirements.  You couldn't run an Ada compiler on your floppy-base PC, and if you could somehow cross-compile your application on the $$mainframe$$, it wouldn't run very well on the 640k PC, either.
Smaller, simpler languages (BASIC, Forth, C, Pascal) won the day, as well as the hearts and souls of a generation or two of programmers.

A decade or two later, Moore's law had had its way with PCs, and Big Compilers and RTEs were no longer considered much of a problem.  Big Languages (C++, Jave, Python) have re-surfaced with a vengeance, and no one thinks twice about throwing (former) super-computer class processing at compilation, even for "small" final environments.  (C++ for $1 8kB microcontrollers, MicroPython for somewhat bigger $5 chips.)

If Ada had come along later - say at the same time as Java, it might have been more accepted.
If it had been a few years earlier, it might have picked up more popularity prior to the PC revolution, and done better (vendors wrote Fortran for PCs...)

[DimitriP]

, it wouldn't run very well on the 640k PC, either.
Smaller, simpler languages (BASIC, Forth, C, Pascal) won the day, as well as the hearts and souls of a generation or two of programmers.

A long while back took Pascal, C, Assembly and ADA one after the other.

Using Borland  Pascal and C was really nice.
Using the Microsoft assembler was kinda clunky by comparison but doable.
Then came ADA .. WTF was that? Dropped the class!

[Sal Ammoniac]

I've never used Ada, but I have used VHDL, which is very Ada-like, and am always happy when I can go back to Verilog. Ada/VHDL are just too verbose and pedantic to be pleasant to use on a regular basis.

[ebastler]

I always grind my teeth at VHDL‘s verbosity too. But on the other hand, VHDL has caught many errors for me which would probably have slipped through in Verilog, and has hence saved me hours (probably days) of debugging time.

No experience with Ada, and despite the rational argument I just typed, I am not all that tempted to try it...

[Bassman59]

I've never used Ada, but I have used VHDL, which is very Ada-like, and am always happy when I can go back to Verilog. Ada/VHDL are just too verbose and pedantic to be pleasant to use on a regular basis.

One could say the opposite -- VHDL's verbosity (such as it is) helps the analyzer find your mistakes, rather than with Verilog where the customer finds them.

[SiliconWizard]

Discussing the verbosity of a language is usually hopeless. Don't do it.
It's like "I find this car way too red. I would never drive it." What can you say to that?