[PATCH 1/2] score: Remove Thread_queue_Queue::operations field

2016-03-23 Thread Sebastian Huber 
Remove the Thread_queue_Queue::operations field to reduce the size of
this structure.  Add a thread queue operations parameter to the
_Thread_queue_First(), _Thread_queue_First_locked(),
_Thread_queue_Enqueue(), _Thread_queue_Dequeue() and
_Thread_queue_Flush() functions.  This is a preparation patch to reduce
the size of several synchronization objects.
---
 cpukit/posix/include/rtems/posix/condimpl.h|  2 +
 cpukit/posix/include/rtems/posix/psignalimpl.h |  2 +
 cpukit/posix/include/rtems/posix/pthreadimpl.h | 12 +++
 cpukit/posix/src/conddestroy.c |  7 +-
 cpukit/posix/src/condinit.c|  5 +-
 cpukit/posix/src/condsignalsupp.c  |  5 +-
 cpukit/posix/src/condwaitsupp.c|  1 +
 cpukit/posix/src/mqueuecreatesupp.c|  6 +-
 cpukit/posix/src/nanosleep.c   |  3 +-
 cpukit/posix/src/prwlockdestroy.c  |  7 +-
 cpukit/posix/src/psignal.c | 11 +--
 cpukit/posix/src/pthread.c |  7 +-
 cpukit/posix/src/pthreadexit.c |  4 +-
 cpukit/posix/src/pthreadjoin.c |  1 +
 cpukit/posix/src/semaphorecreatesupp.c | 21 ++---
 cpukit/posix/src/sigtimedwait.c|  2 +-
 cpukit/rtems/include/rtems/rtems/region.h  |  1 +
 cpukit/rtems/src/msgqcreate.c  |  8 +-
 cpukit/rtems/src/regioncreate.c| 12 +--
 cpukit/rtems/src/regiongetsegment.c|  1 +
 cpukit/rtems/src/regionprocessqueue.c  |  5 +-
 cpukit/rtems/src/semcreate.c   | 14 ++--
 cpukit/score/include/rtems/score/corebarrierimpl.h |  3 +
 cpukit/score/include/rtems/score/coremsg.h | 19 ++---
 cpukit/score/include/rtems/score/coremsgimpl.h | 30 +++
 cpukit/score/include/rtems/score/coremutex.h   |  6 ++
 cpukit/score/include/rtems/score/coremuteximpl.h   |  6 +-
 cpukit/score/include/rtems/score/corerwlockimpl.h  |  2 +
 cpukit/score/include/rtems/score/coresem.h | 10 ++-
 cpukit/score/include/rtems/score/coresemimpl.h | 35 +++-
 cpukit/score/include/rtems/score/threadq.h | 14 
 cpukit/score/include/rtems/score/threadqimpl.h | 92 --
 cpukit/score/src/corebarrier.c |  5 +-
 cpukit/score/src/corebarrierrelease.c  | 12 ++-
 cpukit/score/src/corebarrierwait.c |  2 +-
 cpukit/score/src/coremsg.c | 20 ++---
 cpukit/score/src/coremsgclose.c|  1 +
 cpukit/score/src/coremsgseize.c|  7 +-
 cpukit/score/src/coremsgsubmit.c   |  2 +-
 cpukit/score/src/coremutex.c   | 12 +--
 cpukit/score/src/coremutexflush.c  |  1 +
 cpukit/score/src/coremutexseize.c  |  2 +-
 cpukit/score/src/coremutexsurrender.c  | 10 ++-
 cpukit/score/src/corerwlock.c  |  5 +-
 cpukit/score/src/corerwlockobtainread.c|  7 +-
 cpukit/score/src/corerwlockobtainwrite.c   |  2 +-
 cpukit/score/src/corerwlockrelease.c   | 10 ++-
 cpukit/score/src/coresem.c | 23 +++---
 cpukit/score/src/mpci.c| 15 ++--
 cpukit/score/src/threadq.c | 16 +---
 cpukit/score/src/threadqenqueue.c  |  9 ++-
 cpukit/score/src/threadqfirst.c|  5 +-
 cpukit/score/src/threadqflush.c| 20 +++--
 testsuites/sptests/spthreadq01/init.c  | 14 +---
 54 files changed, 263 insertions(+), 291 deletions(-)

