pmod gps

[zahid]

Hello sir

i need help i have nexys 2 spartan 3e kit and pmod gps.i need to use pmod gps but dont know how.is there a way to use pmod in microblaze and c code r HDL code please provide me. thanks

 

[D@n]

@zahid,

Welcome to the PModGPS.  I've got it, and I've integrated it with both a Basys-3 and now an Arty design.

The most basic thing you need to know in order to work with it is that the interface is fundamentally a UART/serial port.  If you are wondering if it works, just connect the output port from the PmodGPS (via FPGA logic) to the UART transmit port from your board to the USB.  It's a simple enough (4 line?) verilog  program to write, and it'll allow you to know that the device works.  Remember--until/unless you change it, the serial port works at 9600 Baud, 8 data bits, no parity bits, one stop bit.

I can't really speak to any microblaze usage.  I've been using the GPS via the ZipCPU and Verilog RTL instead.  Specifically, I have the Verilog tracking the PPS logic to get/achieve better than one microsecond timing resolution within my design.  It works well ... when GPS is in view.  For me, that's nearly all the time.  For others who've tried it from their basement, that may be never.  Your mileage might vary.

Yours,

Dan

[jpeyron]

Hi Zahid,

Here is a link to Digilents Github for the PmodGPS IP. Here is a link on how to use our ip's.

cheers,

Jon 

[zahid]

@D@n thanks sir.but i dont get how to " connect the output port from the PmodGPS (via FPGA logic) to the UART transmit port from your board to the USB". I want to take data from pmod gps and parse it to get latitude and longitude value then send that latitude and longitude value to builtin uart in my nexys 2 kit to check whether code is working ok.later i will use builtin uart fo GSM module.

[zahid]

@jpeyron the vivado dont support old fpga series like my Nexys 2 so i guess i cant work that.

 

[D@n]

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

[zahid]

@D@n yes i will follow you. i need to design a tracking system that will give us latitude and logitude value using gsm. i have done programs on vhdl of TX and RX between pc and fpga they work fine.but then someone suggested me about microblaze i studied that and done TX and RX program in c language also. but i was stuck there how to use pmods. i really need your help please help me to get through this task.

[D@n]

@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

[zahid]

Hello Sir @D@n I was trying a uart code and receiving this warning

Command Line: bitgen -intstyle ise -f UART_RX_TOP.ut UART_RX_TOP.ncd
WARNING:PhysDesignRules:367 - The signal <i_Clk_IBUF> is incomplete. The signal
   does not drive any load pins in the design.
WARNING:PhysDesignRules:367 - The signal <i_UART_RX_IBUF> is incomplete. The
   signal does not drive any load pins in the design.
 

 

any suggestion please. following is a top level

module UART_RX_TOP
  (input i_Clk ,     // Main Clock
   input i_UART_RX , // UART RX Data
   output [7:0] leds
    );
 
  wire w_RX_DV;
  wire [7:0] w_RX_Byte;
   
  
 //receiver instatiate
  // 25,000,000 / 115,200 = 217
  UART_RX #(.CLKS_PER_BIT(5208)) UART_RX_Inst
  (.i_Clock(i_Clk),
   .i_RX_Serial(i_UART_RX),
   .o_RX_DV(w_RX_DV),
   .o_RX_Byte(w_RX_Byte));

[D@n]

Here's an answer record that discusses the problem you cite, though taking place in someone else's design.

Basically, you've left something unconnected (somehow) and ISE is trying to clean things up for you.

For example, if the output of your serial port isn't going anywhere, ISE might judge that it doesn't need your serial port, and once the serial port is gone then it might judge it no longer needs the clock, etc.  If your entire project was the snippet you clipped above, then I can see the problem--nothings connected to anything to do anything.  If you've got more to your project than what you pasted above, then you'll have to dig a touch deeper.

To find the root of the problem, though, you need to look through the synthesis report.  Reading from the top will help you find the first unconnected register, and then things usually cascade backwards through your logic from there.

Dan

[zahid]

@D@n

I m currently working on gps parsing to get just latitude and longitude value.Is there any verilog code or logic you have in mind?

Let say I receive bit by bit from serial convert that to byte in "RxD_data[7:0] now I don't want to send all received  data to transmitter but latitude and longitude.

 

[D@n]

@zahid,

Processing a slow byte-stream is just the sort of thing CPU's tend to handle better than FPGAs.  It is for this type of problem that many people place CPUs on their FPGAs.  Indeed, processing a GPS stream was one of the initial programs I had my ZipCPU running on a Basys-3 board run.

Dan