Please navigate to http://forum.4dsystems.com.au

This forum is READ ONLY and is DISABLED, please use the new forum

PLEASE do not attempt to change your details. Email webmaster@4dsystems.com.au if you are having problems with the new forum

For all Tech Support, please use the Support Ticket System, from our website. http://www.4dsystems.com.au/support

Latest Topics

Author Comment

Registered: 21/12/07
Posts: 6

I recently purchased a uOLED-96-G1 and so far I have been very impressed with the screen quality.

The question I have relates to the uSD card slot. I realize that Graphics Composer starts writing to sector 0x0 and the OLED as a whole does not use a file system.

Would a file system such as FAT break the commands that the GOLDELOX processor uses for its ability to access programs and graphical objects stored on the uSD card?

If not, what would be the best way to go about implementing the file system? I'm not so much asking how to put FAT on an uSD card (I've found some good sites on this), but I would like to know if there is another way to retrieve data besides the serial commands detailed in the uOLED-96-G1 User's Manual. I know serial access isn't the speediest protocol out there, but that seems to be the only option, and I'll take anything I can get.



Registered: 19/11/07
Posts: 136
To my understanding (and it's not absolute) SD cards always access data serially, by virtue of the way the work. (remember Bubble memory?)

Some of the higher capacity cards access multiple bits serially simultaneously, i.e. 2 bits at a time / 4 bits at a time.

So accessing them serially is in fact the only way to access them.

If you were to put FAT on the card Sector 0 would become the boot sector, followed by the FAT(s), followed by the root directory, followed by Data and non-root directories. If you knew where the data was that was exactly (i.e. wich sector, And assuming the files were contiguous) you should be able to access them.

The question is WHY. After all the trouble you would have to goto to translate the FAT location into the Sector location (and retranslate every time you change the file and ensure that all files are contiguous) why would you want to do this?

Registered: 21/12/07
Posts: 6
Thanks for the reply.

I'm attempting to build a portable device that has a screen, flash memory, and a microcontroller. One of my personal milestones for this device is to be able to use it as a generic USB mass storage device. The biggest factor in choosing parts for it is size, so I was inclined to buy the uOLED-96-G1 so that I might be able to save space by using the built in uSD card slot.

Ignoring the other difficulties that I can offload to the microcontroller (USB mass storage support, enumeration, etc), the problem still boils down to being able to access the uSD card and putting a well supported file system on it like FAT so that the storage would be available to computers while still being usable by the OLED graphics processor.

Although I'm going to need a separate microcontroller no matter what due to the other ideas I have for this project, perhaps it might have been a better idea to purchase the uOLED-96-PROP to handle something like this?

Registered: 19/11/07
Posts: 136
Would partitioning the uSD card be an answer? (i.e. one FAT partition, one 'Other' Partition for OLED graphics use)

I doubt whether it is supported 'now' but it maybe the quickest way so "the storage would be available to computers while still being usable by the OLED graphics processor".

I'm thinking to implement FAT in a microcontroller is not particularly productive, maybe another 'Simpler' file system would be an idea, although not many 'simpler' file systems support the relatively huge capacity of uSD cards.

I'm still not sure why 2 uSD cards wouldn't be better, is the capacity that expensive?

Registered: 15/08/07
Posts: 7
I think the PROP is the way to go for what you're trying to do.  I need to do something similar with data logging to FAT.  I've only had my Prop a week and am very impressed so far with such an open and powerful platform in such a neat little package. 

I'm curious why you'd need an extra processor (pin count is one obvious reason, is there another?)



Registered: 21/12/07
Posts: 6

Please keep me posted on your efforts with the file system, I'd love to hear about your progress. Is there existing spin code out there to support FAT16/32?

The reason for a separate microcontroller is primarily due to pin count, but also because of my inexperience with the Propeller chip. I'd rather use my experience with C and the multitude of online resources for AVR than rely on a newcomer into the microcontroller world with a custom language.

However, I am really interested in the Propeller, and I think it has a lot of potential, and if this wasn't my first real project with a microcontroller I'd definitely give it a shot.
Previous Topic | Next Topic

Quick Navigation:

Powered by Website Toolbox - Create a Website Forum Hosting or Website Chat Room Hosting for your website.