I am working on stm32f107VCx microprocessor.
my compiler is keil and I am using spl (standard peripheral library).
I can send and recieve data with UDP protocol but I dont know how to save this strings that I have given from UDP.
Actually I want to save this strings into a file in my PC.
My suggestion: connect the STM.. and the PC via a RS-232 bus.
Then have the STM.. send the strings over the bus to the PC.
Have the PC read the RS-232 bus and write the resulting data to some file.
if it were me, I would implement some protocol so the STM.. can tell the PC how many bytes are in each string to be saved and have the STM.. append some checksum so the PC can validate the string.
Suggest the PC reply with a ACK or NAK so the STM.. knows if the transfer of the string was successful (or not)
Do note that the RS-232 bus will be MUCH slower than the UDP communications, so some strings may be lost as the PC cannot keep up with the rate the data is coming into the STM..
Given the UDP is not a guaranteed communication protocol, I would expect the losses would be acceptable.
Related
I have two MCUs: atmega8 with SD card along Node MCU - located at different places.
how do i send a hex file of 1MB size from mcu1 to mcu2 by using node mcu's via tcip/ip protocol ?
edit: I have done socket programming in windows environment !
Also, I know how to read/write file in SD card, my problem is... where could I refer for segmentation and reassembly of that 1 MB file.
note: segmentation #MCU1 and reassembly #MCU2
Segmentation # MCU1 : reading the hex file ybte by byte and sending to the other end via ftp over tcp/ip.
TCP maybe not the best choice for Atmega8 because it is too heavy for controllers.
If both MCU under your control you may consider use TFTP (Trivial FTP) for file transfer. It:
Based on UDP and UDP is very lightweight protocol
Supports segmentation and reassembling
Has retransmissions and delivery guarantee
Can send more than one packet at time (acknowledge window)
Is standard
So it has almost all features of TCP but also lightweight and I believe you can easily find free implementation for it.
I am trying to write an application that will read data mirrored from another tcp/ip connection.
Device A connects to machine B via tcp/ip and sends it data. The sent data is duplicated and sent to machine C from device A, but with the same destination address as it did before (pointing to B not C). machine C needs to read the data and do stuff with it.
My question is how do I create a socket that will do this? I know I will need to have it in promiscuous mode. Does it need to be a RAW socket? What is the best way to get the data?
machine C will basically be a network sniffer I guess, but on a network only consisting of those 3 devices.
You want to use libpcap to grab raw packets. Run man 3 pcap to get a list of all the relevant functions.
Okay, what I want to do, as a training exercise, is to implement something like this
client --ethernet--> Modem1 --GPIO--> Modem2 --ethernet--> My Home Router
Where the client connects to Modem1 using an ethernet cable.
Modem1 is a Raberry PI, converting the signal and relaying it via the GPIO
Modem2 is a Raberry PI, receives the data from the GPIO, and send it via the ethernet cable to my home router
I want to implement the Modems, but have little idea where to start.
I have read up a little on ethernet programming, but still can't find answers to the "simple stuff" like.
How do I implement Modem1 so that when its connected to the client, the client discovers it as an internet connection.
On the Modem2 end, how do I make "My Home Router" send packets meant for the "client" to Modem2, so that Modem2 may forward them.
and possibly things I haven't though of....
So, how, concretely, can I implement this? preferably in c.
I'd venture to say you might be able to write some sort of custom GPIO intermediate layer.
Read Ethernet->Encapsulate->Write GPIO->|->Read GPIO->Decapsulate->Write Ethernet
(and vice versa)
The problem then becomes: How can both modems act as "Ethernet proxies"?
Modem1 acts as a proxy for the router. Modem2 acts as a proxy for the client. If your Raspberry Pi can spoof MAC addresses, you might be able to fool Ethernet peers into communicating with your modems' Ethernet port. The reason why you need to spoof MAC addresses is that in TCP/IP networking, there is the ARP table, which maps remote IP addresses to the MAC address that can route IP packets to/from them. This is what allows your client to communicate to your router over TCP/IP.
Another potential pitfall is where your modem communication introduces delays that interfere with the Ethernet layer's handling of the protocol. For example, the Ethernet protocol may have real-time constraints that could be shattered if you introduce delays...
But let's assume anything is possible in a perfect world...
You'll need to write code for reading/writing Ethernet messages (I've seen open source code for reading/writing Ethernet packets over raw sockets in Linux)
You'll need to write a custom driver for your GPIO comms.
This means implementing a carefully thought-out protocol to manage pins state, start-of-message, end-of-message, data-payload, checksum, whatever...
Finally, you'll need to write a top-level communications layer that implements:
Ethernet-to-GPIO process:
a) read from Ethernet port, encapsulates Ethernet packet into a custom message (or message fragments)
b) communicate this custom message, using your custom GPIO protocol driver, to the external GPIO peer
GPIO-to-Ethernet process:
a) Read from GPIO, using your custom driver code
b) Decapsulate Ethernet packet
c) Write Ethernet packet to Ethernet port.
these two processes run forever...
Again, all hinges on whether or not your modems can insert themselves in an peer-to-peer connection without disturbing the natural flow of the Ethernet protocol...
As for the 'C' part...
If you use open source libraries (or code snippets) for reading/writing raw Ethernet via raw sockets, that is most likely written in C.
Your GPIO code will read write from the GPIO pins in one of two ways: from a memory mapped H/W address, or using ioport calls on that H/W address.
Receive raw Ethernet frames in Linux
Send a raw Ethernet frame in Linux
Good luck
I want to send a UDP broadcast datagram to multiple devices on the network, including the sender device itself. The goal is to have all devices receive the data at the EXACT same time (well, +/- 5ms is OK).
The problem is that the network interface on the sending device is looping the data back, so it is received immediately (in contrast to the other devices where network latency comes into play - quite a bit for Wifi for instance)
Any idea how I can disable my network interface to loop the data back directly?
Another idea I had: Is it possible to create a virtual network interface to send the broadcast packet and listen on another interface which only receives it via the network?
I am trying to do that in C on a Linux machine. Any help would be greatly appreciated!
UDP are sent as IP-payload. The routing of IP packets is a domain of the IP stack. It decides how a packet is transferred to the destination. When you IP stack detects that the destination is the local host it will enqueue the packet in the receive queue and the packet will be available immediatly. If your adapters' send queues are filled that you will have a delay. So you can't make a synchronization with this concept.
If you need a hard synchronization you should utilize NTP or SNTP tro synchronize the clocks and define a comment start time for your desired common operation.
Edit:
The (S)NTP protocol is designed to synchronize at millisecond Level. You will get a precision that you can't achieve with any Transmission of UDP packets due to the reason I described above.
(Sorry for my poor english).
Today, I would like to redirect all data from a port to another port. (Like socat or netcat, but I can't use these tools because of their licence).
My data are undefined (so are not start or stop bit) and have different length.
From ethernet port to an ethernet port it's easy(there are the ethernet header).
From ethernet port to an serial port it's also easy (there are the ethernet header to know the begin and the end of the frame and so after cut the data to send data to the serial port).
But my problem is from serial port to Ethernet port.
How do I know when I received my full frame from serial port if I have not header?
Because before redirect the data in Ethernet port, I need to receive all data and only after convert in a ethernet frame, we agree?
I thought about this solution:
I can define an inter-frame delay, if the time between two serial data bytes is less than inter-frame delay, the data are in the same frame, and I wait the next data before convert the frame in a Ethernet frame.
If you use Ethernet encoding over the serial port, including the headers, you should have an easier time figuring out packet boundaries.
Also look at existing tools for tihs such as good old SLIP.