Searching \ for '[PIC] Using DiskOnChip with a PIC?' 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/microchip/devices.htm?key=pic
Search entire site for: 'Using DiskOnChip with a PIC?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Using DiskOnChip with a PIC?'
2006\09\17@165842 by Ariel Rocholl

picon face
Hi, I have some of these cheap FLASH devices, with TrueFFS (FAT) file system
drivers included. I see no easy way to reuse them in a way I connect them to
a PIC, because the TrueFFS driver is designed to talk with an OS. Does
anyone has experience in such a setup (PIC + DiskOnChip)?

--
Ariel Rocholl
Madrid, Spain

2006\09\17@224218 by John Chung

picon face
Do you have a link for the datasheet?

John

--- Ariel Rocholl <spam_OUTarochollTakeThisOuTspamgmail.com> wrote:

{Quote hidden}

> --

2006\09\18@031826 by Ariel Rocholl

picon face
All the technical info including datasheet, app notes, etc is here: *
http://tinyurl.com/krhhm*

2006/9/18, John Chung <.....kravnusKILLspamspam@spam@yahoo.com>:
{Quote hidden}

2006\09\18@042105 by Stef Mientki

flavicon
face
With an USB on the go chip, it shouldn't be too difficult I guess.
A few days ago a hack for the TI84 calculator (Z80) was presented,
and indeed it works like a charm.
see
cellphones.hackaday.com/2006/09/14/usb-flash-drive-on-a-ti84/
cheers,
Stef

Ariel Rocholl wrote:

>Hi, I have some of these cheap FLASH devices, with TrueFFS (FAT) file system
>drivers included. I see no easy way to reuse them in a way I connect them to
>a PIC, because the TrueFFS driver is designed to talk with an OS. Does
>anyone has experience in such a setup (PIC + DiskOnChip)?
>
>  
>

2006\09\18@101315 by Ariel Rocholl

picon face
But I thinking more on a solution to directly connect to the 8bit port data
of the DiskOnChip device to the PIC. On the DiskOnChip you have data port
and address port, plus a few control pins, so it is like a slow NV SRAM,
much cheaper, thus having to use an intermediate USB connection is
unnatractive. The problem I face is that you cannot access it like a SRAM
because the driver expects you to work with it like a FAT16 disk.


2006/9/18, Stef Mientki <.....S.MientkiKILLspamspam.....ru.nl>:
{Quote hidden}

> -

2006\09\18@115736 by John Chung

picon face
www.mpic3.com/downloads/
http://forum.microchip.com/tm.aspx?m=121184

Here are some samples on FAT16.  On the higher layer I
do not have a link.

Regards,
John

--- Ariel Rocholl <EraseMEarochollspam_OUTspamTakeThisOuTgmail.com> wrote:

{Quote hidden}

cellphones.hackaday.com/2006/09/14/usb-flash-drive-on-a-ti84/
{Quote hidden}

2006\09\18@125032 by Ariel Rocholl

picon face
Thanks, I found these nice links too but I guess some additional work will
be needed to adapt to DiskOnChip:
http://pic18fusb.online.fr/wiki/wikka.php?wakka=MsDrive

2006/9/18, John Chung <@spam@kravnusKILLspamspamyahoo.com>:
{Quote hidden}

>

2006\09\18@181509 by WH Tan

picon face
2006/9/18, Ariel Rocholl wrote:
> Hi, I have some of these cheap FLASH devices, with TrueFFS (FAT) file system
> drivers included. I see no easy way to reuse them in a way I connect them to
> a PIC, because the TrueFFS driver is designed to talk with an OS. Does
> anyone has experience in such a setup (PIC + DiskOnChip)?

Yeah!  It looks great at first glance.  But to have it works with a
PIC, seems like you will need their TrueFFS SDK.  Their website isn't
clear about this.  The only thing that I understand:  they provide the
TrueFFS driver in binary format for the suported OSes/platforms.  To
use it in OS-less platform (like PIC I suppose, or RTOS maybe) you
will need the SDK, which basically is source level of TrueFFS.  Their
website asks you to contact them.


--
WH Tan

2006\09\18@194538 by Ariel Rocholl

picon face
2006/9/19, WH Tan spamBeGonewhsiung.myspamBeGonespamgmail.com:
>
> To use it in OS-less platform (like PIC I suppose, or RTOS maybe) you
> will need the SDK, which basically is source level of TrueFFS.  Their
> website asks you to contact them.
>
>
yeah... I saw that... but I was praying to not have to deal with the SDK...
go figure a lot of work...


--
Ariel Rocholl
Madrid, Spain

2006\09\18@225656 by John Chung

picon face
Does your project need to use this chip? Can't you
change............ Customer demands?


John

--- Ariel Rocholl <TakeThisOuTarochollEraseMEspamspam_OUTgmail.com> wrote:

{Quote hidden}

> --

2006\09\19@091525 by WH Tan

flavicon
face

Ariel Rocholl wrote:

> yeah... I saw that... but I was praying to not have to deal with
> the SDK...
> go figure a lot of work...


I think the only good reason to do that is when using the SDK will eat up
too much of ROM/RAM space, then it makes sense to write your own!  However
in these circumstances, I would say that the SDK is still the starting
point. Study it and trim it down to meet your requirement, perhaps.

The only thing that I afraid is: you might face the difficulty in obtaining
the SDK.  The ways that they put the information there make me have some bad
impression - the impression that they don't care about you once they find
out that you're not doing kind of big-masssss-quantity-product.

Anyway give it a shot, try contact them.


Best regards,

WH Tan

2006\09\20@083943 by Alan B. Pearce

face picon face
>Here are some samples on FAT16.  On the higher layer I
>do not have a link.

The ultimate document on FAT file systems is on the Microsoft web site.
Search for fatgen103.pdf using google, and the resulting document will tell
you all you need to know, including psuedo-C code on how to deal with it.

2006\09\20@113127 by Tamas Rudnai

face picon face
Actually when you search on Microsoft website it do something for couple of
second, then it say there is 1 result, when you click on it you can't find
the PDF...

Do the same with Google, gives back the results few ms after pressed the
enter (used scope for measuring it :-) and the first entry is the right
doc...

Tamas


On 20/09/06, Alan B. Pearce <A.B.PearceEraseMEspam.....rl.ac.uk> wrote:
>
> >Here are some samples on FAT16.  On the higher layer I
> >do not have a link.
>
> The ultimate document on FAT file systems is on the Microsoft web site.
> Search for fatgen103.pdf using google, and the resulting document will
> tell
> you all you need to know, including psuedo-C code on how to deal with it.
>
> -

2006\09\20@115052 by Alan B. Pearce

face picon face
>Do the same with Google, gives back the results few ms after
>pressed the enter (used scope for measuring it :-) and the
>first entry is the right doc...

Yeah, I seem to recall going through that loop once before. I think
Microsoft have obfuscated the document within their system. But you will be
on the right track now. That document ahs a lot of info about the right and
wrong ways to play with FAT systems.

2006\09\26@191641 by Ariel Rocholl

picon face
I did contact them, will let you know how it goes, but I do have the same
<bad> impression about them sharing knowledge for a non-standard application
(according to their main market related to embedded OS) and low volumen
product.

2006/9/19, WH Tan <EraseMEtanwhspamnotes.src.global.sharp.co.jp>:
{Quote hidden}

> -

2006\09\26@191802 by Ariel Rocholl

picon face
This document is very interesting, at the very least to get a much better
knowledge of FAT system. It is really good in contents, and surprisingly not
the usual formal Microsoft style.

Thanks for the info.


2006/9/20, Alan B. Pearce <RemoveMEA.B.PearceEraseMEspamEraseMErl.ac.uk>:
>
> >Here are some samples on FAT16.  On the higher layer I
> >do not have a link.
>
> The ultimate document on FAT file systems is on the Microsoft web site.
> Search for fatgen103.pdf using google, and the resulting document will
> tell
> you all you need to know, including psuedo-C code on how to deal with it.
>
> -

2006\09\26@192102 by Ariel Rocholl

picon face
Sure, but it is really very cheap option to record huge NV data for a data
logger, and you can get the data saved in a filesystem format easy to
transport to a OS later... so it is a competitive advantage if I can get it
to work... but if not I can change to standard CF flash for instance, or NV
SRAM, etc.

2006/9/19, John Chung <RemoveMEkravnusspam_OUTspamKILLspamyahoo.com>:
{Quote hidden}

2006\09\27@161054 by Barry Gershenfeld

face picon face

>Sure, but it is really very cheap option to record huge NV data for a data
>logger, and you can get the data saved in a filesystem format easy to
>transport to a OS later... so it is a competitive advantage if I can get it
>to work... but if not I can change to standard CF flash for instance, or NV
>SRAM, etc.

One of the best-kept secrets in the industry (so I'm only sharin' with m'
friends :-) seems to be the "disk on module".  It is two chips on a card
with an IDE connector.  It is true IDE (works with linux, your BIOS, and
presumably, your PIC) and the wear leveling is built in.  We buy single
board computers with the DiskOnChip socket and every one of them goes out
the door with the socket empty.  That's how much I like the module.

For just storing data, a flash memory chip by itself isn't all that hard to
program.

Barry

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