longest path through a task

longest path through a task

[jan.de.kruyf]

Good day,

I was trying to find a semi-automatic way to find the longest runtime path through a task (on an ARM cpu) programmed in ada.
Does the gnat compiler offer such a thing perhaps?

At the moment I still rely on 'suck it and see' which is still quite accurate since it is small. But that is not going to carry the can in the end.

Thanks

j.

Re: longest path through a task

[Niklas Holsti]

On 15-05-27 22:38 , jan.de.kruyf@gmail.com wrote:
> Good day,
>
> I was trying to find a semi-automatic way to find the longest runtime
> path through a task (on an ARM cpu) programmed in ada. Does the gnat
> compiler offer such a thing perhaps?

There are tools calls "WCET analyzers" that compute, or try to compute, 
an upper bound on the execution time of a program, or a subprogram. 
There are two main groups: static analyzers, exemplified by aiT 
(www.absint.com) or Bound-T (www.bound-t.com), and hybrid ones that 
combine measurement with control-flow analysis, exemplified by RapiTime 
(www.rapitasystems.com).

What kind of ARM are you using? A classic ARM7, or a Cortex? "M" series?

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

Re: longest path through a task

[jan.de.kruyf]

On Wednesday, May 27, 2015 at 10:09:22 PM UTC+2, Niklas Holsti wrote:


> 
> What kind of ARM are you using? A classic ARM7, or a Cortex? "M" series?

Thank you Niklas.
CortexM4 since Ada has a cross environment for it. I dont think it will get serious. I dumped the multithread stuff and made a single-thread / multitask runtime (slow in Ada unfortunately, but not as slow as multi-threading and interrupts. The Ravenscar runtime tries to be everything for everybody). But in any case it means that I have to watch my deadlines one way or another.

I did a bit of internet trawling last night to find out what they did for the Xoberon environment I posted about in the language shootout. They restricted the language further, and added a bound on number of loop executions. The bound  you would then give a value in the program.  And then a static calculation via the compiler with dynamic runtime adaption of the value, since it was still way out at times. But that is on a powerpc604, which is not a microcontroller but an office machine animal so there are more variables that cause execution-time variation.

In any case, let me get on with building bridges to Linux Kernel C. 
I learn a lot about tribalism in the IT industry at the moment.

p.s. Ah I see it is your bread and butter, very interesting :)

Peace to you and yours.

j.

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

Re: longest path through a task

[Niklas Holsti]

On 15-05-28 09:54 , jan.de.kruyf@gmail.com wrote:
> On Wednesday, May 27, 2015 at 10:09:22 PM UTC+2, Niklas Holsti
> wrote:
>> What kind of ARM are you using? A classic ARM7, or a Cortex? "M"
>> series?
>
> Thank you Niklas. CortexM4 since Ada has a cross environment for it.
> I dont think it will get serious. I dumped the multithread stuff and
> made a single-thread / multitask runtime (slow in Ada unfortunately,
> but not as slow as multi-threading and interrupts.

Did you get some numbers for the task-switch and interrupt-latency times 
with the Ravenscar kernel? What does "slow" mean, in numbers?

> I did a bit of internet trawling last night to find out what they did
> for the Xoberon environment I posted about in the language shootout.
> They restricted the language further, and added a bound on number of
> loop executions. The bound  you would then give a value in the
> program.
   ...
> p.s. Ah I see it is your bread and butter, very interesting :)

Well, I tried to make it my bread and butter, but failed. So I'm back 
working for my former employer and doing real applications, not tools.

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

Re: longest path through a task

[brbarkstrom]

There are well-known algorithms for computing schedules.  I'd recommend
Sedgewick, R. and Wayne, K., 2011: Algorithms, Fourth Edition, Addison-
Wesley, Upper Saddle River, NJ.  What you want should emerge from a Critical
Path Method (or PERT) algorithm as the time on the critical path, which 
is the longest time through the job network.  The classic, single core 
(non-threaded) algorithm is covered on pp. 574-584.  The "parallel precedence-
constrained scheduling" algorithm starts on p. 663.  The algorithms in this 
book use Java, but they should be fairly easy to translate to Ada.  This book's
algorithms are noted for being concise - and even elegant.  This approach
is probably not quite as easy as trying to find a package that already 
contains what you're looking for (you hope).  However, when you get done,
you'll understand the pieces better and know where the weaknesses are.

