Messages

1

µTasker general / Re: Why not SPI file system and software upload both supported at once?

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

2

µTasker general / Why not SPI file system and software upload both supported at once?

« on: October 02, 2007, 06:52:33 AM »

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.

3

µTasker general / Re: External EEPROM alternative to M95xxx

« on: July 11, 2007, 01:48:08 PM »

Thanks Mark for you detailed explanation, and the suggestion you are considering looks most promising.
Considering the low cost of this try of pseudo EEPROM, it certainly frees up substantial space for code rather than data, and the simple file system you have becomes easy to deal with once the data sizes increase. Indeed , most users will never need to consider skipping first letters with 16K files. I also did some experimants regarding compiling with registar paramater passing, and traced it to as far as it gets into an infinite look on init
extern MULTISTART_TABLE *uTaskerSchedule( void )
-then it crashes with an unimplemented opcode exception.

I think that the combination of A6 frames and register paramaters may be the problem but I havent looked further yet.

As a suggestion in case others encounter the dreaded while(1) unimplemented vector point, it may be useful to add a litte code to parse the exception stack frame into a few registers as the frame structure is mess to work out the vector number after tracing down the stack pointer etc.

I am loking forward to doing the "easy" debugging on application code (not drivers) using your simulator, as this I am sure will be a great timesaver, and the poor quality of the metrowerks debugger compared to their HS08 and HS12 versions does little to help in the hardware "nitty gritty" !

Regards,
Dean.

4

µTasker general / Re: External EEPROM alternative to M95xxx

« on: July 11, 2007, 11:58:22 AM »

Thanks for the tips Mark, I have it up and running fine now with a 25Pe80 (8 M bits).

It was a good learning experience for me and I nneded to change a few more things.
As there are about a dozen changes it is probably not appropriate I post them here but I will PM you in case you can use the changes in future versions. Another suggestion is to use the program memory based error 404 message as uninitialised eeprom would result in a totally blank page.
For now I just createrd an error 404 file and as I use 64 file entries now the last file starts with a "{" (which cannot be hyperlinked anyway). Also I had to change the way you calculated the last file entry as it doesnt work out for eeprom. The same applied to the FILE_GRANUALITY and FLASH_GRANUALITY, as I chose 8K granuality so the 2 paramater blocks fit into the first file slot.
I test the FTP speeds and the HTTP speeds and noticed with a 28K jpeg file FTP is greater than 30K Bytes  per second, but the web page takes about 7 seconds to load in IE7. Not that I will be doing many 30K pages but I thought I would mention it.
It certainly is now quite impressive with 1 M bytes and 63 files for less than 1 US dollar!

Regards,
Dean.

5

µTasker general / External EEPROM alternative to M95xxx

« on: July 09, 2007, 03:46:52 PM »

Hi All,
I have a suggestion as an alternative to Marks example M95xx SPI eeprom implementation for external expanded file system memory. Whilst not a true EEPROM as such the M25PExx series has a sub page granualrity of just 256 bytes , and can still update less then this. it is less than 1USD for the 8 M bit device and can work at 50MHz SPI clock. It has the same package and pinout, and on inspection most cammands are the same as the M95xx, with the exception of the write command and of course an extra byte needed to address the greater than 64K bytes data!. An 8M bit device is of course 1 M bytes, giving as an example 64 pages of 16K bytes. The file system would thus use upper and lower case letters as the first char and 16K would be ample for most web applications etc. As a beginner, I am just trying to debug this at the moment. Interested to hear what others have to say?
Regards,
Dean Sharples.