Search the Community

Showing results for tags 'rs232'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • News
    • New Users Introduction
    • Announcements
  • Digilent Technical Forums
    • FPGA
    • Digilent Microcontroller Boards
    • Non-Digilent Microcontrollers
    • Add-on Boards
    • Scopes & Instruments and the WaveForms software
    • LabVIEW
    • FRC
    • Other
  • General Discussion
    • Project Vault
    • Learn
    • Suggestions & Feedback
    • Buy, Sell, Trade
    • Sales Questions
    • Off Topic
    • Educators
    • Technical Based Off-Topic Discussions


  • Community Calendar

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 10 results

  1. Hello, I am currently working on refurbishing an existing programming bench using the Nexys Video™ FPGA Board Development Kit. Requirements for the test station require that I must use direct Tx/Rx RS232 data communication to the Artix-7 FPGA without the use of the FTDI FT232R USB-UART bridgeUART/Serial Converter Interface as described in the user manual. This used to be achieved with a now obselete Spartan-6 FPGA development board that provided a direct RS232 Serial Port on board. I cannot recall the exact model # for the retired board. Is there any way I can input RS232 data directly into the Nexys Video FPGA Dev Kit without the use of a USB/UART Bridge? Thank you
  2. Hi everyone, I am working on a project about drone. The project is sending and receiving data through UART and controlling the four brushless servo motors by getting these value for the speed of servo motors. I could find and combine codes for accomplishing the communication between fpga and the computer. However, I cannot make a relationship between coming data with servo motor. I get the coming UART data one by one by converting integer for duty cycle. Could you help me out this, how can I get the received data and send it to servo motors? Thanks in advance.
  3. Hello Digilent Community! I just finished putting the finishing touches on a UART demonstration project that you can find here. The project was originally intended to share a C++ class that could work with Verilator to prove that anyone's UART implementation was working. However, after I got into it, I realized the project had a lot of value that others might appreciate. As an example, consider this post by @martin16. Had he used any of the testing mechanisms listed below, he might have known which side of the RS232 port he was working with was at fault. The core contains a complete implementation of both a transmit and receive UART encoder/decoder. These can be easily taken from my project and placed within your own. (Subject, of course, to the limits of the GPL v3) The core also contains a (fairly) generic FIFO implementation. For those wondering how to implement a FIFO, you may find this valuable as well. For those who would rather interact with a serial port over a bus, such as the wishbone bus, there are two approaches within the project that can be used to hook it up to a wishbone bus. One can be used within a larger wishbone slave module, the second as a standalone module. Both are Wishbone B4 compliant, and both use the pipeline mode--allowing you to read/write multiple values on consecutive clocks from/to the controller. Of course, this only really makes sense when using the FIFO. Those might be valuable enough on their own, but you can probably find without too much additional work other implementations of the above. Therefore this project includes some even more valuable files: It includes a series of test programs/configurations that can be used to determine if the hardware on your board is working properly. If you are like me, you've struggled every time you've tried to get a serial port working on a new board. Should you connect your output to the TX or to the RX line? Do you have the UART set up properly, at the right baud rate? Can you handle more than just single values at once? How fast can you transmit/receive? To help you answer these questions, the project file contains the following test configurations: Hello World: You know, that old fashioned hello world program? I would recommend trying this program on your board after you can blink an LED at your favorite rate, or equivalently after you know that your clock works. This particular project is so simple that it depends upon only the clock input and the UART transmit output. Getting this program running on your board will demonstrate that you understand your clock, and that you can modify your I/O constraint file properly, and that you know how to connect a terminal program to your board in order to observe the results. Line Test: Once you've got a hello world program running, so that you know the output UART pin works, then it is time to test the input UART pin. This is the purpose of the line test testing program. It works by reading a line of data (either until a newline or 80--characters), and then dumping that line to the output. (Don't forget to turn off hardware flow control, and be aware of the differences between a new line and a carriage return!) SpeechFifo: Finally, there's a program that can be used to test the FIFO capabilities found within the wishbone UART peripheral. This program uses the FIFO capability to make certain the transmitter stays fully loaded for over a thousand characters of output bytes. (No, this isn't computer speech generation, but rather a computer dumping a Abraham Lincoln's Gettysburg Address across the UART port.) Each of these configurations has a corresponding Verilator simulation file associated with it, allowing you to simulate the functionality within them as part of Verilator. The project includes, like I mentioned above, a C++ class that can be used to determine if your own UART is transmitting correctly under a Verilator simuation. This class can also be used generate UART signaling in order to test if your RTL can receive it properly. (See the line test C++ harness discussed below for an example of this.) As complements to each of the testing configurations above, the project contains C++ files to drive each of those within a Verilator context. Some unique features include: The Line Test C++ test harness automatically generates a linetest.vcd file that can be used together with GTKwave to study how the core works. Further, it can be run in either an interactive or an automated mode. The Speech Test C++ test harness can be used in an automated mode, or with the -i switch in a more interactive mode. In this latter mode, the speech test program generates a speechtrace.vcd file that can be used with GTK wave to understand how the UART transmitter, FIFO, the wishbone bus decoder, or even the test harness itself. I hope you find these as valuable as I have. Please feel free to post any questions or comments you might have about this project below. Dan
  4. Hi, I tried to learn RS232 and created a project on Basys 3 with Pmod R232. The plan I would like to do is that whenever I set binary number at 8 switches on Basys 3, the data will be passed to the PC and I can see the character in the hyperterminal. At the same time, the LEDs for the "ON" switches with be turned on. I have successfully generated the bitstream file but it doesn't seems function. Include the Verilog code for transmitter, receiver and top modules. It will be great if someone can give hints to let me finish this project. P.S. I have used the logic from Transmitter module transmitter( input clk, //clock input reset, // reset input transmit, //input to say transmission is ready, can be push button or switch input [7:0] data, // data transmitted output reg TxD // transmit data line ); reg TxDready; //register variable to tell when transmission is ready reg [3:0] bitcounter; //vector 4 bits counter to count up to 9 reg [13:0] counter; //vector 14 bits counter to count the baud rate, counter = clock / baud rate reg state, nextstate; // register state variable reg [9:0] rightshiftreg; // vector data needed to be transmitted 1 start, 8 data & 1 stop bit reg shift, load, clear; //register variable for shifting, loading the bits and clear the counter //counter logic always @ (posedge clk) //positive edge begin if (reset) begin // reset is asserted (reset = 1) state <=0; // state is idle (state = 0) counter <=0; // counter for baud rate is reset to 0 bitcounter <=0; //counter for bit transmission is reset to 0 end else begin counter <= counter + 1; //start counting if (counter >= 10415) //if count to 5207 because we start the conunt from 0, so not 5208 begin state <= nextstate; //state change to next state counter <=0; // reset counter to 0 if (load) rightshiftreg <= {1'b1,data,1'b0}; //load the data if load is asserted if (clear) bitcounter <=0; // reset the bitcounter if clear is asserted if (shift) begin // if shift is asserted rightshiftreg <= rightshiftreg >> 1; //right shift the data as we transmit the data from lsb bitcounter <= bitcounter + 1; //count the bitcounter end end end end //state machine always @ (state, bitcounter, transmit,rightshiftreg) //trigger by change of state, bitcounter or transmit begin load <=0; // set load equal to 0 at the beginning shift <=0; // set shift equal to 0 at the beginning clear <=0; // set clear equal to 0 at the beginning TxDready <=1; // set TxDReady equal to 1 so no transmission. When TxD is zero, the receiver knows it is transmitting TxD <=0; // set TxD equals to 0 at the beginning to avoid latch case (state) 0: begin // idle state if (transmit) begin // assert transmit input nextstate <=1; // set nextstate register variable to 1 to transmit state load <=1; // set load to 1 to prepare to load the data shift <=0; // set shift to 0 so no shift ready yet clear <=0; // set clear to 0 to avoid clear any counter end else begin // if transmit not asserted nextstate <=0; // next state is 0 back to idle TxDready <=1; // set TxD to 1 to avoid any transmission end end 1: begin // transmit state if (bitcounter >=9) begin // check if transmission is complete or not. If complete nextstate <= 0; // set nextstate back to 0 to idle state clear <=1; // set clear to 1 to clear all counters end else begin // if transmisssion is not complete nextstate <= 1; // set nextstate to 1 to stay in transmit state shift <=1; // set shift to 1 to continue shifting the data TxD <= rightshiftreg[0]; // shift the bit to output TxD end end default: begin // idle state if (transmit) begin // assert transmit input nextstate <=1; // set nextstate register variable to 1 to transmit state load <=1; // set load to 1 to prepare to load the data shift <=0; // set shift to 0 so no shift ready yet clear <=0; // set clear to 0 to avoid clear any counter end else begin // if transmit not asserted nextstate <=0; // next state is 0 back to idle TxDready <=1; // set TxD to 1 to avoid any transmission end end endcase end endmodule Receiver module receiver( input clk, //input clock input reset, //input reset input RxD, //input receving data line output [7:0]RxData // output for 8 bits data // output [7:0]LED // output 8 LEDs ); reg shift; // register variable shift to trigger shifting data reg state, nextstate; // register state variable reg [3:0] bitcounter; // register vector 4 bits counter to count up to 9 reg [3:0] samplecounter; // register vector 4 bits sample counter to count up to 9 reg [13:0] counter; // register vector 14 bits counter to count the baud rate reg [9:0] rxshiftreg; //register vector for bit shifting reg clear_bitcounter,inc_bitcounter,inc_samplecounter,clear_samplecounter; //register variable to clear or increment the counter assign RxData = rxshiftreg [8:1]; // assign the RxData // assign LED = RxData; // assign the LED output //counter logic always @ (posedge clk) begin if (reset)begin // if reset is asserted state <=0; // set state to idle bitcounter <=0; // reset the bit counter counter <=0; // reset the counter samplecounter <=0; // reset the sample counter end else begin // if reset is not asserted counter <= counter +1; // start count in the counter if (counter >= 3472) begin // if counter reach the baud rate with sampling counter <=0; //reset the counter state <= nextstate; // assign the state to nextstate if (shift)rxshiftreg <= {RxD,rxshiftreg[9:1]}; //if shift asserted, load the receiving data if (clear_samplecounter) samplecounter <=0; // if clear sampl counter asserted, reset sample counter if (inc_samplecounter) samplecounter <= samplecounter +1; //if increment counter asserted, start sample count if (clear_bitcounter) bitcounter <=0; // if clear bit counter asserted, reset bit counter if (inc_bitcounter)bitcounter <= bitcounter +1; // if increment bit counter asserted, start count bit counter end end end //state machine always @ (state or RxD or bitcounter or samplecounter or rxshiftreg) // triggered by change of state, Rxd and bit counter begin shift <= 0; // set shift to 0 to avoid any shifting clear_samplecounter <=0; // set clear sample counter to 0 to avoid reset inc_samplecounter <=0; // set increment sample counter to 0 to avoid any increment clear_bitcounter <=0; // set clear bit counter to 0 to avoid claring inc_bitcounter <=0; // set increment bit counter to avoid any count nextstate <=0; // set nextstate equals to 0 at the beginning to avoid any latch case (state) 0: begin // idle state if (RxD) // if input RxD data line asserted nextstate <=0; // back to idle state because RxD needs to be low to start transmission else begin // if input RxD data line is not asserted nextstate <=1; //jump to receiving state clear_bitcounter <=1; // trigger to clear bit counter clear_samplecounter <=1; // trigger to clear sample counter end end 1: begin // receiving state if (samplecounter==1) shift <=1; // if sample counter is 1, trigger shift if (samplecounter==3) begin // if sample counter is 3 as the sample rate used is 3 if (bitcounter ==9) begin // check if bit counter if 9 or not nextstate <= 0; // back to idle state if bit counter is 9 as receving is complete end inc_bitcounter <=1; // trigger the increment bit counter if bit counter is not 9 clear_samplecounter <=1; //trigger the sample counter to reset the sample counter end else inc_samplecounter <=1; // if sample is not equal to 3, keep counting end default: begin // idle state if (RxD) // if input RxD data line asserted nextstate <=0; // back to idle state because RxD needs to be low to start transmission else begin // if input RxD data line is not asserted nextstate <=1; //jump to receiving state clear_bitcounter <=1; // trigger to clear bit counter clear_samplecounter <=1; // trigger to clear sample counter end end endcase end endmodule Top module top( input btn0, input [8:0] sw, // input 8 switches , one for transmit input clk, input RxD, output TxD, output [7:0]LED // output 8 LEDs ); wire [7:0] data; assign data = sw; receiver R1 (.clk(clk), .reset(btn0), .RxD(RxD), .RxData(LED)); transmitter T1 (.clk(clk),.transmit(sw[8]), .reset(btn0),.data(sw[7:0]), .TxD(TxD)); endmodule
  5. Hi! I've got an ARTY board and I find the USB connection incredible useful, as it allows to use only one connection to program the FPGA through JTAG while simultaneously act as an USB to serial converter. So, I also bought a JTAG-SMT2-NC to fit into a custom board and it's a very convenient way to program my FPGA, but... is it possible for it to act as the module that fits on the ARTY, and make it be recognized by the PC as a USB-serial converter, using its GPIO pins as the interface with the FPGA, as the ARTY does? That would be really great, but I think it's not possible, is it?
  6. I've been beavering away on a large project, but ended up thinking about how small a Serial TX module could be. While out splitting firewood stumbled over the idea that takes it down top 12 LUTs and 11 flip-flops library IEEE; use IEEE.STD_LOGIC_1164.ALL; entity tiny_rs232_tx is Port ( clk : in STD_LOGIC; bit_tick : in STD_LOGIC; data : in STD_LOGIC_VECTOR(7 downto 0); data_enable : in STD_LOGIC; tx : out STD_LOGIC := '1'; busy : out STD_LOGIC ); end tiny_rs232_tx; architecture Behavioral of tiny_rs232_tx is signal shift_reg : std_logic_vector(9 downto 0) := (others => '1'); signal i_busy : std_logic; begin busy <= i_busy; with shift_reg select i_busy <= '0' when "0000000000", '1' when others; clk_proc: process(clk) begin if rising_edge(clk) then if i_busy = '0' and data_enable = '1' then shift_reg <= '1' & data & '0'; end if; if bit_tick = '1' then if i_busy = '1' then tx <= shift_reg(0); shift_reg <= '0' & shift_reg(9 downto 1); end if; end if; end if; end process; end Behavioral;
  7. I was looking at the PmodUSBUART, PmodRS232, PmodRS232X and the Digilent Pmod Interface specification and need some clarifications The PmodUSBUART and PmodRS232X uses the Type 4 Pinout and the PmodRS232 uses the Type 3 Pinout. The table pinout on the Pmod Interface Specification is for the Host for Type 3 and Type 4 UARTs. Can someone verify that my assumptions are ok?
  8. The Digilent RS232 UART reference component (downloads found on the PmodRS232 and Nexys2 pages, at least), does not do what many (including myself) might expect. If one looks at the documentation, one can see on page 4 that it expects to see 8 data bits PLUS a parity bit. That is quite unusual - most devices sending data over RS232 send a TOTAL of 8 bits (not including the stop and start bits) -- either 7 bits plus parity or 8 bits with no parity. Now, if one doesn't bother to check the parity, and does not send characters one right after the other, or if one includes two stop bits (this last one I have not actually tried), it may appear to work fine. The first stop bit gets interpreted as a parity bit, and the second stop bit (or the empty time between characters) works just like a stop bit - though if one is using parity, parity errors are likely to be raised by the reference component. BUT, if one sends two characters one right after the other, then parity errors and/or framing errors are quite likely. Also, if one is only expecting 7 bits of data, one might be surprised by the extra bit. Its not a huge deal, and not difficult to fix (one can just rip out everything having to do with parity, and just take in 8 bits with no parity, for example [or do the parity computation once you have all 8 bits], or add an interface flag to tell it whether you want 7 bits and parity or 8 bits and no parity, and adjust things accordingly), but I thought I would put a posting out here - I spent a several hours debugging the input section of a little 12 bit computer (whose design goes back to 1973) before I caught on to what the problem actually was.
  9. Hii.. I am a beginner and presently I am working on NEXYS 3 FPGA board, I am trying to communicate NEXYS 3 with my computer using PMOD NIC 100. My doubt is how and by using which Protocol can I interface my PMOD NIC 100..?? can it be interfaced by RS232 since I have to transmit temperature data only (I am using PMOD TMP2 for that) Is it a proper way to communicate it..??..Or should I use any other protocol..?? Kindly Help...
  10. Hi, Somebody was after a way to send the input state of FPGA pins through to a host/PC for logging, so I knocked a quick hack up for them. http://hamsterworks....ex.php/Log_Pins It logs 11 pins as an ASCII string of ones and zeros, followed by a NL and CR, at 9600 baud using RS232, but that can be tweaked. It only sends an update when the state of the input changes. On the development board I'm using it is to an on-board USB virtual serial port, but you could also use a USB to TTL RS232 adapter. Maybe somebody may be able to make use of it as a debugging interface,..