Bruce B.

Re: longest path through a task

[jan.de.kruyf]

On Thursday, May 28, 2015 at 11:04:05 AM UTC+2, Niklas Holsti wrote:

> 
> Did you get some numbers for the task-switch and interrupt-latency times 
> with the Ravenscar kernel? What does "slow" mean, in numbers?
> 
looking through the interrupt code, I thought I saw a maximum of up to a few usecs response time. so I just eliminated that uncertainty by polling the most important time source. The rest I have not really decided about, but with the multi-tasking framework gone, an interrupt vector can point straight to my code again. without ifs and buts in between.
Otherwise: I did not measure the scheduler overhead, but since 1 millisec is a 'happy medium' for the writer of that code, and since 1 msec cycletime is too slow for me I just decided to make life simple.
I constructed a job stack that is executed whenever I ask for it, with jobs coming and going al the time. With a time measuring frame around it that I can query at any time via the rs232 port. This will give me the min and the max execution time encountered since the last reset of those registers. 
So Heisenberg's uncertainty principle applies in that the reading influences the max value.

This looks al much hairier than it is, at least in cyclic execution like a plc.
And once you have the pattern into your head it is rather easy to keep track of things and not construct infinite tight execution loops.
You will have to get into a new frame of mind of course ;) 

> 
> Well, I tried to make it my bread and butter, but failed. So I'm back 
> working for my former employer and doing real applications, not tools.

That is sad. But if you did not shoot, you would have missed also. And I am sure your employer loves you all the more for the experience you brought back.

Does Bound-T eat Thumb-2 code you think? I would love to try it out. And since I do have the measuring frame work in place for comparison.. .

Keep well,

j.

Re: longest path through a task

[jan.de.kruyf]

On Thursday, May 28, 2015 at 2:27:18 PM UTC+2, brbar...@gmail.com wrote:
> There are well-known algorithms for computing schedules.  I'd recommend
> Sedgewick, R. and Wayne, K., 2011: Algorithms, Fourth Edition, Addison-
> Wesley, Upper Saddle River, NJ.  What you want should emerge from a Critical

Shucks, caught sleeping at the wheel again! Yes of course thank you Bruce. 
It will probably work much better, together with the execution time measuring device I concocted, then any package. 

By the way for whoever comes after me:

ftp://91.193.236.10/pub/docs/linux-support/computer%20science/data%20Structures%20&%20algorithms/%5BPearson%5D%20-%20Algorithms,%204th%20ed.%20-%20%5BSedgewick,%20Wayne%5D.pdf

I was very grateful for it, since to get books here in SA is a major undertaking! The national airline does not transport post anymore for the national post-office because they forgot to pay!. 

cheers,

j.

Re: longest path through a task

[Simon Wright]

jan.de.kruyf@gmail.com writes:

> I dumped the multithread stuff and made a single-thread / multitask
> runtime (slow in Ada unfortunately, but not as slow as multi-threading
> and interrupts. The Ravenscar runtime tries to be everything for
> everybody).

Just did some measurements (clumsily) using the Cortex-M4 counter as in
[1], and from entering the Ada handler to the triggered task starting to
execute averaged at 1200 cycles (6.7 us) with -Og, 1070 cycles (5.9 us)
with -O2. There is some code in the C handler to redirect to the Ada
handler: see [2], starting at line 236.

I wrote the C handling using weak symbols, so there's no reason (that I
can see) why an interrupt that needed better performance shouldn't hook
in directly, avoiding the Ada RTS; not so obvious how it would then
communicate with the rest of the code.

[1] http://stackoverflow.com/a/19124472
[2]
https://sourceforge.net/p/stm32f4-gnat-rts/code/ci/default/tree/stm32f429i-disco-rtos/src/stm32f4xx_it.c

Re: longest path through a task

[jan.de.kruyf]

On Thursday, May 28, 2015 at 6:37:28 PM UTC+2, Simon Wright wrote:

