Hello just want to ask whether I can use file management in uVision3? Because I tried to use which is this " file *fp;" but i say file is an undefined identifier. What should I do to open a file to read and write can anyone tell me thanks!
The reason why I want to open a file to read and write is because I want to pass value from other program to this program. If anyone know the other method can teach me please thank alot!
Hi i am different from the person that you know. Just that we have same name and surname. The reason why i want to open file from C is because I want to read value from vbScript. So is it possible to open file from C? Cause i tried before the "File" method but it gave me an error. studio.h does not have "FILE" in it. So it gave me that error. So is there anyway to get the "File" library? Thanks alot!
"The reason why i want to open file from C is because I want to read value from vbScript."
So where does VBScript fit into embedded software running on an 8051?
Yes, of course the 'C' programming language can support file management - a lot of PC applications are written in 'C'.
But for an embedded 8051 system to use file management you would first need some sort of physical file storage medium, physically attached to the 8051, on which the files could physically be stored.
Then you would need to add a file management system in your software.
Then - and only then - could your program make use of these file management faclities.
"So is there anyway to get the "File" library?"
There is, but how do you think that the 8051 will physically access the files?
See: http://www.keil.com/support/man/docs/c51/c51_xa_librarydif.htm
Where do you fit the hard drive to your 8051? And how do you install Windows into your 8051?
You normally make use of a serial port to transfer configuration to an embedded application. And you normally make use of EEPROM or a flash sector to save that configuration.
Yes, embedded applications can do file operations. But you normally then have to add a SD memory card or similar. And then you need to add support for a file system, so the embedded application can support locating, opening and reading the files on the SD card.
ya i am confuse about these things. because i though C program can open the file. Is there other way to retrieve information from vbscript, not embedded in 8051, is for another hardware.
"i though C program can open the file."
Think about it: a 'C' program is just software. You can go DOWN to your local PC store and buy all kinds of software (it may even have been written in 'C') - but if your PC doesn't have the necessary hardware installed, the software won't work, will it?
Similarly, if your PC doesn't have the necessary System software installed (OS, drivers, etc), a Program that requires it will not work.
And So it is with file management on an 8051: you can write the program, but it will be useless unless you also have the necessary hardware connected and also the necessary supporting "system" software in place.
"Is there other way to retrieve information from vbscript, not embedded in 8051"
Yes - you get the VBScript (or whatever) to send the information in some suitable format over some available communication link.
The most commonly available communication link on an 8051 embedded system is the RS232 Asynchronous Serial Interface; ie, connect it to the PC's COM Port!
The most commonly available communication link on an 8051 embedded system is the RS232 Asynchronous Serial Interface; ie, connect it to the PC's COM Port! .... a USB SLAVE capable derivative.
But this is more due to the RS232 disappearing from the PC than the (dis)advantages of the interface in the '51
Erik
Actually, I think The most commonly available communication link on an 8051 embedded system is still the UART.
BUT, as you say, COM ports are rapidly becoming less common on PCs - and are already missing entirely from most laptops.
Therefore, rather than connect to the PC's COM port, it is becoming more usual to connect to the PC via a USB-to-serial converter device - whether a ready-made cable or an chip on the board (effectively replacing the RS232 transceiver)
Examples:
apple.clickandbuild.com/.../ftdichip
" href= "http://apple.clickandbuild.com/cnb/shop/ftdichip?op=catalogue-products-null&prodCategoryID=10&title=DLP-USB232M-G"> apple.clickandbuild.com/.../ftdichip
USB has more bandwidth, but few embedded devices needs that bandwidth. Especially in the 8051 world, I guess a very high percentage is fine with the normal RS232 baudrates.
Using a USB-to-serial adapter is easier than writing a full USB implementation, with the additional advantage that any microcontroller can be used. Selecting a controller with built-in USB is more natural when moving over to the ARM processors, even if most manufacturers have 8-bit processors with USB built in.
Ask the real question and you will get a sensible answer. some C compilers provides File access function as a library. But Systems such as windows may want you to use their own libraries.
Using a USB-to-serial adapter is easier than writing a full USB implementation
... the "full USB implementation" is provided by the chip manufacturer as source.
But we all know that there can be a lot of work between getting the manuafacturer's "source" and having it properly integrated and working in your own system.
What is it you always say about "sample code"...?
The big attention people give to all of Tsuneo Chinzeis posts can probably be seen as an indication that the "full USB" route is way harder than using a serial-to-USB chip.
The lack of other people who off-load Tsuneo Chinzei helping people should probably also be seen as an indication.
There are of course quite a number of people who do manage to get their USB solutions to work without asking for help here, but the percentage of people getting stuck with their USB implementations seems to be way higher - I hardly see anyone getting stuck with a serial-to-USB solution.
So in the end, I think that for a high-volume product, it may be important to use a chip with built-in USB support since it may give a lower production price. But for a lot of people, the savings on the development time may fincance the extra hardware. Especially if it also gives a shorter time-to-market.
Since all USB I have done has been masters (not slaves) my reading of the SILabs USb section has not been exhaustive, just "reading out of interest". However I think that I have not seen any great difficulty in implementing what is discussed here (a replacement for RS-232) but the difficulties has been in areas like "higher speed" "large packet size" "multiple PIDs" etc.