Searching \ for 'Interfacing to MMC' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=interfacing+mmc
Search entire site for: 'Interfacing to MMC'.

Truncated match.
PICList Thread
'Interfacing to MMC'
1998\12\17@193355 by Dave Celsnak

picon face
Hello,
Does anyone have experience interfacing a PIC to a Multi Media Card from
SanDisk?

I am very interested in using a 4meg Flash memory card from them.

Thanks,
Dave Celsnak
spam_OUTdaveTakeThisOuTspamteamrip.com

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

1998\12\20@111759 by Peter L. Peres

picon face
On Thu, 17 Dec 1998, Dave Celsnak wrote:

> Hello,
> Does anyone have experience interfacing a PIC to a Multi Media Card from
> SanDisk?
>
> I am very interested in using a 4meg Flash memory card from them.

The SanDisk MMCs as used with digital cameras etc, have an almost 100% IDE
compatible interface, with a special micro-miniature connector. afaik they
are not hot pluggable (or rather, require support in the host for
hot-plugging).

They require about the same number of connections for driving, as an IDE
interface, which means a lot of PIC IO pins. imho using a 82C55A for this
is a good idea (or some serial expander to spare PIC pins).

There are also SanDisks with PCMCIA II connection but I've never seen one.

hope this helps,

Peter

1998\12\20@150040 by Harold M Hallikainen

picon face
>On Thu, 17 Dec 1998, Dave Celsnak wrote:
>
>> Hello,
>> Does anyone have experience interfacing a PIC to a Multi Media Card
>from
>> SanDisk?
>>
>> I am very interested in using a 4meg Flash memory card from them.
>


       Which gets me thinking (always dangerous!)...  In my last post, I
commented on my plans to add a 128 Kbyte RAM chip to a product to hold
user data.  Now, the user would, of course, like to safeguard that data
by having SOME sort of removable storage.  Removable memory cards are
expensive (compared to a floppy disk), and may not be a whole lot easier
to interface to.
       There was some previous discussion on the list about interfacing a PIC
to a floppy drive.  At the time I thought that was stupid!  Who would
want to use a floppy to save the contents of 200 or so bytes of RAM in a
PIC.  Now, of course, with 128 Kbytes of external RAM, I DO see some
value in external storage, and the floppy is looking nice.  The disks are
incredibly cheap; the drives are incredibly cheap.  All we need is a
version of DOS on a PIC so you can dedicate a PIC to driving the floppy,
then talk to that PIC through its serial port.  Anyone done ANYTHING like
this?
       About 15 years ago I designed a 6800 based product where I needed
external storage.  The first units used good old audio tape.  I then
wrote code to talk with Commodore (as one of my students pronounced it:
Commode Door) disk drives.  Those were kinda neat since they had the
operating system built in.  You just had to figure out how to talk thru
their serial bus.  I did that and sold a ton (a small ton) of products
that are still using the Commodore drive.  Something like that with the
PIC would be pretty neat.
       It would be CHEAP code you could drop into a PIC to make it a serially
controlled disk drive controller chip that writes IBM format on 3.5 inch
disks.  Anyone written that?


Harold


___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]

1998\12\20@165837 by Mark Willis

flavicon
face
Harold M Hallikainen wrote:
{Quote hidden}

 I'm thinking of making a solid state floppy drive, with something like
an Atmel AT45D081 (8 megabit i.e. 1 Megabyte) flash disk, and an
AT45D041, so I can bring up a computer without an actual floppy disk
drive.  (I have BAD luck with floppy disk drives, they seem to go bad
often enough that it's a constant problem for me.)  [Also there is no
way for a virus to write itself on there, that's a thought too!  <G>]
Simulate multiple floppies on one Flash bank with a rotary switch,
perhaps.  Haven't started that yet, doing other things first.

 These Atmel chips are paged, pretty tiny (SOIC-28 etc.), fairly
inexpensive (~$10 for the 1 MByte chip), fast (10 MHz data clock),
7-wires total (Including Vcc etc.), and run off 5 Volts (There are 3.3V
versions.)  The newest product in this line is the AT45D161 (2 MByte)
chip, same packaging.  You could easily just simulate a 720k floppy disk
off one AT45D081, with spare room <G>  There is a pair of page-size
buffers, 264 {or 528 for the D081} bytes each, in these; you can use one
or both as scratch data space or use one or both for I/O to the flash
RAM.  Use the extra bits for ECC or the like.

 Could stick a couple of these on a PC board, add 5 SMD Zeners or
protective diode bridges as needed, solder the PCB to a DE-9 connector,
pot it all inside a shell, and make a pretty small secure data holding
device that could be carried away at will.

 Using the 24LC256,  you would have to use quite a few 32k devices for
a floppy sized device (45 or 46!);  The same DE-9 connector idea should
work readily for 128k, you'd just need 4 SOIC-8's on a PC board.

 Mark, .....mwillisKILLspamspam@spam@nwlink.com, hoping a 24LC2048 is coming out soon <G>

1998\12\21@014107 by Russell McMahon

picon face
25 years ago (!) or so we played with the SWTP Motorola 6800 based
systems and similar and did quite a lot of work on the low level
floppy control software - not very hard once you get into it. We used
the 1771 floppy disk controller and with it the speed of the 6800 was
adequate. While you may be able to do the whole thing sans controller
(a Scenix would help :-)) you would certainly need a certain amount
of analog interface cctry. I think that using a modern floppy
controller IC would GREATLY reduce the effort. The 1771 is long long
dead but I assume that the single chip solutions I see on modern I/O
cards have the same basic interface and abilities plus, probably, a
sector buffer. If so the PIC would not be speed constrained at all
but would still need a (probably) 8  or 16 bit interface. A floppy
drive presently costs about $NZ30 (?$US15?) and stores 1.44MB (more
in non-std formats) and apart from the nasty 12v/5v supply needs (but
only while working) would be a nice solution in many applications.

