Hi All
I tried but didn't manage to get
all ready for 3.1.2010.
However versions for
SAM7X,
AVR32 and Freescale
M522XX have been made available (see the specific processor forums for an overview of the versions).
Luminary
LM3Sxxxx, NXP
LPC2xxx and
STR91XF have been tested (on at least one development board) but the new packages could not be released on the same day due to the extra work to make and test the packages. These will follow - in the order above - and should all be available before the end of the week.
The user's guide is also being developed in parallel and is probably about 65% complete at the time of writing. It should already be useful for first tests with the new features and can be found here:
http://www.utasker.com/docs/uTasker/uTasker_utFAT.PDFThis is the present state of the new module's development:
- first of all beware that this a new development and has been release very early due to various requests to start using it as Beta. So it is Beta - it has not been tested outside of a warm laboratory environment and also has a few feature that are not yet fully complete. I am however convinced that its development is fairly advanced and it should already start being useful; at the same time its weaknesses can start being identified with more intensive use.
- today the SAM7X and AVR32 releases were tested on the
ATMEL AT91SAM7X-EK and
ATMEL EVK1105 boards (compiled with GCC). These board have SD card sockets on them and all worked basically as expected. The SPI speed is not necessarily set as high as it could be for the processors but serving of web content worked well and also viewing large PDF files form the web server was successful.
- the M52259EVB was used to test the Coldfire release (compiled with Codewarrior). All worked normally apart from the fact that PDFs sometimes show some corruption when viewed via web browser - the same large PDFs can however be retrieved without error via FTP. This gives the impression that maybe the web browser is parsing the content and causing come errors in the file (html and graphics worked well) - it also seems restricted to the Coldfire, or possible the compiler, so this will need to be investigated more. Furthermore the Coldfire development boards are not supplied with SD sockets so an external one had to be wired up; thsi is a potential source of interference but probably not a reason for the different behavior.
- Generally there are some things that don't work optimally or with some errors too. The following are the known bugs, short comings, etc. that will need to be worked through for the next utFAT version (since the utFAT module is in its own directory in the uTasker folder and is also a module that can be exchanged without requiring a new project version it should be possible to simply upgrade when new versions of the module are available).
1) Ensure that the SD card is not activated together with the SPI FLASH - this is presently not possible (either one or the other...)
2) utFAT reads directories and contents with short and long file names. However it doesn't support writing long file names yet. This means that only short file names can be used when creating new files and directories. Furthermore one has to be careful
not to rename or delete files and directories which already have
long file names!! This is because deleting them is rather more complicated and this was not solved before this version - when long file named files are deleted their content is deleted but not their name, which can be confusing. This is probably the first point that will be worked on.
3) Although the mass storage module can detect SD cards it does this by polling the slot (in a background task). The card is successfully detected but sometimes (it seems a little board dependent) it doesn't always recognise the card as being formatted. Therefore insert the SD cards before powering up the board to ensure that they are reliably detected. In addition to the detection, the module can detect their removal - at the moment the card will not be monitored for insertion after the removal; this needs to be worked on. Finally, since not all SD slots include a switch for detection there is presently no use of such switch inputs - this may be added later.
4) When inserted SD cards are successfully recognised during operation (some boards do this quite reliably) they are not necessarily recognised by the HTTP module - therefore point 3) should generally be respected at the moment.
5) The write protection switch that some sockets have is not yet monitored. Assume that write protection is not yet supported...
6) The utFAT module has various opportunities for optimisation - there are a few subroutines that are very similar but were added to achieve something without endangering existing (similar) routines. Such things will be worked on to achieve better code density as the module matures.
7) The size of SD cards with more that 2G are displayed incorrectly. This is due to the fact that the number of bytes no longer fit into an unsigned long (they need long longs to be displayed). For the moment the byte size overflows - a simply solution may be to display them in kBytes. This is not otherwise a problem with operation...
8 ) The relative path addressing doesn't always work perfectly. Specifically creating new directories referenced by a path name (and possibly renaming etc.) [eg.
mkdir dir1/dir2/dir3, or
mkdir ../../dir1/dir2] doesn't behave correctly. For the moment move to the directory and create the new one there to avoid any confusion.
Update on 31.1.2010: utFAT1.2 (the version used by registered Beta testers) now allows full referenced operation so can create files and directories, delete, rename, etc. as in the examples above. In addition it supports root referencing like "cd \" to set the root, "dir \dir1" to display director dir1's (under root) content from any location. The full flexibility seems now to be available ;-) 9) Up to now the operation with the FAT32 info sector has not been fully analysed - it has been implemented so that it keeps the number of free clusters up to date and also increments the next free cluster. Creating new directories and files can take some time when it is necessary to search through large amounts for clusters, whereby the next free cluster value should help; it is probably not used optimally just yet...
10) Only simple FTP tests have been made to date. It is not sure that the FTP implementation with the SD card support will suit all FTP client types and whether there may be some restrictions due to the open point 8 ). This needs to be investigated. DOS FTP has worked well though.
11) With large SD cards, large amounts of data and missing FAT32 info section support (this support is not guaranteed) searching through FAT clusters can be quite time consuming. A count of the free clusters, for example, can easily take several seconds because it involves already reading about 15MBytes on a 2G card and increasing amounts on larger cards. This count is not needed for normal operation (just for displaying) and has been realised as a background task (as has detecting, mounting and formatting cards). Other accesses are blocking accesses and so can cause the system's overall behavior to be degredated. Some seemingly quite simple SD card operations do sometimes require a surprisingly large amount of data to be read, searched and written [
eg. to create a directory requires reading all of the present directory's content - to be sure that its new name doesn't already exist - adding a new directory cluster, deleting the new cluster's content, modifying its entry in all FAT32 cluster areas and also modifying the original directory entry, not to mention upgrading the FAT32 info sector - involving reading several several kbyte of information and writing several kbytes more]. A complete analysis of the read/write times, the SD card internal delays and addition of capabilities to makes these non-blocking tasks is a point which is still open in the development, and its documentation.
12) utFAT already includes some managed file support so that a user can ensure that an open file can not be modified by another user (write protection) or that the user becomes aware of changes made by another user (file synchronisation). Further development of this and point 11 are probably the most challenging aspects involved in optimising the file system as a whole. They will however result in a powerful module in return for this additional development effort.
Good luck with your first tests!
Regards
Mark
P.S. Don't forget that the uTasker simulator now includes SD card simulation support, which greatly helps analysis of program flow. The difference between the SD card content, as opposed to the uFileSystem and general FLASH content, is that it becomes immediately valid and is not saved when the simulator terminates. The main reason is that it doesn't create a memory array (this would be very wasteful for a 16G card...!) but only instead saves only the actually written SD cards sectors directly to a file.
