Clarification on Ethernet, MII, SGMII, RGMII and PHY - networking

I primarily come from an Embedded Software background and hence I have very limited knowledge about hardware in general. I always use to think Ethernet as that little physical connector on your computer into which you attach your Ethernet cable. And from a Software perspective all you need to do is to install the driver (in Windows) or configure the Linux kernel to include the driver for your Ethernet.
Questions:
But as I have started going down one level (towards the hardware) and looking at various datasheet and schematics, I have started to come across terms like PHY, MII, SGMII, RGMII, etc. And now I am little confused as to what constitutes an Ethernet? For example, when I say Intel 82574L 1.0 Gbps Ethernet port, where do all these terms fit in?

Some definitions:
MAC - media access controller. This is the part of the system which converts a packet from the OS into a stream of bytes to be put on the wire (or fibre). Often interfaces to the host processor over something like PCI Express (for example).
PHY - physical layer - converts a stream of bytes from the MAC into signals on one or more wires or fibres.
MII - media independent interface. Just a standard set of pins between the MAC and the PHY, so that the MAC doesn't have to know or care what the physical medium is, and the PHY doesn't have to know or care how the host processor interface looks.
The MII was standardised a long time ago and supports 100Mbit/sec speeds. A version using less pins is also available, RMII ('R' for reduced).
For gigabit speeds, the GMII ('G' for gigabit) interface is used, with a reduced pincount version called RGMII. A very reduced pincount version called SGMII is also available ('S' for serial) which requires special capabilities on the IO pins of the MAC, whereas the other xMIIs are relatively conventional logic signals.
There are also many more varieties of interfaces used in other circumstances, may of which are linked to from the Wikipedia MII page:
http://en.wikipedia.org/wiki/Media_Independent_Interface
Regarding your specific Intel chip question - as far as I can tell (the datasheet link seems dead), that chip is a MAC, with PCIe. So it will sit between the PCIe bus on the host and some kind of gigabit physical layer (PHY).

Let me try to explain:
The MII, SGMII, RGMII are three kinds of interface between the MAC block and the PHY chip. The Intel 82574L is one MAC chip. Looking following figure:
_______ __________ ___________
CPU | PCI-E | | MII/SGMII/RGMII | |
or |<=======>| MAC |<================>| PHY |<====>physical interface
board| or else | | | |
_______ __________ ___________
For details about MII (100Mbps), SGMII (1Gbps, serial), RGMII (1Gbps, reduced) definition, you can google them.
Basically speaking, NIC (Network Interface Card) consist of one MAC block and related PHY chip, and other peripheral modules. And also one Ethernet device driver should work with the NIC hardware. The MAC block has one interface with the control CPU or PC main-board, such as PCIe bus or else.

You might want to look for the term "7 Layers of OSI" in which some frequently heard terms;
Ethernet PHY Corresponds to Physical Layer which consists from the literally physical components of the communication.
Ethernet MAC (not the Mac Address but the Media-Access Controller) Corresponds to Data-Link Layer, which is responsible from arranging the frames before sending them to physical layer.
Configurations such as MII, RMII, Auto-Negotion are configured from these two.And there are libraries to make your life easy.
Network Layer is the one responsible from routing of the packets. Protocols such as IP and DHCP are considered to be in this layer. Also this layer is the first lowest layer that is solely software based. If you are using light-weight IP for example ip & netif libraries are the ones everything else build upon.
Transport Layer is where transmission protocols such as TCP & UDP can be found.
Hope it helps, I don't know much about the upper layers sadly.

The Intel 82574L chip contains both the MAC and the PHY.
Refer to the Architecture block diagram on page 15 in the datasheet available from here: https://ark.intel.com/content/www/us/en/ark/products/32209/intel-82574l-gigabit-ethernet-controller.html
The MAC and PHY are both there, but from my non-engineer view, I was confused about the MII connections because I was expecting two separate chips.

