ansi c library support

malloc is supported - see the manual.
However, dynamic memory allocation is usually a Bad Idea on embedded systems!

fread, fwrite, etc are file functions - so you'll have to implement your own file system. Part of that implementation will included providing appropriate fread, fwrite, etc!

I think Keil does provide an (at least partial) implementation of malloc(), but I'd strongly recommend *not* using malloc() in an 8051 environment unless you have a very good reason.

"bcause the above mentioned ansi c library
is not supported by c-51, is there any other
way of acheiving the ansi c library porting? if so, then please explain how.."

Any way other than what? If you need functions that Keil doesn't provide you'll have to write them, in exactly the same way you'll have to write the rest of the code for your project.

"also, will it run on the 8051 microcontroller?"

That's the general idea.

Stefan

"I think Keil does provide an (at least partial) implementation of malloc()"

It certainly does!

Apart from being a generally Bad Thing on an 8051 (as already noted), be sure to also check out the knowledge base and review the overheads associated with dynamically-allocated memory

library functions like fread, fwrite
files on a '51 ???????

Erik

we want to include ansi c library functions like fread, fwrite, ...

To add support for fread, fwrite, and so on you must...

1. Decide on what kind of mass storage device you will use (floppy drive, IDE hard drive, FLASH memory, bubble memory, ...).

• Create low-level routines to read and write sectors and to format your medium. This would be similar to the BIOS Int 13h routines.

• Obtain, license, or create your own file system based on DOS, NTFS, HPFS, FAT12, FAT16, FAT32, or whatever else that works with your low-level drivers.

• Write the fread, fwrite, etc. functions that will work with your file OS services.
It's probably a good idea to include error detection (like if the floppy or hard drive is full) and display diagnostic messages on the screen or LCD. That assumes that you have a screen or LCD.

so on you must...
specify the hardware platform in detail.

I am sure it will make a lot Of Keil customers ecstatic if Keil specified a hardware design as a requirement for using theit compiler for embedded processors.

It is so amazing how many thinkjj C is C. The difference between PC C and embedderd C is huge.

Erik

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