Author Topic: Why not SPI file system and software upload both supported at once?  (Read 12247 times)

Offline sharning

  • Newbie
  • *
  • Posts: 5
    • View Profile
After considering varios comments, surely there is ample room for reserving the first part of SPI flash for Software uploads (e.g. 256K bytes) and simply modifying the file system to operate from a 256K address offset on the SPI flash. To me this seems fairly simple and would suffice or until a more sophisticated file system is implemented. Then users would not have exclude one for the other. These seperate functions are never concurrent so i guess the existing SP5 code structure should suffuce.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3237
    • View Profile
    • uTasker
Re: Why not SPI file system and software upload both supported at once?
« Reply #1 on: October 02, 2007, 11:41:34 AM »
Hi

Your remark is absolutely correct. There is no reason why not share the SPI FLASH between upload space and file system space. In fact this is supported (in a way) but doesn't work with the uFileSystem but rather with commands at the level under uFileSystem.

The present complication results from the size of the SPI FLASH which is (or can be) available. If a big device (or even several) are used you may have several MByte space which can be used and the set up of the uFileSystem (which is optimised for FLASH memory in the range up to about 200kByte) becomes rather restrictive. Each file block in the FLASH would have to be set up to be rather large (say about 200k in 10Meg) which is far from perfect - this is why the discussion of an alternative file system for large memory models has taken place.

On the other hand if you use a small SPI FLASH (say 512k Byte), 256k could be reserved for upload (either as a file in the uFileSystem or as a seperate area) and the rest can quite easily use the uFileSystem since it is an ideal dimension for it.

The present SP5 (for Coldfire) doesn't support this 'intermediate' solution which would be well suited to the smaller SPI FLASH devices but it doesn't require much work to add such an option.

The idea for the future direction which is formulating in my head (hopefully in line with the majority or users' wishes) is to add this intermediate capability so that small SPI FLASH can work with high efficiency and the SW UPLOAD can be shared with the uFileSystem (present designs will be able to operate by setting the option but this will free up all internal FLASH for program code). Then to implement an optional extension to the uFileSystem whch will address more capabilities and larger memory sizes (larger number of files with long(er) file names at least), but still without going for FAT compatibility. This will mean that removable devices will not be compatible with PCs for reading, which is or course not optimum, but there is no reason why users who do need this capability don't link in a FAT (either licensed or open-source) for the part of the application which needs it. Basically I am assuming that embedded systems are the main applications where larger SPI FLASH devices are used for storing data (either raw data or structured in files) and so larger data sizes are important. It will still be possible to collect this data via a 'standardised' interface - specifically TCP/IP but not by removing a card device and inserting it in a reader. This will at least avoid any potential problems with FAT copyrights and so keep the project free from any such issues.

Regards

Mark

Offline sharning

  • Newbie
  • *
  • Posts: 5
    • View Profile
Re: Why not SPI file system and software upload both supported at once?
« Reply #2 on: October 04, 2007, 11:29:32 AM »
Thanks for the consideration Mark, and certainly here in China prices for the Atmel 8 M bit parts is no more than 256K "EE" parts, with the bonus of extra speed and built in buffers - so perhaps on a cost basis most users with new designs would also be in the same situation. Also, regarding future file system I also agree that built in support would not need to be for fat or fat32, but it may be worthwhile just documenting how to "port" it into uTasker, perhaps keeping Sourceforge code structure in mind when implementing your "intermediate" file system.
My suggestion woulb be for slightly more complex then the simple implementation (perhaps basic error check of block overwrite, file size would "idiot proof" what you have, and then perhaps even storing an 8.3 filename but not fragmented files or file attributes other then maybe creation date (useful if a data logger app?) since you have an RTC module now.
 I have been playing with tweaking SPI flash paramaters and changing conditional assembly to try them both out at once, but not finished yet as I am travelling around a bit at prersent.
One last suggestion a little off topic: - What about a userconfig.h file for all #def options for user customisation so you just refer to one file for most tweaks / user paramaters, and just include it in all the usual source files. then for basic use on one file need be "touched" for basic operation.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3237
    • View Profile
    • uTasker
Re: Why not SPI file system and software upload both supported at once?
« Reply #3 on: October 04, 2007, 12:03:31 PM »
Hi Dean

Yes, if you are going to put in a FLASH then probably it will be as big as possible since the price difference is small.

Originally there was one config file in the system but this was split into two (from V1.3):
- config.h for a general project configuration (eg. does the project need UART or does TCP support SNMP, etc?)
- app_hw_xxxx.h is target specific

The idea is that each target has its own app_hw_xxx.h (where xxx is the target type). This is not obvious in a project with only one app_hw_xxxx.h.

Although there are not many people who run the same project on different processors it does happen (and I do all the time). The split can thus have great benefits in my experience. In my application directory I have presently 7 app_hw_xxxx.h files where each adapts the same project to a different hardware or EVAL board.

The advantage of having one file controlling a build is that it is very easy to coordinate - no messing with which headers are needed. The disadvantage is that when rebuilding large amounts of the projects need to be recompiled due to a small header which possibly only affects very for of the sources. I remember compiling projects on a VAX where building a project could take half an hour or so. It was useful to not have to wait unnecessary time for a file to compile if it really was not necessary.

Today compile time is a relative minor issue (at least in the smallish embedded projects which we are talking about) so I tend to accept the fact that sometimes there are more dependences than absolutely necessary simply due to the fact that it makes life easier.

Cheers

Mark


Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3237
    • View Profile
    • uTasker
Re: Why not SPI file system and software upload both supported at once?
« Reply #4 on: November 17, 2007, 08:52:07 PM »
Hi All

Here's an update on the progress on this one.

Using the M5223X base I have added the possibility of using the file uFileSystem in external SPI FLASH (the parameter system can also be there or can be resident in internal FLASH). Multiple SPI FLASH chips are also possible to extend the memory range using additional chip select lines if required.

To go with this I have added a new document to go with it, including all necesary details:
http://www.utasker.com/docs/uTasker/uTaskerFileSystemSPI_FLASH_001.PDF

Comments are welcome. Please contact me directly if you would like to use this new feature as Beta tester.

Regards

Mark