[Top][All Lists]
[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
> >
> >
> >
>