Author Topic: "Make With Ada" Competition  (Read 19813 times)

0 Members and 1 Guest are viewing this topic.

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 1793
  • Country: fi
  • Embedded SW/HW.
Re: "Make With Ada" Competition
« Reply #50 on: June 25, 2016, 11:04:05 am »
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.
« Last Edit: June 25, 2016, 11:51:01 am by Kalvin »
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 6647
  • Country: us
Re: "Make With Ada" Competition
« Reply #51 on: June 25, 2016, 02:48:11 pm »
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.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10269
  • Country: gb
    • Having fun doing more, with less
Re: "Make With Ada" Competition
« Reply #52 on: June 25, 2016, 03:11:26 pm »
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.

Quote
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)
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10269
  • Country: gb
    • Having fun doing more, with less
Re: "Make With Ada" Competition
« Reply #53 on: June 25, 2016, 03:15:50 pm »
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"?
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline doobedoobedo

  • Regular Contributor
  • *
  • Posts: 206
  • Country: gb
Re: "Make With Ada" Competition
« Reply #54 on: June 25, 2016, 04:41:31 pm »
I spend most of my time with Oracle's PL/SQL which is ADA based. Maybe it's just familiarity, but I love it.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 6647
  • Country: us
Re: "Make With Ada" Competition
« Reply #55 on: June 25, 2016, 04:47:08 pm »
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.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10269
  • Country: gb
    • Having fun doing more, with less
Re: "Make With Ada" Competition
« Reply #56 on: June 25, 2016, 05:11:04 pm »
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 18010
  • Country: nl
    • NCT Developments
Re: "Make With Ada" Competition
« Reply #57 on: June 25, 2016, 10:33:51 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10269
  • Country: gb
    • Having fun doing more, with less
Re: "Make With Ada" Competition
« Reply #58 on: June 25, 2016, 10:53:34 pm »
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 6647
  • Country: us
Re: "Make With Ada" Competition
« Reply #59 on: June 25, 2016, 11:07:19 pm »
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.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3075
  • Country: us
Re: "Make With Ada" Competition
« Reply #60 on: June 26, 2016, 01:32:42 am »
Quote
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...
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3075
  • Country: us
Re: "Make With Ada" Competition
« Reply #61 on: June 26, 2016, 01:38:34 am »
Quote
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?
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 6647
  • Country: us
Re: "Make With Ada" Competition
« Reply #62 on: June 26, 2016, 01:45:50 am »
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...
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 6647
  • Country: us
Re: "Make With Ada" Competition
« Reply #63 on: June 26, 2016, 01:58:58 am »
Quote
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.
 
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3075
  • Country: us
Re: "Make With Ada" Competition
« Reply #64 on: June 26, 2016, 02:19:02 am »
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;
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 6647
  • Country: us
Re: "Make With Ada" Competition
« Reply #65 on: June 26, 2016, 02:59:06 am »
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.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3075
  • Country: us
Re: "Make With Ada" Competition
« Reply #66 on: June 26, 2016, 06:09:14 am »
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 18010
  • Country: nl
    • NCT Developments
Re: "Make With Ada" Competition
« Reply #67 on: June 26, 2016, 10:14:57 am »
Quote
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1076
  • Country: fi
Re: "Make With Ada" Competition
« Reply #68 on: June 26, 2016, 10:36:29 am »
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.

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 6647
  • Country: us
Re: "Make With Ada" Competition
« Reply #69 on: June 26, 2016, 02:13:27 pm »
Quote
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!
« Last Edit: June 27, 2016, 01:48:13 pm by rstofer »
 

Offline FabienC

  • Contributor
  • Posts: 11
  • Country: fr
Re: "Make With Ada" Competition
« Reply #70 on: June 27, 2016, 10:51:49 am »
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,
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 6647
  • Country: us
Re: "Make With Ada" Competition
« Reply #71 on: June 27, 2016, 02:05:56 pm »
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!
 

Offline Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 920
  • Country: us
    • Embedded Tales Blog
Re: "Make With Ada" Competition
« Reply #72 on: June 27, 2016, 03:53:00 pm »
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?
 

Offline FabienC

  • Contributor
  • Posts: 11
  • Country: fr
 

Offline Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 920
  • Country: us
    • Embedded Tales Blog
Re: "Make With Ada" Competition
« Reply #74 on: June 27, 2016, 04:42:32 pm »
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?
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf