ansi c library support

You have not stated what your "file I/O" requirements are, so I thought I'd throw something else in the mix here.

On the few projects where it made sense to do so, I have implemented C's file I/O semantics using an RPC model where fopen, fread, fwrite, etc. on the 8051 side are RPC client stubs marshalling the requests over some communication channel to a RPC server process running on a PC. It works a little like this:

The client application calls a local procedure stub instead of the actual code implementing the procedure. Stubs are compiled and linked with the client application. Instead of containing the actual code that implements the remote procedure, the client stub code:

1. Retrieves the required parameters from the client address space.
2. Translates the parameters as needed into an external data representation (XDR) format for transmission over a communications channel.
3. Calls functions in the RPC client run-time library to send the request and its parameters to the remote server.

1. The server RPC run-time library functions accept the request and call the server stub procedure.
2. The server stub retrieves the parameters from the communications buffer and converts them from the external transmission format to the format the server needs.
3. The server stub calls the actual procedure on the server.

1. The remote procedure returns its data (if any) to the server stub.
2. The server stub converts any output parameters to the format required for transmission over the communication channel and returns them to the RPC server.
3. The server RPC run-time library functions transmit the data on the communication channel to the client system.

1. The client RPC run-time library receives the remote-procedure return values and returns them to the client stub.
2. The client stub converts the data from its external data representation to the format used by the client system. The stub writes data into the client memory and returns the result to the calling program on the client.
3. The calling procedure unblocks and continues as if the procedure had been called on the same system.

You have not stated what your "file I/O" requirements are, so I thought I'd throw something else in the mix here.

On the few projects where it made sense to do so, I have implemented C's file I/O semantics using an RPC model where fopen, fread, fwrite, etc. on the 8051 side are RPC client stubs marshalling the requests over some communication channel to a RPC server process running on a PC. It works a little like this:

The client application calls a local procedure stub instead of the actual code implementing the procedure. Stubs are compiled and linked with the client application. Instead of containing the actual code that implements the remote procedure, the client stub code:

1. Retrieves the required parameters from the client address space.
2. Translates the parameters as needed into an external data representation (XDR) format for transmission over a communications channel.
3. Calls functions in the RPC client run-time library to send the request and its parameters to the remote server.

1. The server RPC run-time library functions accept the request and call the server stub procedure.
2. The server stub retrieves the parameters from the communications buffer and converts them from the external transmission format to the format the server needs.
3. The server stub calls the actual procedure on the server.

1. The remote procedure returns its data (if any) to the server stub.
2. The server stub converts any output parameters to the format required for transmission over the communication channel and returns them to the RPC server.
3. The server RPC run-time library functions transmit the data on the communication channel to the client system.

1. The client RPC run-time library receives the remote-procedure return values and returns them to the client stub.
2. The client stub converts the data from its external data representation to the format used by the client system. The stub writes data into the client memory and returns the result to the calling program on the client.
3. The calling procedure unblocks and continues as if the procedure had been called on the same system.

Hi all,

Can anyone help me out to create an own file system,since keil does not support file read or write operations.

Any URL link regarding this will me more helpful to me.

Thanks in advance

Chris

Well, the short answer is "implement fopen(), fread(), etc, as appropriate for your device". (Or open(), read(), etc, if you prefer.)

The long answer depends on details of your hardware. We have no idea what sort of device your file system is supposed to live on. Flash? A micro disk drive? A remote device over a network? Is the device block structured? Random access? Do you need to add a buffering layer to the I/O, or can the fread() calls just cut right to the device? Is your device complicated enough to require a driver layer to make it go?

The design needs to consider how much, if any, of the file system semantics you really need. Do you need to be able to fseek() within a file? Write variable length pieces? Keep track of multiple independent files named with strings? Stored in a hierachical directory structure? Much of this sort of thing tends to be excessive on small embedded systems. (File IDs, for example, could be small integers rather than strings, especially when they're not human-readable or named by humans. A directory tree is only necessary to organize lots and lots of files. And so on.)

Implementing non-volatile storage does not mean you have to have a file system. Be sure this is the path you really want to take.

http://www.8052.com/forum/read.phtml?id=82032