| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Configure the timer capture pin to input mode in the timer control
register, in addition to configuring it as input with the pinmux driver.
There was a control register bit commented as "no desc in datasheet". A
later revision of the manual reveals the bit to be an input/output control
for the timer pin. In addition to configuring capture or pulse mode, you
apparently have to separately configure the pin direction in the timer
control register.
Before this change, the timer block was apparently driving a signal onto a
pad configured by pinmux as input. Capture mode still accidentally worked
for me during testing because I was using a very strong signal source that
just out-muscled the weaker drive from the misconfigured pin.
|
|
|
redoing it as a separate driver. Now that each hardware timer is handled by
a separate instance of the timer driver, it no longer makes sense to bundle
the pps driver with the regular timecounter code. (When all 8 timers were
handled by one driver there was no choice about this.)
Split the hardware register definitions out to their own file, so that the
new pps driver (coming in a separate commit later) can share them.
With the PPS driver gone, the question of which hardware timer to use for
what purpose becomes much easier (some instances can't do the PPS capture).
Now we can just hardcore timer2 for eventtimer and timer3 for timecounter.
This also now only instantiates devices for the 2 hardware timers actually
used to implement eventtimer and timecounter. This is required so that
other drivers can come along and attach to other hardware timers to provide
other functionality. (In addition to PPS, this hardware can also do PWM
stuff, general pulse width and frequency measurements, etc. Maybe some
day we'll have drivers for those things.)
|
