simulavr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Simulavr-devel] Re: Output Compare registers.


From: Keith Gudger
Subject: [Simulavr-devel] Re: Output Compare registers.
Date: Fri, 12 Mar 2004 14:48:49 -0800 (PST)

Ted:

Yes, I knew that's what you had in mind.  However, to get things up and
running quickly (and incorporate all of the changes needed to do that), I
left things in their separated Vdevs state.  It might even make sense for
the OCRegs in the Timers, as they are a resource several timers might
have.  Anyway, what I've submitted is split up.  I don't need the OCRegs
for the forseeable future, so I'll probably just stop where I am.

Keith

On Fri, 12 Mar 2004, Theodore A. Roth wrote:

> 
> 
> On Fri, 12 Mar 2004, Keith Gudger wrote:
> 
> > Ted:
> >
> > Here is what's going on with the Output Compare Registers.  It will also
> > affect Input Capture registers, whenever that code exists.
> >
> > The Timer16 structure has the following members:
> >     OCReg16_T *ocra;            /* Output compare registers */
> >     OCReg16_T *ocrb;            /* Output compare registers */
> >     OCReg16_T *ocrc;            /* Output compare registers */
> >
> > These pointers are used by the Timer16 clock routine to decide when to set
> > the OCRx interrupt flags in the TIFR register.  This register was passed
> > to the timerxx_create() functions in the .related field.
> >
> > The OCReg's get created before the Timers (because their addresses are
> > smaller) by calling ocreg16_create.
> 
> I think my plan here was to combine all the registers for a given timer
> into a single vdev. Then you just use the timer16_create() at the
> address of the first register involved and all the other registers just
> reference the first.
> 
> That should simplify things greatly.
> 
> The create function gets passed the name of the register, so it can use
> that to map the register into the correct field of a single vdev
> structure for the timer.
> 
> Does that make sense to you? I have a feeling I never let you know that
> was what I was planning to do.
> 
> I am busy until after dinner tonight and then I'll look over what you've
> done in more detail.
> 
> Thanks.
> 
> Ted Roth
> 
> >
> > Currently the pointers above *do not* get filled with the proper value.
> > As far as I can see, they never were.  That means the clock callback can't
> > find them and the interrupts can't get set.
> >
> > With the current order in the 43usb3xx.h files, there are no fields left
> > to pass the OCReg addresses to the timerxx_creates (and there would need
> > to be at least 3 fields).  Here is one suggestion on how to do this:
> >
> > 1.  Timer creates come first in the file.
> > 2.  OCReg creates use .related to point to the associated timer.
> > 3.  OCReg create finds the Timer with avr_core_get_vdev_by_addr(), and
> > installs a pointer to itself in the appropriate place.
> >
> > Problems with this include that the OCReg create might not know which one
> > it is (a,b,c?) and that the OCReg creates come out of numerical sequence.
> >
> > All of this code is in the timers.h/c that I started with, so you don't
> > need to look at the updated code to find this.
> >
> > Suggestions?  Or is my rambling unintelligible?  Would you prefer that the
> > .data field passed to the timerxx_create be an array with OCReg info in it
> > (as another way to do this)?
> >
> > Keith
> >
> >
> >
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]