PL8 AVR version.
Phill Harvey-Smith
I've just successfully implemented an AVR driven version of the PL8
interface, again using 2 chips as Charlie's PIC interface does. Though
in this case as well as the AVR I have an XC9572 CPLD to act as a buffer
and latches between the Atom and the AVR, this makes up for the lack of
the paralell interface port on the PIC.
When the Atom writes to the buffer the AVR gets an interupt, reads the
buffer, does an SPI transfer and sends the result back to the Atom.
The CPLD could also generate an IRQ on the Atom when the AVR writes, but
the current AtoMMC firmware does not support this (yet) so it's not
implemented, I see nothing in the list file that would stop this working
tho.
There is a picture here :-
http://protein.bio.warwick.ac.uk/~phillhs/Atom/AtomMMC-AVR.JPG
Note the LS chips to the right of the SD card and all the resistors/caps
at the bottom are just parked there and have nothing to do with the
interface !
Why do this ? Well the Atom clone alreadh has an AVR that is used for
it's keyboard interface which has enough unused lines to also act as an
MMC controler, so rather than add 2 chips, plus have yet another type of
programable chip (PIC), I wanted to see if I could do this with the
already existing AVR, which it seems I can.
I've currently made it compatible with Charlie's PIC, so it works with
the recently uploaded 3.0, and is *MUCH* faster than the bitbanged
interface on a 1MHz machine.
Cheers.
Phill.
--
Phill Harvey-Smith, Programmer, Hardware hacker, and general eccentric !
"You can twist perceptions, but reality won't budge" -- Rush.
Sir Morris
That is BOSTIN!
One question though - won't using interrupts slow the whole thing
down? There'd be a big old overhead plus all the extra logic to handle
the protocol.. Better to have a longer operation on the copro side and
have a single interrupt to signal its end than have one per byte
transferred. Though thinking about it I suppose that it does away with
any hardware differences there may be between different solutions.
Are you going to make up a board? If so we'll need to talk $ - Jason
at the centre for computing history was interested in getting his
hands on a couple. I'd like one too :)
Phill Harvey-Smith
> You win :)
>
> That is BOSTIN!
>
> One question though - won't using interrupts slow the whole thing
> down? There'd be a big old overhead plus all the extra logic to handle
> the protocol.. Better to have a longer operation on the copro side and
> have a single interrupt to signal its end than have one per byte
> transferred. Though thinking about it I suppose that it does away with
> any hardware differences there may be between different solutions.
Well the AVR (will be) also handling the PS/2 keyboard interface, which
itself is inturrupt driven, also the AVR can be clocked at up to 20MHz,
which should make response time fast enough.
Cirtainly in my tests with it clocked at 8MHz, it seemed to work
perfectly with the 3.0 version of AtoMMC.
It's a real shame that the 6502 doesn't have an instruction like the
6809's sync where you could mask the IRQ/FIRQ inturrupts, then do a sync
which would make the processor wait for the inturrupt, but withough
jumping to it's vector, so you can use it to create very tight IO loops.
> Are you going to make up a board? If so we'll need to talk $ - Jason
> at the centre for computing history was interested in getting his
> hands on a couple. I'd like one too :)
Wellll..... initally it'll be for the clone, though I dare say that a
version for a genuine Atom would be easy enough to knock together, I'll
have a look once the verion for the clone is working correctly.
Charlie Robson
There is a weird thing happening consistently no matter how I play with the initialisation procedure, commands sent or timing. Bizarrely the symptoms _exactly_ match those described here:
http://www.electro-tech-online.com/archive/index.php/t-29648.html
The answer was given as:
"I then ripped out the voltage regulator I was using and powered the card directly from my bench power supply set at 3.3v, and now everything seems to be working."
Now I thought that I'd used a rubbish regulator which only delivered 30ma though on closer inspection (when I went to fix it) I'd used a l78l33 which can chuck out 100ma.. So I'm stumped :(
I wonder if a cap or 2 on the mmc supply might help? And if so what kind of things should I take into account when selecting one? The card clock frequency? Or should I try another reg - this was a second-hand one - or use a different type? 1.5A anyone?!
Thanks
C
Celebrate a decade of Messenger with free winks, emoticons, display pics, and more. Get Them Now
Phill Harvey-Smith
> My pl8 board is (still) failing :¬(
>
> There is a weird thing happening consistently no matter how I play
> with the initialisation procedure, commands sent or timing. Bizarrely
> the symptoms _exactly_ match those described here:
>
> http://www.electro-tech-online.com/archive/index.php/t-29648.html
>
> The answer was given as:
>
> "I then ripped out the voltage regulator I was using and powered the
> card directly from my bench power supply set at 3.3v, and now
> everything seems to be working."
>
> Now I thought that I'd used a rubbish regulator which only delivered
> 30ma though on closer inspection (when I went to fix it) I'd used a
> l78l33 which can chuck out 100ma.. So I'm stumped :(
Do you have a schematic of your circuit ? Might help determine the
cause of the problem
> I wonder if a cap or 2 on the mmc supply might help? And if so what
> kind of things should I take into account when selecting one? The
> card clock frequency? Or should I try another reg - this was a
> second-hand one - or use a different type? 1.5A anyone?!
What does the data sheet for the regulator recommend, normally they need
a cap at least between the output line and ground, as I believe without
this the reg can oscilate causing unpridictable results.
Charlie Robson
No schematic I'm afraid, it was wired as I thought of it :)
There is an 8mb archive of close-up pix though - pl8.zip in the files
section.
There's one with a few relevant pads identified, it's fairly straightforward
though. The reg is a l78l33. The data sheet says no external components
required, and I've used the part on nearly all my boards now without
trouble. All that copper though,.. I think I can hear radio luxemburg LOL.
I'll try out some cappage and see what happens.
Ta
C
Phill Harvey-Smith
> Hiya,
>
> No schematic I'm afraid, it was wired as I thought of it :)
>
> There is an 8mb archive of close-up pix though - pl8.zip in the files
> section.
Got it !
> There's one with a few relevant pads identified, it's fairly straightforward
> though. The reg is a l78l33. The data sheet says no external components
> required, and I've used the part on nearly all my boards now without
> trouble. All that copper though,.. I think I can hear radio luxemburg LOL.
>
> I'll try out some cappage and see what happens.
Couple of things strike me, having a quick look.
1) Does the PIC need bypass caps ? generally IIRC you should have 1 for
every set of power pins a chip has.
2) The wires between the PIC and the MMC seem a little long I've
generally tried to minimise the wire lenngth on the SPI signals,
especially as it's operating at a lower voltage, so would be more prone
to interference.
The other thing that might help here is some small resistors in series
to try and help stop signal reflections.
Does your logic probe know how to interpret SPI ? could be worth probing
it to see if it seems valid.
Charlie Robson
> every set of power pins a chip has.
They are hidden underneath the chip in the well formed by the socket, as are
the crystal caps.
> 2) The wires between the PIC and the MMC seem a little long I've
> generally tried to minimise the wire lenngth on the SPI signals,
> especially as it's operating at a lower voltage, so would be more prone
> to interference.
Yeah, I've actually shortened it and I'll be removing the fly lead
altogether if the caps don't fit ;)
> The other thing that might help here is some small resistors in series
> to try and help stop signal reflections.
OK, by small do you mean 50r, 100r, 1k?
> Does your logic probe know how to interpret SPI ? could be worth probing
> it to see if it seems valid.
Yep, the signal is valid until it returns FC for the data start token. It's
as if 7 clocks have been lost and the data has arrived a bit early. Very
weird.
I'm just doing some probing now.
C
Charlie Robson
wrong data token, but the init sequence is much smoother, it usually took
more tries to go idle. The trace shows the MOSI line going low in between
bytes. I don't know if this is a problem but I've always held mosi high when
writing software spi code.. I'll try pulling it up and see what happens.
(Trace)
Time [s],MOSI,MISO
0.0004740,0x40,0xff ; cmd0 - go idle
0.0005037,0x00,0xff
0.0005333,0x00,0xff
0.0005629,0x00,0xff
0.0005925,0x00,0xff
0.0006217,0x95,0xff
0.0006509,0xff,0xff
0.0006801,0xff,0x01 ; returns 1 - gone idle
0.0007727,0x41,0xff ; cmd1 - reset card ready for action
0.0008023,0x00,0xff
0.0008319,0x00,0xff
0.0008615,0x00,0xff
0.0008911,0x00,0xff
0.0009203,0x95,0xff
0.0009495,0xff,0xff
0.0009787,0xff,0x01 ; failed - card is still idle
0.0010405,0x41,0xff ; cmd1 - retry
0.0010701,0x00,0xff
0.0010997,0x00,0xff
0.0011293,0x00,0xff
0.0011589,0x00,0xff
0.0011881,0x95,0xff
0.0012173,0xff,0xff
0.0012465,0xff,0x00 ; succeeded - card is reset and ready for commands
0.0013075,0x51,0xff ; read sector
0.0013372,0x00,0xff
0.0013668,0x00,0xff
0.0013960,0x40,0xff
0.0014255,0x00,0xff
0.0014548,0x95,0xff
0.0014840,0xff,0xff
0.0015132,0xff,0xff
0.0015430,0xff,0x00 ; command accepted, now wait for data token
0.0015730,0xff,0xff
0.0016030,0xff,0xff
0.0016330,0xff,0xff
0.0016630,0xff,0xff
0.0016930,0xff,0xff
0.0017230,0xff,0xff
0.0017530,0xff,0xff
0.0017830,0xff,0xfd ; WRONG! should be FE. the 0 bit has arrived one clock
too soon
0.0018130,0xff,0x93 ; blah...
0.0018430,0xff,0x80
0.0018730,0xff,0x08
0.0019030,0xff,0x20
0.0019330,0xff,0x0e
0.0019630,0xff,0x12
0.0019930,0xff,0x0c
0.0020230,0xff,0x40
0.0020530,0xff,0x00
0.0020830,0xff,0x00
0.0021130,0xff,0x00
Charlie Robson
Corrected. I've put a schematic up in the files section, there may be bugs
in it - I haven't tried to board it up yet...
pl8.sch - made with eagle 5.6.0.
C
KC
protocol but can I use SD-cards with your interface or is there a
difference between the hardware (pin layout) and software (access
protocol) of MMC and SD cards?
KC
Charlie Robson
> (access protocol) of MMC and SD cards?
They are both pin and protocol compatible in SPI mode. There are protocol
enhancements that may be used for SD cards but in practical terms they may
be treated identically.
The SD2IEC project illustrates this (it's c++ but you should be able to read
it - after all a function is a function :)
http://sd2iec.de/sd2iec-0.8.1a.zip
-Charlie
af...@aurigae.demon.co.uk
Welll... allowing for the fact that my PL8 interface is different from
Charlie's (AVR instead of PIC), I have had no problems using an SD
card, as they where designed to be backwardly compatible, and most
will indeed work in SPI mode.
The old bit-banged 6522 interface also worked fine with the SD cards I
threw at it too.
You may have a problem with micro/mini SD as I believe on one of them
the SPI was an optional thing that may or may not be implemented by
the manufacturer.
Cheers.
Phill.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
KC
SDDOS project!
KC