> 
> > I dumped the multithread stuff and made a single-thread / multitask
> > runtime (slow in Ada unfortunately, but not as slow as multi-threading
> > and interrupts. The Ravenscar runtime tries to be everything for
> > everybody).
> 
> Just did some measurements (clumsily) using the Cortex-M4 counter as in
> [1], and from entering the Ada handler to the triggered task starting to
> execute averaged at 1200 cycles (6.7 us) with -Og, 1070 cycles (5.9 us)
> with -O2. There is some code in the C handler to redirect to the Ada
> handler: see [2], starting at line 236.
> 
> I wrote the C handling using weak symbols, so there's no reason (that I
> can see) why an interrupt that needed better performance shouldn't hook
> in directly, avoiding the Ada RTS; not so obvious how it would then
> communicate with the rest of the code.
> 
> [1] http://stackoverflow.com/a/19124472
> [2]
> https://sourceforge.net/p/stm32f4-gnat-rts/code/ci/default/tree/stm32f429i-disco-rtos/src/stm32f4xx_it.c

I lost you a bit here Simon, your thinking is way ahead of your fingers :) I guess. or I am not familiar with your terminology. (more than likely) 
Is this interrupt latency? or software interrupt latency? 
Are you running multi threaded? are you triggering a task in this thread to run in that thread? 
Is this including your C runtime?
Sorry to be so inquisitive, but I like to understand even though I have a pea brain.

In the mean time I am having fun digesting Bruce's books' algorithms and trying to see how to apply them. I will have to go back to the Corti thesis I think, but it will not be as easy as what he did, since he could hack the compiler with relative ease (a one floppy compiler). I will probably end up entering code twice, in some reduced form to extract the longest path.

Thanks for your guys help.

j.

Re: longest path through a task

[Simon Wright]

jan.de.kruyf@gmail.com writes:

> On Thursday, May 28, 2015 at 6:37:28 PM UTC+2, Simon Wright wrote:
>
>> 
>> > I dumped the multithread stuff and made a single-thread / multitask
>> > runtime (slow in Ada unfortunately, but not as slow as multi-threading
>> > and interrupts. The Ravenscar runtime tries to be everything for
>> > everybody).
>> 
>> Just did some measurements (clumsily) using the Cortex-M4 counter as in
>> [1], and from entering the Ada handler to the triggered task starting to
>> execute averaged at 1200 cycles (6.7 us) with -Og, 1070 cycles (5.9 us)
>> with -O2. There is some code in the C handler to redirect to the Ada
>> handler: see [2], starting at line 236.
>> 
>> I wrote the C handling using weak symbols, so there's no reason (that I
>> can see) why an interrupt that needed better performance shouldn't hook
>> in directly, avoiding the Ada RTS; not so obvious how it would then
>> communicate with the rest of the code.
>> 
>> [1] http://stackoverflow.com/a/19124472
>> [2]
>> https://sourceforge.net/p/stm32f4-gnat-rts/code/ci/default/tree/stm32f429i-disco-rtos/src/stm32f4xx_it.c
>
> I lost you a bit here Simon, your thinking is way ahead of your
> fingers :) I guess. or I am not familiar with your terminology. (more
> than likely)

I have been accused of terseness, sorry

> Is this interrupt latency? or software interrupt latency? 
> Are you running multi threaded? are you triggering a task in this
> thread to run in that thread?
> Is this including your C runtime?

This is a Ravenscar runtime; the C interrupt handler has to invoke the
Ada handler, which was registered by the Ada runtime when it saw a PO
like

   protected Button
   with
     Interrupt_Priority => System.Interrupt_Priority'First
   is
      entry Wait_For_Trigger;
   private
      Triggered : Boolean := False;
      procedure Handler;
      pragma Attach_Handler (Handler, Ada.Interrupts.Names.EXTI0_IRQ);
   end Button;

and I started timing in Button.Handler.

The corresponding task called Button.Wait_For_Trigger and I ended timing
immediately on return.

Re: longest path through a task

[jan.de.kruyf]

On Thursday, May 28, 2015 at 7:52:55 PM UTC+2, Simon Wright wrote:

> 
> I have been accused of terseness, sorry

