I am working on fpga firmware, in which i want to have very fast data transfer using ethernet . I got help from FPGA forum they say that suggest designs for data transfer using light weight internet protocol (LWIP).
How this is different from transfering the data using NDIS. I will be grateful if you can suggest me some guide to interface my visual c++ application to the network guide and tranfer the data.
many greeting in advance.
LWIP is a library for talking IP on a network.
NDIS is a specification for how an OS talks to network cards.
Neither is necessarily what you appear to want.
If you want to transfer data very simply and quickly point-to-point using Ethernet, you need to understand how Ethernet works at the packet level, and form your data into some Ethernet packets. You can make up your own protocol for this if you have control over both ends of the link.
If you want to transfer the data over an existing network topology, you would be better doing it using an existing protocol. UDP/IP might be one such protocol, depending on your requirements for data-rate, latency, software complexity, reliability etc. LWIP is one library which implements UDP, so might be of use.
Related
I would like to communicate over USB using COAP protocol.
I am currently planning to use libcoap, it has examples but it is based on UDP server-client.
If I want to use USB, what must be done?
Thanks
Depends a bit on the deployment scenario, but in general I'd recommend using USB Ethernet inbetween (CDC-ECM). Then you can use CoAP over USB like you use it over any other network connection. (If you use RIOT for your embedded device and build the gcoap example on a board with native USB and enable the usbus_cdc_ecm module, you get that almost out of the box).
The large downside of this approach is that you are subject to the whims of the host OS's network setup. Probably it'll take up at least the IPv6 link-local interface so you can go ahead with requests to fe80::addr:ess (or even use link-local multicast to find your device), but there may be pitfalls.
There is the slipmux proposal which would do CoAP over serial, but a) I don't know implementations thereof, and b) it leaves you with similar issues of how to make sure your application can really find the right serial port.
It wouldn't be impossible to specify CoAP over custom USB commands (which would then be taken up by an application), but there'd need to be really good reasons not to just go through USB networking to justify them, and I'm not sure that the complexity of ensuring that your NetworkManager is set up correctly counts.
I'm new to Linux.
My doubt is regarding v4l2 driver supporting existing ISP harware in Jetson TX1.
I would like to know whether basic v4l2 implementation in Linux provides an interface to send data to ISP(hardware module) or not?
If not provided, is it possible to modify the v4l2 implementation so that it does not bypass ISP.
And also, I would like to know, how the data flows from an image sensor to system memory through v4l2( if possible can i get sources for block diagram representing this data flow)
Please help me...
I am looking at a project that requires the crafting of S1 Application Protocol (S1AP) packets. It is used between a eNodeB and MME of a 4G LTE network. S1AP is IP based and carried by the Steam Control Transmission Protocol (SCTP).
Does anyone have any idea if the current library for SCTP in Scapy is sufficient to do this, or I might have to define a new protocol?
My first goal is to emulate a connection (via a program) to a physical MME, anyone have any suggestions?
Thanks!
It depends on your development environment & requirement. In the case of linux/FreeBSD based development setup, the libsctp and ASN.1 tools should be enough for having S1-AP over SCTP protocol in the interface with the MME.
Coming to Scapy, note that it is based on python.
Scapy seems to have support for all types of SCTP chunks and so it must most probably be fine for your testing.
S1-AP protocol uses ASN.1. For generating S1-AP packets, you should integrate with ASN.1 for S1-AP encoding/decoding and use over scapy. Scapy provides support for ASN.1.
The S1-AP support extension should be done by you. The best part is that you can extend Scapy without having to edit source files for making your automated tool based on the type of requirement.
I want to implement a driver in Linux, that has a Ethernet stack but the data going out on hardware will be a serial port. Basically, I want to register my serial port as a Ethernet driver. Does anyone have any idea if this is possible?
I want to be able to push IPv6 and/or UDP packets out of the serial port and in a similar way receive the packets via a serial port and pass it up the Ethernet stack.
I do not want to use the solution of serial-to-ethernet convertors(external hardware that convert a serial port to a ethernet port) but have that in my PC itself.
I tried PPP over the serial port and it works well. I am also told that I can do FTP, HTTP etc using the PPP. Reference to this - http://www.faqs.org/docs/Linux-HOWTO/Serial-Laplink-HOWTO.html
I have tried to hack the code from a RealTek Ethernet driver with a serial driver but not able to gain much success. Rather I do not know the stack of either to actually do anything meaningful. Any advice, guidance or tutorials would be helpful.
Thanks
Aditya
You need to get back to de basics on networking, the way I understand you question is: "I have a serial port and I want to use is an Ethernet link". Sorry to crush your dreams but you don't have the real hardware to do so, I'll elaborate on it.
A serial connection is a physical connection that requires 3 wires (at least) tx, rx and ground. On the logical side you have an IC that coverts binary data into signals that are represented by discrete voltage ranges.
Ethernet is a layer 2 protocol, the layer 1 is provided by the technology used to transmit the signals (coax, up, fiber etc.) As you might see by now, you need a different set of hardware to convert the logical Ethernet frames into a stream of digital numbers, in fact this is call framing.
Since Ethernet has been an easy to use protocol it has been implemented as e preferred protocol for many network operators, of course one of the biggest is PPPoE where you have a PPP session over an Ethernet link. Of course this won't work with your example neither since you're trying the opposite.
If you're just learning and have all the time in the world you can attempt to write your own Ethernet framer over serial lines. This means you need to implement IEEE802.3 into the driver and then you need to serialize the data to push it as a stream of bits over the serial line. Of course note the following drawbacks:
Your driver won't be able to fully support Ethernet, you need some support at hardware level to implement some signaling (example, auto negotiation, CSMA/CD, etc)
You driver will be pretty much useless unless you back in time where 115.2kbps is top speed in data transfers
IMHO there are more exciting projects that you can pick up in the networking field for device drivers. You can for example attempt to buy a NIC and develop the device driver for it from scratch and you can optimize certain areas. Finally, remember that most of the Ethernet implementations are now done in hardware so you don't have to do anything but filling a few registers on the MAC and voila!
SLIP and PPP do already what you want.
I am Developing a Java ME Application. Here I am using WiFi Connection. Now My Question is how to get a particular WiFi Connections name using Java ME Code ?
My Requirement is for Nokia E5 Device only.
After doing much research work I found that this is not possible in Java ME Technology to fetch the WiFi Connection's Name.
However Similar Library would be com.nokia.multisim.networkid which returns Network ID and Network Short Name.
I Dont Think so it is 100% possible in J2ME and even though if it has worked and there is no guarantee that it will work on all J2ME devices which has Wifi connectivity.
most appropriate answer i have found , please go through it once.
" Much as I hate to put you through all that grief and then not have a simple answer, I don't have a simple answer.
The reason for that is because Java's networking model is based on TCP/IP, and the TCP/IP architecture is based on the idea that applications will neither know nor care about the hardware details of networking. A typical mobile device may contain several different network interfaces (WiFi, Bluetooth, Infrared, USB cable, and so forth), but when an app wants to contact another network node, the app doesn't know which of these interfaces is actually being used. And in fact, if the OS wants to do so, it can use more than one (in parallel) and/or switch interfaces in and out, based on routing criteria such as best measured data rates. Rather like how cell phones route phone calls.
So basic Java/JME won't know anything about WiFi.
However, there is an extension, specified as JSR 309 (http://jsp.org) that looks like it may help. It supports learning about and controlling the network interfaces themselves. The problem is that not all devices will implement this extension, so it will depend on what device(s) you are supporting. "