View unanswered posts | View active topics It is currently Thu Oct 02, 2014 10:49 am






Reply to topic  [ 9 posts ] 
1.38: file I/O: file read /write values, ANSI C stdio.h 
Author Message
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post 1.38: file I/O: file read /write values, ANSI C stdio.h
hi,
[Updated:]
i've got some questions to the file I/O example (see below, modified).

1.) where is the file "woops.rso" :?:

2.) what is the corresponding "read command" to
WriteString(hFileHandle, nIoResult, mystring)

(actually I supposed "ReadString", but this was not accepted by the compiler) :?:

3.) where can my own stored file be found in the NXT display file menu :?:

4.) why are the ANSI C file commands not supported - when will they be in future? ("stdio.h": fopen, fclose, fget, fgets, fread, fwrite, fprintf, fscanf...) :?:
your RobotC commands are "Not-(Quite)-C" ! (and the documentation is awfully bad...) ;
stdio commands are desirable for code portation and compatibility to other C platforms)

This is the code:

Code:
///////////////////////////////////////////////////////////////////////////////////////////
//
//                             Test NXT File I/O Functions
//
// Tests the capability to access the NXT file system fro ROBOTC.
//
// The NXT has a file system capable of storing up to 64 files in it's flash memory. The
// files are preserved across power off periods on the NXT.
//
// Filenames are limited to 15 characters on the NXT. There is a 3 character file extension.
///////////////////////////////////////////////////////////////////////////////////////////

#pragma platform(NXT)     // This program only works on NXT -- generate error for other platforms
#define println nxtDisplayTextLine

const string sFileName = "testFile.dat";


TFileIOResult nIoResult;
TFileHandle hFileHandle;

int   nFileSize     = 100;
byte  myByte  = 123;
short myShort = 32000;
long  myLong  = 1234567890;
float myFloat = 980.1234567;

string myString="abcdefg";
int    index;


task main()
{
   CloseAllHandles(nIoResult);
   wait1Msec(500);
   PlaySoundFile("Woops.rso");  // where ??
   wait1Msec(11);

   //
   // Deletes an existing file
   //
   Delete(sFileName, nIoResult);
   hFileHandle = 0;

  OpenWrite(  hFileHandle, nIoResult, sFileName, nFileSize);

  WriteByte  ( hFileHandle, nIoResult, myByte);
  WriteShort ( hFileHandle, nIoResult, myShort);
  WriteLong  ( hFileHandle, nIoResult, myLong);
  WriteFloat ( hFileHandle, nIoResult, myFloat);

  //WriteString(hFileHandle, nIoResult, myString);

  Close(hFileHandle, nIoResult);

  //
  // reset for testing ...
  //

  myByte  = 0;
  myShort = 0;
  myLong  = 0;
  myFloat = 0.0;
  myString="xxx";


  //
  // re-opening ...
  //
  OpenRead(hFileHandle, nIoResult, "testFile.dat", nFileSize);

  ReadByte (hFileHandle, nIoResult, myByte);
  ReadShort(hFileHandle, nIoResult, myShort);
  ReadLong (hFileHandle, nIoResult, myLong);
  ReadFloat(hFileHandle, nIoResult, myFloat);

  ReadString(hFileHandle, nIoResult, myString);

  Close(hFileHandle, nIoResult);

  println(0,"%d",    myByte);
  println(1,"%d",    myShort);
  println(2,"%d",    myLong);
  println(3,"%5.3f", myFloat);
  println(4,"%s",    myString);
  println(5,"%d",   nIoResult);

  while (true)
  {
    }

}

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Last edited by Ford Prefect on Fri Jul 25, 2008 3:50 pm, edited 12 times in total.



Thu May 22, 2008 9:02 am
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post 
[EDIT]:
and some other questions:
5.) why do you need to know the filesize in advance for OpenRead, OpenWrite and FindFirstFile?

Sometimes you don't know the size, you just need to read until EndOfFile (eof=chr(0)) or write until the last value has been written (then add an (eof)).

6.) what if you don't have any idea, how large the file is, e.g. when you are searching any file by
FindFirstFile(hFileHandle, nIoResult, sSearch, sFileName, nFilesize);

7.) related to the last function
FindFirstFile(hFileHandle, nIoResult, sSearch, sFileName, nFilesize):
where has sFileName been declared?
if this should be a private variable which had to be declared before, the function is expected to work better if the declaration was
Code:
string FindFirstFile(hFileHandle, nIoResult, sSearch, nFilesize);
and the function call:
Code:
sFileName=FindFirstFile(hFileHandle, nIoResult, sSearch, nFilesize);