It is an occupational disease, ask my wife.


> This is a Ravenscar runtime; the C interrupt handler has to invoke the
> Ada handler, which was registered by the Ada runtime when it saw a PO
> like
> 
>    protected Button
>    with
>      Interrupt_Priority => System.Interrupt_Priority'First
>    is
>       entry Wait_For_Trigger;
>    private
>       Triggered : Boolean := False;
>       procedure Handler;
>       pragma Attach_Handler (Handler, Ada.Interrupts.Names.EXTI0_IRQ);
>    end Button;
> 
> and I started timing in Button.Handler.
> 
> The corresponding task called Button.Wait_For_Trigger and I ended timing
> immediately on return.

Thanks, I think I remember coming to 5 usecs from glancing through the code, so it is even worse than that.

According to the gnat ravenscar profile they need that extra code layer to do things with locks and threads, but I could not tell you what anymore. I just cut my losses as explained above.

Here is the link to Matteo's page with the research papers on the subject.

http://inf.ethz.ch/personal/corti/

cheers,

j.

Re: longest path through a task

[Niklas Holsti]

On 15-05-28 16:04 , jan.de.kruyf@gmail.com wrote:

> That is sad. But if you did not shoot, you would have missed also.

Yeah, but perhaps I could have taken better aim... I did have a couple 
of moments of euphoria, feeling the freedom of the entrepreneur :-)

> Does Bound-T eat Thumb-2 code you think?

I was working on that at the time when it became clear that Bound-T 
would not make it as a commercial product. I still have hopes of 
finishing a Bound-T version for the Cortex M-series, but my employer 
loves me so much that I have no time...

The main problem is that the way Bound-T analyses the computation and 
data flow in the code is (intentionally) unsound (in the program-proving 
sense). For example, pointers are mainly ignored, and there is no global 
value analysis (which would be required for most pointer analysis). This 
was not so harmful at the start (some 15 years ago, gosh) when the 
analysis results were not used for much (mainly to find iteration bounds 
on simple loops) but by and by the use of the analysis results expanded 
(sometimes by technical necessity) to include, for example, detection of 
infeasible execution paths -- and if that is based on an unsound 
analysis, it is very likely that an analysis of a large program will 
trigger some false conclusions, and the end results of the analysis will 
be wrong.

So Bound-T unfortunaly needs a fresh start with respect to the model of 
the computation. I have been thinking about that for a good while, but I 
haven't found anything good yet. The simple and sound methods are so 
much weaker than the current model that is based on a Presburger 
Arithmetic and the Omega library.

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

Re: longest path through a task

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> Just did some measurements (clumsily) using the Cortex-M4 counter as
> in [1], and from entering the Ada handler to the triggered task
> starting to execute averaged at 1200 cycles (6.7 us) with -Og, 1070
> cycles (5.9 us) with -O2. There is some code in the C handler to
> redirect to the Ada handler: see [2], starting at line 236.

The code in the C handler takes 150 cycles.

So, for my FreeRTOS-based RTS, interrupt to Ada handler is 150 cycles,
Ada handler to task is 1200 cycles, grand total 1350 cycles or 7.5
microseconds (core clock 180 MHz).

I understand that a 1-millisecond tick is inadequate for some control
applications (though the Crazyflie seems to do OK with FreeRTOS); maybe
one could use one of the other timers on the STM32F4 to act as the basis
for the hard control loop, while retaining the Ada tasking for less
demanding aspects?

Re: longest path through a task

[jan.de.kruyf]

On Friday, May 29, 2015 at 6:31:27 PM UTC+2, Simon Wright wrote:

> 
> > Just did some measurements (clumsily) using the Cortex-M4 counter as
> > in [1], and from entering the Ada handler to the triggered task
> > starting to execute averaged at 1200 cycles (6.7 us) with -Og, 1070
> > cycles (5.9 us) with -O2. There is some code in the C handler to
> > redirect to the Ada handler: see [2], starting at line 236.
> 
> The code in the C handler takes 150 cycles.
> 
> So, for my FreeRTOS-based RTS, interrupt to Ada handler is 150 cycles,
> Ada handler to task is 1200 cycles, grand total 1350 cycles or 7.5
> microseconds (core clock 180 MHz).
> 
> I understand that a 1-millisecond tick is inadequate for some control
> applications (though the Crazyflie seems to do OK with FreeRTOS); maybe
> one could use one of the other timers on the STM32F4 to act as the basis
> for the hard control loop, while retaining the Ada tasking for less
> demanding aspects?