In very basic terms when you connect ethernet cable to you laptop you are able to access internet. The ethernet port is the interface in above example. Likewise there is an interface connecting your Ethernet Media Access Control(MAC) to Ethernet PHY. Let me break it down here Ethernet MAC is address of NIC(Network interface Card). Ethernet PHY is the physical layer which acts as interface between your ethernet port and Ethernet MAC. Now the Ethernet MAC takes packer from processor converts it into bits and Ethernet PHY convert bits into electrical signals. The interface between the MAC and PHY is where MII/RGMII(etc) comes into picture.
Being media independent means that different types of PHY devices for connecting to different transmission media (i.e. twisted pair, fiber optic, etc.) can be used without redesigning or replacing the MAC hardware. Thus any MAC may be used with any PHY, independent of the network signal transmission media.

SoCs/PCs may have the number of Ethernet ports. For each Ethernet supported device you will have Either SGMII, RGMII interfaces for the data stream. And, you will also have MDIO/MDC interfaces that are used by the drivers on the SoC to control BOTH your MAC and PHY chips if separate (PHY can be SFP or small form factor pluggable).
Combined MAC/PHY chips that work directly with the SoC/CPU to provide both data path & control, as well as PHY (electrical or optical signaling). The MAC part validates packets CRC - counts errored frames, and runts, and provides VLAN capability and pause frame support if an interface is running low on input queue buffers. And, the PHY chip supports line-level signaling like PAM (a modulation scheme).
Go WIDE SCREEN TO SEE DIAGRAMS BELOW.
IE: (SoC or CPU or peripheral interface)
<separate PHY and MAC and shared MDIO/MDC access of PHY(SFP) and MAC>
SoC -----SGMII/RGMII---- MAC chip (can be a switch chip with VLAN support) --- PHY chip for magnetics etc (SFP).
SoC ----- MDIO/MDC ----------------------------------------------------------- PHY
(controlling PHY-related things like speed/FDX/HDX/Auto Negotiate)
SoC ----- MDIO/MDC ----- MAC chip
(controlling VLAN tagging, reading MAC-related data - overruns/runts and time stamps (for PTP) if the chip is 1588 capable)
The MDIO/MDC supports addressing different devices attached to the MDIO/MDC data bus.
OR
SoC ---- SGMII/RGMII ---- MAC chip w/Magnetics --- Cable (in this case magnetics and their control is on the MAC chip i.e. Speed, Duplex to control PAM signals etc)
SoC ---- MDIO/MDC ------- MAC chip
The MDIO/MDC control bus essentially gives the user access to Clause 22 and Clause 45 registers used to control the MAC/PHY or a MAC and PHY chip interface to the actual cable.
SFP allows the user to plug in different interfaces (telco etc) your PC only will have a RJ485 connector with magnetics built in. But telco's use SFP to convert to Optical or Electrical interfaces between their different pieces of equipment. Optical is usually preferred due to noise immunity, distance of transmission, and electrical isolation.

Related

Porting Arduino serial communication to standalone atmega328

