ESP8266 Community Forum

- Thu Jan 17, 2019 6:32 am #80108 I read the document, and thought interesting.

I suspect that until there is a beta to try out you are not going to get too many detailed questions / comments.

I realise that in a company product development specifications will be reviewed, revised etc., but many here will not have the time / inclination to indulge in a theoretical exercise.

I encourage you to release the code as soon as you think it is viable. It doesn't have to be perfect; that's what feedback is for.

- Thu Jan 17, 2019 1:07 pm #80112 OK, I've had a good cry and collected-up some of the toys around my pram...

Never let it be said that professional software engineers weren't prima donas and that they love documentation.

I will get a beta done with examples, and we'll wing it from there. If I provide enough variations of example then it will become clear, and I accept that this kind of tool is not for everyone. The fact that the 'main players' are interested encourages me. The trouble with being a perfectionist is that I hate giving out untidy code, but it does work as I want it to, there are lots of enhancements I want to do, but it will suffice as-is if you want to try it - I will provide a list of new issues and to-do items.

I need to rework my build installation on a new PC and get the licensing info in place and then I will give you a beta library.

There is in addition, the remote analysis tool which communicates with the MCU in real-time and allows the time consuming work of trace analysis and report generation to be done without encumbering the MCU, however the build docs for that are not in place and it's quite a bit of work. That is fine however, as the analysis & reports will default to being done on the MCU, it just means that the workload will be placed there and therefore sufficient sizing of things like the buffer to hold the trace data is needed in accordance with the amount of stuff you trace, otherwise your code gets held up. We'll just have to cross that bridge when we come to it, and of course I will answer all questions. When I say 'held up' it is only a matter of 200 milliseconds but of course that defeats the point if it gets in the way. When the analysis is done externally it is a millisecond or so, according to the time to transmit the data (which I will also change to make a background isr task when I do the next version, and then no hold up of the user task will occur).

- Thu Jan 17, 2019 1:46 pm #80114

TRAP Design & Usage.pdf

I recently mentioned that I have a long standing project in development but I am not done with the software such as I can release it to you all, however I have documented the main concepts of the library and its features.

The tool has an API/library and associated tooling/analysis, so that you can trace your code execution in real-time, print/log anywhere (including ISRs) and be able to finely measure the performance of the parts of the code that you select for profiling instrumentation.

So, I am attaching the document here, and ask that if you are interested please read through and ask any questions or raise and problems you see with it.

I would be interested to give TRAP a try on on one of my programs that has an intermittent problem. The WiFi analysis output stream would be very useful for me.

- Sat Jan 19, 2019 7:19 pm #80156 In order to keep the momentum and the interest up, I have just run some tests with a large test suite that I have to show you some example results.

Obviously, data and function trace of your code is tightly coupled to the code you are tracing, but this gives an example of tracing an software timer (isr) with a frequency of 1mSec intermixed with other events, functions and data logging.

There are two types of report :

1. Textual trace and profiler stats. This is the complete time ordered events as they occur, with the profiling stats at the end.

2. Interactive graphic : Using chrome trace tools (Have you used them?) TRAP will build a file that can be imported into Chrome Trace and then this can be interactively filtered/viewed etc, just as any chrome trace style stuff.

I have attached both styles of report, a text file (of textual trace/profiler) and a png (of chrome trace). If you want the raw file to import into chrome trace to interact with let me know.

The chrome trace shows the isr running for a short period, and I have selected some of the function calls which gives profiling time summary at the bottom of the picture.

I'm in the process of sorting the software for your use, as promised.

Oh and... this is running from the esp-core Arduino framework, so you don't need any fancy freeRTOS or anything else to use it, which is the point of it really. It also runs on Arduino Uno/Micro etc and Due.

You do not have the required permissions to view the files attached to this post.