Translating an embedded C algorithm

Translating an embedded C algorithm

[Talulah]

Hi,

I am in the process of writing a book about real-time embedded
development (hardware and software). In it there is a section on
different programming languages that are available for embedded
development. I'm using a small C function that does temperature
measurement by linear interpolation of a lookup table as an example. I
have C code to do this, and would like to have the same algorithm
implemented in other languages.

Unfortunately I'm really a C programmer, with very little experience
of other languages, so I would like to ask if anyone on this newsgroup
is interested in translating the algorithm into Ada. Of course you
would be mentioned in thanks in the book once it is finished.

If you are interested, I have placed the section of the book here:

http://homepages.which.net/~paul.hills/Temporary/Temperature.pdf

so you can see the code and description. Please email me if you are
interested to paul (dot) hills (who is at) uk (dot) landisgyr (dot)
com.

Thanks very much
Paul Hills

Re: Translating an embedded C algorithm

[Jeffrey Carter]

Talulah wrote:
> 
> I am in the process of writing a book about real-time embedded
> development (hardware and software). 
> 
> Unfortunately I'm really a C programmer, with very little experience
> of other languages, ...

I would think that someone qualified to write such a book would be 
familiar with at least one language that was designed for RT embedded SW 
development. Such a language would have things like tasking, timing, and 
fixed-point types built in.

Clearly C is not such a language, so I have to wonder about the 
qualifications of someone who only knows C.

Re: Translating an embedded C algorithm

[Marc A. Criley]

On Tue, 16 Jan 2007 00:06:59 +0000, Jeffrey Carter wrote:

> Talulah wrote:
>> 
>> I am in the process of writing a book about real-time embedded
>> development (hardware and software).

> Clearly C is not such a language, so I have to wonder about the
> qualifications of someone who only knows C.

Thanks Jeff, go ad hominem on someone who's unfamiliar with Ada yet
willing to give it a fair hearing.

-- Marc A. Criley
-- McKae Technologies
-- www.mckae.com
-- Avatox - DTraq - XIA - XML EZ Out

Re: Translating an embedded C algorithm

[Cesar Rabak]

Jeffrey Carter escreveu:
> Talulah wrote:
>>
>> I am in the process of writing a book about real-time embedded
>> development (hardware and software).
>> Unfortunately I'm really a C programmer, with very little experience
>> of other languages, ...
> 
> I would think that someone qualified to write such a book would be 
> familiar with at least one language that was designed for RT embedded SW 
> development. Such a language would have things like tasking, timing, and 
> fixed-point types built in.

Can you please enlight us why "Such a language *would have* things like" 
and not "programming in a such language that has things like..."

> 
> Clearly C is not such a language, so I have to wonder about the 
> qualifications of someone who only knows C.

And why cannot C be augmented by RTOSs and other systems software to 
achieve this?

Instead of taking profit of an opportunity you rather just spit a bit of 
arrogance?

How does this helps Ada?

Re: Translating an embedded C algorithm

[Markus E Leypold]

> And why cannot C be augmented by RTOSs and other systems software to
> achieve this?

Can and has been. Of course there are tradeoffs like the safer type
system of Ada vs. the higher popularity (read more libraries and
existing code) of C and the fact that you can invent your own tasking
primitives in C.

Regards -- Markus

Re: Translating an embedded C algorithm

[Larry Kilgallen]

In article <xehcurdzkh.fsf@hod.lan.m-e-leypold.de>, Markus E Leypold writes:
> 
>> And why cannot C be augmented by RTOSs and other systems software to
>> achieve this?
> 
> Can and has been. Of course there are tradeoffs like the safer type
> system of Ada vs. the higher popularity (read more libraries and
> existing code) of C and the fact that you can invent your own tasking
> primitives in C.

It seems to me you _can_ invent your own tasking primitives in Ada,
but such is rarely necessary.  Using the tasking system that comes
with Ada is typically preferable.

Re: Translating an embedded C algorithm

[Jeffrey Carter]

Cesar Rabak wrote:
> 
> And why cannot C be augmented by RTOSs and other systems software to 
> achieve this?

It can. You can also write everything in assembler. Both are very error 
prone. Neither is very portable.

> Instead of taking profit of an opportunity you rather just spit a bit of 
> arrogance?

Let's see ... It's not arrogant to write a book on RT embedded SW 
development when one is ignorant of basic tools for the task, but it is 
arrogant to point it out? Thanks for pointing that out to me.

Re: Translating an embedded C algorithm

[Cesar Rabak]

Jeffrey Carter escreveu:
> Cesar Rabak wrote:
>>
>> And why cannot C be augmented by RTOSs and other systems software to 
>> achieve this?
> 
> It can. You can also write everything in assembler. Both are very error 
> prone. Neither is very portable.
> 

Yes. When building embedded systems, is it very rare that 'portability' 
be on the top of any requirements list.

In fact, here (to my own dismay) Ada is in the opposite side: it is very 
hard to find Ada development tools for a lot of popular microcontrollers�.

Our message could have promoted Ada as a better way of developing such 
systems and emphasizing the advantages of it.

>> Instead of taking profit of an opportunity you rather just spit a bit 
>> of arrogance?
> 
> Let's see ... It's not arrogant to write a book on RT embedded SW 
> development when one is ignorant of basic tools for the task, but it is 
> arrogant to point it out? Thanks for pointing that out to me.

Two mistakes don't make a good result!

To our chagrin (Ada professionals) a lot of "RT embedded SW" is made 
with those less than safe (and incomplete tools) but we have to accept 
this and see better ways of sending our message out.

The arrogance I felt in your repply stems of an interpetration that 
anyone not having knowledge of Ada should not dare to write a book about 
on RT embedded SW, which besides being prejudicial is non sense.

A lot of people could bring to this thread a lot of counter examples of 
systems built in Ada which have been plagued by errors (some of IMNSHO 
could have been avoided by better use of Ada technology and practices it 
facilitates).

regards,

--
Cesar Rabak

[1] I sent a private e-mail to OP asking what chips he intends to use in 
the examples but still did receive any repply. Depending upon the 
technology mentioning Ada would be somewhat pointless.

Re: Translating an embedded C algorithm

[Jeffrey Carter]

Cesar Rabak wrote:
> 
> Yes. When building embedded systems, is it very rare that 'portability' 
> be on the top of any requirements list.

Many of the Ada RT embedded systems I've worked on have been ported to 
new hardware or compilers, fairly easily, since I tend to avoid (RT)OS 
and compiler dependencies, and to encapsulate and hide them when 
unavoidable.

> Two mistakes don't make a good result!

I see. Pointing out a mistake is a mistake. I didn't realize that.

Re: Translating an embedded C algorithm

[Cesar Rabak]

Jeffrey Carter escreveu:
> Cesar Rabak wrote:
>>
>> Yes. When building embedded systems, is it very rare that 
>> 'portability' be on the top of any requirements list.
> 
> Many of the Ada RT embedded systems I've worked on have been ported to 
> new hardware or compilers, fairly easily, since I tend to avoid (RT)OS 
> and compiler dependencies, and to encapsulate and hide them when 
> unavoidable.

I see, you probably have more latitude or freedom than other engineers 
that have to work with specific RT OS and components (sometimes even 
written in other languages than Ada).

> 
>> Two mistakes don't make a good result!
> 
> I see. Pointing out a mistake is a mistake. I didn't realize that.

NO! Being rude and agressive is *the* mistake and now belittling is a 
continuation of it...

Re: Translating an embedded C algorithm

[Alexander E. Kopilovich]

Jeffrey Carter wrote:

>> I am in the process of writing a book about real-time embedded
>> development (hardware and software). 
>> 
>> Unfortunately I'm really a C programmer, with very little experience
>> of other languages, ...
>
>I would think that someone qualified to write such a book would be 
>familiar with at least one language that was designed for RT embedded SW 
>development. Such a language would have things like tasking, timing, and 
>fixed-point types built in.
>
>Clearly C is not such a language, so I have to wonder about the 
>qualifications of someone who only knows C.

Translation of Jeff's reply:

Ada has many features, which are directly related to real-time embedded
programming, and which have no counterparts in C (tasking, timing, and
fixed-point types built in).

Therefore there is little chance for translation of a program of that kind
from C to Ada without essential redesign of that program (for making proper
use of available Ada features).

But if the program will be redesigned for Ada then there will be little sense
in placing those C and Ada implemetation side-by-side for comparison.

So, within this kind of software, probably C and Ada may be sensibly put
side-by-side not for pieces of code or relatively small algorithms, but only
for whole projects (applications or even systems).

Re: Translating an embedded C algorithm

[Cesar Rabak]

Alexander E. Kopilovich escreveu:
> Jeffrey Carter wrote:
> 
>>> I am in the process of writing a book about real-time embedded
>>> development (hardware and software). 
>>>
>>> Unfortunately I'm really a C programmer, with very little experience
>>> of other languages, ...
>> I would think that someone qualified to write such a book would be 
>> familiar with at least one language that was designed for RT embedded SW 
>> development. Such a language would have things like tasking, timing, and 
>> fixed-point types built in.
>>
>> Clearly C is not such a language, so I have to wonder about the 
>> qualifications of someone who only knows C.
> 
> Translation of Jeff's reply:
> 
> Ada has many features, which are directly related to real-time embedded
> programming, and which have no counterparts in C (tasking, timing, and
> fixed-point types built in).
> 
> Therefore there is little chance for translation of a program of that kind
> from C to Ada without essential redesign of that program (for making proper
> use of available Ada features).
> 
> But if the program will be redesigned for Ada then there will be little sense
> in placing those C and Ada implemetation side-by-side for comparison.
> 
> So, within this kind of software, probably C and Ada may be sensibly put
> side-by-side not for pieces of code or relatively small algorithms, but only
> for whole projects (applications or even systems).
> 
Very good indeed! And perhaps it begs to another aspect: in a such kind 
of work, the OP would need to find a person knowledgeable enough to do 
the design of the Ada version to insure the implementation is a good 
representation of the best practices with this technology.

Re: Translating an embedded C algorithm

[Simon Wright]

"Alexander E. Kopilovich" <aek@VB1162.spb.edu> writes:

> Ada has many features, which are directly related to real-time
> embedded programming, and which have no counterparts in C (tasking,
> timing, and fixed-point types built in).
>
> Therefore there is little chance for translation of a program of
> that kind from C to Ada without essential redesign of that program
> (for making proper use of available Ada features).
>
> But if the program will be redesigned for Ada then there will be
> little sense in placing those C and Ada implemetation side-by-side
> for comparison.
>
> So, within this kind of software, probably C and Ada may be sensibly
> put side-by-side not for pieces of code or relatively small
> algorithms, but only for whole projects (applications or even
> systems).

But the OP's example isn't in any way specifically embedded or RT, and
in a one-page example one wouldn't expect more. There are some
externally-defined macros which might be 'embedded', and which could
be interesting to us but perhaps don't address the point to be made.

If what is wanted is an example of what code looks like then I see no
reason not to provide an Ada translation. If possible, it should be in
real Ada and not a transliteration of the C.

Re: Translating an embedded C algorithm

[Cesar Rabak]

Simon Wright escreveu:
> "Alexander E. Kopilovich" <aek@VB1162.spb.edu> writes:
> 
>> Ada has many features, which are directly related to real-time
>> embedded programming, and which have no counterparts in C (tasking,
>> timing, and fixed-point types built in).
>>
>> Therefore there is little chance for translation of a program of
>> that kind from C to Ada without essential redesign of that program
>> (for making proper use of available Ada features).
>>
>> But if the program will be redesigned for Ada then there will be
>> little sense in placing those C and Ada implemetation side-by-side
>> for comparison.
>>
>> So, within this kind of software, probably C and Ada may be sensibly
>> put side-by-side not for pieces of code or relatively small
>> algorithms, but only for whole projects (applications or even
>> systems).
> 
> But the OP's example isn't in any way specifically embedded or RT, and
> in a one-page example one wouldn't expect more. 

I think an implementation in a microcontroller can count easily as 
'embedded', and at least if the OP doesn't elaborate, I agree it can be 
non RT at all.

> There are some
> externally-defined macros which might be 'embedded', and which could
> be interesting to us but perhaps don't address the point to be made.

I don't think the macros are any difference in this context.

> 
> If what is wanted is an example of what code looks like then I see no
> reason not to provide an Ada translation. If possible, it should be in
> real Ada and not a transliteration of the C.
> 

This is the thing I second in full. However, the OP still did not answer 
my private e-mail where I asked some questions in order to ascertain how 
much of effert he would need.

For example to make a ADC package (I already played a little bit with it 
) creating a Adc_Int type. From the PDF example one could, conceivable, 
subtype even further to the range from the Table 1 of his article, etc.

RE: Translating an embedded C algorithm

[Vo, Anh (US SSA)]

-----Original Message-----
From: comp.lang.ada-bounces@ada-france.org [mailto:comp.lang.ada-bounces@ada-france.org] On Behalf Of Talulah
Sent: Monday, January 15, 2007 6:37 AM
To: comp.lang.ada@ada-france.org
Subject: Translating an embedded C algorithm

<< [..]

Unfortunately I'm really a C programmer, with very little experience
of other languages, so I would like to ask if anyone on this newsgroup
is interested in translating the algorithm into Ada. Of course you
would be mentioned in thanks in the book once it is finished.

If you are interested, I have placed the section of the book here:

http://homepages.which.net/~paul.hills/Temporary/Temperature.pdf

so you can see the code and description. Please email me if you are
interested to paul (dot) hills (who is at) uk (dot) landisgyr (dot)
com. >>>

Here I just translated directory to Ada from C code in the table. Please pay attention to the Important Note below the Table. Note also that I have slightly modified some variables for readability. Let me know if more information is desired.

AV
------------------------------------------------------------------------
--| MeasureTemperature
--|
--| Calculates the temperature in ºC given the ADC count by lookup
--| table and linear interpolation of the diode circuit characteristic.
--|
--| Parameters:
--| AdcCount Raw ADC count.
--|
--| Returns:
--| Temperature in ºC x 10. INVALID_TEMPERATURE if out of range.
--| 
--| Note: GNAT-GPL-2006 compiler on Windows was used
-------------------------------------------------------------------------
function Measure_Temperature (Adc_Count : in Integer) return Integer is

   Index : Integer := 0;
   InterpolationDistance : Integer := 0;
   TempDiff : Integer := 0;
   TempCalOffset : Integer := 0;
   Temperature : Integer := 0;
   
   TEMPERATURE_TABLE_NUM_ENTRIES : constant := 32;
   Table : constant array 
      (0 .. TEMPERATURE_TABLE_NUM_ENTRIES - 1) of Integer := (
               1171, 1116, 1061, 1006, 952,   899,  846,  793,
                741,  689,  638,  588, 537,   488,  438,  389,
                341,  293,  246,  199, 152,   106,   61,   16,
                 -29,  -73, -116, -160, -202, -244, -286, -327);

   -- *** Important Note: 
   -- The following constants and function need to be defined.
   -- They are arbitrary set so compilation is successful.
   MINIMUM_ADC_COUNT : constant := Integer'Last;
   MAXIMUM_ADC_COUNT : constant := Integer'Last;
   SPACING : constant := 1; 
   TEMPERATURE_CAL_VALUE : constant := 0;

   function ReadEEPROM (Temp : in Integer) return Integer is
   begin
      return Temp; -- for now
   end ReadEEPROM;
   -----------------------------------------------------------
   
begin
   
   -- Index is the index into the table. Each table entry is 8 ADC
   -- counts higher than the last one, so subtract the offset and
   -- divide by 8 to find the table index. InterpolationDistance
   -- is the linear distance between the the table entry ADC cou nt
   -- and the actual ADC count.
   -- Check range of Adc_Count and saturate index if out of range.
   if (Adc_Count < MINIMUM_ADC_COUNT) then
      -- Underflow of ADC - saturate at minimum value
      Index := 0;
   elsif (Adc_Count > MAXIMUM_ADC_COUNT) then
      -- Overflow of ADC - saturate at maximum value
      Index := TEMPERATURE_TABLE_NUM_ENTRIES - 1;
   else
      -- Find the index of the table entry just below the ADC value
      Index := (Adc_Count - MINIMUM_ADC_COUNT) / SPACING;
   end if;
   
   -- Calculate the interpolation between the table entries either side of
   -- the ADC value. This is the remainder of the difference between the
   -- ADC count and the minimum temperature ADC count divided by the
   -- spacing between table entries. Since the spacing is a power of 2,
   -- this can be achieved by simply masking all but the bottom 3 bits.
   InterpolationDistance := (Adc_Count - MINIMUM_ADC_COUNT) + (SPACING - 1);
   TempDiff := (Table(Index) - Table (Index+1));
   
   -- The temperature is then the base temperature minus the amount
   -- calculated by linear interpolation. The compiler is clever enough
   -- to know that dividing by 8 is a right shift of three bits.
   Temperature := 
            Table(Index) - ((TempDiff * InterpolationDistance) / SPACING);
   
   -- To this is then added the calibration offset to the temperature table.
   TempCalOffset := ReadEeprom (TEMPERATURE_CAL_VALUE);
   Temperature := Temperature + TempCalOffset;
   
   return Temperature;
        
end Measure_Temperature;
         

Re: Translating an embedded C algorithm

[Niklas Holsti]

Vo, Anh (US SSA) wrote:
> -----Original Message-----
> <<<...
> If you are interested, I have placed the section of the book here:
> 
> http://homepages.which.net/~paul.hills/Temporary/Temperature.pdf
> 
> so you can see the code and description. Please email me if you are
> interested to paul (dot) hills (who is at) uk (dot) landisgyr (dot)
> com. >>>
> 
> Here I just translated directory to Ada from C code in the table. Please pay attention to the Important Note below the Table. Note also that I have slightly modified some variables for readability. Let me know if more information is desired.
> 
> ...
>    -- ... Since the spacing is a power of 2,
>    -- this can be achieved by simply masking all but the bottom 3 bits.
>    InterpolationDistance := (Adc_Count - MINIMUM_ADC_COUNT) + (SPACING - 1);
                                                              ^^^

Mistake: That "+" is a bit-wise logical AND operation (&) in the C code. 
We could use modular types, but if (as noted later in the C code) the 
compiler is clever enough to implement division by 8 with shifting, it 
should also be clever enough to implement "mod 8" as masking, so the Ada 
code could be simply "mod Spacing".

I agree with other posters that simply translating this function into 
Ada does not give a good comparison between C and Ada. The first steps 
in an Ada design would be to consider encapsulation (packages) and data 
representation (types), for which the C version gives no model.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Translating an embedded C algorithm

[Simon Wright]

Niklas Holsti <niklas.holsti@nospam.please> writes:

> I agree with other posters that simply translating this function
> into Ada does not give a good comparison between C and Ada. The
> first steps in an Ada design would be to consider encapsulation
> (packages) and data representation (types), for which the C version
> gives no model.

I agree too. But it's a one-page example; if we try to fit all those
good things in we'll swamp the message (would help to kown what that
was).

Re: Translating an embedded C algorithm

[Niklas Holsti]

Niklas Holsti wrote:
> ...
> 
> I agree with other posters that simply translating this function into 
> Ada does not give a good comparison between C and Ada. The first steps 
> in an Ada design would be to consider encapsulation (packages) and data 
> representation (types), for which the C version gives no model.

I'm replying to my own post because I've changed my opinion a bit: I 
think that an Ada translation of this C function can, with a bit of 
elaboration, illustrate several Ada features for "programming in the 
small", even if not for "programming in the large".

So here is my try at an Ada version of the code and some of the context. 
This makes for a long post, for which I apologize in advance. Putting 
the sources somewhere for download seemed like overkill, and I prefer to 
expose my suggestion to the purifying flames of c.l.a instead of sending 
it privately to the OP. The Ada code below has been compiled
and tested (gnat 3.15p, Debian). It is hereby put in the public domain.

In this code, I tried to use as many relevant Ada features as possible, 
without trying to limit myself to some "8-bit subset". It would be 
interesting to compile this code with AVR-Ada; I don't happen to have 
that installed, but I may try it later, if no-one else does it.

First, the context. The C function deals with two kinds of data: ADC 
readings ("counts") and temperatures expressed in deci-degrees Celsius 
(that is, units of 0.1 degrees C). The ADC count-type does not depend on 
temperatures, and the temperature type does not depend on the ADC, so I 
would define these types in different packages, so:

    package ADC is

       type Count_T is range 0 .. 1023;
       --
       -- An ADC reading.

       -- More ADC stuff ...

    end ADC;

and

    package Temperatures is

       type Celsius_T is delta 0.1 digits 5 range -40.0 .. 120.0;
       --
       -- A temperature in degrees Celsius.

       -- More temperature stuff ...

    end Temperatures;

The function to convert ADC counts to temperatures then seems suitable 
for a child of package ADC. Here is the package declaration, in which I 
have added a Saturation option and two Ada idioms of reporting 
out-of-range results (discriminated type; exception):

    with Temperatures;

    package ADC.Thermometer is

       type Reading_T (In_Range : Boolean := False) is record
          case In_Range is
          when False => null;
          when True  => Temperature : Temperatures.Celsius_T;
          end case;
       end record;
       --
       -- A temperature, measured through the ADC.
       -- The ADC reading can be In the expected Range, in which
       -- case we have a Temperature. If the reading is out of
       -- range, we have no temperature (it might be interesting
       -- to have here the ADC count, for diagnostic purposes).
       --
       -- The default initial value of a Reading is "not In Range".

       Saturation : Boolean := True;
       --
       -- Whether the temperature is saturated at its lower or
       -- upper limit when the ADC count is out of range.
       -- If this option is True, the Temperature functions below
       -- always return a temperature, never an out-of-range
       -- indication. If the ADC count is below the minimum
       -- expected value, the minimum temperature is returned;
       -- if the ADC count is above the maximum expected value,
       -- the maximum temperature is returned. If this option is
       -- False, the Temperature functions do not return a
       -- temperature when the ADC count is out of range but
       -- instead give an out-of-range indication.

       function Temperature (Count : Count_T)
       return Reading_T;
       --
       -- The temperature corresponding to the given ADC Count,
       -- following the Saturation option defined above. When
       -- saturation is not used the in-range/out-of-range
       -- status is shown by the In_Range component.

       Out_Of_Range : exception;
       --
       -- Signals an out-of-range ADC reading for temperature.
       -- See function Temperature, below.

       function Temperature (Count : Count_T)
       return Temperatures.Celsius_T;
       --
       -- The temperature corresponding to the given ADC Count,
       -- following the Saturation option defined above. When
       -- saturation is not used and the Count is out of the
       -- range expected for the thermometer, the function
       -- propagates the Out_Of_Range exception.

    end ADC.Thermometer;


To finish this posting, here is the package body. It follows the 
inerpolation logic of the C code but makes saturation optional. Also, it 
handles separately the case where the Index becomes the last index of 
the calibration table, where I think the C code uses Index+1 incorrectly 
as an index to the Table.


package body ADC.Thermometer is

    use type Temperatures.Celsius_T;
    --
    -- We will need to compute with values of this type, so we
    -- like to have easy access to the operators for this type.

    -- The conversion from ADC counts to Celsius degrees uses linear
    -- interpolation in a table of temperatures for a sequence of
    -- calibration points corresponding to equispaced ADC counts in
    -- increasing order.

    Points : constant := 32;
    --
    -- The number of calibration points.

    type Point_Count_T is range 0 .. Points - 1;
    --
    -- A count of calibration points. For example, the number of
    -- points (spacings) from the first calibration point to the
    -- calibration point that precedes a given ADC reading.

    subtype Index_T is Point_Count_T;
    --
    -- The index of a calibration point.

    First_Count : constant Count_T := 220;
    --
    -- The ADC count for the first calibration point.

    Spacing : constant := 8;
    --
    -- The spacing of calibration points (difference in ADC counts
    -- between two adjacent calibration points).

    Last_Count : constant Count_T :=
       First_Count + (Points - 1) * Spacing;
    --
    -- The ADC count for the last calibration point.

    Table : constant array (Index_T) of Temperatures.Celsius_T := (
        0 => 117.1,
        1 => 111.6,
        2 => 106.1,
        3 => 100.6,
        4 =>  95.2,
        5 =>  89.9,
        6 =>  84.6,
        7 =>  79.3,
        8 =>  74.1,
        9 =>  68.9,
       10 =>  63.8,
       11 =>  58.8,
       12 =>  53.7,
       13 =>  48.8,
       14 =>  43.8,
       15 =>  38.9,
       16 =>  34.1,
       17 =>  29.3,
       18 =>  24.6,
       19 =>  19.9,
       20 =>  15.2,
       21 =>  10.6,
       22 =>   6.1,
       23 =>   1.6,
       24 =>  -2.9,
       25 =>  -7.3,
       26 => -11.6,
       27 => -16.0,
       28 => -20.2,
       29 => -24.4,
       30 => -28.6,
       31 => -32.7);
    --
    -- The calibration table. The first entry corresponds to First_Count
    -- and the last entry to Last_Count.

    subtype Interpolation_Distance_T is Natural range 0 .. Spacing - 1;
    --
    -- The difference in ADC counts between an ADC reading and the
    -- preceding calibration point.


    function Temperature (Count : Count_T)
    return Reading_T
    is

       Index : Index_T;
       -- The index in the calibration Table such that the Count
       -- lies in the interval between the calibration points
       -- number Index (inclusive) and Index + 1 (exclusive).

       Interpolation_Distance : Interpolation_Distance_T;
       -- The difference in ADC counts between Count and the
       -- calibration point at Table(Index).

       Temp_Diff : Temperatures.Celsius_T;
       -- The difference in temperature between the calibration
       -- points at Index and Index + 1.
       --
       -- We assume that calibration points are spaced closely
       -- enough that Temp_Diff * (Spacing - 1) stays in range
       -- for Celsius_T.

    begin

       if Count in First_Count .. Last_Count then
          -- The ADC reading is in range for this calibration table.

          Index := Point_Count_T ((Count - First_Count) / Spacing)
                   + Table'First;

          if Index = Table'Last then
             -- Count is Last_Count, so Index + 1 is out of the Table.
             -- But in this case we do not need to interpolate.

             return (In_Range => True, Temperature => Table(Table'Last));

          else
             -- Both Index and Index + 1 are valid Table indices.

             Interpolation_Distance := Interpolation_Distance_T (
                (Count - First_Count) mod Spacing);

             Temp_Diff := Table(Index) - Table(Index + 1);

             return (
                In_Range    => True,
                Temperature =>
                     Table(Index)
                   - (Temp_Diff * Interpolation_Distance) / Spacing);

          end if;

       elsif not Saturation then
          -- We report the out-of-range status.

          return (In_Range => False);

       elsif Count < First_Count then
          -- Saturate at minimum temperature.

          return (In_Range => True, Temperature => Table(Table'First));

       else
          -- Saturate at maximum temperature.

          return (In_Range => True, Temperature => Table(Table'Last));

       end if;

    end Temperature;


    function Temperature (Count : Count_T)
    return Temperatures.Celsius_T
    is

       Reading : constant Reading_T := Temperature (Count);
       -- The temperature, with an in-range/out-of-range indication.

    begin

       if Reading.In_Range then

          return Reading.Temperature;

       else

          raise Out_Of_Range;

       end if;

    end Temperature;

end ADC.Thermometer;



-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Translating an embedded C algorithm

[Ludovic Brenta]

Niklas Holsti writes:
[...]

Hi Niklas,

I think your program is excellent.  You are the first who used a fixed
point real type and never to return an "invalid" temperature; both
were the Right Thing to Do, IMHO.  Would you like to work in avionics?
:)

Given the very high quality of your program, I'll offer only
nit-picking criticisms :)

> The function to convert ADC counts to temperatures then seems suitable
> for a child of package ADC.

It does not need to be a child of ADC; it could be another top-level
package.  Better yet, reverse the relationship to hide the ADC in a
private child package:

package Thermometer is
   function Temperature return Temperatures.Reading_T;
   function Temperature return Temperatures.Celsius_T;
   Out_Of_Range : exception;
end Thermometer;

private package Thermometer.Some_Particular_Kind_Of_Sensor is
   type Count_T is range 0 .. 1024;
   ...
end Thermometer.Some_Particular_Kind_Of_Sensor;

Of course, that also encapsulates the reading of the Count from the
sensor, thus requiring a change in the way the function was specified.

-- 
Ludovic Brenta.

Re: Translating an embedded C algorithm

[Niklas Holsti]

Ludovic Brenta wrote:
> Niklas Holsti writes:
> [...]
> 
> Hi Niklas,
> 
> I think your program is excellent.  You are the first who used a fixed
> point real type and never to return an "invalid" temperature; both
> were the Right Thing to Do, IMHO.

Thanks.

>  Would you like to work in avionics? :)

I used to work on space SW (www.ssf.fi). I quit partly (but not mainly) 
because the customers started to specify C as the implementation 
language "for reasons of business strategy" or some such phrase.

>>The function to convert ADC counts to temperatures then seems suitable
>>for a child of package ADC.
> 
> 
> It does not need to be a child of ADC; it could be another top-level
> package.

True. Firstly, I wanted to demonstrate child packages; secondly, the 
conversion is very dependent on the type ADC.Count_T (its nature and 
range), so a child package feels natural to me.

>  Better yet, reverse the relationship to hide the ADC in a
> private child package:
> 
> package Thermometer is
>    function Temperature return Temperatures.Reading_T;
>    function Temperature return Temperatures.Celsius_T;
>    Out_Of_Range : exception;
> end Thermometer;

I agree "in the large" that those SW parts that need to know the 
temperature should be able to get it from a top-level package like that, 
without knowing that the temperature (in this version of the 
application) is acquired through the ADC. My code focuses on the issues 
of "programming in the small".

> private package Thermometer.Some_Particular_Kind_Of_Sensor is
>    type Count_T is range 0 .. 1024;
>    ...
> end Thermometer.Some_Particular_Kind_Of_Sensor;

I assumed that the ADC would be used to read various voltages, not just 
thermometer voltages. All these ADC channels share the same type Count_T 
(defined by the nature of the ADC itself), so its definition should not 
depend on the Sensor that is being read, which is why I defined Count_T 
in the package ADC.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Translating an embedded C algorithm

[Cesar Rabak]

Ludovic Brenta escreveu:
> Niklas Holsti writes:
> [...]
> 
> Hi Niklas,
> 
> I think your program is excellent.  You are the first who used a fixed
> point real type and never to return an "invalid" temperature; both
> were the Right Thing to Do, IMHO.  Would you like to work in avionics?
> :)
> 
> Given the very high quality of your program, I'll offer only
> nit-picking criticisms :)
[snipped]

Maintaining the kudos, a nit-pick�:

> 
> private package Thermometer.Some_Particular_Kind_Of_Sensor is
>    type Count_T is range 0 .. 1024;
The ADC is ten bit, so it should be: "type Count_T is range 0 .. 1023;" 
-- 2#11111_11111#

Re: Translating an embedded C algorithm

[Niklas Holsti]

Cesar Rabak wrote:
> Ludovic Brenta escreveu:
> 
>> Niklas Holsti writes:
>> [...]
>>
>> private package Thermometer.Some_Particular_Kind_Of_Sensor is
>>    type Count_T is range 0 .. 1024;
> 
> The ADC is ten bit, so it should be: "type Count_T is range 0 .. 1023;" 
> -- 2#11111_11111#

In this case, I find the base-2 literal harder to read -- how many 1's 
are there really? My eyes cross if I try to count them... Perhaps the 
best form is 2**10 - 1, as in Steve's version of the function.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Translating an embedded C algorithm

[Cesar Rabak]

Niklas Holsti escreveu:
> Cesar Rabak wrote:
>> Ludovic Brenta escreveu:
>>
>>> Niklas Holsti writes:
>>> [...]
>>>
>>> private package Thermometer.Some_Particular_Kind_Of_Sensor is
>>>    type Count_T is range 0 .. 1024;
>>
>> The ADC is ten bit, so it should be: "type Count_T is range 0 .. 
>> 1023;" -- 2#11111_11111#
> 
> In this case, I find the base-2 literal harder to read -- how many 1's 
> are there really? My eyes cross if I try to count them... Perhaps the 
> best form is 2**10 - 1, as in Steve's version of the function.
> 
The three forms for me are OK while they are the correct representation 
(for the OP) of the 10 bit ADC spec.

Re: Translating an embedded C algorithm

[Simon Wright]

Niklas Holsti <niklas.holsti@nospam.please> writes:

> Cesar Rabak wrote:
>> Ludovic Brenta escreveu:
>>
>>> Niklas Holsti writes:
>>> [...]
>>>
>>> private package Thermometer.Some_Particular_Kind_Of_Sensor is
>>>    type Count_T is range 0 .. 1024;
>>
>> The ADC is ten bit, so it should be: "type Count_T is range 0
>> .. 1023;" -- 2#11111_11111#
>
> In this case, I find the base-2 literal harder to read -- how many
> 1's are there really? My eyes cross if I try to count
> them... Perhaps the best form is 2**10 - 1, as in Steve's version of
> the function.

I suppose it would depend on whether your roots were in octal or hex;
personally I started on an F1600 where the address fields were 5-bits
wide, so I instantly recognise 11111 as 31, but most would prefer
2#11_1111_1111# or 2#1_111_111_111# if we have to use base 2. Steve
wins, though!

Re: Translating an embedded C algorithm

[Robert A Duff]

Niklas Holsti <niklas.holsti@nospam.please> writes:

I didn't read your whole post carefully.  It looks good, but:

>       type Celsius_T is delta 0.1 digits 5 range -40.0 .. 120.0;

I think you might want:

    for Celsius_T'Small use Celsius_T'Delta;

here.

Also, I think it would be overkill to put both ways of dealing with
invalid results in an example in a book.  I'd suggest just using the
exception method, and ignore the rather complex idea of variant
records.

- Bob

Re: Translating an embedded C algorithm

[Jeffrey Carter]

Robert A Duff wrote:
> Niklas Holsti <niklas.holsti@nospam.please> writes:
> 
> I didn't read your whole post carefully.  It looks good, but:
> 
>>       type Celsius_T is delta 0.1 digits 5 range -40.0 .. 120.0;
> 
> I think you might want:
> 
>     for Celsius_T'Small use Celsius_T'Delta;
> 
> here.

ARM 3.5.9: "For a decimal fixed point type, the small equals the delta; 
the delta shall be a power of 10."

Re: Translating an embedded C algorithm

[Robert A Duff]

Jeffrey Carter <spam.jrcarter.not@spam.acm.not.org> writes:

> Robert A Duff wrote:
>> Niklas Holsti <niklas.holsti@nospam.please> writes:
>> I didn't read your whole post carefully.  It looks good, but:
>>
>>>       type Celsius_T is delta 0.1 digits 5 range -40.0 .. 120.0;
>> I think you might want:
>>     for Celsius_T'Small use Celsius_T'Delta;
>> here.
>
> ARM 3.5.9: "For a decimal fixed point type, the small equals the delta;
> the delta shall be a power of 10."

Yes, you're right.  I was wrong.

Thanks.

- Bob

Re: Translating an embedded C algorithm

[Niklas Holsti]

Robert A Duff wrote:
> ...
> 
> Also, I think it would be overkill to put both ways of dealing with
> invalid results in an example in a book.  I'd suggest just using the
> exception method, and ignore the rather complex idea of variant
> records.

You may be right that having both methods is too much for this example, 
but I see an important difference in capability and applications between 
variant records and exceptions:

- Exceptions are dynamic and evanescent; they are useful for
   forcing the program to take immediate note of an unexpected
   situation that makes it impossible or incorrect to continue
   with business as usual. In this example, the exception says
   "your present attempt to convert this ADC count into a
   temperature is impossible and I will not let you continue
   as if it had succeeded".

- Variant records can be static and persistent; they are useful
   for recording the fact that some data are available, others
   not. In this example, an ADC.Thermometer.Reading_T could
   be stored in some status record, or telemetry packet, and
   could be consulted later, by other parts of the program, to
   get the temperature or notice the out-of-range condition.
   A value with In_Range = False says "no current temperature
   is available because the last attempt to read the temperature
   gave an out-of-range result".

Thus I think that both methods have their uses, often in the same 
program but at different points.

Of course one could store a non-variant record with a Boolean in-range 
flag and a temperature component, but this would not prevent some part 
of the program from accessing the temperature component even if its 
value is wrong because of an out-of-range condition. As you know (but 
the OP perhaps does not) the variant record form guards against such 
errors by raising Constraint_Error if the program tries to access a 
component that is not present in the current variant.

The variant record approach could also be extended a bit to bring 
enumerated types into the example. Instead of the current Boolean 
discriminant (which is a bit ugly in the "case" constructs) we could 
define, in ADC.Thermometer:

    type Status_T is (Out_Of_Range, In_Range, Under_Min, Over_Max);
    --
    -- The general status of an ADC thermometer reading.
    --
    -- Out_Of_Range
    --    The ADC count was not within the expected range,
    --    and saturation was not requested, so no temperature
    --    is available.
    -- In_Range
    --    The ADC count was within the expected range so the
    --    temperature is available.
    -- Under_Min
    --    The ADC count was below the minimum expected value.
    --    The temperature was saturated at its minimum value.
    -- Over_Max
    --    The ADC count was above the maximum expected value.
    --    The temperature was saturated at its maximum value.

    type Reading_T (Status : Status_T := Out_Of_Range) is record
       case Status is
       when Out_Of_Range =>
          null;
       when In_Range | Under_Min | Over_Max =>
          Temperature : Temperatures.Celsius_T;
       end case;
    end record;

(I expect someone will object that one should use the discriminant only 
to discriminate the variant forms (temperature available or not) and not 
to differentiate other status (temperature saturated or not). That is a 
valid philosophy, and I certainly consider that alternative when I 
design a variant record type, but I defend my right to use the above 
approach, too, when it suits me. :-)

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Translating an embedded C algorithm

[Robert A Duff]

Niklas Holsti <niklas.holsti@nospam.please> writes:

>...and I certainly consider that alternative when I
> design a variant record type, but I defend my right to use the above
> approach, too, when it suits me. :-)

Perfectly reasonable.  But the OP just wants a half-page of C code
translated into nice-looking Ada code.  We don't need to provide
a demo of every Ada feature under the Sun!

- Bob

Re: Translating an embedded C algorithm

[Jeffrey Carter]

Niklas Holsti wrote:
> 
> Thus I think that both methods have their uses, often in the same 
> program but at different points.

As a general component, all these approaches have their uses, but in the 
context of code for a small address space you probably don't want unused 
capability.

Re: Translating an embedded C algorithm

[Jeffrey Carter]

Niklas Holsti wrote:
>    package ADC is
> 
>       type Count_T is range 0 .. 1023;

Why not mod 2 ** 10?

Is

for Count_T'Size use 10;

appropriate here?

Seems to me these are only used to produce temperatures, and so should 
be hidden from the rest of the application.

>       Saturation : Boolean := True;

Control coupling through global variables. Terrible SW engineering. What 
happens when one task changes the value when another is part way through 
the function?

Re: Translating an embedded C algorithm

[Niklas Holsti]

Jeffrey Carter wrote:
> Niklas Holsti wrote:
> 
>>    package ADC is
>>
>>       type Count_T is range 0 .. 1023;
> 
> 
> Why not mod 2 ** 10?

Yes, that would be possible. But the code did not need logical bit-wise 
operations nor shifting (because, following the OP, I assumed that the 
compiler is smart enough to use shifting for divisions and remainders 
where the right operand is a power of 2). Modular arithmetic for ADC 
readings also seems undesirable; if it overflows I don't want 
wrap-around, I want Constraint_Error (or saturation, but Ada has no 
predefined forms of saturating integer types).

> Is
> 
> for Count_T'Size use 10;
> 
> appropriate here?

I don't see any reason for it in this example. If we had some packed 
data structures with Count_T components, sure.

> Seems to me these are only used to produce temperatures, and so should 
> be hidden from the rest of the application.

As I replied to Ludovic, I assumed that the same ADC is used to measure 
other sensors, too. The question of the public visibility of ADC.Count_T 
is a question of "programming in the large", for example which part of 
the SW is actually reading the ADC, and whether we can encapsulate all 
ADC interactions under the hierarchy of package ADC, in which case the 
type Count_T could be hidden in this hierarchy, as you suggest.

>>       Saturation : Boolean := True;
> 
> 
> Control coupling through global variables. Terrible SW engineering. What 
> happens when one task changes the value when another is part way through 
> the function?

I considered the alternative of making Saturation a parameter with a 
default value:

    function Temperature (
       Count      : Count;
       Saturation : Boolean := True)
    return Reading_T;

but I wanted to demonstrate mutable package state in the simplest 
possible way. I agree that "in the large" such freely mutable variables 
are usually a bad idea, and especially in multi-threaded programs, as 
you say.

If we want to follow the original C code exactly then the saturation 
option should of course be removed (assumed always true).

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Translating an embedded C algorithm

[Niklas Holsti]

A correction, or improvement:

Niklas Holsti wrote:
> ...
>    package Temperatures is
> 
>       type Celsius_T is delta 0.1 digits 5 range -40.0 .. 120.0;
                                            ^
I have little experience with fixed-point types, but I think "digits 4" 
should actually be enough in this case (-40.0 .. 120.0). At least the 
code works with "digits 4", too. Anyway, Gnat says the minimum 'Size of 
the type is 12 bits in both cases, so I guess the variables have the 
same size and arithmetic the same speed in both cases (except, perhaps, 
if we multiply or divide two values of this type, but this example code 
does not do that.)

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Translating an embedded C algorithm

[Cesar Rabak]

Niklas Holsti escreveu:
> Niklas Holsti wrote:
>> ...
>>
>> I agree with other posters that simply translating this function into 
>> Ada does not give a good comparison between C and Ada. The first steps 
>> in an Ada design would be to consider encapsulation (packages) and 
>> data representation (types), for which the C version gives no model.
> 
> I'm replying to my own post because I've changed my opinion a bit: I 
> think that an Ada translation of this C function can, with a bit of 
> elaboration, illustrate several Ada features for "programming in the 
> small", even if not for "programming in the large".
> 
> So here is my try at an Ada version of the code and some of the context. 
> This makes for a long post, for which I apologize in advance. Putting 
> the sources somewhere for download seemed like overkill, and I prefer to 
> expose my suggestion to the purifying flames of c.l.a instead of sending 
> it privately to the OP. The Ada code below has been compiled
> and tested (gnat 3.15p, Debian). It is hereby put in the public domain.

Nice! I will only make a pair of comments that I believe relate to the 
OP idea, and will skip suggestions or observations which in the bottom 
line may be considered by other engineers as stylistic.

> 
> In this code, I tried to use as many relevant Ada features as possible, 
> without trying to limit myself to some "8-bit subset". It would be 
> interesting to compile this code with AVR-Ada; I don't happen to have 
> that installed, but I may try it later, if no-one else does it.

Note that the home page for AVR-Ada has this (Status 2nd paragraph):


"The Ada run time system (RTS) on the other hand is for the most part 
not even a run time system. It is more a compile time system :-). Most 
files in the RTS are only needed at compile time. As a consequence we 
don't yet have support for exceptions nor for tasking (multi-threading)."



[snipped]

> and
> 
>    package Temperatures is
> 
>       type Celsius_T is delta 0.1 digits 5 range -40.0 .. 120.0;
>       --
>       -- A temperature in degrees Celsius.
> 
>       -- More temperature stuff ...
> 
>    end Temperatures;

I don't know how an Ada compiler targeted for microcontrollers would 
make the internal representation of this type, but if it employs more 
than a 16 bit word, I would rather stick to the other implementation 
elsethread.

[snipped]

HTH

--
Cesar Rabak

Re: Translating an embedded C algorithm

[Niklas Holsti]

Cesar Rabak wrote:
> Niklas Holsti escreveu:
> ...
>>  ...
>> So here is my try at an Ada version of the code and some of the 
>> context. ...
> 
> Nice! I will only make a pair of comments that I believe relate to the 
> OP idea, and will skip suggestions or observations which in the bottom 
> line may be considered by other engineers as stylistic.

Well, I would like to hear your stylistic views, too... even if no 
objective right or wrong can be judged.

>> ...  It would be interesting to compile this code with AVR-Ada;
> 
> Note that the home page for AVR-Ada has this (Status 2nd paragraph):
>  
> "The Ada run time system (RTS) on the other hand is for the most part 
> not even a run time system. It is more a compile time system :-). Most 
> files in the RTS are only needed at compile time. As a consequence we 
> don't yet have support for exceptions nor for tasking (multi-threading)."

Yes, so the exception-raising form of ADC.Thermometer.Temperature would 
have to be excluded. Luckily :-) there is the other form with a variant 
record type.

To diverge a bit, it would be lovely if some intrepid academic with 
access to hordes of eager students would give them a project to port the 
Open Ravenscar Kernel (ORK) to the AVR for use with AVR-Ada. That would 
give us tasking, at least.

> [snipped]
> 
>>       type Celsius_T is delta 0.1 digits 5 range -40.0 .. 120.0;
> 
> I don't know how an Ada compiler targeted for microcontrollers would 
> make the internal representation of this type, but if it employs more 
> than a 16 bit word, I would rather stick to the other implementation 
> elsethread.

Gnat (3.15p on Debian, target native Intel x86) accepts a 'Size clause 
of 12 bits for this type. I don't see why a compiler targeted to a 
microcontroller should use a larger representation. I'm not expert in 
fixed-point arithmetic implementations but I think addition and 
subtraction can be done without using larger intermediate 
representations, and the example program has no multiplication or 
division operations with this type (it has Celsius_T * Natural, but that 
  does not need special scaling).

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Translating an embedded C algorithm

[Steve Whalen]

Niklas Holsti wrote:
> ... I think that an Ada translation of this C function can, with a bit of
> elaboration, illustrate several Ada features for "programming in the
> small", even if not for "programming in the large".
>
> So here is my try at an Ada version of the code and some of the context. ...

Thank you for taking the time to create the Ada version of the example.

I agree with the others that it is very well done. Even if your example
were not as well done as it is, almost any correct Ada example would
have been vastly better than a blank page in a book. Especially in a
book targeted at a field where Ada should be considered more frequently
than it is.

If you hadn't created this example, the author also would have been
quite justified in putting a comment in the book that the programmers
on comp.lang.ada think Ada is not well suited to embedded programming
(or at least that it would be too much work to create an illustrative
Ada example).

Thanks again for taking the time to write the Ada code. Maybe Martin
can find a place for it in his Wiki book on Ada programming.

Also, you might want to send a copy of the code to the OP, since I'm
not sure the OP is still reading this thread, given the relatively
unprofessional reception the OP was given here.

Steve

Re: Translating an embedded C algorithm

[Niklas Holsti]

Steve Whalen wrote:
> ... 
> Also, you might want to send a copy of the code to the OP, since I'm
> not sure the OP is still reading this thread, given the relatively
> unprofessional reception the OP was given here.

Thanks for the suggestion, I have now done that. I also gave a simpler 
version that always saturates the temperature, as in the C code, and has 
no exceptions or variant records.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Translating an embedded C algorithm

[Cesar Rabak]

Vo, Anh (US SSA) escreveu:
> -----Original Message----- From: comp.lang.ada-bounces@ada-france.org
> [mailto:comp.lang.ada-bounces@ada-france.org] On Behalf Of Talulah 
> Sent: Monday, January 15, 2007 6:37 AM To:
> comp.lang.ada@ada-france.org Subject: Translating an embedded C
> algorithm
> 
[snipped]

> 
> Here I just translated directory to Ada from C code in the table.
> Please pay attention to the Important Note below the Table. Note also
> that I have slightly modified some variables for readability. Let me
> know if more information is desired.
> 
[snipped]

I think a direct translation form C to Ada does not help to 'sell' Ada 
very well.

In the PDF the OP mentions the ADC is 10 bit, so one of advantages of 
Ada, for example, would have been a restricted type for that.

A minor but interesting snag is that the comments do not reflect 
accurately the working of code (C) and the present translation maintains 
it: "Returns: Temperature in �C x 10. INVALID_TEMPERATURE if out of range."

There is no attribution of a such constant INVALID_TEMPERATURE in the 
whole function body!

my 0.01999...

Re: Translating an embedded C algorithm

[Gautier]

Vo, Anh (US SSA) wrote:

A micro-detail: the translation is an occasion to get rid of plenty of *%@�!* 
useless parentheses:

<    if (Adc_Count < MINIMUM_ADC_COUNT) then
..
<    elsif (Adc_Count > MAXIMUM_ADC_COUNT) then
..
<    TempDiff := (Table(Index) - Table (Index+1));
..
<    Temperature :=
<             Table(Index) - ((TempDiff * InterpolationDistance) / SPACING);

 >    if Adc_Count < MINIMUM_ADC_COUNT then
..
 >    elsif Adc_Count > MAXIMUM_ADC_COUNT then
..
 >    TempDiff := Table(Index) - Table (Index+1);
..
 >    Temperature :=
 >             Table(Index) - (TempDiff * InterpolationDistance) / SPACING;

A question: I see all the time things like "if (.. < ..)" in C - are the 
parentheses required there ?
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

Re: Translating an embedded C algorithm

[Cesar Rabak]

Gautier escreveu:
[snipped]

> A question: I see all the time things like "if (.. < ..)" in C - are the 
> parentheses required there ?
Yes.

Re: Translating an embedded C algorithm

[Jean-Pierre Rosen]

Gautier a �crit :
> Vo, Anh (US SSA) wrote:
> 
> A micro-detail: the translation is an occasion to get rid of plenty of 
> *%@�!* useless parentheses:
> 
> <    if (Adc_Count < MINIMUM_ADC_COUNT) then
> [...]
Of course, this is another thing that AdaControl can check.
Never post something without passing it to AdaControl :-) :-) :-)

> A question: I see all the time things like "if (.. < ..)" in C - are the 
> parentheses required there ?
Yes, they are - because C has no "then" keyword. There must be something 
to tell the compiler where the expression ends...
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Translating an embedded C algorithm

[Ludovic Brenta]

Jean-Pierre Rosen a écrit :
>> A question: I see all the time things like "if (.. < ..)" in C - are the
>> parentheses required there ?
> Yes, they are - because C has no "then" keyword. There must be something
> to tell the compiler where the expression ends...

Not to mention that the parentheses may contain several expressions
separated by the comma operator, some or all of which may have side
effects, and only the last of which actually controls the if
statement... for example:

if (a = 1, b = a, c = --a, (a = --b) == c) {
   ...
}

Ah, the joy of obfuscated programming :) :) :)

-- 
Ludovic Brenta.

Re: Translating an embedded C algorithm

[Georg Bauhaus]

On Tue, 2007-01-16 at 08:12 -0800, Ludovic Brenta wrote:
> Jean-Pierre Rosen a écrit :
> >> A question: I see all the time things like "if (.. < ..)" in C - are the
> >> parentheses required there ?
> > Yes, they are - because C has no "then" keyword. There must be something
> > to tell the compiler where the expression ends...
> 
> Not to mention that the parentheses may contain several expressions
> separated by the comma operator, some or all of which may have side
> effects, and only the last of which actually controls the if
> statement... for example:
> 
> if (a = 1, b = a, c = --a, (a = --b) == c) {
>    ...
> }
>
> Ah, the joy of obfuscated programming :) :) :)

Obfuscuation in this style is quite possible in Ada, too,
including side effects. This is from a legal program:

   if (a = 1, b = a) = T' (c = -a, (a = -b) =- c) then
      null;
   end if;

Hint: the parentheses are needed :)

Re: Translating an embedded C algorithm

[Ludovic Brenta]

Georg Bauhaus <bauhaus@arcor.de> writes:
>On Tue, 2007-01-16 at 08:12 -0800, Ludovic Brenta wrote:
[...]
>> if (a = 1, b = a, c = --a, (a = --b) == c) {
>>    ...
>> }
>>
>> Ah, the joy of obfuscated programming :) :) :)
>> Obfuscuation in this style is quite possible in Ada, too,
>
> including side effects. This is from a legal program:
>
>    if (a = 1, b = a) = T' (c = -a, (a = -b) =- c) then
>       null;
>    end if;
>
> Hint: the parentheses are needed :)

Including the side effects?  All I see are two aggregates for a
hypothetical "type T is array (Positive range <>) of Boolean", but
where are the assignments to a, b and c?  And where are the decrements
of a and b?

-- 
Ludovic Brenta.

Re: Translating an embedded C algorithm

[Georg Bauhaus]

On Tue, 2007-01-16 at 23:32 +0100, Ludovic Brenta wrote:
> Georg Bauhaus <bauhaus@arcor.de> writes:
> >On Tue, 2007-01-16 at 08:12 -0800, Ludovic Brenta wrote:
> [...]
> >> if (a = 1, b = a, c = --a, (a = --b) == c) {
> >>    ...
> >> }
> >>
> >> Ah, the joy of obfuscated programming :) :) :)
> >> Obfuscuation in this style is quite possible in Ada, too,
> >
> > including side effects. This is from a legal program:
> >
> >    if (a = 1, b = a) = T' (c = -a, (a = -b) =- c) then
> >       null;
> >    end if;
> >
> > Hint: the parentheses are needed :)
> 
> Including the side effects?  All I see are two aggregates for a
> hypothetical "type T is array (Positive range <>) of Boolean", but
> where are the assignments to a, b and c?  And where are the decrements
> of a and b?

The assignments happen in the body of
  function "-"(x: Integer) return Boolean;
which is defined at the same level as a, b, and c.

Re: Translating an embedded C algorithm

[Ludovic Brenta]

Georg Bauhaus  writes:
> The assignments happen in the body of
>   function "-"(x: Integer) return Boolean;
> which is defined at the same level as a, b, and c.

Wow, that's mean :)  You won the first Obfuscated Ada Contest :)

-- 
Ludovic Brenta.

Re: Translating an embedded C algorithm

[Cesar Rabak]

Ludovic Brenta escreveu:
> Jean-Pierre Rosen a �crit :
>>> A question: I see all the time things like "if (.. < ..)" in C - are the
>>> parentheses required there ?
>> Yes, they are - because C has no "then" keyword. There must be something
>> to tell the compiler where the expression ends...
> 
> Not to mention that the parentheses may contain several expressions
> separated by the comma operator, some or all of which may have side
> effects, and only the last of which actually controls the if
> statement... for example:
> 
> if (a = 1, b = a, c = --a, (a = --b) == c) {
>    ...
> }
> 
> Ah, the joy of obfuscated programming :) :) :)
> 
Would you believe that:

if (a = 1) {
     ...
}

Is semantically valid C, but because it is very easy to mistake this 
when the intended was:

if (a == 1) {
     ...
}

That there are tools to look for and signal this!?

Re: Translating an embedded C algorithm

[Frank J. Lhota]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]

"Cesar Rabak" <csrabak@yahoo.com.br> wrote in message 
news:eoj0u8$148$1@aioe.org...
> Ludovic Brenta escreveu:
>> Jean-Pierre Rosen a �crit :
>>>> A question: I see all the time things like "if (.. < ..)" in C - are 
>>>> the
>>>> parentheses required there ?
>>> Yes, they are - because C has no "then" keyword. There must be something
>>> to tell the compiler where the expression ends...
>>
>> Not to mention that the parentheses may contain several expressions
>> separated by the comma operator, some or all of which may have side
>> effects, and only the last of which actually controls the if
>> statement... for example:
>>
>> if (a = 1, b = a, c = --a, (a = --b) == c) {
>>    ...
>> }
>>
>> Ah, the joy of obfuscated programming :) :) :)
>>
> Would you believe that:
>
> if (a = 1) {
>     ...
> }
>
> Is semantically valid C, but because it is very easy to mistake this when 
> the intended was:
>
> if (a == 1) {
>     ...
> }
>
> That there are tools to look for and signal this!?

A lot of C compiler will warn you about constructs such as

    if (a=1) {
        ...
    }

Re: Translating an embedded C algorithm

[Cesar Rabak]

Frank J. Lhota escreveu:
> "Cesar Rabak" <csrabak@yahoo.com.br> wrote in message 
> news:eoj0u8$148$1@aioe.org...
[snipped]

>> Is semantically valid C, but because it is very easy to mistake this when 
>> the intended was:
>>
>> if (a == 1) {
>>     ...
>> }
>>
>> That there are tools to look for and signal this!?
> 
> A lot of C compiler will warn you about constructs such as
> 
>     if (a=1) {
>         ...
>     }
> 
Yes and there is no way (except of a human reading and checking) to say
if that is right or wrong... but I've been told a lot of other languages
(out of direct descendants of C) also have similar constructs.

Re: Translating an embedded C algorithm

[Dmitry A. Kazakov]

On Tue, 16 Jan 2007 15:12:44 -0200, Cesar Rabak wrote:

> Would you believe that:
> 
> if (a = 1) {
>      ...
> }
> 
> Is semantically valid C, but because it is very easy to mistake this 
> when the intended was:
> 
> if (a == 1) {
>      ...
> }
> 
> That there are tools to look for and signal this!?

