I am working on a project which requires data to be sent FROM PC TO FPGA,which processes the data and sends it BACK TO PC.
The board I am using is Atlys™ Spartan-6 FPGA Development Board.
The data is to be sent as 1 byte , because 1 byte is processed at each rising edge of the clock.
Could you please suggest me ways of sending data to FPGA ?
Thanks
Pick some method of communication that you have access to IP (intellectual property) cores for. For example, if you can readily access a UDP/IP core for your FPGA, then use that. If you have to develop the HDL yourself, serial protocols (UART, I2C, etc) will be simpler blocks to write. In general, HDL takes longer to develop, debug, and test.
UDP has some advantage because you can use tools like Wireshark to capture packets on the PC (once you get past the initial hurdle of actually getting packets to/from the FPGA). Plus, many people are familiar with UDP in various programming languages (C, C++).
In any case, you'll probably spend time with an oscilloscope and logic analyzer checking out signal levels and timing when data is sent to/from the FPGA.
Related
Recently i was digging information about communication between RaspberryPi and multiple Arduino slaves over long distance wire (10-15 meters). My initial thought was to use I2C, but after doing some research i have found out that wire length is a problem since it does not capable to transit/receive data over such a distance. Maybe someone would have any suggestions?
I was thinking about another approach - communication over ethernet (using shields). I would place a switch between all the Arduino nodes and Raspberry with multi threaded TCP server on RPI. Does it sound reasonable?
P.S. Wireless communication methods are not allowed.
You can use one of many standards for communications, such as RS-485 or CAN-bus. Both of those allow for "long" distances, but the longer the wire, the slower the speed.
You will need transceivers for each device, but you can buy pre-made modules for quite cheap.
I have a remote sensor that talks to the world via a low bandwidth TCP connection over GSM. It can often be in a location with extremely patchy GSM connectivity though. At the moment, the remote sensor waits for a GPRS network and then initiates a TCP connection with the server and then listens for commands (which are only a dozen or so bytes every hour or so)
Is an SMS more or less likely to get through to the remote sensor than being able complete a TCP connection? I guess I'm wondering how likely it is that a network signal strength is sufficient for SMS but not for TCP.
Using standard text messaging services for M2M is good idea if you can fit your data in 140 bytes. For short transmissions, opening an GPRS/1xRTT (2G) IP session, transmitting the data to a server and closing the session is less efficient and more likely to go wrong than sending an SMS.
As a side note, you can also use SMS (MT-SMS) to bring IoT device online (mechanism called "Shoulder-Taps" ).
Compared to data (or voice), SMS use only the signaling part of the mobile network. It's a quite cheap operation in terms of network resources reservation so you'll more likely get through with an SMS than with a data connection in a weak signal environment. One additional advantage is much lower power consumption of your terminal which might be important for M2M context.
As stated by #Jarek previously, you need to be able to pack your data into 140 bytes or to forge "long" SMSes which are kind of concatenation of "simple" 140-bytes SMSes
I'm trying to understand whether its redundant for me to include some kind of CRC or checksum in my communication protocol. Does the chrome.serial and other chrome hardware communication API's in general if anyone can speak to them (e.g. chrome.hid, chrome.bluetoothLowEnergy, ...)
Serial communications is simply a way of transmitting bits and its major reason for existence is that it's one bit at a time -- and can therefore work over just a single communications link, such as a simple telephone line. There's no built-in CRC or checksum or anything.
There are many systems that live on top of serial comms that attempt to deal with the fact that communications often takes place in a noisy environment. Back in the day of modems over telephone lines, you might have to deal with the fact that someone else in the house might pick up another extension on the phone line and inject a bunch of noise into your download. Thus, protocols like XMODEM were invented, wrappering serial comms in a more robust framework. (Then, when XMODEM proved unreliable, we went to YMODEM and ZMODEM.)
Depending on what you're talking to (for example, a device like an Arduino connnected to a USB serial port over a wire that's 25 cm long) you might find that putting the work into checksumming the data isn't worth the trouble, because the likelihood of interference is so low and the consequences are trivial. On the other hand, if you're talking to a controller for a laser weapon, you might want to make sure the command you send is the command that's received.
I don't know anything about the other systems you mention, but I'm old enough to have spent a lot of time doing serial comms back in the '80s (and now doing it again for devices using chrome.serial, go figure).
I'm using Chrome's serial API to communicate with Arduino devices, and I have yet to experience random corruption in the middle of an exchange (my exchanges are short bursts, 50-500 bytes max). However, I do see garbage bytes blast out if a connection is flaky or a cable is "rudely" disconnected (like a few minutes ago when I tripped over the FTDI cable).
In my project, a mis-processed command wont break anything, and I can get by with a master-slave protocol. Because of this, I designed a pretty slim solution: The Arduino slave listens for an "attention byte" (!) followed by a command byte, after which it reads a fixed number of data bytes depending on the command. Since the Arduino discards until it hears an attention byte and a valid command, the breaking-errors usually occur when a connection is cut while a slave is "awaiting x data bytes". To account for this, the first thing the master does on connect is to blindly blast out enough AT bytes to push the Arduino through "awaiting data" even in the worst-case-scenario. Crude, yet sufficient.
I realize my solution is pretty lo-fi, so I did a bit of surfing around and I found this post to be pretty comprehensive: Simple serial point-to-point communication protocol
Also, if you need a strategy for error-correction over error-detection/re-transmission (or over my strategy, which I guess is "error-brute-forcing"), you may want to check out the link to a technique called "Hamming," near the bottom of that thread - That one looked promising!
Good luck!
-Matt
I'm working on code that communicates via serial port between different languages and different platforms, and I'd like a single test mechanism I can use that'll hook up to a serial port and then run a series of scripted conversations (send "this", wait for "that", pause 2s, wait for "that" again etc). Messages are binary. I could write something, but there must already be something out there for this that's had decades to mature, so not only would I be re-inventing the wheel but I'd probably be making it triangular. Does anyone know of such a thing? Can be either Windows or Linux.
I´m not sure to understand your question... If what you are developing is a propietary (your own) serial protocol to execute some tasks from different platforms (with different programming languages), all talking your protocol, and what you want to do is to plug a serial cable from/to PC-device and send from the PC serial commands of your protocol to the device (could be another PC) to test your software, yes, there are plenty of software to send serial data:
With some limitations on the free versión:
http://www.commfront.com/commfront-downloads.htm
A full free software from Extron (you can send a script file):
http://www.extron.com/product/software.aspx?id=dataviewer&s=5
There are many more, specially if want to waste your money, but those are the ones i´ve worked with for some years and works great.
I'm building an electronic device that has to be prepared for RS232 connections, and I'd like to know if it's really necessary to make room for more than 3 pins (Tx, Rx, GND) on each port.
If I don't use the rest of signals (those made for handshaking): am I going to find problems communicating with any device?
Generally, yes, that's a problem. The kind of problem that you can only avoid if you can give specific instructions to the client on how to configure the port on his end. Which is never not a problem, if that's not done properly then data transfer just won't occur and finding out why can be very awkward. You are almost guaranteed to get a support call.
A lot of standard programs pay attention to your DTR signal, DSR on their end. Data Terminal Ready indicates that your device is powered up and whatever the client receives is not produced by electrical noise. Without DSR they'll just ignore what you send. Very simple to implement, just tie it to your power supply.
Pretty common is flow control through the RTS/CTS signals. If enabled in the client program, it won't send you anything until you turn on the Request To Send signal. Again very simple to implement if you don't need flow control, just tie it logically high like DTR so the client program's configuration doesn't matter.
DCD and Ring are modem signals, pretty unlikely to matter to a generic device. Tie them logically low.
Very simple to implement, avoids lots of mishaps and support calls, do wire them.
And do consider whether you can actually live without flow control. It is very rarely a problem on the client end, modern machines can very easily keep up with the kind of data rates that are common on serial ports. That is not necessarily the case on your end, the usual limitation is the amount of RAM you can reserve for the receive buffer and the speed of the embedded processor. A modern machine can firehose you with data pretty easily. If your uart FIFO or receive interrupt handler or data processing code cannot keep up then the inevitable data loss is very hard to deal with. Not an issue if you use RTS/CTS or Xon/Xoff handshaking or if you use a master/slave protocol or are comfortable with a low enough baudrate.