From: Hársfalvi Levente (hlpublic_at_freestart.hu)
Date: 2004-11-03 14:23:28
Hi!,
> It is, if that is ALL you are doing, or if you can accomplish what you
> need in the 256 "wait" cycles, but that's not always possible.
Yep, this bit-banging method is cycle-consuming a little, and it's also
tricky to fit with other tasks (as long as they're also timing-critical).
> As an update, I decided to try this. Instead of having both sides of the interface handles by different timer IRQs, I combined them, as the transfer of 1 byte of data from the originating system is clocks by a 20uS clock, which is 160uS/byte. Thus, when I see the falling edge, I transfer a byte. The transfer and the parse of the incoming byte is taken care of before the charge cycle starts, so the jitter I was seeing went completely away.
:-)
> I forgot to thank Levente for the idea. Very good idea.
You could have found it yourself sooner or later, so all I'm responsible
of (if at all) is probably giving some time advantage ;-))).
> I am familiarizing myself with this new scope I bought, and I was able to zoom in on the leading edges of the waveform. I noticed a 300nS jitter in catching the SID clamping action, and I noticed a 700nS jitter in the compare match (when the line goes high). Since my trigger code is deterministic (the first thing done in the ISR is to bring the line low), I can only assume that if the AVR is fetching a jmp or branch instruction when the IRQ happens, the CPU completes all opcodes in the pipeline before servicing the IRQ. I think the AVR has a 4 stage pipeline, so that would explain the 3 cycle jitter, and then the 7 cycle jitter at the match point would be the accumulation of 2 such events. I have no other interrupts happening in this code (now that I synchronized the reading of data and the emulation of the POT line).
Yes, probably something like this. Although I never experimented with
this part of the AVR, I think the AVR's opcodes are "true" 1,2,...x
cycle opcodes (unlike the PIC, where even "2 cycle" opcodes are
effectively executed as 2 separate instructions). Thus, similarly to the
65xx and other processors, interrupt servicing is not "cycle exact" on
the AVR.
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.
> In any event, I think possible uses for this code will cope fine with the error margin, and I have no desire to rewrite for the SX just to get rid of it. The SX is not offered in as small a package, I'd need a resonator for the SX to get the high speeds, and something about using a 50MHz CPU to power the joystick port just seems wrong.
Yes, true. The SX' are also reasonably simpler anyway; AVRs are much
better in all possible subjects, except for the SX' high cpu frequency.
Best regards!,
L.
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.