There is a good C-style rule for that. Place all constants on the left,
i.e.

 if (1 = a) {  // Compile error

Another advantage is that constant expressions are usually shorter, so it
becomes more readable as well.

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

Re: Translating an embedded C algorithm

[Cesar Rabak]

Dmitry A. Kazakov escreveu:
> On Tue, 16 Jan 2007 15:12:44 -0200, Cesar Rabak wrote:
> 
>> Would you believe that:
>>
>> if (a = 1) {
>>      ...
>> }
>>
>> Is semantically valid C, but because it is very easy to mistake this 
>> when the intended was:
>>
>> if (a == 1) {
>>      ...
>> }
>>
>> That there are tools to look for and signal this!?
> 
> There is a good C-style rule for that. Place all constants on the left,
> i.e.
> 
>  if (1 = a) {  // Compile error
> 
> Another advantage is that constant expressions are usually shorter, so it
> becomes more readable as well.
> 
Not always the assigment or comparison is being done against a constant, 
so this is an advance, but still does not avoid all mishaps.

Re: Translating an embedded C algorithm

[Dmitry A. Kazakov]

On Tue, 16 Jan 2007 16:08:21 -0200, Cesar Rabak wrote:

> Dmitry A. Kazakov escreveu:
>> 
>> There is a good C-style rule for that. Place all constants on the left,
>> i.e.
>> 
>>  if (1 = a) {  // Compile error
>> 
>> Another advantage is that constant expressions are usually shorter, so it
>> becomes more readable as well.
>> 
> Not always the assigment or comparison is being done against a constant,

Yes, but it makes 80% of the cases. Interestingly, but I have a feeling
that in Ada programs there is somehow less comparisons like above. Maybe
because of use of enumeration types and case-statements?

> so this is an advance, but still does not avoid all mishaps.

Yes, it does not, but it reduces risk. A further step could be switching to
Ada...

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

Re: Translating an embedded C algorithm

[Cesar Rabak]

Dmitry A. Kazakov escreveu:
> On Tue, 16 Jan 2007 16:08:21 -0200, Cesar Rabak wrote:
> 
>> Dmitry A. Kazakov escreveu:
>>> There is a good C-style rule for that. Place all constants on the left,
>>> i.e.
>>>
>>>  if (1 = a) {  // Compile error
>>>
>>> Another advantage is that constant expressions are usually shorter, so it
>>> becomes more readable as well.
>>>
>> Not always the assigment or comparison is being done against a constant,
> 
> Yes, but it makes 80% of the cases. Interestingly, but I have a feeling
> that in Ada programs there is somehow less comparisons like above. Maybe
> because of use of enumeration types and case-statements?
> 

I don't have this statistic, but, may I think you're in the ballpark.

WRT use of enum types, perhaps. C has case statements as well.

I feel the whole issue revolves around some philosophic ideas that 
programmers in each language learn from day one and then start to reason 
in that way for a full life.

>> so this is an advance, but still does not avoid all mishaps.
> 
> Yes, it does not, but it reduces risk. A further step could be switching to
> Ada...
> 

Yes, but this switching is costly and if we just do an 'automated' 
translation you do not earn any bonuses. . .

Re: Translating an embedded C algorithm

[Björn Persson]

Cesar Rabak wrote:

> C has case statements as well.

The switch statement is utterly broken (so to speak). I prefer not to use
it. I suppose my code contains slightly more "==" because of this.

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Translating an embedded C algorithm

[Cesar Rabak]

Bj�rn Persson escreveu:
> Cesar Rabak wrote:
> 
>> C has case statements as well.
> 
> The switch statement is utterly broken (so to speak). I prefer not to use
> it. I suppose my code contains slightly more "==" because of this.
> 
The problem with people prefering or not certain things is exactly this! 
You are on the 'not use it [C case statements], and a lot of developers 
in 'not use Ada at all'...

Re: Translating an embedded C algorithm

[Björn Persson]

Cesar Rabak wrote:

> Bj�rn Persson escreveu:
>> Cesar Rabak wrote:
>> 
>>> C has case statements as well.
>> 
>> The switch statement is utterly broken (so to speak). I prefer not to use
>> it. I suppose my code contains slightly more "==" because of this.
>> 
> The problem with people prefering or not certain things is exactly this!
> You are on the 'not use it [C case statements], and a lot of developers
> in 'not use Ada at all'...

Huh?

Dmitry guessed that Ada programmers' use of case statements contributes to
comparisons against constants with the equality operator being less
frequent in Ada code than in C code. You objected, saying "C has case
statements as well." You thereby implied that the use of case statements
cannot contribute to any such difference in frequency. I provided a counter
example, explaining how I don't use the switch statement even though it
exists, and how this causes a my C code to contain more equality operators.

Now my not using switch statements is somehow a problem to you? Why is that,
and what does it have to do with how frequently equality operators are
used?

Do you perchance try to use as many different things as you possibly can,
just so that you'll be able to say that there is nothing in the word that
you prefer not to use?

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Translating an embedded C algorithm

[Cesar Rabak]

Bj�rn Persson escreveu:
> Cesar Rabak wrote:
> 
>> Bj�rn Persson escreveu:
>>> Cesar Rabak wrote:
>>>
>>>> C has case statements as well.
>>> The switch statement is utterly broken (so to speak). I prefer not to use
>>> it. I suppose my code contains slightly more "==" because of this.
>>>
>> The problem with people prefering or not certain things is exactly this!
>> You are on the 'not use it [C case statements], and a lot of developers
>> in 'not use Ada at all'...
> 
> Huh?
> 
> Dmitry guessed that Ada programmers' use of case statements contributes to
> comparisons against constants with the equality operator being less
> frequent in Ada code than in C code. You objected, saying "C has case
> statements as well." You thereby implied that the use of case statements
> cannot contribute to any such difference in frequency. 

Yes. I do not intend to write a PhD thesis on it, but I think so.

> I provided a counter
> example, explaining how I don't use the switch statement even though it
> exists, and how this causes a my C code to contain more equality operators.

You're explanation (still available above) says explicitly "..I 
prefer.." after a gratuitous judgement "...s utterly broken...".
> 
> Now my not using switch statements is somehow a problem to you? Why is that,
> and what does it have to do with how frequently equality operators are
> used?
> 

Your preferences and your use of any language construct is not a problem 
to me. I just found your statement a good (counter) example on how easy 
is to find justifications for use of something, which includes Ada language.

> Do you perchance try to use as many different things as you possibly can,
> just so that you'll be able to say that there is nothing in the word that
> you prefer not to use?
> 
No, I try to use the things each language offers me to be the more 
idiomatically within the language proposition. Disguising case 
('swuitch') constructs with other low level equivalent code falls in 
this category.

But in your code for your boss/client you the way you want or is allowed 
to, OK!? I just commented your witness!

Regards,

--
Cesar Rabak

Re: Translating an embedded C algorithm

[Maciej Sobczak]

Bj�rn Persson wrote:

>> C has case statements as well.
> 
> The switch statement is utterly broken (so to speak). I prefer not to use
> it. I suppose my code contains slightly more "==" because of this.

What have you gained? Is your code more readable? Easier for maintenance?

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Translating an embedded C algorithm

[Björn Persson]

Maciej Sobczak wrote:

> Bj�rn Persson wrote:
> 
>>> C has case statements as well.
>> 
>> The switch statement is utterly broken (so to speak). I prefer not to use
>> it. I suppose my code contains slightly more "==" because of this.
> 
> What have you gained? Is your code more readable? Easier for maintenance?

I get rid of the risk of forgetting a break, so my code is hopefully less
buggy.

I feel that the risk that I'll forget a break is greater than the risk that
I'll make an assignment instead of a comparison. If you feel the other way,
maybe you'll choose to use the switch statement.

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Translating an embedded C algorithm

[Robert A Duff]

Bj�rn Persson <spam-away@nowhere.nil> writes:

> Maciej Sobczak wrote:
>
>> Bj�rn Persson wrote:
>> 
>>>> C has case statements as well.
>>> 
>>> The switch statement is utterly broken (so to speak). I prefer not to use
>>> it. I suppose my code contains slightly more "==" because of this.
>> 
>> What have you gained? Is your code more readable? Easier for maintenance?
>
> I get rid of the risk of forgetting a break, so my code is hopefully less
> buggy.
>
> I feel that the risk that I'll forget a break is greater than the risk that
> I'll make an assignment instead of a comparison. If you feel the other way,
> maybe you'll choose to use the switch statement.

A switch statement in C is really just a computed goto.  Google for
"duff's device" for an "interesting" example.  (No relation, by the
way.)

I agree that "forgetting break" is an issue.  But the much bigger issue
is that Ada case statements have full-coverage rules, checked at compile
time.  That's one of my favorite features of Ada.

- Bob

Re: Translating an embedded C algorithm

[Maciej Sobczak]

Cesar Rabak wrote:

> Would you believe that:
> 
> if (a = 1) {

> Is semantically valid C, but because it is very easy to mistake this 
> when the intended was:
> 
> if (a == 1) {

> That there are tools to look for and signal this!?

No need for separate tools, gcc -Wall issues an informative warning.
And you do compile with -Wall, right?

If you are not comfortable with the above problem, consider this:

if ($a = $b) { ...
if ($a == $b) { ...
if ($a === $b) { ...

All three are legal in PHP and have different meaning.
Now *that* is funny. ;-)

BTW - if just parentheses in C are problematic for anybody, I recommend 
some Lisp or Scheme exercise for better perspective... :-)

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Translating an embedded C algorithm -- OT

[Cesar Rabak]

Maciej Sobczak escreveu:
> Cesar Rabak wrote:
> 
>> Would you believe that:
>>
>> if (a = 1) {
> 
>> Is semantically valid C, but because it is very easy to mistake this 
>> when the intended was:
>>
>> if (a == 1) {
> 
>> That there are tools to look for and signal this!?
> 
> No need for separate tools, gcc -Wall issues an informative warning.
> And you do compile with -Wall, right?
> 
Not all C code is compiled [only] with gcc...

Re: Translating an embedded C algorithm -- OT

[Talulah]

Cesar Rabak wrote:

> Maciej Sobczak escreveu:
> > Cesar Rabak wrote:
> >
> >> Would you believe that:
> >>
> >> if (a = 1) {
> >
> >> Is semantically valid C, but because it is very easy to mistake this
> >> when the intended was:
> >>
> >> if (a == 1) {
> >
> >> That there are tools to look for and signal this!?
> >
> > No need for separate tools, gcc -Wall issues an informative warning.
> > And you do compile with -Wall, right?
> >
> Not all C code is compiled [only] with gcc...


Quite right Cesar! I guess very little EMBEDDED code is compiled with
GCC. This is why in our company we have a rule that code must first
pass through Lint (which would catch that error) before being peer code
reviewed!

Re: Translating an embedded C algorithm -- OT

[Cesar Rabak]

Talulah escreveu:
> Cesar Rabak wrote:
> 
>> Maciej Sobczak escreveu:
>>> Cesar Rabak wrote:
[snipped]

>>> And you do compile with -Wall, right?
>>>
>> Not all C code is compiled [only] with gcc...
> 
> 
> Quite right Cesar! I guess very little EMBEDDED code is compiled with
> GCC. This is why in our company we have a rule that code must first
> pass through Lint (which would catch that error) before being peer code
> reviewed!
> 
Yes, several companies I do consulting for have this practice in place. 
Run trough a pretty printer and a version of lint.

Re: Translating an embedded C algorithm -- OT

[Maciej Sobczak]

Cesar Rabak wrote:

>>> if (a = 1) {

>>> if (a == 1) {

>> No need for separate tools, gcc -Wall issues an informative warning.
>> And you do compile with -Wall, right?
>>
> Not all C code is compiled [only] with gcc...

If you use another compiler and it does not provide the functionality 
that you have for free from gcc, you should certainly report this 
complaint to the vendor.

More to this, if you are at least moderately serious about robustness of 
your code, I'd expect that you compile it (or at least its isolated 
critical parts) with a *set* of compilers (the fact that gcc is free 
makes it an easy candidate) to get as much feedback as you can. 
Preferably on a regular basis, nightly build or such.

If your working environment is so constrained that you don't even run 
noghtly builds on a set of compilers, you can always write a simple 
Perl/Tcl/Python/awk/grep/whatever script that will highlight such 
constructs - just look for if and = that comes in the subsequent pair of 
parentheses.

Note also that in C++ the above constructs are both legal provided that 
the following two are true:

1. assignment operator returns something ...
2. ... that is implicitly convertible to some fundamental type.

These two points already give you many opportunities to guard against 
such mistakes.

In general - I totally understand your points, but I don't count them as 
showstoppers.

And coming back to Ada - can you believe that when I write Finalise 
instead of Finalize, it is legal but does not do what I want? 
Unbelievable. Any compiler options for this? ;-)

(I know - in some future I will be able to enjoy the override keyword.)

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Translating an embedded C algorithm -- OT

[Alex R. Mosteo]

Maciej Sobczak wrote:

> And coming back to Ada - can you believe that when I write Finalise
> instead of Finalize, it is legal but does not do what I want?
> Unbelievable. Any compiler options for this? ;-)
> 
> (I know - in some future I will be able to enjoy the override keyword.)

I'm already using it with gnat, and it really comes in handy for situations
like this. It would be even better if some style check is added to issue
warnings about it.

Re: Translating an embedded C algorithm -- OT

[Jeffrey Carter]

Maciej Sobczak wrote:
> 
> And coming back to Ada - can you believe that when I write Finalise 
> instead of Finalize, it is legal but does not do what I want? 
> Unbelievable. Any compiler options for this? ;-)

Yeah, and when I write Fina1ize or Finolize or Vinylize instead of 
Finalize, it is legal but does not do what I want. Shouldn't there be 
some way to prevent that?

Re: Translating an embedded C algorithm -- OT

[Cesar Rabak]

Jeffrey Carter escreveu:
> Maciej Sobczak wrote:
>>
>> And coming back to Ada - can you believe that when I write Finalise 
>> instead of Finalize, it is legal but does not do what I want? 
>> Unbelievable. Any compiler options for this? ;-)
> 
> Yeah, and when I write Fina1ize or Finolize or Vinylize instead of 
> Finalize, it is legal but does not do what I want. Shouldn't there be 
> some way to prevent that?
Don't your IDE show Finolize or Vinylize in different colour?

Re: Translating an embedded C algorithm -- OT

[Jeffrey Carter]

Cesar Rabak wrote:
> Don't your IDE show Finolize or Vinylize in different colour?

No, all identifiers (including Finalize) are the same color. Otherwise, 
Finalise would appear differently than Finalize.

Re: Translating an embedded C algorithm -- OT

[Cesar Rabak]

Maciej Sobczak escreveu:
> Cesar Rabak wrote:
> 
>>>> if (a = 1) {
> 
>>>> if (a == 1) {
> 
>>> No need for separate tools, gcc -Wall issues an informative warning.
>>> And you do compile with -Wall, right?
>>>
>> Not all C code is compiled [only] with gcc...
> 
> If you use another compiler and it does not provide the functionality 
> that you have for free from gcc, you should certainly report this 
> complaint to the vendor.

It is arguable something to try but not a thing the vendor would be 
obliged to.

> 
> More to this, if you are at least moderately serious about robustness of 
> your code, I'd expect that you compile it (or at least its isolated 
> critical parts) with a *set* of compilers (the fact that gcc is free 
> makes it an easy candidate) to get as much feedback as you can. 

With embedded work this approach brings a lot of problems on the side. 
If you work for a rich enough company that can afford more than a vendor 
for the compiler, the problems are bearable, but even so many (most of 
them on non standard header names and so on).

Attempting to check C source code intended for some MCU with hosted 
compilers (ca. 15 yrs ago the company I worked had some guys that tried 
that using Turbo C) opens a can of worms about the header files and the 
constants, macros, etc.

In the last chapter of a soap opera, management had to forbid due the 
ammount of #ifdefs in code and vendor supplied files.

Then (PC) Lint came to scene!

> Preferably on a regular basis, nightly build or such.
> 
> If your working environment is so constrained that you don't even run 
> noghtly builds on a set of compilers, you can always write a simple 
> Perl/Tcl/Python/awk/grep/whatever script that will highlight such 
> constructs - just look for if and = that comes in the subsequent pair of 
> parentheses.

For that single one, yes, for a lot of idiomatic symptoms worth looking, 
in a moderate size shop buying some licenses for lint or using LCLint 
(a.k.a. Splint) which is FOSS, is better.

> 
> Note also that in C++ the above constructs are both legal provided that 
> the following two are true:
> 
> 1. assignment operator returns something ...
> 2. ... that is implicitly convertible to some fundamental type.
 >
 > These two points already give you many opportunities to guard against
 > such mistakes.
 >

OK. But C++ in embedded work still is not as widespread.
> In general - I totally understand your points, but I don't count them as 
> showstoppers.

I agree. The showstoppers belong to the management [dept.]!

> 
> And coming back to Ada - can you believe that when I write Finalise 
> instead of Finalize, it is legal but does not do what I want? 
> Unbelievable. Any compiler options for this? ;-)

Yes. Sinc I'm a non native English speaker I _do_ know what you're 
writing about!

> 
> (I know - in some future I will be able to enjoy the override keyword.)
> 

Probably sooner than you might expect!

Re: Translating an embedded C algorithm -- OT

[Simon Wright]

Cesar Rabak <csrabak@yahoo.com.br> writes:

>> And coming back to Ada - can you believe that when I write Finalise
>> instead of Finalize, it is legal but does not do what I want?
>> Unbelievable. Any compiler options for this? ;-)
>
> Yes. Sinc I'm a non native English speaker I _do_ know what you're
> writing about!

Or even (like me) a non-American English speaker!

Re: Translating an embedded C algorithm

[Cesar Rabak]

Vo, Anh (US SSA) escreveu:
> -----Original Message-----
[snipped]
A suggestion for the OP:

<    MINIMUM_ADC_COUNT : constant := Integer'Last;
<    MAXIMUM_ADC_COUNT : constant := Integer'Last;
<    SPACING : constant := 1;
..
 >    MINIMUM_ADC_COUNT : constant := 220;
 >    MAXIMUM_ADC_COUNT : constant := 468;
 >    SPACING : constant := 8;

The values 220 and 468 come from its Table 1 (PDF file). Also SPACING is 
described as being 8.

RE: Translating an embedded C algorithm

[Vo, Anh (US SSA)]

-----Original Message-----
From: comp.lang.ada-bounces@ada-france.org [mailto:comp.lang.ada-bounces@ada-france.org] On Behalf Of Cesar Rabak

Vo, Anh (US SSA) escreveu:
> -----Original Message-----
[snipped]
A suggestion for the OP:

<    MINIMUM_ADC_COUNT : constant := Integer'Last;
<    MAXIMUM_ADC_COUNT : constant := Integer'Last;
<    SPACING : constant := 1;
..
 >    MINIMUM_ADC_COUNT : constant := 220;
 >    MAXIMUM_ADC_COUNT : constant := 468;
 >    SPACING : constant := 8;

The values 220 and 468 come from its Table 1 (PDF file). Also SPACING is 
described as being 8.

Thanks for pointing these values out. I did it in hurry. So, I did not read the PDF file in details. Today I attempted to find out where ReadEEPROM table or function is defined. I did not see it. In addition, I did ask for its definition. However, it was left out. Again, here it is.

   function ReadEEPROM (Temp : in Integer) return Integer is
   begin
      return Temp; -- for now
   end ReadEEPROM;

I assume ReadEEPROM is a function. Whether it is a table or a function, it needs to be defined. Assume that ReadEEPROM is defined, here is the updated version of it. Thanks to Christoph Grein for his correction.

------------------------------------------------------------------------
--| MeasureTemperature
--|
--| Calculates the temperature in ºC given the ADC count by lookup
--| table and linear interpolation of the diode circuit characteristic.
--|
--| Parameters:
--| AdcCount Raw ADC count.
--|
--| Returns:
--| Temperature in ºC x 10. INVALID_TEMPERATURE if out of range.
--| 
--| Note: GNAT-GPL-2006 compiler on Windows was used
-------------------------------------------------------------------------
function Measure_Temperature (Adc_Count : in Integer) return Integer is

   Index : Integer := 0;
   InterpolationDistance : Integer := 0;
   TempDiff : Integer := 0;
   TempCalOffset : Integer := 0;
   Temperature : Integer := 0;
   
   TEMPERATURE_TABLE_NUM_ENTRIES : constant := 32;
   Table : constant array (0 .. TEMPERATURE_TABLE_NUM_ENTRIES - 1) of Integer :=
                               (1171, 1116, 1061, 1006, 952,   899,  846,  793,
                                 741,  689,  638,  588, 537,   488,  438,  389,
                                 341,  293,  246,  199, 152,   106,   61,   16,
                                 -29,  -73, -116, -160, -202, -244, -286, -327);

   MINIMUM_ADC_COUNT : constant := 220;
   MAXIMUM_ADC_COUNT : constant := 246;
   SPACING : constant := 8; 
   TEMPERATURE_CAL_VALUE : constant := 0;

   -- *** Important Note: 
   -- The algorithm of the following function needs to be defined.
   function ReadEEPROM (Temp : in Integer) return Integer is
   begin
      return Temp; -- for now
   end ReadEEPROM;
   -----------------------------------------------------------
   
begin
   
   -- Index is the index into the table. Each table entry is 8 ADC
   -- counts higher than the last one, so subtract the offset and
   -- divide by 8 to find the table index. InterpolationDistance
   -- is the linear distance between the the table entry ADC cou nt
   -- and the actual ADC count.
   -- Check range of Adc_Count and saturate index if out of range.
   if (Adc_Count < MINIMUM_ADC_COUNT) then
      -- Underflow of ADC - saturate at minimum value
      Index := 0;
   elsif (Adc_Count > MAXIMUM_ADC_COUNT) then
      -- Overflow of ADC - saturate at maximum value
      Index := TEMPERATURE_TABLE_NUM_ENTRIES - 1;
   else
      -- Find the index of the table entry just below the ADC value
      Index := (Adc_Count - MINIMUM_ADC_COUNT) / SPACING;
   end if;
   
   -- Calculate the interpolation between the table entries either side of
   -- the ADC value. This is the remainder of the difference between the
   -- ADC count and the minimum temperature ADC count divided by the
   -- spacing between table entries. Since the spacing is a power of 2,
   -- this can be achieved by simply masking all but the bottom 3 bits.
   InterpolationDistance := (Adc_Count - MINIMUM_ADC_COUNT) mod (SPACING - 1);
   TempDiff := (Table(Index) - Table (Index+1));
   
   -- The temperature is then the base temperature minus the amount
   -- calculated by linear interpolation. The compiler is clever enough
   -- to know that dividing by 8 is a right shift of three bits.
   Temperature := Table(Index) - ((TempDiff * InterpolationDistance) / SPACING);
   
   -- To this is then added the calibration offset to the temperature table.
   TempCalOffset := ReadEeprom (TEMPERATURE_CAL_VALUE);
   Temperature := Temperature + TempCalOffset;
   
   return Temperature;
        
end Measure_Temperature;
         

Re: Translating an embedded C algorithm

[Cesar Rabak]

Vo, Anh (US SSA) escreveu:
> -----Original Message----- From: comp.lang.ada-bounces@ada-france.org
> [mailto:comp.lang.ada-bounces@ada-france.org] On Behalf Of Cesar
> Rabak
> 
> Vo, Anh (US SSA) escreveu:
>> -----Original Message-----
> [snipped] A suggestion for the OP:
> 
> <    MINIMUM_ADC_COUNT : constant := Integer'Last; <
> MAXIMUM_ADC_COUNT : constant := Integer'Last; <    SPACING : constant
> := 1; ..
>> MINIMUM_ADC_COUNT : constant := 220; MAXIMUM_ADC_COUNT : constant
>> := 468; SPACING : constant := 8;
> 
> The values 220 and 468 come from its Table 1 (PDF file). Also SPACING
> is described as being 8.
> 
> Thanks for pointing these values out. I did it in hurry. So, I did
> not read the PDF file in details. Today I attempted to find out where
> ReadEEPROM table or function is defined. I did not see it. In
> addition, I did ask for its definition. However, it was left out.
> Again, here it is.

You're welcome. I also did read very diagonally, probably an
implementation of mine would have errors as well ;-)

> 
> function ReadEEPROM (Temp : in Integer) return Integer is begin 
> return Temp; -- for now end ReadEEPROM;
> 
> I assume ReadEEPROM is a function. Whether it is a table or a
> function, it needs to be defined. Assume that ReadEEPROM is defined,
> here is the updated version of it. Thanks to Christoph Grein for his
> correction.
> 

Here a comment: it's the right assumption per OP description and
C code. However, I think that in an embedded system (specially for a
microcontroller) the cost of a function call just to get a value may be
not worth of. As the value of the argument seems to be a constant (all
uppercase names in C normally are macros), I think ReadEEPROM just reads
a memory (in E�PROM probably).

> ----------------------------------------------------------------------
>  --| MeasureTemperature --| --| Calculates the temperature in �C
> given the ADC count by lookup --| table and linear interpolation of
> the diode circuit characteristic. --| --| Parameters: --| AdcCount
> Raw ADC count. --| --| Returns: --| Temperature in �C x 10.
> INVALID_TEMPERATURE if out of range. --| --| Note: GNAT-GPL-2006
> compiler on Windows was used 
> -----------------------------------------------------------------------
> 
Observe the 'specification' on this comment (not yours I know, but
rather a direct translation of the OP C code) and the implementation:


> function Measure_Temperature (Adc_Count : in Integer) return Integer
> is
[snipped]

I would have written this part (to be accord the spec):
> if (Adc_Count < MINIMUM_ADC_COUNT) then -- Underflow of ADC -
> saturate at minimum value Index := 0; elsif (Adc_Count >
> MAXIMUM_ADC_COUNT) then -- Overflow of ADC - saturate at maximum
> value Index := TEMPERATURE_TABLE_NUM_ENTRIES - 1;

this way:
         -- beware of line wrap in Usenet
	if Adc_Count < MINIMUM_ADC_COUNT or else Adc_Count >
	MAXIMUM_ADC_COUNT then
       return INVALID_TEMPERATURE;

> else -- Find the index of the table entry just below the ADC value 
> Index := (Adc_Count - MINIMUM_ADC_COUNT) / SPACING; end if;

and thus I would have put all the remaining of this code within the else
block above.

Re: Translating an embedded C algorithm

[Niklas Holsti]

Vo, Anh (US SSA) wrote:
> [snipped] 
> here is the updated version of it. Thanks to Christoph Grein for his correction.
> 
> ------------------------------------------------------------------------
> --| MeasureTemperature
> --|
> [snipped]
>    InterpolationDistance := (Adc_Count - MINIMUM_ADC_COUNT) mod (SPACING - 1);

To pick a nit: I think that should be "mod SPACING", not "SPACING - 1".

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Translating an embedded C algorithm

[Talulah]

Thanks everyone for your very valuable comments. I'm sorry that the C
code I provided had a few problems - I had taken it out of a previous
project of mine and edited it for a stand-alone function, but
overlooked the values of the constants, and the comment in the header
returning INVALID_TEMPERATURE (which was originally FFFF hex), and a
couple of other things.

To answer Jeffrey Carter's assertion that I am not qualified to write
this book, I can only answer that since the majority of embedded RT
projects ARE written in C, then the majority audience for the book will
be interested in seeing examples written in C. That is no reflection on
the "quality" of the language, but is just facing facts. Secondly, the
product that this code came from is a domestic electricity meter for
India, a market of 18 million devices per year. This is not a
safety-critical product at all, but one which in those volumes must be
designed for the lowest cost possible. Hence the use of 4 diodes as a
temperature sensor, and hence (this may get more argument) the use of C
rather than Ada. Crossing an 8k ROM boundary (the current code is just
over 32kbytes) adds 3 pence (UK) to the cost on this microcontroller
(Renesas H8/3827). Multiply that by 18 million and the resulting half
million UK pounds is the reason I program in C. Thirdly, I am
thick-skinned enough to brush off rudeness from newsgroup posters, it
is just a shame that you decided not to post any useful comments.

By asking you kind people for help in reproducing the example in Ada,
it hopefully will allow readers to see the advantages that Ada can give
them, and encourage them to research Ada as a possible language for
future products that would benefit from these advantages, but also to
understand the disadvantage of code size and speed (hard hat firmly in
place after that!).

I understand now that a direct translation of the code into Ada would
not be a good illustration of the Ada language, and that an example
which performed the same calcuation, but added the additional useful
features would better serve. I have been sent an example written by a
member of your newsgroup which does this, introducing better
protection. I will also write a section in the text describing why a
direct translation is a bad idea, and demonstrate how the extra
features have made the code much more reliable.

Finally, I regret adding the section reading the calibration factor
from EEPROM!!! This is irrelevant to what I am trying to do with this
example anyway (which is to see how a simple algorithm is implemented
in different languages), and I will remove it. It is in the original C
code on the electricity meter of course.

Thanks again for all this discussion, it is vey useful for me.
regards,
paul

Re: Translating an embedded C algorithm

[Jeffrey Carter]

Talulah wrote:
> 
> Secondly, the
> product that this code came from is a domestic electricity meter for
> India, a market of 18 million devices per year. This is not a
> safety-critical product at all, but one which in those volumes must be
> designed for the lowest cost possible. Hence the use of 4 diodes as a
> temperature sensor, and hence (this may get more argument) the use of C
> rather than Ada.

Where the example came from should be irrelevant for a small example in 
a text. Apparently you have a monopoly, since your share of the market 
in your calculations is the total market.

Where we have hard data, they show that Ada reduces development costs by 
1/2 over C, reduces post-deployment errors by 1/4, and reduces the cost 
to fix an error by 1/10.

There is a least one documented case of Ada producing smaller code than 
hand-optimized assembler. Dewar has a number of examples of equivalent 
Ada and C code that produce identical object code.

Thus, the assumption that C is necessary to keep costs down is 
unsupported, a fact that anyone qualified to choose the language for 
such SW should know.

Finally, I did not assert that you are unqualified to write such a book. 
I said, "I have to wonder about the qualifications of someone who only 
knows C." I am perfectly willing to have it demonstrated that you are 
qualified.

Re: Translating an embedded C algorithm

[Talulah]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 2914 bytes --]


Jeffrey Carter wrote:

> Where the example came from should be irrelevant for a small example in
> a text.

It is irrelevant for the book, but not for the choice of language.

>Apparently you have a monopoly, since your share of the market
> in your calculations is the total market.

Our estimate is for 20% of this market. The same argument applies to
the resulting £100,000 profit as it would to a £500,000 profit. If we
did have a monopoly, price would not be an issue of course!

> Where we have hard data, they show that Ada reduces development costs by
> 1/2 over C, reduces post-deployment errors by 1/4, and reduces the cost
> to fix an error by 1/10.

I accept that may be the case. However, there are no Ada tools for very
many microcontrollers. The cost drives the choice of microcontroller,
and the microcontroller then drives the choice of development system.

> There is a least one documented case of Ada producing smaller code than
> hand-optimized assembler.

I love these statistics. There's a Java vendor who reckons the byte
code runs faster than C as well. You can prove anything if y0ou have
choice over the tools that you use to produce the results. This "hand
coded assembler" could mean anything - it could mean taking Ada
compiled code and ADDING instructions to it!

Thinking logically, if the assembler coder was any good, he can always
produce code of equal size to compiled code, and should always produce
tighter code. It just depends what he is trying to prove, and who has
sponsored him to do the work!

> Dewar has a number of examples of equivalent
> Ada and C code that produce identical object code.
> Thus, the assumption that C is necessary to keep costs down is
> unsupported, a fact that anyone qualified to choose the language for
> such SW should know.

When was the last time you wrote an Ada program to run on a
microcontroller such as a PIC or ATMega48, i.e. something around the
$0.50 price mark? And can you tell me a compiler vendor? C compilers
are available for both these devices. Therefore most embedded
developers (who are not in the military market and where cost is the
greatest issue) cannot choose the language they develop in.

> Finally, I did not assert that you are unqualified to write such a book.
> I said, "I have to wonder about the qualifications of someone who only
> knows C." I am perfectly willing to have it demonstrated that you are
> qualified.

Nit-picking. Fine distinctions. As I said before, most embedded
development IS doen in C, so that should be reflected in the book. The
fact that I want to show readers that other languages exist, and are
better for certain applications does not mean that I have to be an
expert in, or even know those other languages, especially when there
are so many very helpful posters to this thread that have made useful
suggestions.

Re: Translating an embedded C algorithm

[Jean-Pierre Rosen]

Talulah a �crit :
>> There is a least one documented case of Ada producing smaller code than
>> hand-optimized assembler.
> 
> I love these statistics. There's a Java vendor who reckons the byte
> code runs faster than C as well. You can prove anything if y0ou have
> choice over the tools that you use to produce the results. This "hand
> coded assembler" could mean anything - it could mean taking Ada
> compiled code and ADDING instructions to it!
This was not the case.
See http://www.acm.org/sigada/education/pages/lawlis.html for the full story

> Thinking logically, if the assembler coder was any good, he can always
> produce code of equal size to compiled code, and should always produce
> tighter code. 
The reference above has a good explanation why this is not the case.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Translating an embedded C algorithm

[Cesar Rabak]

Jean-Pierre Rosen escreveu:
> Talulah a �crit :
>>> There is a least one documented case of Ada producing smaller code than
>>> hand-optimized assembler.
>>
>> I love these statistics. There's a Java vendor who reckons the byte
>> code runs faster than C as well. You can prove anything if y0ou have
>> choice over the tools that you use to produce the results. This "hand
>> coded assembler" could mean anything - it could mean taking Ada
>> compiled code and ADDING instructions to it!
> This was not the case.
> See http://www.acm.org/sigada/education/pages/lawlis.html for the full 
> story
> 
>> Thinking logically, if the assembler coder was any good, he can always
>> produce code of equal size to compiled code, and should always produce
>> tighter code. 
> The reference above has a good explanation why this is not the case.
> 
This paper is the one it should never shown for people are not already 
knowledgeable of Ada:

1) It is old;

2) It hides labour under reporting the effort to write the Ada version: 
in section 5. "This 700 lines of Ada development had taken three weeks 
of labor, approximately 150 hours."

    It took also (section 2.) "...experts with various backgrounds in 
widely diverse organizations--the chip manufacturer, an Ada vendor, an 
independent consultant, a government laboratory, and the Air Force's 
graduate school, the Air Force Institute of Technology.", plus I 
understand the authors of the paper itself.

3) It puts away costs that are not insignificant (US$1000 in 1996 
dollars) *per system*;

4) A close reading of section 4. "The Proof Backfired" shows that for 
the Ada version arrive at the same performance of the assembly code, one 
engineer from the compiler vendor had to perform a series of non trivial 
experiments, write a hand crafted version of Ada code to unroll loops 
*after* analysis of the assembly code and binary. So, not Ada technology 
for itself, after of all.

Again, I remember: the report is old, and for present state of art chips 
with multiple datapaths, positively its more likely than a hand made 
assembly code will not match a HLL compiler generated binary.

So, I think that it is the case Talulah points out.

Re: Translating an embedded C algorithm

[Jeffrey Carter]

Talulah wrote:
> 
> I accept that may be the case. However, there are no Ada tools for very
> many microcontrollers. The cost drives the choice of microcontroller,
> and the microcontroller then drives the choice of development system.

There is Ada for every microcontroller with an ANSI C compiler. See

http://sofcheck.com/products/adamagic.html

> When was the last time you wrote an Ada program to run on a
> microcontroller such as a PIC or ATMega48, i.e. something around the
> $0.50 price mark? And can you tell me a compiler vendor? C compilers
> are available for both these devices. Therefore most embedded
> developers (who are not in the military market and where cost is the
> greatest issue) cannot choose the language they develop in.

Already answered.

> Nit-picking. Fine distinctions. As I said before, most embedded
> development IS doen in C, so that should be reflected in the book. The
> fact that I want to show readers that other languages exist, and are
> better for certain applications does not mean that I have to be an
> expert in, or even know those other languages, especially when there
> are so many very helpful posters to this thread that have made useful
> suggestions.

Fine distinctions are essential to SW engineering. As a SW engineer, I 
tend to carry them over to other areas, forgetting that most people are 
not SW engineers.

Re: Translating an embedded C algorithm

[Cesar Rabak]

Jeffrey Carter escreveu:
> Talulah wrote:
>>
>> I accept that may be the case. However, there are no Ada tools for very
>> many microcontrollers. The cost drives the choice of microcontroller,
>> and the microcontroller then drives the choice of development system.
> 
> There is Ada for every microcontroller with an ANSI C compiler. See
> 
> http://sofcheck.com/products/adamagic.html

This is not what the site says... the vendors of compilers for the MCUs 
must incorporate the product mentioned on their site.

> 
>> When was the last time you wrote an Ada program to run on a
>> microcontroller such as a PIC or ATMega48, i.e. something around the
>> $0.50 price mark? And can you tell me a compiler vendor? C compilers
>> are available for both these devices. Therefore most embedded
>> developers (who are not in the military market and where cost is the
>> greatest issue) cannot choose the language they develop in.
> 
> Already answered.

Could you post a more explicit site, please?

Re: Translating an embedded C algorithm

[Jeffrey Carter]

Cesar Rabak wrote:
> 
> This is not what the site says... the vendors of compilers for the MCUs 
> must incorporate the product mentioned on their site.

I'm not sure what you mean. The ANSI-C producing version is available as 
a stand-alone product.

Re: Translating an embedded C algorithm

[Cesar Rabak]

Jeffrey Carter escreveu:
> Cesar Rabak wrote:
>>
>> This is not what the site says... the vendors of compilers for the 
>> MCUs must incorporate the product mentioned on their site.
> 
> I'm not sure what you mean. The ANSI-C producing version is available as 
> a stand-alone product.
See Alexander's post elsethread for a more complete discussion.

Re: Translating an embedded C algorithm

[Jeffrey Carter]

Cesar Rabak wrote:
> Jeffrey Carter escreveu:
>>
>> I'm not sure what you mean. The ANSI-C producing version is available 
>> as a stand-alone product.
> See Alexander's post elsethread for a more complete discussion.

It appears to be FUD. The compiler exists. You can buy it. Several 
posters have, or know a person or organization that has.

Re: Translating an embedded C algorithm

[Alexander E. Kopilovich]

Jeffrey Carter wrote:
>There is Ada for every microcontroller with an ANSI C compiler. See
>
>http://sofcheck.com/products/adamagic.html

Did you try this compiler at least once? Or, if not, do you know personally
at least one person (outside SofCheck, a dozen of their big customers listed
on their website, and, perhaps, ARG members and other Ada compiler vendors)
who actually tried it?

The existence of this compiler seems somehow virtual. Most probably SofCheck
has something of that kind - because they said so, and because they certainly
have a technology and tools for that. But from the other hand, they do not say
what exactly they can offer, whether it is immediately ready for use, and how
much it costs (not even dreaming about downloadable evaluation version).

So probably Sofcheck is really able to provide that Ada-to-C compiler for a
determined customer, who is willing to pay enough for that. But this is not
the case for absolute majority of embedded software developers.

Re: Translating an embedded C algorithm

[Larry Kilgallen]

In article <mailman.30.1169173524.18371.comp.lang.ada@ada-france.org>, "Alexander E. Kopilovich" <aek@VB1162.spb.edu> writes:
> Jeffrey Carter wrote:
>>There is Ada for every microcontroller with an ANSI C compiler. See
>>
>>http://sofcheck.com/products/adamagic.html
> 
> Did you try this compiler at least once?

I have (although I am not Jeffrey Carter).

> The existence of this compiler seems somehow virtual. Most probably
> SofCheck has something of that kind - because they said so, and
> because they certainly have a technology and tools for that. But
> from the other hand, they do not say what exactly they can offer,
> whether it is immediately ready for use, and how much it costs
> (not even dreaming about downloadable evaluation version).

I found it was easy to deal with them as someone seriously interested.

> So probably Sofcheck is really able to provide that Ada-to-C compiler for a
> determined customer, who is willing to pay enough for that. But this is not
> the case for absolute majority of embedded software developers.

Because they are not determined, or because they want it free ?

Re: Translating an embedded C algorithm

[Alexander E. Kopilovich]

Larry Kilgallen wrote:
>> from the other hand, they do not say what exactly they can offer,
>> whether it is immediately ready for use, and how much it costs
>> (not even dreaming about downloadable evaluation version).
>
>I found it was easy to deal with them as someone seriously interested.

Well, I suppose so. The problem, though, is in being "seriously interested"
in advance.

>> So probably Sofcheck is really able to provide that Ada-to-C compiler for a
>> determined customer, who is willing to pay enough for that. But this is not
>> the case for absolute majority of embedded software developers.
>
>Because they are not determined, or because they want it free ?

Mostly because they are far from determined customers in this case.

Even if one developed some interest for a way through Ada (perhaps looking
at Ada as a kind of "super lint") there still will be significant obstacles
to overcome (mostly non-technical) and perspective gains are very uncertain
without any past experience of that kind.

The price is secondary in this case, I believe - it may repel some, but not
all... even not majority of perspective customers of that kind - because
various embedded development kits aren't too cheap anyway, and they are
routinely purchased and used.

Anyway, as there appeared at least 2 experienced users of that AdaMagic
Ada-to-C compiler, it may be an elegant (and even, perhaps, useful) completion
of this thread if someone takes from it hand-made C-to-Ada translation, feed
this Ada program to AdaMagic compiler, and then post the resulting C code
(produced by AdaMagic compiler) here.

Re: Translating an embedded C algorithm

[Larry Kilgallen]

In article <mailman.31.1169254197.18371.comp.lang.ada@ada-france.org>, "Alexander E. Kopilovich" <aek@VB1162.spb.edu> writes:
> Larry Kilgallen wrote:
>>> from the other hand, they do not say what exactly they can offer,
>>> whether it is immediately ready for use, and how much it costs
>>> (not even dreaming about downloadable evaluation version).
>>
>>I found it was easy to deal with them as someone seriously interested.
> 
> Well, I suppose so. The problem, though, is in being "seriously interested"
> in advance.
> 
>>> So probably Sofcheck is really able to provide that Ada-to-C compiler for a
>>> determined customer, who is willing to pay enough for that. But this is not
>>> the case for absolute majority of embedded software developers.
>>
>>Because they are not determined, or because they want it free ?
> 
> Mostly because they are far from determined customers in this case.

I don't believe the company sees their mission as convincing those who
are not already interested in Ada.  I believe they support the trade
organization (whose name escapes me), but they are not primarily a
marketing organization.

For a vendor who puts most of their resources into convincing customers
to see it their way, try Microsoft.

Re: Translating an embedded C algorithm

[Alexander E. Kopilovich]

Larry Kilgallen wrote:
>> Mostly because they are far from determined customers in this case.
>
>I don't believe the company sees their mission as convincing those who
>are not already interested in Ada.  I believe they support the trade
>organization (whose name escapes me), but they are not primarily a
>marketing organization.

Well, I believe that I understand why SofCheck does not want their AdaMagic
Ada-to-C compiler to be used too widely. I also can guess why AdaCore does not
provide similar facility in GNAT. I can see some reasons for Green Hills or
(IBM)Rational for not doing that.

What I do not understand is - why Aonix does not have it as a feature of their
ObjectAda compiler.

Re: Translating an embedded C algorithm

[Larry Kilgallen]

In article <mailman.32.1169312348.18371.comp.lang.ada@ada-france.org>, "Alexander E. Kopilovich" <aek@VB1162.spb.edu> writes:
> Larry Kilgallen wrote:
>>> Mostly because they are far from determined customers in this case.
>>
>>I don't believe the company sees their mission as convincing those who
>>are not already interested in Ada.  I believe they support the trade
>>organization (whose name escapes me), but they are not primarily a
>>marketing organization.
> 
> Well, I believe that I understand why SofCheck does not want their AdaMagic
> Ada-to-C compiler to be used too widely. I also can guess why AdaCore does not
> provide similar facility in GNAT. I can see some reasons for Green Hills or
> (IBM)Rational for not doing that.
> 
> What I do not understand is - why Aonix does not have it as a feature of their
> ObjectAda compiler.

I thought Aonix was a customer of SofCheck (or their predecessor),
and if so it might be that Aonix does not have the rights to use
AdaMagic in that fashion.

Re: Translating an embedded C algorithm

[Jeffrey Carter]

Larry Kilgallen wrote:
> 
> I don't believe the company sees their mission as convincing those who
> are not already interested in Ada.  I believe they support the trade
> organization (whose name escapes me), but they are not primarily a
> marketing organization.

The Ada Resource Association (ARA).

Re: Translating an embedded C algorithm

[Markus E Leypold]

Hi Larry,

Kilgallen@SpamCop.net (Larry Kilgallen) writes:
>
>> So probably Sofcheck is really able to provide that Ada-to-C compiler for a
>> determined customer, who is willing to pay enough for that. But this is not
>> the case for absolute majority of embedded software developers.
>
> Because they are not determined, or because they want it free ?

The spectre of free software raises its ugly head ...

I'd expect that there is some middle ground between wanting everything
for free and paying any every price.

What some people in this thread might not have considered, is that
something like the following situation: A company intends to build a
prototype embedded system (for control of something or whatever). They
do not know wether the new product will ever fly/sell and they have a
small market (some hundred units, not more) for the next years.

Now -- usually they get the C development system and the evaluation
board rather cheap. On the other site adding the SofCheck compiler
might (a) result in a couple of man weeks of work, retraining of
staff, and of course (b) the additional price/licensing for the
compiler.

Even worse -- if you contract partner requires to guarantee delivery
and fixing of further units for the next ten years (never many, I know
of contracts that require 150 units now with the option to further 400
units during the next ten years), you'll have to pay maintenance or
licensing for ten years (not just for the year when you do most of the
board development.

So, in case of a small unit number and small system the additional per
unit costs might not be negligible. You're just not competitive this
way against a competitor doing it in C only even if they spent a
substantial amount of time going through their C code with a fine comb
to ensure quality.


So yes: Ada is available via the SofCheck compilers or others for more
target than most people think. Still the entry costs into the first
Ada project might be prohibitive. 

And not the paradox: Large companies which already have C/C++ coding
styles are not likely to start a new development line with Ada or
retrain staff. Small companies that could (because there is no real
policy yet) cannot afford Ada because they can't distribute the cost
of many projects yet. 

So what did I want to say? -- There is more to a language decision
than being "not determined" or being a cheapskate ("want it
free"). There are simple economic reasons sometimes why people decide
against Ada (or never really start to consider it seriously). They
might be mistaken in their reasons (might underestimate the
difficulties to keep quality with C or how much Ada might help them
with keeping quality or designing) but nonetheless -- what I really
want to emphasize that those people usually make a rational decision
based on some kind of evaluation, not the kind of decisions on a gut
level you and some of the posters in this thread seem to imply.

Another aspect: A lot of people here seem to assume that quality comes
with the choice of the right language. Nothing could be further from
the truth. I remember a study (IBM I think) in which the effectiveness
of various QA measures and combinations was evaluated. If I remember
right, code review was an essential ingredient ever getting a high
quality: No project achieved high quality without code review. So
perhaps C with a good reviewing process might still be better than Ada
without review.

Regards -- Markus

Re: Translating an embedded C algorithm

[Larry Kilgallen]

In article <nfbqkmzs22.fsf@hod.lan.m-e-leypold.de>, Markus E Leypold writes:
> 
> Hi Larry,
> 
> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
>>
>>> So probably Sofcheck is really able to provide that Ada-to-C compiler for a
>>> determined customer, who is willing to pay enough for that. But this is not
>>> the case for absolute majority of embedded software developers.
>>
>> Because they are not determined, or because they want it free ?
> 
> The spectre of free software raises its ugly head ...
> 
> I'd expect that there is some middle ground between wanting everything
> for free and paying any every price.

I don't know what is meant by "any every" price, but the Sofcheck
pricing seemed fair to me.

> So yes: Ada is available via the SofCheck compilers or others for more
> target than most people think. Still the entry costs into the first
> Ada project might be prohibitive. 

Certainly there are some projects that are undercapitalized.  And they
are the rightful prey of lowest-common-denominator languages.

Re: Translating an embedded C algorithm

[Markus E Leypold]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> In article <nfbqkmzs22.fsf@hod.lan.m-e-leypold.de>, Markus E Leypold writes:
>> 
>> Hi Larry,
>> 
>> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
>>>
>>>> So probably Sofcheck is really able to provide that Ada-to-C compiler for a
>>>> determined customer, who is willing to pay enough for that. But this is not
>>>> the case for absolute majority of embedded software developers.
>>>
>>> Because they are not determined, or because they want it free ?
>> 
>> The spectre of free software raises its ugly head ...
>> 
>> I'd expect that there is some middle ground between wanting everything
>> for free and paying any every price.
>
> I don't know what is meant by "any every" price, but the Sofcheck
> pricing seemed fair to me.

It is meant to be a typo. "Any price", I think, expresses what I mean.

>
>> So yes: Ada is available via the SofCheck compilers or others for more
>> target than most people think. Still the entry costs into the first
>> Ada project might be prohibitive. 

> Certainly there are some projects that are undercapitalized.  And they
> are the rightful prey of lowest-common-denominator languages.

Since you say "some", and we know that Ada is not as widely used as
most people here would wish, we are now faced with 2 choices:

 - The majority of projects "are undercapitalized" and "the rightful
   prey of lowest-common-denominator languages".

 - The majority of people making decisions in software development
   projects are simple morons and their decision has nothing to do
   with economical considerations.


Which will it be?

Regards -- Markus

Re: Translating an embedded C algorithm

[Cesar Rabak]

Markus E Leypold escreveu:
> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
[snipped]

> 
> Since you say "some", and we know that Ada is not as widely used as
> most people here would wish, we are now faced with 2 choices:
> 
>  - The majority of projects "are undercapitalized" and "the rightful
>    prey of lowest-common-denominator languages".
> 
>  - The majority of people making decisions in software development
>    projects are simple morons and their decision has nothing to do
>    with economical considerations.
> 
> 
> Which will it be?
> 
A linear combination of both.

Re: Translating an embedded C algorithm

[Jeffrey Carter]

Alexander E. Kopilovich wrote:
> 
> Did you try this compiler at least once? Or, if not, do you know personally
> at least one person (outside SofCheck, a dozen of their big customers listed
> on their website, and, perhaps, ARG members and other Ada compiler vendors)
> who actually tried it?

I've seen the compiler in use at Praxis, precisely to allow 
high-integrity SW in SPARK to target a microprocessor without a 
dedicated Ada compiler. It worked much like any other compiler.

Re: Translating an embedded C algorithm

[Warner BRUNS]

Alexander E. Kopilovich wrote:
> Jeffrey Carter wrote:
>> There is Ada for every microcontroller with an ANSI C compiler. See
>>
>> http://sofcheck.com/products/adamagic.html
> 
> Did you try this compiler at least once? Or, if not, do you know personally
> at least one person (outside SofCheck, a dozen of their big customers listed
> on their website, and, perhaps, ARG members and other Ada compiler vendors)
> who actually tried it?
> 
> The existence of this compiler seems somehow virtual. Most probably SofCheck
> has something of that kind - because they said so, and because they certainly
> have a technology and tools for that. But from the other hand, they do not say
> what exactly they can offer, whether it is immediately ready for use, and how
> much it costs (not even dreaming about downloadable evaluation version).
> 
> So probably Sofcheck is really able to provide that Ada-to-C compiler for a
> determined customer, who is willing to pay enough for that. But this is not
> the case for absolute majority of embedded software developers.
> 
> 
> 
  I have purchased the AdaMagic Ada to C translator from SofCheck, after trying it
  out for some weeks. I am using it since several years as my main Ada compiler.
  I did not get it via a download but I did send an email, stating my requirements,
  and they could be met.

  Warner Bruns

Re: Translating an embedded C algorithm

[Robert A Duff]

"Alexander E. Kopilovich" <aek@VB1162.spb.edu> writes:

> So probably Sofcheck is really able to provide that Ada-to-C compiler for a
> determined customer, who is willing to pay enough for that. But this is not
> the case for absolute majority of embedded software developers.

I suggest you ask SofCheck.

- Bob

Re: Translating an embedded C algorithm

[Steve]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5631 bytes --]

"Talulah" <paul.hills@uk.landisgyr.com> wrote in message 
news:1168871816.263502.212100@11g2000cwr.googlegroups.com...
> Hi,
>
> I am in the process of writing a book about real-time embedded
> development (hardware and software). In it there is a section on
> different programming languages that are available for embedded
> development. I'm using a small C function that does temperature
> measurement by linear interpolation of a lookup table as an example. I
> have C code to do this, and would like to have the same algorithm
> implemented in other languages.
>
> Unfortunately I'm really a C programmer, with very little experience
> of other languages, so I would like to ask if anyone on this newsgroup
> is interested in translating the algorithm into Ada. Of course you
> would be mentioned in thanks in the book once it is finished.
>

Here is a bit more Ada-ish version:

with Interfaces;
package Temperature_Evaluation is

    type Kelvin_Tenths is new Interfaces.Integer_16;

    type Adc_Reading is range 0 .. 2**10-1;

  ------------------------------------------------------------------------
  -- MeasureTemperature
  --
  -- Calculates the temperature in �C given the ADC count by lookup
  -- table and linear interpolation of the diode circuit characteristic.
  --
  -- Parameters:
  -- AdcCount Raw ADC count.
  --
  -- Returns:
  -- Temperature in �C x 10. INVALID_TEMPERATURE if out of range.
  ------------------------------------------------------------------------
    function MeasureTemperature( AdcCount : Adc_Reading ) return 
Kelvin_Tenths;

end Temperature_Evaluation;

with Interfaces;

package body Temperature_Evaluation is

    ----------------------------------------------------------------------
    -- The Temperature_Lookup table is used to map ADC counts to a
    -- temperature in kelvins.
    -- Consecutive values in the table represent an increase of 8 ADC
    -- counts.
    -- The ADC value of the first entry in the table is given by:
    -- Base_Adc_Value;
    ----------------------------------------------------------------------
    Interp_Interval    : constant := 8;
    Base_Adc_Value     : constant := 220;
    Temperature_Lookup : constant array( Positive range <>) of Kelvin_Tenths 
:=
    (
        1171, 1116, 1061, 1006,  952,  899,  846, 793,
         741,  689,  638,  588,  537,  488,  438, 389,
         341,  293,  246,  199,  152,  106,   61,  16,
         -29,  -73, -116, -160, -202, -244, -286, -327
    );

------------------------------------------------------------------------
-- MeasureTemperature
--
-- Calculates the temperature in �C given the ADC count by lookup
-- table and linear interpolation of the diode circuit characteristic.
--
-- Parameters:
-- AdcCount Raw ADC count.
--
-- Returns:
-- Temperature in �C x 10. INVALID_TEMPERATURE if out of range.
------------------------------------------------------------------------
function MeasureTemperature( AdcCount : Adc_Reading ) return Kelvin_Tenths 
is

    Table_Index     : Integer;
    Table_Remainder : Integer;
    Temperature     : Kelvin_Tenths;
    Temp_Diff       : Integer;

begin
    --------------------------------------------------------------------
    -- Evaluate the index into Temperature_Lookup as well as remaining
    -- Adc counts that are not covered by the lookup.
    --------------------------------------------------------------------
    Table_Index     :=   Temperature_Lookup'First
                       + (Integer(AdcCount) - Base_Adc_Value) / 
Interp_Interval;

    Table_Remainder := (Integer(AdcCount) - Base_Adc_Value) rem 
Interp_Interval;

    --------------------------------------------------------------------
    -- Check the index against the bounds of the lookup table
    --------------------------------------------------------------------

    if Table_Index < Temperature_Lookup'First then
        ----------------------------------------------------------------
        -- For an index before the first index of the table, use
        -- the first index.
        ----------------------------------------------------------------
        Table_Index := Temperature_Lookup'First;
    elsif Table_Index >= Temperature_Lookup'Last then
        ----------------------------------------------------------------
        -- For an index that at or beyond the last index of the table,
        -- use the last index.
        ----------------------------------------------------------------
        Table_Index := Temperature_Lookup'Last;
    end if;

    --------------------------------------------------------------------
    -- Evaluate the base temperature value
    --------------------------------------------------------------------
    Temperature := Temperature_Lookup( Table_Index );

    if Table_Remainder /= 0 then
        Temp_Diff   := Integer(Temperature_Lookup( Table_Index + 1 ) - 
Temperature_Lookup( Table_Index ));
        Temperature :=   Temperature
                       + Kelvin_Tenths( ( Temp_Diff * Table_Remainder ) / 
Interp_Interval);
    end if;

    return Temperature + ReadEeprom(TEMPERATURE_CAL_VALUE);
end MeasureTemperature;

end Temperature_Evaluation;

I took the liberty of making minor changes in the logic which I believe 
simplifies things a bit.

Regards,
Steve
(The Duck)

> If you are interested, I have placed the section of the book here:
>
> http://homepages.which.net/~paul.hills/Temporary/Temperature.pdf
>
> so you can see the code and description. Please email me if you are
> interested to paul (dot) hills (who is at) uk (dot) landisgyr (dot)
> com.
>
> Thanks very much
> Paul Hills
> 

Re: Translating an embedded C algorithm

[Simon Wright]

"Steve" <nospam_steved94@comcast.net> writes:

>   ------------------------------------------------------------------------
>   -- MeasureTemperature
>   --
>   -- Calculates the temperature in �C given the ADC count by lookup
>   -- table and linear interpolation of the diode circuit characteristic.
>   --
>   -- Parameters:
>   -- AdcCount Raw ADC count.
>   --
>   -- Returns:
>   -- Temperature in �C x 10. INVALID_TEMPERATURE if out of range.
>   ------------------------------------------------------------------------
>     function MeasureTemperature( AdcCount : Adc_Reading ) return Kelvin_Tenths;

If the comment says 'degrees C' the type returned should NOT be in
Kelvin!!!

And it seems extraordinarily contrary to the Ada view of life to
return an integral value in tenths of a degree (never mind where the
zero is). This should be a real number (I don't see any virtue in
making the application deal in fixed-point, float might even be faster
on modern hardware. OK, probably not on an 8-bit microcontroller!)

And there's an inconsistency of style: AdcCount vs Adc_Reading.

And shouldn't that be ADC_Reading?

And what's with this weird non-LRM parenthesis style?

--S