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