Hi I have a FPGA board as the title suggests. I want to hook up 2 PCI cards to it. The block diagram of the board says it has two PCIe ports, however the picture of the board does not contain one. The manual of the FPGA mentions PCIe but the board simply does not have one. Other I/O include USB, RS-232, and SATA. Is there any possible way for me to hook up two PCI cards to the board using some kind of adapter or converter? Here is a link to the block diagram and picture. http://www.systemseng.cornell.edu/intel/team/upload/DE2i-150.pdf
The board has only one mPCIe connector, but the FPGA is using 2 PCIe channels to connect to the CPU chipset.
You should check out the HSMC connector to see if the PCIe signals are available then but I doubt it.
Related
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.
I have successfully compiled a sample program, which came with a developer board. I have also connected to the board via putty and ran the executable which was on the board from the factory. But I can not push my elf file to the board apparently because the debug/programming interface is missing. I can not figure out what the issue is. I turned off Win7's firewall, and defender before I installed the driver. Enclosed are a couple of pics; do I need to purchase a JTAG to usb cable? Right now, I am just connected to the board via the usb interface which is on the board. But the board comes with JATG, and miniJTAG.
#DigiNinja- I have AT97SC3205T-SDK2. Can you also comment on the firewall? Do I need to keep win firewall and defender off all along or just while I install the USB driver?
I posted a pic of the board with all the other interfaces.
Do I need one of these
Here is a pic of Device Programming options:
#all- Thanks. I have a starting point. I need to read the docs now.
The user guide provides the info you need, and can be downloaded here: http://www.atmel.com/Images/Atmel-8528-TPM-I2C-SPI-Development-Kit-UserGuide.pdf
From the user guide:
"The USB bootloader remains pre-programmed in ROM memory. This bootloader may be used to either reload the TPM demonstration software images or to load the SAM4S ARM demonstration software. The kit has a JTAG connector that can be detached from the kit and connected to the mini JTAG connector on the board. This will allow the reprogramming of the SAM4S ARM."
So that means you should be able to load new software images using the pre-loaded USB bootloader. If you don't want to use the bootloader or it's been removed then you will need to use JTAG.
From the user guide: "For more advanced in-system programming techniques, the In-System Programmer SAM JTAG ICE combined with Atmel Studio® can be utilized over the provided JTAG interface port to exercise complete programming control over the processor."
So what is the easiest way to get started? There are so many options available it's hard to decide, from a beginner's standpoint, which is the best.
What is the best option for simple wireless communication? That is, communication from a controller to move a robot, or from an arduino to relay information back to a computer for processing.
Drawing from your experiences, what's the 'best' option in your opinion?
Bluetooth would be the most flexible, however I believe xbee to be the easiest. Software wise xbee is exactly the same as serial an even allows for wireless reprogramming and the higher end ones have some serious range.
Bluetooth can be easy if you have a Bluetooth device you're trying to talk to (e.g. Mac-book or Smartphone). The problem is that Bluetooth radios for the the Arduino are still (in 2013) expensive. A Bluetooth radio usually costs more than an Arduino! Low Power Bluetooth may be an option as well. Essentially, Bluetooth is a simple serial transfer of data so you have to create your own protocol on both sides.
Bluetooth Low Energy BLEis an emerging technology and is available on some new devices (recent iPads, macbooks etc: Supoorted Devices ), this may or may not meet your requirements.
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.
What I have in mind is having a number of sensors (temperature, accelerometer, sound level meter) that are controlled by a micro controller. What I want to do is take this information and transmit it wireless to a laptop that will take this information and put it on to a web server using Zigbee. I don't know where to start.
Since you don't have any hardware as of yet, you might want to give the Arduino a try. The hardware is affordable, can be connected to your system via USB while being programmable in-system.
The basic board can be extended via so called "shields", which offer additional features. In your case, the XBee shield would be appropriate. Connecting your laptop to a XBee module is as simple as using Sparkfun's breakout board and a mini-USB cable.
The Arduino has a large community, so you will find a lot of resources, like books, online material, example code etc.
We also provide wireless modules that can be used for serial data transmission. They can be found at www.starmanelectric.com Our modules are very similar to the xbee, but more plug and play. They can be a great for going wireless for the first time. Our devices are designed to function like a "wireless cable" so if you're used to using wires then you'll be up and running in no time at all. We also have circuit examples for transmitting to a laptop serial port or USB. Any micro-controller will be fine for this application, as long as it has a serial port and a few ADCs to sample your data. Our modules also provide simple analog in/out which can run in parallel to the serial. If you want to compare to other systems, I would google "wireless serial modules"
Regards,
Michael
Starman Electric