Yes a person can, You can also modify the runtime.

it is in bbbosu.adb:

   -----------------------
   -- Sys_Tick Handling --
   -----------------------

   --  We use the Sys_Tick timer as a periodic timer with 1 kHz rate. This
   --  is a trade-off between accurate delays, limited overhead and maximum
   --  time that interrupts may be disabled.

   Tick_Period   : constant Timer_Interval := Clock_Frequency / 1000;

-----------------

But from too much looking at that code I got squint eyes ;)

In any case based on that comment and my experience I thought I will construct a single thread multitask environment, which is easy. The programming for a novice will be a bit more complex especially when you have hard deadlines.
It is basically just a choice.

I did find a write-up from Brega on the Xoberon runtime, I am still looking for the code. In any case they did have multi-threading but mixed it with hard task dead times, and some more tricks, quite a feat.

Now back to my kernel module, I am making good progress, but it is hairy, at least if you want to have any runtime at all. And I cant use gnat for linking either. So I do every step by hand. 
cheers,

j.

Windows Text_IO.Get_Line issue

[tornenvi]

Hello,

   I have found some unexpected behavior for calls to Ada.Text_IO.Get_Line
   on windows when reading from a text that has only one line in it.

   The program below simply reads the first line of a text file into a 6
   character buffer, and outputs the length of the line read, the line and
   the line again as hex.

   I use windows notepad to create the test file Test.txt.

   When using Test.txt with the one line of text
    ABCD
   with no blank line at the end of the file I get output 1 below

-- Output 1 ------------------------------------------------------
Length=  4
Line=[ABCDXX]
Line as hex=[414243445858]
------------------------------------------------------------------

   as expected. However if Test.txt is the one line of text
    ABCDE
   with no blank line at the end of the file then I get output 2 below

-- Output 2 -----------------------------------------------------
Length=  6
Line=[ABCDE ]
Line as hex=[4142434445ff]
-----------------------------------------------------------------

   I receive an unexpected length of 6, expected 5. The fact that the last two
   characters are not 'XX' is acceptable since ARM A.10.7 19 says
   "The values of characters not assigned are not specified."

   I get the same output 2 if I compile the program with
   GNAT GPL 2014, 2013,2012 or 2011 or with mingw FSF GNAT 4.7.0-1 or 4.8.1-4.

   However if I compile with mingw FSF GNAT 4.5.2-1 , 4.5.0-1, 4.4.0 or
   3.4.5 then I get the expected output 3 below

-- Output 3 -----------------------------------------------------
Length=  5
Line=[ABCDEX]
Line as hex=[414243444558]
-----------------------------------------------------------------

   Under windows the one line text file does not have an end of line
   character (usually CRLF) which means it is not a canonical text file
   as described here

   http://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/the_implementation_of_standard_i_o.html#text-io

   however that section also states that text_io can be use to read non canonical text files
   and the very last line of that section says
   "Every LF character is considered to end a line, and there is an
     implied LF character at the end of the file."

   this indicates to me that there should be an implied LF at the end of the
   file and I should be getting the expected output 3 result for
   all the compilers.

   Is this a bug in the windows builds of GNAT?





---- Program -----------------------------------------------------
with Ada.Text_IO;

