zahid

Members
  • Content Count

    18
  • Joined

  • Last visited


Reputation Activity

  1. Like
    zahid reacted to D@n in UART   
    @zahid,
    Yeah, ... but ... we still haven't solved your original problem--that of receiving every other letter when you pipe things directly from the GPS to your computer.  But, at least now, we know some new things:
    We know that your computer isn't broken, neither is the serial port or terminal on it, and the cable you are using appears to be good then. We know there are no foreign character set issues, such as things that take 2 characters to print one. We know that it can successfully receive at 9600 Baud.  (We're you trying with the extra stop bit, or not? So, the question now is, what happened and what can we do to fix it?
    Here's my thought: when you used the echo test program to read from your GPS device, we rounded the number of baud clocks downward (as the spec suggests).  The result, though, was that the receiver--which calibrates its input to the start bit of each character, was receiving the characters in just a couple clocks fewer than the transmitter was using.  The result, then, was that when the receiver was done with the second character -- the transmitter was still transmitting the last one.  The receiver strobes the line for the transmitter to start (i_wr inside txuart.v), but the transmitter is still busy ... so it ignores the write request.  By the time the next byte is received, the transmitter is now idle and ready to accept the next request.  As a result, you got what you saw above: every other character received.  The problem was in your FPGA code, and not within your host.
    Suppose we test this? 
    If you want to go back to your echo test and try again, then try setting the i_setup register to one or two clocks faster. When I personally ran the test to echo what was received from the GPS receiver to the PC/host (I haven't posted the code for this), I switched the line speed from 9600 Baud up to 115,200 Baud or faster, such as 1MBaud.  At this high speed, you wouldn't have a problem.  To do this, you'd need to set the setup register on the transmitter (txuart) for 115,200 Baud and that on the receiver (rxuart) for 9600 Baud--you'd also set your PC for the 115,200 Baud. Another possibility might be to try the line testing program.  This one should manage to do large strings without losing anything, but I expect it would still struggle after a long series of things were received--only to recover by the top of the next second. So, at this point, I think we know what's going on and can move forward successfully.  Feel free to tell me how any of these new tests work!
    Dan
  2. Like
    zahid reacted to D@n in UART   
    You might consider this project.  It is one I know and can speak to.  I know, for example, that this file when used as a top-level not only works, but also broadcasts a long speech with no breaks between the characters.  You will need to change the setup register to 30'd434 if you wish to get 115200 baud out from a 50MHz clock.
    If you only get some characters through while using this approach, then the problem is on the receiving end.
    Dan
  3. Like
    zahid reacted to D@n in pmod gps   
    @zahid,
    Aah ... microblaze is not my specialty.  I don't use it.  There are many problems associated with it: it's a black box, you can't debug all of the pieces to it, when you have problems with it then it is hard to know how to solve them, it hides much of the complexity/reality of a design from you, it's not portable to non-Xilinx parts such as Altera, Lattice, or Actel, etc.   Making matters worse, most of the components I use work with a wishbone bus, not the AXI bus microblaze uses.  While I have built a bridge to convert from AXI to wishbone, since I don't use AXI it ... hasn't gotten the testing it needs.  (The wishbone to axi bridge works quite nicely though ...)
    Many others on this forum will be able to guide you through a microblaze design.  The trick is to build the design, perhaps including external components, and then to export the design so that you can fill in the blanks of those external components.  Again, this isn't my specialty, so I'm not sure I can offer much guidance with that approach.  However, using this design you would use other components other than the ones I might suggest/recommend for you.
    Still, if you follow the wbuart approach, you can try the test programs and get them to work:
    Hello World, to know that you can transmit over the board serial port EchoTest, to know that you can reecive as well as transmit.  (You could set this up to receive from your board, and transmit to your built-in USB serial port--there's not much more to this than the code I gave you above.) LineTest, just adds some logic to the echo test.  Specifically, it waits for a line of data before dumping the output out. Getting these working will be a good/strong start towards getting something up and running. 
    After that, you might want to sit back and consider your next step.  There are lots of possibilities out there.  For example, it looks like you will need a CPU.  You might wish, then, to start working on getting microblaze up and running on your platform.
    Dan
  4. Like
    zahid reacted to D@n in pmod gps   
    What I was referring to was a really, *really* simple configuration that might look like:
    module toplevel(i_pmod_gps_rx, o_usb_uart_tx); input i_pmod_gps_rx; output wire o_usb_uart_tx; assign o_usb_uart_tx = i_pmod_gps_rx; endmodule You will need an XDC file to go with this--one that maps the GPS rx pmod pins to one of your FPGA's pins, and likewise maps the UART tx port.  Write back if this is where you are struggling, and we can go into it.
    The configuration above would allow you to use a terminal program on your host computer to read what's coming from the GPS, while using the FPGA as a pass-through.  If nothing else, it would help you learn of the UART settings associated with the GPS stream (600 baud, 8 data bits, no parity, 1 stop bit), how to configure your UART terminal to those settings, and perhaps even how to parse the GPS messages.
    This would be the first step in your journey.  As in any journey, there will be many steps within it.
    If you would like to follow my path, you can find several RTL/source code files in this wbuart project that you might find valuable.  In particular, the rxuart.v and txuart.v files will show you how you can read from and write to a generic serial port, and the many "test-benches" within the project will give you chances to test these modules.  There's also a wishbone bus-controlled component, which I've used when connecting the PModGPS to a wishbone bus, from which I can then make a CPU the master of it and do as you are describing.  Not knowing how you wish to design your system, I'd hesitate to declare this the one sized fits all path for everybody though.
    Dan