From: Jim Brain (brain_at_jbrain.com)
Date: 2004-11-03 15:31:47
You could have found it yourself sooner or later, so all I'm responsible
of (if at all) is probably giving some time advantage ;-))).
Ahh, humble to the end...
> I could think of 2 or 3 possible solutions; first, similarly to the
> C64, you could probably write a "cycle exact timing" routine (use an
> otherwise unused timer in the AVR, and for each interrupt services,
> first determine the 1,2 or 3 cycles extra delay of the executed IRQ
> routine, then spend 3,2 or 1 plus cycles respectively). The second:
> program the hw to do the task "itself"; IIRC the timer1 can be reset
> upon an external event, and can activate outputs upon a compare match.
> (Could possibly be tricky in overall, but...) 3.) Even if something is
> missing for the full hw operation, the timer is read/writeable, so
> previous values (ie. current time ;-) ) can be taken into account.
I'm not sure how you'd determine the "overflow" cycle count. The first
IRQ is the detection of the falling edge of the POT line. I tried the
latter approach, which would reduce jitter to 3 cycles, but wasn;t
having much luck. However, I looked at my code, and I'm essentially
doing the same thing, so I'll try it again.
> Yes, true. The SX' are also reasonably simpler anyway; AVRs are much
> better in all possible subjects, except for the SX' high cpu frequency.
I've been playing around with the SX52 here, and I've got dual 115200bps
UARTs running, but my is it painful for code for this after coding for
the AVR. Shame the AVR tops out at 16MHz or so.
Jim
--
Jim Brain, Brain Innovations
brain@jbrain.com http://www.jbrain.com
Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times!
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.