procedure FileRead is


   TestFileName : constant string := "Test.txt";
   TestFile : Ada.Text_IO.File_Type;

   Line   : string(1..6) := "XXXXXX";
   Length : natural;

   function ToHex(Msg : string) return string is
     Hex   : constant array (0..15) of character := "0123456789abcdef";
     Str   : String(1..Msg'length*2) := (others => ' '); -- 2 hex digits per byte
     Index : Integer :=1;
     ByteValue : Integer;
   begin
     for i in Msg'Range loop
       ByteValue := character'Pos(Msg(i));
       Str(Index) := Hex(ByteValue / 16);
       Index := Index + 1;
       Str(Index) := Hex(ByteValue mod 16);
       Index := Index + 1;
     end loop;
     return Str;
   end;

begin

   Ada.Text_IO.Open( TestFile, Ada.Text_IO.IN_FILE, TestFileName );
   if not Ada.Text_IO.End_Of_File(TestFile) then
     Ada.Text_IO.Get_Line( TestFile, Line, Length );
     Ada.Text_IO.Put_Line("Length= " & integer'image(Length));
     Ada.Text_IO.Put_Line("Line=[" & Line & "]");
     Ada.Text_IO.Put_Line("Line as hex=[" & ToHex(Line) & "]");
   end if;

exception

   when E: others =>
     Ada.Text_IO.Put_Line("Exception");

end;
-------------------------------------------------------------

Re: Windows Text_IO.Get_Line issue

[tornenvi]

Sorry posted in wrong spot.
Will repost

On 6/1/2015 1:57 PM, tornenvi wrote:
> Hello,
>
>    I have found some unexpected behavior for calls to Ada.Text_IO.Get_Line
>    on windows when reading from a text that has only one line in it.
>
>    The program below simply reads the first line of a text file into a 6
>    character buffer, and outputs the length of the line read, the line and
>    the line again as hex.
>
>    I use windows notepad to create the test file Test.txt.
>
>    When using Test.txt with the one line of text
>     ABCD
>    with no blank line at the end of the file I get output 1 below
>
> -- Output 1 ------------------------------------------------------
> Length=  4
> Line=[ABCDXX]
> Line as hex=[414243445858]
> ------------------------------------------------------------------
>
>    as expected. However if Test.txt is the one line of text
>     ABCDE
>    with no blank line at the end of the file then I get output 2 below
>
> -- Output 2 -----------------------------------------------------
> Length=  6
> Line=[ABCDE ]
> Line as hex=[4142434445ff]
> -----------------------------------------------------------------
>
>    I receive an unexpected length of 6, expected 5. The fact that the last two
>    characters are not 'XX' is acceptable since ARM A.10.7 19 says
>    "The values of characters not assigned are not specified."
>
>    I get the same output 2 if I compile the program with
>    GNAT GPL 2014, 2013,2012 or 2011 or with mingw FSF GNAT 4.7.0-1 or 4.8.1-4.
>
>    However if I compile with mingw FSF GNAT 4.5.2-1 , 4.5.0-1, 4.4.0 or
>    3.4.5 then I get the expected output 3 below
>
> -- Output 3 -----------------------------------------------------
> Length=  5
> Line=[ABCDEX]
> Line as hex=[414243444558]
> -----------------------------------------------------------------
>
>    Under windows the one line text file does not have an end of line
>    character (usually CRLF) which means it is not a canonical text file
>    as described here
>
>    http://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/the_implementation_of_standard_i_o.html#text-io
>
>    however that section also states that text_io can be use to read non canonical text files
>    and the very last line of that section says
>    "Every LF character is considered to end a line, and there is an
>      implied LF character at the end of the file."
>
>    this indicates to me that there should be an implied LF at the end of the
>    file and I should be getting the expected output 3 result for
>    all the compilers.
>
>    Is this a bug in the windows builds of GNAT?
>
>
>
>
>
> ---- Program -----------------------------------------------------
> with Ada.Text_IO;
>
> procedure FileRead is
>
>
>    TestFileName : constant string := "Test.txt";
>    TestFile : Ada.Text_IO.File_Type;
>
>    Line   : string(1..6) := "XXXXXX";
>    Length : natural;
>
>    function ToHex(Msg : string) return string is
>      Hex   : constant array (0..15) of character := "0123456789abcdef";
>      Str   : String(1..Msg'length*2) := (others => ' '); -- 2 hex digits per byte
>      Index : Integer :=1;
>      ByteValue : Integer;
>    begin
>      for i in Msg'Range loop
>        ByteValue := character'Pos(Msg(i));
>        Str(Index) := Hex(ByteValue / 16);
>        Index := Index + 1;
>        Str(Index) := Hex(ByteValue mod 16);
>        Index := Index + 1;
>      end loop;
>      return Str;
>    end;
>
> begin
>
>    Ada.Text_IO.Open( TestFile, Ada.Text_IO.IN_FILE, TestFileName );
>    if not Ada.Text_IO.End_Of_File(TestFile) then
>      Ada.Text_IO.Get_Line( TestFile, Line, Length );
>      Ada.Text_IO.Put_Line("Length= " & integer'image(Length));
>      Ada.Text_IO.Put_Line("Line=[" & Line & "]");
>      Ada.Text_IO.Put_Line("Line as hex=[" & ToHex(Line) & "]");
>    end if;
>
> exception
>
>    when E: others =>
>      Ada.Text_IO.Put_Line("Exception");
>
> end;
> -------------------------------------------------------------
>
>
>
>
>

Re: longest path through a task

[Patrick Noffke]

On Friday, May 29, 2015 at 11:31:27 AM UTC-5, Simon Wright wrote:
> Simon Wright writes:
> 
> > Just did some measurements (clumsily) using the Cortex-M4 counter as
> > in [1], and from entering the Ada handler to the triggered task
> > starting to execute averaged at 1200 cycles (6.7 us) with -Og, 1070
> > cycles (5.9 us) with -O2. There is some code in the C handler to
> > redirect to the Ada handler: see [2], starting at line 236.
> 
> The code in the C handler takes 150 cycles.
> 
> So, for my FreeRTOS-based RTS, interrupt to Ada handler is 150 cycles,
> Ada handler to task is 1200 cycles, grand total 1350 cycles or 7.5
> microseconds (core clock 180 MHz).
> 

I am able to instrument the TRACESWO pin on my Cortex-M4 (Atmel SAM4S) and capture the ITM trace information, which includes when the processor enters or exits an exception, and user trace information.  I can neatly capture this on my Saleae Logic Pro 16 analyzer and export it for use by PulseView/sigrok, which has recently added decoding of ITU/ITM/ETM (see http://essentialscrap.com/tips/arm_trace/ and http://www.sigrok.org/blog/new-protocol-decoders-arm-tpiu-itm-etmv3).

I have turned on timestamps (since the ITU baud rate is 8 Mbits/sec, and it can take a while to serialize the ITM information when things get busy), but I'm not sure what the values represent.  From what I read, the timestamps are based on the AHB clock, but I'm not sure what that is for this processor (processor clock of 120 MHz).

On one capture, I have the following ITM exception trace events:

Exit: IRQ 31
Enter: PendSV
Timestamp: 904 (exact)
Exit: PendSV
Timestamp: 906 (exact)
Resume: Thread
Timestamp: 907 (exact)

The actual time from Exit: IRQ 31 to the end of the last timestamp is about 19 us, but the ITU data stream is going continuous that entire time (no gaps), which leads me to suspect the ITU can't quite keep up (indeed, when I was experimenting with faster ITU baud rates, the total actual time for this sequence was less, but I can't recall the exact number).

Do you have some idea how to correlate these timestamps to real time?

Regards,
Patrick

Re: longest path through a task

[Simon Wright]

Patrick Noffke <patrick.noffke@gmail.com> writes:

> I have turned on timestamps (since the ITU baud rate is 8 Mbits/sec,
> and it can take a while to serialize the ITM information when things
> get busy), but I'm not sure what the values represent.  From what I
> read, the timestamps are based on the AHB clock, but I'm not sure what
> that is for this processor (processor clock of 120 MHz).

The STM standard setup for the STM32F429I has AHB running at the same
rate as the system clock (AHB prescaler 1).

> Do you have some idea how to correlate these timestamps to real time?

No, sorry (other than the above)

Re: longest path through a task

[Stephen Leake]

Patrick Noffke <patrick.noffke@gmail.com> writes:

> I am able to instrument the TRACESWO pin on my Cortex-M4 (Atmel SAM4S)
> and capture the ITM trace information, which includes when the
> processor enters or exits an exception, and user trace information. I
> can neatly capture this on my Saleae Logic Pro 16 analyzer and export
> it for use by PulseView/sigrok, 

I'm always happy to run across a Heinlein reference in an Ada group :).

-- 
-- Stephe