On 7 Sep 2010 at 16:23, Philip Pemberton wrote:
In that case, as long as you start the timer at zero
and record when
it wraps, there should be no (significant) problem. You'll need to
keep track of last_counter_value modulo max_counter_value and subtract
that from each timer value, but it should work. Just a little more
effort in the 'decode to delta' stage.
The ARM allows for byte access, so you simply set the counter to zero
at the beginning of the sample sequence and store the low order 8
bits. You could keep the "last value" around in a register and
calculate and store the delta as part of the process and have cycles
to burn.
I found that an AVR Mega128 was more than up to the job of sampling
250Kpbs and 500kbps media at 16MHz, using the capture mode with a
timer run at 16MHz. The only place I used actual interrupt servicing
routines was for basic event timing (i.e. seek and head settle) and
index detection. The sample loop simply polled the "capture
complete" status. Rather than use Jens' high-order bit index status
in the sample output, I noted the leading edge of each index with a
00 sample--my own experience told me that the falling edge of index
could vary wildly from drive maker to drive maker.
The result worked amazingly well on the few samples I tossed at it,
but I didn't pose any "tough cases" to see how aliasing affected
recovery. I never investigated if it was good enough for writing,
however.
What I'm investingating currently is if a NXP ARM "thumb" uC can not
only sample but decode on the fly, at least to the extent of
recognizing sector ID headers, so that sector-mode operation is
possible, rather than track at a time.
Does your DF have that capability?
Neat. Seems a lot of modern "all-in-one"
style Super I/O controllers
have really poor data separators and precomp engines though. I've
never found a PC controller that could even read BBC Micro floppies
(250kbps FM 5.25in) without complaining.
I'd have to go back to my samples, but something is itching in the
back of my skull that the Beeb floppies weren't strictly 3740-
conforming. Oddball DAM or IDAM maybe?
--Chuck