Re: GSoC 2016 Interested in Tracing was Re:
Hi Joel Sorry for the delay in responding and thank you for your comments on my proposal. I would like to share my progress so far. I ran the fileio trace example as described on the Trace Buffering page and started studying rtems-tld. I made changes so that rtems-tld command auto-generates a CTF metadata file for a given .ini file. I assumed each buffer as a different stream containing events like buffer entry/exit, buffer argument, return values etc. Then i modified the buffer functions so they produce trace described by above metadata. I have also made changes to RTEMS shell utility rtrace so it can print trace in CTF format for analysis. Thank you for highlighting user extensions. I haven't looked into these yet. Can you point me to an example or a test where these are being used? I will study these and update the document soon. Also, as you mentioned currently capture has to be paused for generating trace. Im investigating how this can be addressed in the capture engine. Any suggestions are appreciated. For example, im looking at a producer-consumer solution for simultaneous read/write using 2 threads. I intend to keep the framework structure intact, and reuse the existing functional tests. I will extend unit tests to test the new features regarding CTF trace generation. By the mid-term evaluation, auto generation of metadata and trace wrappers that produce CTF traces will be complete. The mid term deliverable will have all the capabilites of current trace framework, alebit the trace generated will be in CTF format. That will also allow us to decode these traces in Babeltrace too. I will also pay attention to creating good examples, documentation and video demonstration as you have suggested. Im occupied with my college exams but I will put these details in the document as soon as possible. Regards, Vivek ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Starting Tool Bump
Hi I am starting a tool bump to: gcc-6-20160327 newlib-2.4.0 I am switching rtems-default to that and will be starting the tool builds followed by a build of all BSPs after that. This is needed for a few changes over the past month: + newlib's standard feature flags were completely reworked to be more correct + newlib epiphany machine code had random/srandom and they are now in in portable location + newlib i386 setjmp does not disable interrupts anymore + misc improvements from newlib community + gcc fixed a false postive warning I reported Once these tools are available to the community, I highly recommend compiling as much user and third party code as possible. The newlib feature flag change pointed out a few places we didn't set the right OS/standard level feature flags before including .h files. I expect the same issue in user code. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: BBB PWM driver development - GSOC 2016
Please read https://devel.rtems.org/wiki/Developer/Coding/Conventions carefully including some of the linked pages related to style. Search back through this mailing list for discussions related to the gpio framework. Would it be sensible to stick close to the gpio framework and add pwm to it? On Fri, Apr 1, 2016 at 4:10 PM, punit vara wrote: > Recently Worth Burruss suggested me function prototype for getting started > to develop PWM driver. I updated my blog > http://punitvara.github.io/rtems%20drivers/2016/02/28/basic-function with > sample functions. > > rtems_status_code SetDutyCycle(int subSystemNumber,float HZ, float > DutyCycleA, float DutyCycleB); > void PWMSubSystemEnable(int subSytemNumber,bool EnableOrDisable); > > I have written this function at > https://github.com/punitvara/rtems_gsoc16/blob/master/pwd/worth.c > > > Marcos, can you please look at blog and function definition? Do you have > advice for me ? > > Thanks, > Punit Vara > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-testing commit] bit_rtems: Disable C++ on architectures it is broken on
Ping. On 20/03/2016 12:28 PM, Chris Johns wrote: On 20/03/2016 11:09 AM, Joel Sherrill wrote: Module:rtems-testing Branch:master Commit:8c82823aff36b5a59d1154d37a3a109f3d06f736 Changeset: http://git.rtems.org/rtems-testing/commit/?id=8c82823aff36b5a59d1154d37a3a109f3d06f736 Author:Joel Sherrill Date: Sat Mar 19 19:09:09 2016 -0500 bit_rtems: Disable C++ on architectures it is broken on What is broken with these architectures? Which RTEMS branches does this effect? Is the RSB in sync with these changes? How do we keep the RSB in sync? :) Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
