From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.66.218.102 with SMTP id pf6mr1725595pac.20.1433165545671; Mon, 01 Jun 2015 06:32:25 -0700 (PDT) X-Received: by 10.182.105.65 with SMTP id gk1mr128535obb.27.1433165544605; Mon, 01 Jun 2015 06:32:24 -0700 (PDT) Path: buffer1.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news.glorb.com!h15no859511igd.0!news-out.google.com!n7ni50007igk.0!nntp.google.com!h15no1568516igd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 1 Jun 2015 06:32:24 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=74.203.194.21; posting-account=bXcJoAoAAAAWI5APBG37o4XwnD4kTuQQ NNTP-Posting-Host: 74.203.194.21 References: <9ad1fcdc-cdf9-4ff0-aa7e-051d53b6736a@googlegroups.com> <7d56e720-5e91-4950-b4ae-29d7ddbdc11a@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: longest path through a task From: Patrick Noffke Injection-Date: Mon, 01 Jun 2015 13:32:25 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: number.nntp.giganews.com comp.lang.ada:193429 Date: 2015-06-01T06:32:24-07:00 List-Id: On Friday, May 29, 2015 at 11:31:27 AM UTC-5, Simon Wright wrote: > Simon Wright writes: >=20 > > 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. >=20 > The code in the C handler takes 150 cycles. >=20 > 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). >=20 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 t= his on my Saleae Logic Pro 16 analyzer and export it for use by PulseView/s= igrok, which has recently added decoding of ITU/ITM/ETM (see http://essenti= alscrap.com/tips/arm_trace/ and http://www.sigrok.org/blog/new-protocol-dec= oders-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), b= ut I'm not sure what the values represent. From what I read, the timestamp= s are based on the AHB clock, but I'm not sure what that is for this proces= sor (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 ga= ps), 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 thi= s 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