On Thu, Dec 12, 2019 at 7:08 AM Joel Sherrill <j...@rtems.org> wrote:
> > > On Thu, Dec 12, 2019, 7:21 AM Fernando Domínguez Pousa <fdpo...@gmv.com> > wrote: > >> >> >> >> >> *From:* Joel Sherrill [mailto:j...@rtems.org] >> *Sent:* 10 December 2019 17:36 >> *To:* Fernando Domínguez Pousa <fdpo...@gmv.com> >> *Subject:* Re: Print stack info using >> rtems_stack_checker_report_usage_with_plugin() >> >> >> >> >> >> On Tue, Dec 10, 2019, 8:37 AM Fernando Domínguez Pousa <fdpo...@gmv.com> >> wrote: >> >> Hi all, >> >> >> >> I’m interested in getting stack information via an UDP message with an >> ASCII log trace inside. Basically, I cannot get the information using a >> printf. I found the function >> rtems_stack_checker_report_usage_with_plugin(rtems_printer* printer) in >> order to get the information and send it using my UDP log function. So >> first of all I created a function called logPlugin (I used as exampled the >> plugin at printf_plugin.c): >> >> >> >> static int logPlugin(void *context, const char *format, va_list ap) >> >> { >> >> (void) context; >> >> return addLog(INFO, STACK,format, ap); /* First two arguments are used >> to classify message at reception*/ >> >> } >> >> >> >> Then at rtems_stack_checker_report_usage_with_plugin calling scope: >> >> >> >> rtems_printer printer; >> >> >> >> printer.context = NULL; >> >> printer.printer = logPlugin; >> >> >> >> rtems_stack_checker_report_usage_with_plugin(&printer); >> >> >> >> It is important to say that addLog puts the message in a circular buffer >> that other task will read and send the content using UDP. >> >> >> >> When stack checker report usage is called, only the information header is >> printed: " STACK USAGE BY THREAD\n" >> >> "ID NAME LOW HIGH CURRENT >> AVAIL USED\n" >> >> >> >> Next, stack values are not printed correctly and I can only get a value >> that is constant and equal to the same memory location (in decimal). It is >> a correct guide to implement this? I do not know how to use the printer >> struct context variable, can this cause my problem? >> >> >> >> Did you add CONFIGURE_ENABLE_STACK_CHECKER? >> >> >> >> Yes, it was enabled. >> >> >> >> Also it would be handy to have methods for obtain cpu and stack usage >> without relying on the printf hook >> >> >> >> I developed a code to gather all the tasks stack information into a >> struct that can be retrieved via function. Then I pack this struct and sent >> it via Ethernet. Can I add my code to check.c in order to retrieve stack >> information without print it? Is this an intersesting feature for the >> community? >> > > Yes it is interesting. File a ticket so there is one to track this > addition. > > It also will need a test and some documentation. I'm not sure how the test > will check the function behaves correctly. > > Looking forward to seeing your submission. > > We've had this feature request before. It was somewhat captured in https://devel.rtems.org/wiki/Developer/Projects/Open/StackChecker and the related: https://devel.rtems.org/wiki/Developer/Projects/Open/CPU_Statistics It's not clear it is enough work for a GSoC, but it seems too much work for someone to do voluntarily :) > --joel > >> >> >> Regards, >> >> >> >> >> >> Thanks in advance, >> >> >> >> Regards, >> >> >> >> >> ------------------------------ >> >> >> *Fernando Domínguez Pousa *Ingeniero de Software >> Software Engineer >> >> GMV >> Isaac Newton, 11 >> P.T.M. Tres Cantos >> E-28760 Madrid >> Tel. +34 91 807 21 00 >> Fax +34 91 807 21 99 >> www.gmv.com >> >> >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.facebook.com_infoGMV&d=DwMFaQ&c=CIoxZ4z5BqFvKvSGFOTo726QZIiNTc_M9CmngT-Pla4&r=JJRyTkGL8xI4YFJLjo7JWw&m=ZnGDe8CiC5tUJJuEodtypPFjSXET23uigE7l-uSzLMY&s=TVgsYD5kZtUVH9LulD6BpnRsdJjK7KKhwm0gExv79V0&e=> >> >> >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.twitter.com_infoGMV-5Fes&d=DwMFaQ&c=CIoxZ4z5BqFvKvSGFOTo726QZIiNTc_M9CmngT-Pla4&r=JJRyTkGL8xI4YFJLjo7JWw&m=ZnGDe8CiC5tUJJuEodtypPFjSXET23uigE7l-uSzLMY&s=AKhuDTIEG9B5SSppSI9W2IZbCtlVN6Xxghmhqw_8xrs&e=> >> >> >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__plus.google.com_-2BGmvcompany&d=DwMFaQ&c=CIoxZ4z5BqFvKvSGFOTo726QZIiNTc_M9CmngT-Pla4&r=JJRyTkGL8xI4YFJLjo7JWw&m=ZnGDe8CiC5tUJJuEodtypPFjSXET23uigE7l-uSzLMY&s=aH_sTC6ItBsWu6XvQPqgmMi4brzX7wBHmPqFQ2FbfSc&e=> >> >> >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.youtube.com_infoGMV&d=DwMFaQ&c=CIoxZ4z5BqFvKvSGFOTo726QZIiNTc_M9CmngT-Pla4&r=JJRyTkGL8xI4YFJLjo7JWw&m=ZnGDe8CiC5tUJJuEodtypPFjSXET23uigE7l-uSzLMY&s=LeXn3Vd6znq0lx28JCcO0BUCbRxzg36aodelZfSy_QE&e=> >> >> >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_gmv&d=DwMFaQ&c=CIoxZ4z5BqFvKvSGFOTo726QZIiNTc_M9CmngT-Pla4&r=JJRyTkGL8xI4YFJLjo7JWw&m=ZnGDe8CiC5tUJJuEodtypPFjSXET23uigE7l-uSzLMY&s=qQvn0q84_7QaJIvkgK7wpqkfzr7YoJNDa9KIA6w0TVQ&e=> >> >> <http://www.gmv.com/en/RSS> >> >> >> >> <http://www.gmv.com/blog_gmv/language/en/> >> >> >> >> >> >> >> >> >> >> >> P Please consider the environment before printing this e-mail. >> >> _______________________________________________ >> users mailing list >> users@rtems.org >> http://lists.rtems.org/mailman/listinfo/users >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_users&d=DwMFaQ&c=CIoxZ4z5BqFvKvSGFOTo726QZIiNTc_M9CmngT-Pla4&r=JJRyTkGL8xI4YFJLjo7JWw&m=ZnGDe8CiC5tUJJuEodtypPFjSXET23uigE7l-uSzLMY&s=dGxmP2gK5vUyNRX5UQVoMbmLLQ1K6M-QpFkFJfVYVEY&e=> >> >> >> P Please consider the environment before printing this e-mail. >> > _______________________________________________ > users mailing list > users@rtems.org > http://lists.rtems.org/mailman/listinfo/users
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