8.) referring to hfilehandle:
what is this for? Do you have to choose a value by your own (0, 1, whatever?), or will the value be assigned by the file opening procedure or so?

9.) Why didn't you use the common C commands and syntax from the beginning?

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Tue Jun 24, 2008 9:39 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Jan 31, 2007 3:39 am
Posts: 299
Location: San Diego, California. USA
Post 
The woops.rso sound file comes with NXG, it installs a large database of sounds and pictures for use on the NXT.

Those ANSI C commands are not supported.

I haven't played with data logging yet, so Im afraid I cant help with the other questions. Good luck.

Scott B-)

_________________
Mmmm Legos B-)

My Robot Projects:
http://www.freewebs.com/robotprojects/


Fri Jul 11, 2008 12:12 am
Profile WWW
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post 
Scott,
thx for your reply, but unfortunately this doesn't help.
my 8 questions are about the usage of the file handling commands (not data logging).
Maybe only the developers might/could help...

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Sat Jul 12, 2008 8:47 am
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post Re: 1.38: file I/O: file read /write values, ANSI C stdio.h
Dick Swan/Bug Tracker wrote:
There is no "ReadString" function and none is planned. Read and write strings are not complimentary. Write string does not write leadning and trailing '"' characters to delimit the string. A read string function would need to know the format of allowable strings which can be pretty complicated. For example:
- Are blanks allowed?
- How is the string delimited?
- Should leadning and trailing blanks be trimmed?
- Is comma allowed in the string?
- Can string be all numeric errors? Or should this create an exception
- Etc.

I think I explained before the ANSI file functions will not be supported. ROBOTC is dependent on the file system provided by LEGO. It is nowhere close to the ANSI specificaton.

If you use the file extension type ".dat" you can find your files in the NXT on-screen menu. You also have to turn on a system parameter related to this because they are normally hidden. Check in the debugger "System Parameters" display for a likely name for this. This feature is not found in NXT-G by the way.

File size is needed in advance because of the limitation of the NXT CPU and the LEGO file system. Some file types -- like RXE files and I think sound files -- need to be stored in contiguous locations rather than as a linked list of 256 byte blocks. The file size is needed to know how big a contiguous area to locate for the file. For files that are "linked list", the file system implementation needs to know the linked list size because the implementation allocates on fuke open and cannot dynamically grow.

In "find first" the "filename" variable is the name of the first file found that matches the search criteria. Normally this will be a local variable in your program.

YOu are right that "find first" could possibly return a string variable. Chronologically, it was implemented before strings were fully supported -- i.e. before functions could return string values -- which resulted in a function parameter instead. At this point, with a body of end user code out there that would break if the parameters were changed, it is not something that should be changed.

Why not "Common C syntax"? File system is dependent on LEGO's file system which is not close to ANSI C. And ANSI C doees not have things like specifying files as contiguous operation.

I have heard reports of people trying to implement an Open Source version of the WINDOWS FAT File System on the NXT. They abandoned it when they realized how big the code was. This doesn't justify the current implementation; it just partially explains how it came about.

The parameters to procedures again are dictated by the underlying file system provided by LEGO in their firmware implementation. ROBOTC builds on this.

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Wed Aug 20, 2008 12:43 pm
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post Re: 1.38: file I/O: file read /write values, ANSI C stdio.h
hello,
I've got 1 more question to this:
Quote:
File size is needed in advance because of the limitation of the NXT CPU and the LEGO file system. Some file types -- like RXE files and I think sound files -- need to be stored in contiguous locations rather than as a linked list of 256 byte blocks. The file size is needed to know how big a contiguous area to locate for the file. For files that are "linked list", the file system implementation needs to know the linked list size because the implementation allocates on fuke open and cannot dynamically grow.


what if I have no idea for openfile, closefile or FindFirstFile and so on, how big the file might be?

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Sun Sep 21, 2008 3:09 pm
Profile
Creator
Creator

Joined: Fri Feb 09, 2007 9:21 am
Posts: 615
Post Re: 1.38: file I/O: file read /write values, ANSI C stdio.h
Ford Prefect wrote:
hello,
what if I have no idea for openfile, closefile or FindFirstFile and so on, how big the file might be?