I have a fairly complex project done on Arduino2560, which I want to port to a standalone Atmega328. My problem is that one feature in the project is that it can communicate with my computer via serial (I made a C# program to handle it on the computer side, using the COM3 port). However, Arduino uses the USB communication for a virtual serial port, and I got a bit confused about how it could be done for the Atmega. It has the RX-TX lines, but what's next? Maybe use some serial-USB converters? What's the best approach for this? Is there anything I should be careful about?
Thanks.
Considering you mention a specific port COM3 on your computer I guess we can assume you have a native RS-232 port (one of those with the sub-D9 male connector that we were used to in the old days but are not so common anymore).
If that's the case, then you can get an RS232 level shifter. You'll just have to make the connections to RX, TX, Vcc, and GND and this device will change the RS-232 voltage levels to whatever your board requires (most likely 5V or 3.3V). Some (maybe most) high-end development boards include this kind of level shifter so maybe check yours in case you already have it (if you do you'll probably see a MAX232 IC somewhere). Or if you are crafty you can also DIY.
If you prefer to connect to a USB port (then, of course, it won't be COM3unless you explicitly change the configuration on Windows Device Manager) you can go for a USB-to-serial adaptor. On that front, you have many choices, starting from the cheapest at maybe 5$, but I'd rather choose one based on the FTDI chip, which is nowadays quite ubiquitous and has proven its reliability. This one is a good example, and at the same cost as the level shifter.
Now, are there any differences between using the native RS-232 or the USB adaptor? The answer is, for most practical purposes, no. If you go to the fine details, like buffer sizes, there will be differences, but if you need to go there you'll need to study the details in both cases to see if the port you have (or the one you're planning to add) meet your needs. For most scenarios, I would choose the USB, if only because you have it everywhere (most laptops don't have a native RS-232).
All of the above (based on RS-232 and/or USB) will work fine for cables running up to 5 meters (~15 ft.) for USB or maybe 10 to 15 meters (~30-45 ft.). This should be enough for most hobbyist or at-home projects. If you want to run longer cables you'll have to go for something like RS-485.
If you choose now the USB adaptor and you think you might need to relocate your board in the future to end up more than 20 meters (15 of RS-232 + 5 of USB) away from your computer just make sure your adaptor includes a TX Enable signal (TXEN). Most adaptors based on the FTDI chip will have this signal on a pin (like the one I linked above), and that will make your life way easier if you want to use RS-485 on a two-cable half-duplex bus.
EDIT: based on the feedback below there is new info that deserves a quick update.
First, you don't have an old school RS-232 port on your PC and second you have to design the connection on the microcontroller's side.
With that in mind it's clear you have to go for the USB solution. But you need to choose if you shift both sides to RS-232 levels or you stay at TTL. That decision depends again on the length of your bus. If it'll be really short (up to 2 meters) then you can stay on TTL, otherwise better shift to RS-232 to be on the safe side. There are many people who will tell you they have much longer serial links but how reliable they are you'll never know.
Since you have to design the board, I guess it makes sense to integrate the MAX232 and a sub D-9 connector there and get the cable you mentioned for your PC.
Or, you can add only a connector on the board and get the Sparkfun level shifter I linked above for the micro's side plus the same USB to RS-232 for your PC.

Connecting 2 USB ports together over a "Null Modem" like in the old days with COM ports?

I was curious if anybody knows a way to connect two different computers together over a USB line and what API's exist to program this interface.
For Serial Ports its common to buy a "Null Modem" adapter to cross over the Transmit and Receive lines of the UART so that the computers can talk together. And then You would read and write them like normal windows files over special system files called "COM1", "COM2", etc.
I was wondering if there was an Adapter of some kind that could emulate this same behavior except for native USB protocol. I realize they have USB-to-UART adapters. That's not really what i'm interested in because the baud rate is very slow for uarts. I was looking for something with USB speeds to transfer from one computer to another that is not going over a network link such as ethernet or wifi.
This is what I have:
COMPUTER A<-->USB<-->UART<-->NULL_MODEM<-->UART<--->USB<-->COMPUTER B
Speed 110,000 Baud, whatever... to slow to transfer files... ok for text...
This is what I want:
COMPUTER A<-->USB<-->Crossover_Adapter<--->USB<-->COMPUTER B
Speed 480 megabits per second
Assuming this beast exists, how do you program it and where do you buy it?
The only solution that I know of is the "FTDI Chip USB-to-USB Null modem cable" that can transfer between computers two computers using USB ports at a rate of 3 MBaud (384 kbytes/s) That's a lot faster than using older serial ports with null modem cable that maxs out at say 115200 baud (14 kbytes/s). The FTDI chip cable can be programed in c/c++/c# just like a standard windows serial port by way of a virtual serial port.
http://shop.clickandbuild.com/cnb/shop/ftdichip?op=catalogue-products-null&prodCategoryID=92&title=Null+Modem+Cables
From Their Website:
USB NMC-2.5m
NMC In the era of legacy PCs with onboard RS232 COM Ports, it was
common practice to establish a simple communications network between
PCs using a cable popularly known as a Null-Modem cable. Typically,
such a cable would have DB9 female connectors on each end with the TX
/ RX and handshaking signals cross-connected so that the PCs could
communicate with each other via legacy COM ports.
On modern PCs the legacy COM Port connector is rapidly disappearing as
USB becomes the multi-function communication port of choice. However,
this presents a dilemma in application areas that previously relied on
legacy COM Ports for inter-PC communication.
A convenient solution to the problem is the FTDI USB NMC cable. From
the outside, this cable appears to be two USB type “A” sockets wired
together, however each of the USB sockets conceal a small PCB with a
FT232RQ based USB-UART converter IC plus support components inside.
The interconnect cable cross-connects the TXD / RXD data signals, RTS
/ CTS handshaking signals and interconnects the common GND reference
rail betwen the two converter PCBs.
When used together with FTDI’s supplied Virtual COM Port ( VCP )
drivers, the USB NMC cable may be used to establish inter-PC COM Port
based communication at baud rates of up to 3M baud. The standard USB
NMC cable p/n USB NMC-2.5m comes with an interconnect length of 2.5m (
8.2ft ) - other lengths may be available on request. Multiple operating systems are supported including Windows, Linux, Mac OS etc.
single cable
Another Alternative is to use Bluetooth which is also programmable just like a the older serial port.
I think I found the solution: Avnet Spartan-6 LX9 MicroBoard.
It has a USB on one end and an ethernet port on the other end.
http://www.xilinx.com/products/boards-and-kits/1-3i2dfk.html
I can put the fpga/microblaze-cpu in the middle to filter out traffic to make sure the link doesn't get hacked and maybe encrypted it as well.
Easy Computer Sync sells the null modem cable plus the data transfer software. The SW is versatile and easy to use. https://www.bravurasoftware.com/easy-computer-sync/ (I have no connection with other than being a satisfied user.)

AVR Atmega8 Serial Communication

I am posting this question after not getting any sort of help across the web and reading many articles and tutorials. I ended up asking questions with hope of getting guided.
DESPERATE FOR HELP.
What i want:
1) I want to build a R/C tank.
2) Basically its not controlled by a remote control but i want control by a laptop.(i could write a c++ or c# program).
What i know:
1) I know how to develop a development board. (i want to develop my own, not use arduino)
2) I know c++ and assembly very well.
3) I know about AVR's ALU, Memories(all 3), Stack, Interrupts, IO Operations well.
4) I know theory about how SPI, RS232, UART works.
PROBLEMS: (I have many questions, but most important are)
1) B/c i have made my own board. How can i transfer my program(hex file) to my board(i seek practical and physical implementation, not theory please)(i know about a 6-pin ISP but not clear about practical implementation)
2) After it, how can i make wireless communication b/w my AVR and laptop.(hardware device?)(SPI, RS232, UART?)
MAIN CONFUSION:
1) I cannot help myself differentiating or relating SPI, RS232 and UART.
I know these are used for serial communication between devices but how?(which is used when and why and how)(appropriate hardware for transmitting device and receiving device)
THING TO KNOW:
1) I haven't started making my board and programming it because i think i should learn everything first and then do it in a one go. OR should i start practical work and things get easier automatically??
2) I learnt a tutorial series on Serial Communication from http://maxembedded.com/2013/09/serial-communication-introduction/ the starting 5 topics leaving the last one(I2C). Am i missing something there?
I hope everything is clear, and waiting for a good-men's words.
Note: I am already very misguided and lost, so i want experienced and expert's guidance. Many Many Many Many Thanks in Advance.
MY BOARD LOOKS LIKE:
http://www.robotplatform.com/howto/dev_board/schematic_l/38.jpg
1) To upload your code into AVR chip, you can use ISP interface. That requires you to connect at least 5 pins: SCK, MISO, MOSI, RESET, GND, and optionally VCC (it used to control or supply voltage, but not mandatory, if your board has it's own power supply). All you need is just to wire 6- or 10-pin ISP connector to that pins of your CPU.
To begin programming process you need to obtain some programmer device (USBasp, AVRISPmk2, STK500/600 etc.), Also, you can use Arduino board itself as ISP-programmer for external AVR chip, like this: http://www.instructables.com/id/Programming-an-ATTiny13A-using-Arduino-servo-int/
Each of programmer model requires it's compatible software (such as PonyProg), for example STK500 and AVRISP programmes could be used directly from Atmel Studio.
Also, you can connect ISP to parallel (LPT) port of the PC, and upload firmware using specialized software, such as uniprof
Another way to upload software - it is to make your own bootloader - a tiny program that will update firmware, using any available interface.
2) USART, SPI, I2C - it is different interfaces to communicate with peripherals. Note that RS232 - it is electrical interface built over USART. I.e. you need external IC which will convert USART logical level signals to RS232 electrical levels.
each of that interfaces have it's own profs and cons. And usually selection of which interface to use depends on which interface is supported by peripherals.
SPI - it is interface for high-speed communication. One master many slaves. It requires a lot of wires: MISO (data from master to slave), MOSI (data from slave to master), SCK (clock) - those three could be common for all slaves. Also it requires a SS (slave select) - one SS wire for each slave to determine which slave is in communication at the moment, also it sets the edges of the data packet.
USART - it is common interface, to communicate two chips. Each byte transmitted with foregoing start bit, optional parity and following stop bit. I.e. transfer has a quarter overhead, but byte can be transmitted in any moment.
Works in synchronous and asynchronous modes. Asynchronous mode requires only 2 wires (RX and TX, not counting GND that also required). This mode requires that receiver and transmitter to be sychronized, in most cases that required to crystal oscillator to be installed.
Synchronous mode works in the same format as asynchronous, but have additional XCK (clock) wire, that determines in which moments bits are possible to be transmitted. This allows to increase transmission speed and not requires time precision from receiver. Synchronous mode is rare used.
I2C - it's a bus with only two wires, allows many masters and many slaves. Utilizes pull-up resistors to achieve wired AND, have it's own algorithm to detect collisions, more complicated to be programmed, transmission speed is limited.
Often used by peripherals, such as accelerometers, RTCs etc.
AVR chips have no it's own support for wireless communication, therefore, to do that you need to use some external wireless chip, for example bluetooth, or WiFi, there are a lot of such modules (for example ESP8266). AVR chip communicate with them using USART, sending and receiving simple commands.

