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
Related
Newbie in the community, here. First of all, thanks for all the help in all these years i've been working on embedded development :D
I have a problem with an Atmel AT91RM9200 ARM microprocessor, connected via RMII to a Mikrel KSZ8863 ethernet physical interface. The ARM is loaded with U-Boot 1.1.2, which loads the Linux Kernel v2.4.27.
I manually added the code to interface U-Boot with the KSZ.
The problem is:
Using U-Boot, if I try to download something from my TFTP server (located in the same network), the connection sometimes has so many timeouts that the download fails, and sometimes has just 2 or 3 timeouts.
I checked the U-Boot FAQ page, and the most probable reason for the timeouts is a wrong speed configuration, which I double checked.
What could be the reason for the unreliability of my connection?
Thanks,
Loranzp.
Setup a minimalist network consistent of TFTP server, client and Sniffer (Wireshark in promiscuous mode) (if you use a switch it must have a repeater port where to connect the sniffer PC)
Next run traffic captures and analyze when and how the timeouts occur.
Consider:
TFTP BlockSize too big leading to mishandled IP fragmentation.
Server provides the packets too fast after REQ or ACK
Not correctly handling block number roll-over (only when handling big files)
etc
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 : )
I am working on a project like "openvswitch" --- a linux kernel modules that interfaces with
various network interface cards.
You can bind some network interfaces (like eth0, eth1) to the module, and then packet received from the interfaces will be handled by the kernel module (it may modified the packet header and send the packet from another binding interface).
In a virtual machine environment, I can easily do the development work (kernel space programming often crash the machine) but I can hardly do the testing work. It is difficulty to
send a specific packet to the vm's specific interface. Is there any easy way for this?
Use a traffic generation tool like Scapy on your hypervisor to send traffic to the virtual NICs that are attached to your VM. With qemu/libvirt these interfaces normally come up as "vnet0", "vnet1", etc.
Do not use bridges, but send traffic directly to the vnic. Linux bridges are good at forwarding IP traffic but will not let every ethernet frame go through unmodified.
I believe that my question is:
Is there a simple user-mode TCP stack on PC operating systems that could be used to exchange data over a lossy serial link with a Linux-based device?
Here is more context:
I have a Linux-based device connected via a serial link to a PC. The serial link is lossy so data being sent between the two devices sometimes needs to be retransmitted. Currently the system uses a custom protocol that includes framing, addressing (for routing to different processes within the Linux device), and a not-so-robust retransmission algorithm.
On the Linux device side, it would be convenient to replace the custom protocol, implement SLIP over the serial link and use TCP for all communications. The problem is that on the PC-side, we're not sure how to use the host's TCP stack without pulling in general IP routing that we don't need. If there were a user-mode TCP stack available, it seems like I could integrate that in the PC app. The only TCP stacks that I've found so far are for microcontrollers. They could be ported, but it would be nice if there were something more ready-to-go. Or is there some special way to use the OS's built in TCP stack without needing administrative privileges or risking IP address conflicts with the real Ethernet interfaces.
Lastly, just to keep the solution focused on TCP, yes, there are other solutions to this problem such as using HDLC or just fixing our custom protocol. However, we wanted to explore the TCP route further in case it was an option.
It appears that the comments have already answered your question, but perhaps to clarify; No you can not use TCP without using IP. TCP is built on top of IP, and it isn't going to work any other way.
PPP is a good way of establishing an IP connection over a serial link, but if you do not have administrative access on both sides of the computer this could be difficult. 172.16.x, 10.x, and 192.168.x are defined as being open for local networks, so you should be able to find a set of IP addresses that does not interfere with the network operation of the local computer.
From the point of view of no configuration, no dependencies, comping up with your own framing / re-transmit protocol should not be too hard, and is probably your best choice if you don't need inter-operability. That being said kermit, {z,y,z}modem would provide both better performance and a standard to code against.
Lastly, you may be able to use something like socat to do protocol translation. I.e. connect a serial stream to a TCP port. That wouldn't address data reliability / re-transmission, but it may be the interface you are looking to program against.
I want to know how to communicate between two systems using only MAC address using C program (without using IP address). I think this is raw ethernet communication. My requirement is to send data from client to server only by using the MAC address. May be this can be done by creating our own raw ethernet frame.
Please help me regarding this. If anybody has written code in C, please share.
This link may help you, http://aschauf.landshut.org/fh/linux/udp_vs_raw/ch01s03.html
The libpcap library allows you to assemble raw Ethernet packets and send them directly to an adapter: the hardest part being the discovery of the correct adapter. This is designed for C/C++ usage on most platforms (Win PCAP etc.).
Be sure this is what you want though: I have seen several projects where raw Ethernet packet interfaces have been used, only for more and more protocol to be put in place for re-transmission and windowing etc. until you end up with your own version of TCP/IP (only one that hasn't been tested by millions of people using Windows/Linux or whatever your platform is). Most Ethernet chips have functions to accelerate TCP/IP stacks these days too: so you will be missing out on that too.
Here are examples for C#, maybe you can leverage this. The right code depends on OS and even from the used chips when programming for microcontrollers.