AtoMMC 2.0
See the final version atommmc2 i.c. K.v.Oss here
|
What's going on here then?
Let's see ... that's:
Acorn Atom Rev.4 with PL8 fitted + Microchip PIC 16f77 +
74ls00 + Custom firmware + DScaler 4.1.15 + Saleae Logic 1.0.21
An equation that = Joy.
Here's the trace of SPI activity whilst loading the above program from MMC.
Click for a larger view. Go on. I know you want to.
|
Click  : That'll be ~5k of Galaxians loading in ... ooh let me see now...
|
Oh yes. 0.3 seconds
|
The previous board
sat cuddled up to the VIA and all of the SPI communication was
performed by banging bits against one another. This board takes bytes at
a time, like a man. These are then passed on to the inboard SPI
hardware and the reply posted back.
Some PICs, like the one used here, have what's called a
parallel slave port. See the manual.
You access it like any other bus-based device. It has /EN, /OE and /WR
lines which directly control the state of one of its 8-bit data ports.
With no valid control signals present the chip sits happily processing
with the PS port data lines in a high impedance state. Enabling the chip
and clocking /WR will latch the data found on the port at that time.
Similarly asserting /OE with the chip enabled will take the port out of
high impedance state and present latched data to the bus. There are
separate latches for reading and writing. The reception and recovery of
data can cause an interrupt. Very handy. Having been an AVR freak
for a long time now since migrating away from PICs I'm starting to see
their appeal once more. There. Ah sayed it. I Love PICs. Again. I don't
know why I fell out of love with them, I suppose it was becasue they
felt rough and ready. AVRs were sexier. With better development tools. I
digress.
So with appropriate code written, and some
neat decoding logic
in place to translate the 6502's r/wr signal to separate /RD and /WR
signals away we go. Fortunately I'm a reasonable programmer and the
AtoMMC firmware that I wrote for the VIA interface was device
independent. After as long as it took to recompile and burn a new EPROM,
I had a new working driver for the new working hardware.
In all
the round-trip time from presenting a byte to the chip to receiving a
reply is as long as it takes to process the following 16 cycles:
;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~ ; ; spi transfer ; ; on entry ; A = byte to transmit ; ; on exit ; A = received byte, Y preserved, X trashed ; xferbyte: sta $b400 nop nop nop nop lda $b400 rts
Quite a big difference from the original code..
;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~ ; ; spi transfer ; ; on entry ; A = byte to transmit ; ; on exit ; A = received byte, Y preserved, X trashed ; xferbyte: stx XBTEMP sty XBTEMP+1
ldy #8
xb_xferbit: sta XBTEMP+2 ; ZP write .. faster than PHA
and #MOSI ; present data, CS is low ora #CLK ; bring clock high sta VIA
ldx VIA ; read data
eor #CLK ; bring clock low sta VIA
txa ; rx'd data into carry ror a
lda XBTEMP+2 rol a ; 7<-next bit, 0<-rx'd data
dey bne xb_xferbit
ldy XBTEMP+1 ldx XBTEMP rts
All this joy has happened relatively quickly since receiving my logic
analyser. I don't know how I coped without it. Having a window onto the
private world of your signals is more revealing than the televisual
programme 'Katie and Peter'. Speaking of feeling dirty I must admit that
I used to feel the idea of attaching a peripheral processor arguably
more powerful than the host computer to be anathema. However now I'm
over the initial revulsion I have to admit I quite like it. Again I
digress. So for a perfect example of how having an analyser helps, let's
look at the behaviour of the flip-flop that I programmed to change
whenever a SPI transfer completes:
|
You might be able to see it in the thumbnail here, but click for more
pixels. The top two signals are enable and write. Taking the falling
edge of the write line, when data is latched from the bus and passed to
the SPI hardware, we see that the third line, rdy, is flipped about 12
microseconds later indicating that data is ready for reading. The writes
occur at about 16 microsecond intervals. Remember the 16 clock code
earlier? Aah yes. That code was generating this trace. I could probably
drop a couple of NOPs to push things a little faster but I want a small
comfort zone. I could also use a faster SPI clock. I'll perhaps
experiment with that another time
Mmm. Katie and Peter. Dirty boy. Go to your basket.
Rapidly scribbled and then
Posted by Sir Morris
|
|