AFAIR the hardest problem with the 6800's was writing a track while
formatting as this had to be done on the fly at full diskette data
speed. The track image was written into RAM and read out in real
time. A small PIC would not have enough memory for this approach.


regards

           Russell McMahon

From: Harold M Hallikainen <haroldhallikainenspamKILLspamJUNO.COM>
>        There was some previous discussion on the list about
interfacing a PIC
>to a floppy drive.  At the time I thought that was stupid!  Who
would
>want to use a floppy to save the contents of 200 or so bytes of RAM
in a
>PIC.  Now, of course, with 128 Kbytes of external RAM, I DO see some
>value in external storage, and the floppy is looking nice.  The
disks are
>incredibly cheap; the drives are incredibly cheap.  All we need is a
>version of DOS on a PIC so you can dedicate a PIC to driving the
floppy,
>then talk to that PIC through its serial port.  Anyone done ANYTHING
like
>this?
>        About 15 years ago I designed a 6800 based product where I
needed
>external storage.  The first units used good old audio tape.  I then
>wrote code to talk with Commodore (as one of my students pronounced
it:
>Commode Door) disk drives.  Those were kinda neat since they had the
>operating system built in.  You just had to figure out how to talk
thru
>their serial bus.  I did that and sold a ton (a small ton) of
products
>that are still using the Commodore drive.  Something like that with
the
>PIC would be pretty neat.
>        It would be CHEAP code you could drop into a PIC to make it
a serially
>controlled disk drive controller chip that writes IBM format on 3.5
inch
>disks.  Anyone written that?

1998\12\21@030656 by brad

flavicon
face
Russell McMahon wrote:
>
> 25 years ago (!) or so we played with the SWTP Motorola 6800 based
> systems and similar and did quite a lot of work on the low level
>> AFAIR the hardest problem with the 6800's was writing a track while
> formatting as this had to be done on the fly at full diskette data
> speed. The track image was written into RAM and read out in real
> time. A small PIC would not have enough memory for this approach.
>
>
Look at the old Apple ][ DOS. System. Used NO Dedicated floppy
controller
All decoding was done in S/W from memory, on a 1mhz 6502. Pretty nifty
for
the time. It was also SOFT sectored, so used any disk you cared to name.
Unlike the old PC which had to use hard sectored disks.
>From memory, the apple never buffered more than 1 sector at a time
either. (256 bytes)
When I get my old apple back, I'll disasemble some  DOS code and have a
look.

--
-----------------------------------
Brad Campbell
Technical Manager

Seme Electrical Engineering Co
59 Collingwood St Osborne Park 6017
Western Australia
Ph    :-+61 8 9445 2577
Fax   :-+61 8 9244 1327
Email :- .....bradKILLspamspam.....seme.com.au

 /"\
 \ /
  X  ASCII RIBBON CAMPAIGN
 / \ AGAINST HTML MAIL

1998\12\21@050156 by paulb

flavicon
face
Russell McMahon wrote:

> AFAIR the hardest problem with the 6800's was writing a track while
> formatting as this had to be done on the fly at full diskette data
> speed.  The track image was written into RAM and read out in real
> time.  A small PIC would not have enough memory for this approach.

 I really wouldn't worry about it.  As long as you accept IBM 1.44M
format, you nowadays buy them pre-formatted, so it isn't a concern.  It
is in fact quite difficult to buy them *un*-formatted.  And PCs are
ready to hand in any case.

 Of course you use a modern integrated FDC chip (which AFAIK are still
8-bit data) which supports this format.
--
 Cheers,
       Paul B.

1998\12\21@061345 by wwl

picon face
On Mon, 21 Dec 1998 14:05:17 +1300, you wrote:

>25 years ago (!) or so we played with the SWTP Motorola 6800 based
>systems and similar and did quite a lot of work on the low level
>floppy control software - not very hard once you get into it. We used
>the 1771 floppy disk controller and with it the speed of the 6800 was
>adequate. While you may be able to do the whole thing sans controller
>(a Scenix would help :-)) you would certainly need a certain amount
>of analog interface cctry. I think that using a modern floppy
>controller IC would GREATLY reduce the effort. The 1771 is long long
>dead but I assume that the single chip solutions I see on modern I/O
>cards have the same basic interface and abilities plus, probably, a
>sector buffer. If so the PIC would not be speed constrained at all
>but would still need a (probably) 8  or 16 bit interface. A floppy
>drive presently costs about $NZ30 (?$US15?) and stores 1.44MB (more
>in non-std formats) and apart from the nasty 12v/5v supply needs (but
>only while working) would be a nice solution in many applications.
>
>AFAIR the hardest problem with the 6800's was writing a track while
>formatting as this had to be done on the fly at full diskette data
>speed. The track image was written into RAM and read out in real
>time. A small PIC would not have enough memory for this approach.
But as most of the track data is predictable & fixed, a PIC is
probably fast enough to generate it in real-time, inserting the
appropriate values into the sector headers.

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...