I agree that it would be nice to have variable length files. Again, this comes back to some of the original design decisions. I believe the current implementation stores files as follows:
- some header information
- the linked list of file blocks. This is a variable length list, but size of list is fixed when file is first open.
- the actual file data.
Above is the "linear" layout of files. If file is not a contiguous type, then data is actually stored in a linked list of 256-byte sectors.

The above storage technique requires the size of the linked list to be known when the file is created. This is why you must specify the file size. I know there are alternative approaches that could have avoided this limitation, but this is what was chosen. No amount of ongoing questions is going to change this.

It would be nice to turn the file size parameter into a "maximum size" rather than an exact size. If you wrote less than the "maxiimum size" then it would be neat if the unused data space was released. I think this might even be an existing feature for some file types, although I'm not sure.

In any case remember than 99% of all NXT users (ROBOTC, NXT-G, etc) never actually write files within their programs. Looking only at ROBOTC, I suspect fewer than 5% of end users will write to files. Of the end users that write to files, the majority find the existing capabilities adequate.

I'm not sure if I've mentioned it before, but one of my colleagues looked at porting an open source version of a FAT16 file system to the NXT. What he found was that after implementation, there wasn't much space left in flash memory for actual files.


Mon Sep 22, 2008 11:09 pm
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post Re: 1.38: file I/O: file read /write values, ANSI C stdio.h
hello,
thx for your reply.
I understood the limitations of the Lego file system.
What I just didn't know was what to do if one has no idea of the size.

So because I don't know if I understood you right or if I misunderstood you (because my English is not good enough to understand everything you wrote), there are just 2 questions:

1.) it doesn't matter if the estimated file size was much too big (estimated =2000 bytes, but the real file size is only 900 bytes), does it?

2.) E.g., you want to open a file to read one byte after the other (estimated file size =2000 bytes), but the real file size is only 900 bytes: Is there any a end-of-file-byte (eof()) to recognize where the file ends?

I want to give you an example, why this is important to me:
I have a navigator robot, he drives around the floor, and he explores his environment.
For this he has an internal 40*40 map where he writes all the obstacles to that he recognized -
24 10 = 1 means: on field (24,10) is an obstacle
24 11 = 0 means: field (24,11) is free
20 20 = 2 means: (20, 20) is the current position.
Now I want to switch the robot off, and so he has to write these data to a file.
I don't want to write all the 1600 fields to the flash, but only those which are marked as occupied and maybe the one with the current position, but not all the other fields - overall there will be about 200 to 400 fields to be written, far less than all 1600. And he writes always a block [x y z ] of 3 bytes, which means:
x y = position, z= condition
When I switch the robot on again, he has to read this file to reload his old "brain" - but how can he know how many fields have been written the last time, and thus where to stop reading a file of what length?

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Tue Sep 23, 2008 2:42 am
Profile
Creator
Creator

Joined: Fri Feb 09, 2007 9:21 am
Posts: 615
Post Re: 1.38: file I/O: file read /write values, ANSI C stdio.h
Ford Prefect wrote:
hello,
thx for your reply.
I understood the limitations of the Lego file system.
What I just didn't know was what to do if one has no idea of the size.

So because I don't know if I understood you right or if I misunderstood you (because my English is not good enough to understand everything you wrote), there are just 2 questions:

1.) it doesn't matter if the estimated file size was much too big (estimated =2000 bytes, but the real file size is only 900 bytes), does it?

2.) E.g., you want to open a file to read one byte after the other (estimated file size =2000 bytes), but the real file size is only 900 bytes: Is there any a end-of-file-byte (eof()) to recognize where the file ends?
<<snip>>

I believe the file system keeps track of both the "total size allocated" and the "actua size used". The "actual size used" is effectively an EOF indicator and when you try to read back a file will return the "end of file" error code when you try to read past it. This is what you want.

The "problem" for you is that the NXT file system does not allow just any type of file to be written smaller than the actual size. As I recall, it is only for certain file types (".dat"?). I can't remember exactly which types allow for this; it's not very well documented.

For the example you've given, which I "snipped" from the quote, it would probably be just as easy to write the full 40 x 40 matrix.

I am not sure if only writing 900 bytes of a 1600 byte file actually only allocates 900 bytes for the file. It might allocate the full 1600 bytes and 700 bytes would remain allocated even when you write the smaller size. I think about the only way to know for sure is to try it out and see how much space is left. Naturally you'll have to account for fact things are allocated in chunks of 256 byte sectors.


Tue Sep 23, 2008 7:04 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 9 posts ] 

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  



Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.