What kind of port is the USB port?

I am developing a serial port communication java-J2ME-J2SE application. There is a mobile phone and a computer ( running Windows XP ). These two machines are communicating through the phone mobile's cable. And the phone mobile's cable is a USB cable. So what is the type of the port : is it COM1 or something else ?
I looked the device manager and I found that the mobile phone ( Alcatel OT-806D ) is in port COM4. Here is a captured image of the device manager:
An USB port is a kind of serial port that computers and devices can use to communicate. It defines the connectors and cables, as well as the physical and link layer protocols that devices must use to communicate over USB. In this sense, it's similar to Ethernet, Firewire or other communication protocols.
At a physical level, USB is a serial protocol, meaning that bits are sent in a serial fashion. Old serial RS-232 ports (traditionally named COMx under Windows) are not related to modern USB architecture. Old serial ports used a simpler and slower communication protocol (RS-232) that was usually handled by a family of chips called UARTs, whereas USB communication requires more complex hardware.
So, the physical and link-layer characteristics of these two protocols are very different. While both are serial protocols, USB allows for several devices to share the same bus (traditional serial ports don't) and communication speed is much higher in USB. Error detection and correction, flow control and other data transfer concerns are better handled in USB.
COM ports are a Windows abstraction to represent any communication port. In other operating systems other names are used. In Linux, the COM1 port is represented by the device /dev/ttyS0.
Note that this is no more than an abstraction. It is possible (and often done) to use serial ports that are not using the traditional, physical, serial port. In fact, you can create operating system drivers that provide serial ports that are in fact communicating over Ethernet, USB, IP or any other communication layer. The COM port at operating system level is no more than an abstraction to represent a communications port.
Mobile phones offer a variety of services through their USB port. This often includes raw serial communication (which you can use in your application), but in many other cases the USB port provides other "profiles" (usb mass storage, headphones, or whatever). All those profiles are standarized so you can plug your phone to a computer and establish a "serial communication" channel, among other things, without having to code communication drivers for the computer or the phone.
So, to answer your question, no, an USB port is not a COM port. It is an USB port. You can use it for serial communications, but you can also use it for other things.
USB means Universal Serial Bus. Generally all os the USB connections on PC will be linked on the same bus. All devices connected to the bus are assigned virtual port numbers. These port numbers will change depending on what is connected to the bus.
However, you won't be communicating with the phone directly but with any driver that is installed for it, unless you're writing the driver itself.
Some phones are not controllable in any way, others may appear as a modem, because that is the functionality that their manufacturer has assigned them through the drive.
My current phone installs as a device in itself (for use with a manufacturers piece of software), a modem and a storage device.
Have a look here for some more information.
um, depends what you mean by "type of port". I think you want to know the name of the port, but what you really need to know is what protocol your phone will understand.
You need to know what protocol (if any) the phone can communicate with over USB. Just because you can connect the phone to a USB cable doesn't mean that you can control the phone. This depends on the phone. Not all phones are built to understand the same protocols.
Also, USB is a serial bus because it transmits data serially on a single line (as opposed to transmitting in parallel over multiple lines), but it doesn't (necessarily) use the same RS-232 protocol as a computer's serial port. If you had a RS-232 device connected to a USB port, then you would connect to it using COM1 (or COM2 or COM3, your operating system assigns this port name).

TCP - LRO/TSO techniques

Why is it must that all interfaces (routers and bridges) involved support LRO/TSO technique ?
Routers don't. Bridges do.
External routers, hubs, switches or anything else that is externally connected to the network will not see the effects of TSO, only interfaces inside the device with TSO will experience any effects - it's a software thing.
A router is an external device which is connected to the network by ethernet cables, fibre optic cables, wireless comms etc. These communication mediums adhere to internation standards such as 803.2 for ethernet or 803.11 for wireless - they're hardware devices, and hardware devices have very strict rules on how they communicate.
A bridge is an internal software construct and is specific to your OS.
Let's use 803.2 (ethernet) and a linux host for an example.
An application calls for a socket to be created and then pushes a large data chunk into the socket. The linux kernel determines which interface this data should be transitted on. The kernel will next interrogate the driver for this interface to determine its capabilities, if the interface is TSO capable the kernel will pass an sk_buff with a single "template" header and a huge chunk of data (more than 1 packets worth) to the interface driver.
Let's consider a standard interface straight to a hardware NIC first:
Some interfaces have fake TSO (they segment the packet in the driver) and some have true TSO (the template header and data are passed to the hardware with minimal alterations). At this point ether the driver or the NIC hardware will convert this large segment of data into multiple, standard compliant, 803.2 ethernet frames, it is these compliant frames that an external device, such as a router, hub, switch, modem or other host will see on the wire.
Now let's consider several NICs behind a software bridge:
Although the kernel is aware of each NIC at a low level, the network stack is only aware of the bride, thus only capabilities that ALL of the underlying NICs have should be passed up to the bridge. If an sk_buff is passed to a bridge, then ALL the interfaces in the bridge will receive the same sk_buff. We'll assume that the kernal has once again passed our large TSO sk_buff to a bridge, if any of the underlying interfaces does not support TSO then the packet will most likely be dropped by the hardware NIC in question.
In summary:
Worst case scenario is the bridge will repeatedly retry to send the same data chunk on the broken interface and the whole bridge will lock up until the application decides to give up. Best case scenario, the non TSO NIC will simply appear to be dead.
That said, if the NIC has unsafe code in its driver then this could cause a segmentation fault that could bring the whole system down.

Resources