I'm using a LPC178 development board and I want to read a file present on a Windows PC. My dev board only has a RS2323 interface to communicate with.
How can I go about transferring the file from my PC to my MCU using a RS232 (serial) link? I found a reference which explains how to transfer data between a MCU and PC but it isn't about file transfers.
Afaik there is no easy solution for this like calling something like "copy" or "fopen" over RS232. I would be happy to be proven wrong here.
The fastest solution might be to write a little programm running on your Windows Host, which listens to your RS232 communication and pipes your communication into/out of the file based on your communication protocol. This can be done with standard file operations in the language of your choice, for example C, C++ or Python.
Your problem is one of the oldest in the book. How do you transfer files without fancy operating system abstractions. For RS232 (or any other serial method) there exists many file transfer protocols.
One of them is kermit. This is a protocol from 1981 and can transfer binary and text files. It is able to be embedded in a micrcontroller and there exists programs to transfer/receive using kermit.
alternative old site for reference
In the simplest case you would use a file transfer protocol such as XMODEM, YMODEM, ZMODEM or Kermit - these protocols were designed in the days before networking and the Internet were ubiquitous and deal with simple point-to-point transfers between two computers. They are supported bu most terminal emulator tools such as TeraTerm Pro or PuTTY so no specific PC software need be written, just the microcontroller end.
A more complex but flexible solution is to implement a TCP/IP stack and a PPP driver, and an FTP application layer - probabaly only practical if using a third-party TCP/IP stack and application layer. You can then use any FTP client for the PC end, so again no PC software required. While this may be overkill if all you need to do is transfer files, it has the advantage of allowing you to use the the single serial port concurrently for other data streams and application protocols such as Telnet. The disadvantage perhaps is that while Windows does support PPP it is buried within the dial-up networking and to be frank a pain to get working.
Very first step you have to do is ensure serial communication is working fine.
Send a byte continuously from mcu to PC and display it on some io console (for example: HyperTerminal, Dock light )
Receive a byte to mcu from PC and echo it back to PC.
Once you are sure that serial communication is working fine then select some file transfer protocol and implement it.
While you can select any of the available protocols or write your own protocol and implement it.
For purpose of discussion i select Xmodem protocol.
If you consider some other protocol you may stop reading answer here.
XMODEM is a simple file transfer protocol.
Refer http://web.mit.edu/6.115/www/amulet/xmodem.htm for detailed information.
You may implement Xmodem mcu side by reading protocol. Or may consider using open source also ( if available )
PC side i prefer to use HyperTerminal io console as it is compatible with Xmodem.
In HyperTerminal all that i have to do is configure settings and select file for transfer to mcu.
Now transfer any file to mcu using Xmodem protocol from PC.
What you do with received file in mcu is up to you : )
Related
I wish to write a Linux device driver which spawns a thread which listens to the comport on /dev/ttyAMA0.
On the comport is an rf device which connects to a host of other devices. I wish I add each rf device as I discover them as if they were physical devices to Linux and upon probing the parameters of each device add files for controlling the device parameters.
I have done quite a bit of searching around this and have already done many of the simple hello world driver tutorials and found how to spawn threads from within a driver.
I already know how to read/write to the comport from user-land c.
My question is; is this approach OK? i.e. a driver which can spawn multiple devices. Should this instead be a service? How about reading/writing to the comport from another device is this ok? What are the best practices? Examples?
N.B. I realise I will have to control access to the comport. I am choosing to ignore that complexity for the moment, but I will achieve this via some sort of semaphore.
This is for a personal project by day I'm mainly a c# developer.
EDIT
I have found this related question, I don't however believe it to be a duplicate. I think recommends not to write drivers over drivers. But I wish to add these external devices as if they were physical devices.
Does anyone know of a Source Code for a FTP Client that I can use with a PIC microcontroller?
Preferably in C and I am using a PIC 18F97J60. It is ok even if the source is for a different PIC, I can modify it to support my need.
Thanks.
From this page:
Microchip offers a free licensed TCP/IP stack optimized for the PIC18, PIC24, dsPIC and PIC32 microcontroller families. As shown in figure below, the stack is divided into multiple layers, where each layer accesses services from one or more layers directly below it. Per specifications, many of the TCP/IP layers are “live”, in the sense that they not only act when a service is requested, but also when events like time-out or new packet arrival occurs. Microchip’s TCP/IP stack includes the following key features:
Optimized for all PIC18, PIC24, dsPIC and PIC32 families
Supported Protocols: ARP, IP, ICMP, UDP, TCP, DHCP, SNMP, HTTP, FTP, TFTP
EDIT: This package does not include source for an FTP client; only an FTP server. So this can get you most of the way there.
There are so many open source code, such as(get from google):
http://www.thefreecountry.com/webmaster/freeftpclients.shtml
I'm programming a 8051 microcontroller system (in C) connected to a PC via a serial port. I'd like for the µC to write to a file on the PC. Is there a simple general way to do this from the C level?
I'm not aware of a off-the-shelf way to do this, but it's not hard to develop yourself. You will need to:
Define a serial protocol for transmitting the file data. There are existing protocols from the old dialup modem days, but they might be too complex. See: http://en.wikipedia.org/wiki/List_of_file_transfer_protocols
Write your microcontroller code to transmit the file data over the serial port, using your protocol.
Write a program that runs on your PC to receive the data and write it to a file.
What are the best tutorials and API's for Linux and C based USB programming? I want to be able to transfer data at max throughput point to point between two PCs, with USB 3.0.
Load the Ethernet over Usb kernel driver (a howto for setting up one machine is here), set up static IPs on both ends, and use rcp.
You can't connect two Hosts directly over USB, one side must have a device controller (such as the NetChip 228x), in which case you can load the g_ether module (enabled with USB_ETH) and do as suggested by gnud
I am writing a C program in Linux which will read/write to/from a serial port. I know the data that needs to be read and written on the port but I don't have a serial port to currently test this with.
Is there any way to simulate a serial port? Would reading/writing to a file be sufficient? I can have one process write to the file while another process reads that data and writes back other data to the file. Or are there others tools that can be used to simulate a port?
Thanks
Serial ports on Linux are terminal devices. A close simulation is to create a pseudo-terminal pair; the program that normally talks to the serial port is instead told to open the slave side of the pseudo-terminal, and the simulator writes and reads from the master side.
The pty(7) man page has more information.
Despite being an old topic, and my answer is not exactly something the OP was looking for, I decided to share my experience, as someone else might come across it like I did. Instead of straightforward simulation, I used the software called Serial to Ethernet Connector to gain access to the specific device I needed to test the app with. Worked nicely for me.
A character device, even something as simple as normal stdin and stdout should work if you don't care about attributes specific to port devices.