diff --git a/cpukit/posix/include/rtems/posix/condimpl.h 
b/cpukit/posix/include/rtems/posix/condimpl.h
index 789d3e8..b079a43 100644
--- a/cpukit/posix/include/rtems/posix/condimpl.h
+++ b/cpukit/posix/include/rtems/posix/condimpl.h
@@ -32,6 +32,8 @@ extern "C" {
  */
 #define POSIX_CONDITION_VARIABLES_NO_MUTEX 0
 
+#define POSIX_CONDITION_VARIABLES_TQ_OPERATIONS &_Thread_queue_Operations_FIFO
+
 /**
  *  The following defines the information control block used to manage
  *  this class of objects.
diff --git a/cpukit/posix/include/rtems/posix/psignalimpl.h 
b/cpukit/posix/include/rtems/posix/psignalimpl.h
index 6104aca..eeb060e 100644
--- a/cpukit/posix/include/rtems/posix/psignalimpl.h
+++ b/cpukit/posix/include/rtems/posix/psignalimpl.h
@@ -35,6 +35,8 @@
 #include 
 #include 
 
+#define POSIX_SIGNALS_TQ_OPERATIONS &_Thread_queue_Operations_FIFO
+
 #define _States_Is_interruptible_signal( _states ) \
   ( ((_states) & \
 (STATES_WAITING_FOR_SIGNAL|STATES_INTERRUPTIBLE_BY_SIGNAL)) == \
diff --git a/cpukit/posix/include/rtems/posix/pthreadimpl.h 
b/cpukit/posix/include/rtems/posix/pthreadimpl.h
index 16b0163..14db6f0 100644
--- a/cpukit/posix/include/rtems/posix/pthreadimpl.h
+++ b/cpukit/posix/include/rtems/posix/pthreadimpl.h
@@ -35,6 +35,8 @@ extern "C" {

[PATCH 2/2] score: Use constant for maximum count of CORE sema

2016-03-23 Thread Sebastian Huber 
---
 cpukit/libmisc/monitor/mon-sema.c  |  7 ++-
 cpukit/posix/src/semaphorecreatesupp.c |  1 -
 cpukit/rtems/src/semcreate.c   |  1 -
 cpukit/score/include/rtems/score/coresem.h | 13 -
 cpukit/score/include/rtems/score/coresemimpl.h |  4 +---
 cpukit/score/src/coresem.c |  3 ---
 cpukit/score/src/mpci.c|  1 -
 7 files changed, 3 insertions(+), 27 deletions(-)

diff --git a/cpukit/libmisc/monitor/mon-sema.c 
b/cpukit/libmisc/monitor/mon-sema.c
index f7e35ed..5add7cf 100644
--- a/cpukit/libmisc/monitor/mon-sema.c
+++ b/cpukit/libmisc/monitor/mon-sema.c
@@ -28,11 +28,8 @@ rtems_monitor_sema_canonical(
 
 if (_Attributes_Is_counting_semaphore(canonical_sema->attribute)) {
   /* we have a counting semaphore */
-  canonical_sema->cur_count  =
-   rtems_sema->Core_control.semaphore.count;
-
-  canonical_sema->max_count  =
-   rtems_sema->Core_control.semaphore.Attributes.maximum_count;
+  canonical_sema->cur_count  = rtems_sema->Core_control.semaphore.count;
+  canonical_sema->max_count  = UINT32_MAX;
 }
 else {
   /* we have a binary semaphore (mutex) */
diff --git a/cpukit/posix/src/semaphorecreatesupp.c 
b/cpukit/posix/src/semaphorecreatesupp.c
index c527a9b..9a24e0a 100644
--- a/cpukit/posix/src/semaphorecreatesupp.c
+++ b/cpukit/posix/src/semaphorecreatesupp.c
@@ -95,7 +95,6 @@ int _POSIX_Semaphore_Create_support(
   _CORE_semaphore_Initialize(
 &the_semaphore->Semaphore,
 CORE_SEMAPHORE_DISCIPLINES_FIFO,
-0x,
 value
   );
 
diff --git a/cpukit/rtems/src/semcreate.c b/cpukit/rtems/src/semcreate.c
index c8111fd..d289546 100644
--- a/cpukit/rtems/src/semcreate.c
+++ b/cpukit/rtems/src/semcreate.c
@@ -153,7 +153,6 @@ rtems_status_code rtems_semaphore_create(
 _CORE_semaphore_Initialize(
   &the_semaphore->Core_control.semaphore,
   semaphore_discipline,
-  0x,
   count
 );
 #if defined(RTEMS_SMP)
diff --git a/cpukit/score/include/rtems/score/coresem.h 
b/cpukit/score/include/rtems/score/coresem.h
index 44e17c3..84fde0b 100644
--- a/cpukit/score/include/rtems/score/coresem.h
+++ b/cpukit/score/include/rtems/score/coresem.h
@@ -50,15 +50,6 @@ typedef enum {
 }   CORE_semaphore_Disciplines;
 
 /**
- *  The following defines the control block used to manage the
- *  attributes of each semaphore.
- */
-typedef struct {
-  /** This element indicates the maximum count this semaphore may have. */
-  uint32_tmaximum_count;
-}   CORE_semaphore_Attributes;
-
-/**
  *  The following defines the control block used to manage each
  *  counting semaphore.
  */
@@ -73,10 +64,6 @@ typedef struct {
*/
   const Thread_queue_Operations *operations;
 
-  /** This element is the set of attributes which define this instance's
-   *  behavior.
-   */
-  CORE_semaphore_Attributes   Attributes;
   /** This element contains the current count of this semaphore. */
   uint32_tcount;
 }   CORE_semaphore_Control;
diff --git a/cpukit/score/include/rtems/score/coresemimpl.h 
b/cpukit/score/include/rtems/score/coresemimpl.h
index 365345a..c70e54f 100644
--- a/cpukit/score/include/rtems/score/coresemimpl.h
+++ b/cpukit/score/include/rtems/score/coresemimpl.h
@@ -87,13 +87,11 @@ typedef void ( *CORE_semaphore_API_mp_support_callout )(
  *
  *  @param[in] the_semaphore is the semaphore to initialize
  *  @param[in] discipline the blocking discipline
- *  @param[in] maximum_count the maximum count
  *  @param[in] initial_value is the initial count of the semaphore
  */
 void _CORE_semaphore_Initialize(
   CORE_semaphore_Control *the_semaphore,
   CORE_semaphore_Disciplines  discipline,
-  uint32_tmaximum_count,
   uint32_tinitial_value
 );
 
@@ -158,7 +156,7 @@ RTEMS_INLINE_ROUTINE CORE_semaphore_Status 
_CORE_semaphore_Surrender(
 _Thread_Dispatch_enable( _Per_CPU_Get() );
 #endif
   } else {
-if ( the_semaphore->count < the_semaphore->Attributes.maximum_count )
+if ( the_semaphore->count < UINT32_MAX )
   the_semaphore->count += 1;
 else
   status = CORE_SEMAPHORE_MAXIMUM_COUNT_EXCEEDED;
diff --git a/cpukit/score/src/coresem.c b/cpukit/score/src/coresem.c
index db2d47f..2bdd81c 100644
--- a/cpukit/score/src/coresem.c
+++ b/cpukit/score/src/coresem.c
@@ -23,12 +23,9 @@
 void _CORE_semaphore_Initialize(
   CORE_semaphore_Control *the_semaphore,
   CORE_semaphore_Disciplines  discipline,
-  uint32_tmaximum_count,
   uint32_tinitial_value
 )
 {
-
-  the_semaphore->Attributes.maximum_count = maximum_count;
   the_semaphore->count = initial_value;
 
   _Thread_queue_Initialize( &the_semaphore->Wait_queue );
diff --git a/cpukit/score/src/mpci.c b/cpukit/score/src/mpci.c
index 8e93d74..132d3e5 100644
--- a/cpukit/score/src/mpci.c
+++ b/cpukit/score/src/mpci.c
@@ -120,7 +120,6 @@ static void _MPCI_Handler

PWM testing API

2016-03-23 Thread punit vara 
What are the RTEMS APIs that worth reusing in testing of PWM driver?
Can someone please help to list out ?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Participation in GSoC 2016

2016-03-23 Thread Deval Shah 
On Tue, Mar 22, 2016 at 10:04 PM, Alan Cudmore  wrote:
> Hi Deval,
> Your proposal looks good. I would suggest adding a step where you build a
> known BSP with BSD lib support. It will help you become familiar with the
> development process.

Thanks for the suggestion, Alan. I will be adding this to my proposal.
Also, which BSP would you recommend that I pick up ? Is there any list
of currently added BSPs from which I can choose?

> You should also address which Raspberry Pi model you will support. Now that
> there are so many Raspberry Pi models, it might make the project more
> complicated:
> Original raspberry Pi Model A & A+: a single built in USB port in the
> BCM2835 CPU. No ethernet or USB hub.
> Raspberry Pi Model B & B+: USB hub and Ethernet in LAN9512 chip.
> Raspberry Pi 2 Model B: USB hub and Ethernet in LAN9514 chip.
> Raspberry Pi 3 Model B:  I would not worry about this one yet.
> Raspberry Pi Zero: A single USB OTG port , no ethernet or USB hub.
>
> I would pick one of them and get it working before seeing if another model
> could be supported.
>
> If the Raspberry Pi 1/B+ and 2/B Hubs are functionally the same ( LAN9512
> vs. LAN9514 ), this would support the widest range of devices out there.
>
I was also thinking for that. I have a Raspberry PI 1/B+ and a
majority of users have either 1/B+ or 2/B. Probably we can start with
1/B+ and then enable the other models.

> If you have time, I would love to see USB support for the BCM2835 on the Pi
> Model A+ and especially the Pi Zero.

Sure, I had left some buffer time in my proposal, probably if things
goes as per plan that time can be used for USB support for the
BCM2835.

>
> Thanks,
> Alan
>
>
> On Tue, Mar 22, 2016 at 8:52 AM, Deval Shah  wrote:
>>
>> Hello,
>>
>> I have updated my draft proposal and shared on the tracking page. I'm
>> sharing it here as well. https://goo.gl/QQiAf6
>>
>> Sorry, I was busy with my Mid-Semester exams, could not update earlier.
>>
>> Since this is a draft proposal, it may not be completely polished yet.
>> I'd appreciate any comments on it, especially regarding the project
>> description
>> and timeline.
>>
>> Thank you.
>>
>> Regards,
>> Deval Shah
>>
>> On Fri, Mar 11, 2016 at 11:02 PM, Deval Shah 
>> wrote:
>> > On Fri, Mar 11, 2016 at 8:33 PM, Gedare Bloom  wrote:
>> >> On Fri, Mar 11, 2016 at 8:19 AM, Deval Shah 
>> >> wrote:
>> >>> Hello everyone!
>> >>>
>> >>> I went through the links and blogs of the SD card and USB/Ethernet
>> >>> project for Raspberry PI. I would like to work for the USB/Ethernet
>> >>> support project.
>> >>>
>> >>> I have prepared a draft of the timeline as follows:
>> >>>
>> >>> Acceptance Waiting Period:
>> >>> Understanding previous year's GSOC work
>> >>>
>> >>> First Half:
>> >>> completing USB support for RPI
>> >>> Testing USB and add drivers for HIDs like Mouse and Keyboard
>> >>>
>> >>> Second Half:
>> >>> Adding Ethernet Support
>> >>> Testing (ARP, PING, DHCP, FTP, TFTP)
>> >>> Adding support for lwIP (since it is already ported to BBB, this
>> >>> should not take more time)
>> >>>
>> >> Timeline seems good. Is the USB support available from freebsd for the
>> >> libbsd codebase?
>> >
>> > Yes. libbsd has support for USB.
>> > Last year issues were in porting the driver (
>> > http://gtament-rtems.blogspot.in/2015/06/my-progress-report.html ).
>> >
>> >>> If we have wifi support in RTEMS, can support of a USB wifi module be
>> >>> added to the project?
>> >>>
>> >> I haven't seen any one using wifi yet.
>> >>
>> >>> I'd really appreciate any feedback on my deliverables, especially
>> >>> regarding the feasibility of doing it in this time frame. If there is
>> >>> anything I may have missed out or anything else I should consider as a
>> >>> part of this, I'd be really glad if someone could point that out, so
>> >>> as to increase my chances of selection.
>> >>>
>> >>> A quick question: How can I add my name to the tracking list @
>> >>> https://devel.rtems.org/wiki/GSoC/2016 ?
>> >>>
>> >> You need to register an account to edit the page through link at the
>> >> bottom.
>> >> Okay, Thank you.
>> >>> Deval Shah
>> >>>
>> >>> On Tue, Mar 1, 2016 at 3:07 AM, André Marques
>> >>>  wrote:
>>  Hello Jan and Deval,
>> 
>>  Às 20:24 de 29-02-2016, Jan Sommer escreveu:
>> >
>> > Hi,
>> >
>> > If you take a look here:
>> >
>> > https://devel.rtems.org/wiki/GSoC/2015#StudentsSummerofCodeTrackingTable
>> >  you
>> > can find the links to the reports and repositories of the previous
>> > GSoC.
>> > Yurii Shevtsov was doing the work on the Ethernet/USB part for the
>> > pi.
>> > Andre Marques worked on the SPI and SD-Card driver.
>> 
>> 
>>  I have updated a bit the Raspberry Open Projects page with the state
>>  of the
>>  low level peripherals project, and provided links to the state of
>>  each of
>>  the other projects (the wiki pages of the students working on them
>>  last
>>  year,

Re: Request for GPIO Examples

2016-03-23 Thread Worth Burruss 
On 23 Mar 2016 at 0:57, punit vara wrote:

> Hi Worth Burruss,
> 
> This year I proposed a plan (https://goo.gl/cGCXbS) to develop Beagle
> bone black BSP which includes PWM drivers as well as I2C driver. Could
> you please suggest me testing methods to test PWM on BBB ?
> 
> Regards,
> Punit
> 

Punit,

I will preface this with my solutions tend to be overly complex and I do not 
know specifically 
what is available to use to test with in the BBB.  So this may not be what you 
are looking for.  
It also depends on the frequency of your PWM signals.

When I think of test on hardware, I want to know it is working the way I think 
it is working 
(proving correctness).  For PWM, this means the duty cycle is correct.  I would 
be using 
another hardware counter timer to measure the High time followed by the Low 
time and doing 
the math to prove that the times are correct for the programmed duty cycle.

As an alternate, with appropriate selection of PWM frequency and software 
timers, you can 
do the High and low counting using the timers.

As for me, I would find it hard to see the change in an LED's intensity except 
in a crude 
fashion, so would not meet my personal goal of proving correctness.   But you 
may be 
thinking of ON and OFF times in seconds, In which case an LED and maybe a stop 
watch 
would be appropriate.

Hopefully this gives you some ideas.

Thank you,

Worth Burruss




___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Fwd: GSoC 2016 Student Proposal Deadline is Friday, March 25th 19:00 UTC

2016-03-23 Thread Joel Sherrill 
Just a reminder to any students watching this list.

You MUST have an application into the Google website with your proposal.

We can fine-tune your proposal in Google Docs but if you don't meet their
requirements, you won't be eligible for consideration.

-- Forwarded message --
From: 'Stephanie' via Google Summer of Code Discuss <
google-summer-of-code-disc...@googlegroups.com>
Date: Wed, Mar 23, 2016 at 6:00 AM
Subject: GSoC 2016 Student Proposal Deadline is Friday, March 25th 19:00 UTC
To: Google Summer of Code Discuss <
google-summer-of-code-disc...@googlegroups.com>


If you are a university student and want to submit a proposal for
consideration for GSoC 2016, the deadline is Friday, March 25th at 19:00
UTC (in less than 56 hours).


Visit the program site, g.co/gsoc, to register and submit your proposal to
the organization that interests you.


Be sure to read the Ideas List for each organization and reach out to the
organization immediately to get feedback on your proposal so that you can
write the best possible proposal before the final deadline.


For tips on writing an excellent proposal read the short Student Manual

written by Mentors, Org Administrators and former students.


We are very close to the deadline so many orgs will be swamped with
requests to review student draft proposals and they may not be able to give
you feedback before the deadline. But don’t be discouraged, if you haven’t
heard back from the organization with less than 24 hours before the
deadline, go ahead and submit your Final PDF Proposal. Be sure to write the
best quality proposal you can.


Applications close Friday, March 25 at 19:00 UTC.  All final pdf proposals
must be submitted before the deadline to be considered by the mentor
organizations.


Good luck everyone!

-- 
You received this message because you are subscribed to the Google Groups
"Google Summer of Code Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-summer-of-code-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to
google-summer-of-code-disc...@googlegroups.com.
Visit this group at
https://groups.google.com/group/google-summer-of-code-discuss.
For more options, visit https://groups.google.com/d/optout.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RSB 4.11] Bump OpenRISC versions

2016-03-23 Thread Chris Johns 

On 23/03/2016 04:55, Gedare Bloom wrote:


You can check them in. Let Joel/Chris know as they have been release
testing 4.11



Hesham, sorry I have lost track of what is needed. Do clean patches 
exist to make the required changes for 4.11 and master?


Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Request for GPIO Examples

2016-03-23 Thread Ketul Shah 
Hi Punit,

Apart from what Worth Burruss suggested,

First of all setting on off timing and testing on LED would be OK for
primary testing.

You can always test your PWM signals on DSO/CRO to have a clear picture of
what is happening over signals.

And if you can manage to have second BBB you can test signals on it too:-
http://hackaday.com/2015/02/19/turn-your-beagleboneblack-in-to-a-14-channel-100msps-logic-analyzer/

Also thinking towards a bit application side,

Using PWM signals you can very DC motor speed using motor driver IC.
RGB Led would be a great visual to test it and many more

Hope this helps for your further testing...

Ketul

On 23 March 2016 at 19:51, Worth Burruss  wrote:

> On 23 Mar 2016 at 0:57, punit vara wrote:
>
> > Hi Worth Burruss,
> >
> > This year I proposed a plan (https://goo.gl/cGCXbS) to develop Beagle
> > bone black BSP which includes PWM drivers as well as I2C driver. Could
> > you please suggest me testing methods to test PWM on BBB ?
> >
> > Regards,
> > Punit
> >
>
> Punit,
>
> I will preface this with my solutions tend to be overly complex and I do
> not know specifically
> what is available to use to test with in the BBB.  So this may not be what
> you are looking for.
> It also depends on the frequency of your PWM signals.
>
> When I think of test on hardware, I want to know it is working the way I
> think it is working
> (proving correctness).  For PWM, this means the duty cycle is correct.  I
> would be using
> another hardware counter timer to measure the High time followed by the
> Low time and doing
> the math to prove that the times are correct for the programmed duty cycle.
>
> As an alternate, with appropriate selection of PWM frequency and software
> timers, you can
> do the High and low counting using the timers.
>
> As for me, I would find it hard to see the change in an LED's intensity
> except in a crude
> fashion, so would not meet my personal goal of proving correctness.   But
> you may be
> thinking of ON and OFF times in seconds, In which case an LED and maybe a
> stop watch
> would be appropriate.
>
> Hopefully this gives you some ideas.
>
> Thank you,
>
> Worth Burruss
>
>
>
>
> ___
> 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: Request for GPIO Examples

2016-03-23 Thread punit vara 
On Wed, Mar 23, 2016 at 7:51 PM, Worth Burruss  wrote:
> On 23 Mar 2016 at 0:57, punit vara wrote:
>
>> Hi Worth Burruss,
>>
>> This year I proposed a plan (https://goo.gl/cGCXbS) to develop Beagle
>> bone black BSP which includes PWM drivers as well as I2C driver. Could
>> you please suggest me testing methods to test PWM on BBB ?
>>
>> Regards,
>> Punit
>>
>
> Punit,
>
> I will preface this with my solutions tend to be overly complex and I do not 
> know specifically
> what is available to use to test with in the BBB.  So this may not be what 
> you are looking for.
> It also depends on the frequency of your PWM signals.
>
> When I think of test on hardware, I want to know it is working the way I 
> think it is working
> (proving correctness).  For PWM, this means the duty cycle is correct.  I 
> would be using
> another hardware counter timer to measure the High time followed by the Low 
> time and doing
> the math to prove that the times are correct for the programmed duty cycle.
>
> As an alternate, with appropriate selection of PWM frequency and software 
> timers, you can
> do the High and low counting using the timers.
>
> As for me, I would find it hard to see the change in an LED's intensity 
> except in a crude
> fashion, so would not meet my personal goal of proving correctness.   But you 
> may be
> thinking of ON and OFF times in seconds, In which case an LED and maybe a 
> stop watch
> would be appropriate.
>
> Hopefully this gives you some ideas.
>
> Thank you,
>
> Worth Burruss
>
>
>
>
Did you mean to say ?  General purpose timer that is continuous
increasing can be configured to toggle the PWM output high when a
certain value reached and low when it overflows. I have referred this
from here (

Activating PWM via Timer Registers)

http://elinux.org/BeagleBoardPWM#OMAP_Mux_Configuration
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel