Post by thread:[PIC] Using DiskOnChip with a PIC?

Do you have a link for the datasheet? John --- Ariel Rocholl <spam_OUTarochollTakeThisOuTgmail.com> wrote: {Quote hidden}> 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 > --

All the technical info including datasheet, app notes, etc is here: * http://tinyurl.com/krhhm* 2006/9/18, John Chung <.....kravnusKILLspam@spam@yahoo.com>: {Quote hidden}> > Do you have a link for the datasheet? > > John > > --- Ariel Rocholl <arochollKILLspamgmail.com> 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)? > > > > -- > > Ariel Rocholl > > Madrid, Spain > > --

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)? > > >

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.MientkiKILLspam.....ru.nl>: {Quote hidden}> > 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)? > > > > > > > > -

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_OUTTakeThisOuTgmail.com> wrote: {Quote hidden}> 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.Mientkispam_OUTru.nl>: > > > > 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/ {Quote hidden}> > 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)? > > > > > > > > > > > > > --

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@kravnusKILLspamyahoo.com>: {Quote hidden}> > http://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 <KILLspamarochollKILLspamgmail.com> wrote: > > > 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 <RemoveMES.MientkiTakeThisOuTru.nl>: > > > > > > 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/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/9/19, WH Tan spamBeGonewhsiung.myspamBeGonegmail.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

Does your project need to use this chip? Can't you change............ Customer demands? John --- Ariel Rocholl <TakeThisOuTarochollEraseMEspam_OUTgmail.com> wrote: {Quote hidden}> 2006/9/19, WH Tan RemoveMEwhsiung.myTakeThisOuTgmail.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 > --

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

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.PearceEraseME.....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. > > -

>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.

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 <EraseMEtanwhnotes.src.global.sharp.co.jp>: {Quote hidden}> > > 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 > > -

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.PearceEraseMEEraseMErl.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. > > -

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_OUTKILLspamyahoo.com>: {Quote hidden}> > Does your project need to use this chip? Can't you > change............ Customer demands? > > > John > > --- Ariel Rocholl <RemoveMEarochollTakeThisOuTspamgmail.com> wrote: > > > 2006/9/19, WH Tan EraseMEwhsiung.myspamspamBeGonegmail.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 > > --

>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