UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Participant glennparaiso
Participant
2,049 Views
Registered: ‎10-11-2016

Polled mode: Interfacing GPS in Pmod Zedboard

Jump to solution

Dear FPGA experts,

 

May I ask some valuable comments and suggestions on the experts on this forum regarding of our encoutered problem.

We interface our ublox M8U gps into a xilinx zedboard using the UART-Pmod connections. Created the hardware design and routed the Ublox gps signals into the PL side using the axi-uartlite IP. Then, in SDK, we used the axi-uartlite pre built code "uartlite_polled_example.c" and take some minor changes in order to get the data directly in the ublox gps module. Running the program and printing the Received buffer was successfull.

 

But comparing the hex data received, between the sdk and the hex data recieved using the logic analyzer are different. We pressumed  that the data in the logic analyzer are correct since it was coincide with the message structuring of the ublox protocol specification manual. 

 

I also attached  the code used,  hardware design, logic analyzer result and the sample output data for you to validate my findings aboved.

 

My understanding with the logic analyzer result as againts in the sdk hex data is that " header tag + class id tag + length of data bytes" should be the same.

 

Hope to hear from you.

 

Thanks.

 

Best regards,

Glenn

 

 

 

 

/******************************************************************************
*
* Copyright (C) 2002 - 2015 Xilinx, Inc. All rights reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* Use of the Software is limited solely to applications:
* (a) running on a Xilinx device, or
* (b) that interact with a Xilinx device through a bus or interconnect.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* XILINX BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
* WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
* OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*
* Except as contained in this notice, the name of the Xilinx shall not be used
* in advertising or otherwise to promote the sale, use or other dealings in
* this Software without prior written authorization from Xilinx.
*
******************************************************************************/
/******************************************************************************/
/**
*
* @file xuartlite_polled_example.c
*
* This file contains a design example using the UartLite driver (XUartLite) and
* hardware device using the polled mode.
*
* @note
*
* The user must provide a physical loopback such that data which is
* transmitted will be received.
*
* MODIFICATION HISTORY:
* <pre>
* Ver Who Date Changes
* ----- ---- -------- -----------------------------------------------
* 1.00a jhl 02/13/02 First release
* 1.00a sv 06/13/05 Minor changes to comply to Doxygen and coding guidelines
* 2.00a ktn 10/20/09 Updated this example to wait for valid data in receive
* fifo instead of Tx fifo empty to update receive buffer
* and minor changes as per coding guidelines.
* 3.2 ms 01/23/17 Added xil_printf statement in main function to
* ensure that "Successfully ran" and "Failed" strings
* are available in all examples. This is a fix for
* CR-965028.
* </pre>
******************************************************************************/

/***************************** Include Files *********************************/

#include "xparameters.h"
#include "xstatus.h"
#include "xuartlite.h"
#include "xil_printf.h"

/************************** Constant Definitions *****************************/

/*
* The following constants map to the XPAR parameters created in the
* xparameters.h file. They are defined here such that a user can easily
* change all the needed parameters in one place.
*/
#define UARTLITE_DEVICE_ID XPAR_UARTLITE_0_DEVICE_ID

/*
* The following constant controls the length of the buffers to be sent
* and received with the UartLite, this constant must be 16 bytes or less since
* this is a single threaded non-interrupt driven example such that the
* entire buffer will fit into the transmit and receive FIFOs of the UartLite.
*/
#define TEST_BUFFER_SIZE 700

/**************************** Type Definitions *******************************/


/***************** Macros (Inline Functions) Definitions *********************/


/************************** Function Prototypes ******************************/

int UartLitePolledExample(u16 DeviceId);

/************************** Variable Definitions *****************************/

XUartLite UartLite; /* Instance of the UartLite Device */

/*
* The following buffers are used in this example to send and receive data
* with the UartLite.
*/
u8 SendBuffer[TEST_BUFFER_SIZE]; /* Buffer for Transmitting Data */
//u8 RecvBuffer[TEST_BUFFER_SIZE]; /* Buffer for Receiving Data */
char RecvBuffer[TEST_BUFFER_SIZE]; /* Buffer for Receiving Data */


/*****************************************************************************/
/**
*
* Main function to call the Uartlite polled example.
*
* @param None.
*
* @return XST_SUCCESS if successful, otherwise XST_FAILURE.
*
* @note None.
*
******************************************************************************/
int main(void)
{
int Status;

/*
* Run the UartLite polled example, specify the Device ID that is
* generated in xparameters.h
*/
Status = UartLitePolledExample(UARTLITE_DEVICE_ID);
if (Status != XST_SUCCESS) {
xil_printf("Uartlite polled Example Failed\r\n");
return XST_FAILURE;
}

xil_printf("Successfully ran Uartlite polled Example\r\n");

/*for (int Index = 0; Index < TEST_BUFFER_SIZE; Index++) {

xil_printf("Buffer[%d] = %x\n",Index,RecvBuffer[Index]);

}
*/

 

/*int i=1;

while(1){

xil_printf("Buffer[%d] = %d\n",i,RecvBuffer);

i++;

}

*/

return XST_SUCCESS;

}


/****************************************************************************/
/**
* This function does a minimal test on the UartLite device and driver as a
* design example. The purpose of this function is to illustrate
* how to use the XUartLite component.
*
* This function sends data and expects to receive the data thru the UartLite
* such that a physical loopback must be done with the transmit and receive
* signals of the UartLite.
*
* This function polls the UartLite and does not require the use of interrupts.
*
* @param DeviceId is the Device ID of the UartLite and is the
* XPAR_<uartlite_instance>_DEVICE_ID value from xparameters.h.
*
* @return XST_SUCCESS if successful, XST_FAILURE if unsuccessful.
*
*
* @note
*
* This function calls the UartLite driver functions in a blocking mode such that
* if the transmit data does not loopback to the receive, this function may
* not return.
*
****************************************************************************/
int UartLitePolledExample(u16 DeviceId)
{
int Status;
unsigned int SentCount;
int ReceivedCount = 0;
int InitCount = 0;
int i;

int Index;

/*
* Initialize the UartLite driver so that it is ready to use.
*/
Status = XUartLite_Initialize(&UartLite, DeviceId);
if (Status != XST_SUCCESS) {
return XST_FAILURE;
}

/*
* Perform a self-test to ensure that the hardware was built correctly.
*/
Status = XUartLite_SelfTest(&UartLite);
if (Status != XST_SUCCESS) {
return XST_FAILURE;
}

/*
* Initialize the send buffer bytes with a pattern to send and the
* the receive buffer bytes to zero.
*/
//for (Index = 0; Index < TEST_BUFFER_SIZE; Index++) {
// SendBuffer[Index] = Index;
// RecvBuffer[Index] = 0;
//}

/*
* Send the buffer through the UartLite waiting til the data can be sent
* (block), if the specified number of bytes was not sent successfully,
* then an error occurred.
*/
//SentCount = XUartLite_Send(&UartLite, SendBuffer, TEST_BUFFER_SIZE);
//if (SentCount != TEST_BUFFER_SIZE) {
// return XST_FAILURE;
//}

/*
* Receive the number of bytes which is transfered.
* Data may be received in fifo with some delay hence we continuously
* check the receive fifo for valid data and update the receive buffer
* accordingly.
*/
while(1) {


while ((ReceivedCount = XUartLite_Recv(&UartLite,RecvBuffer,TEST_BUFFER_SIZE)) > 0)

{

//InitCount = RecvBuffer[0];

//xil_printf("Init count is %x\n", InitCount);

for(i=0; i<TEST_BUFFER_SIZE; i++)
{
//xil_printf("buffer[%d] = %x" ,i,RecvBuffer[i]);
xil_printf("%02x" ,RecvBuffer[i]);


}

xil_printf("\n");

 

 

//xil_printf("data is %x \n",RecvBuffer[0]);


if(InitCount == 0xB5620107)
{
xil_printf("Good!!!!");

return XST_SUCCESS;
//break;
}
//InitCount += XUartLite_Recv(&UartLite,RecvBuffer,1);

//if(InitCount==1 & RecvBuffer[0]== 0xB5){

//ReceivedCount += XUartLite_Recv(&UartLite,
// RecvBuffer + ReceivedCount,
// TEST_BUFFER_SIZE - ReceivedCount);

}

}

 


//ReceivedCount = XUartLite_Recv(&UartLite, RecvBuffer ,TEST_BUFFER_SIZE);

//xil_printf("Received Count is %d\n",ReceivedCount );

//if (ReceivedCount == TEST_BUFFER_SIZE) {
// break;
//}
//}

/*
* Check the receive buffer data against the send buffer and verify the
* data was correctly received.
*/
//for (Index = 0; Index < TEST_BUFFER_SIZE; Index++) {
// if (SendBuffer[Index] != RecvBuffer[Index]) {
// return XST_FAILURE;
//}
//}

//xil_printf("Received Count is %d\n", ReceivedCount);

//for (Index = 0; Index < TEST_BUFFER_SIZE; Index++) {
//xil_printf("Buffer[%d] = %x\n",Index,RecvBuffer[Index]);

//}
return XST_SUCCESS;
}

 

0 Kudos
1 Solution

Accepted Solutions
Participant glennparaiso
Participant
2,891 Views
Registered: ‎10-11-2016

Re: Polled mode: Interfacing GPS in Pmod Zedboard

Jump to solution
@austin

Yeah, your right. Its working now, just need to edit the data bytes size in the sdk.

Thank you.

Best regards,
Glenn
0 Kudos
7 Replies
Participant glennparaiso
Participant
2,047 Views
Registered: ‎10-11-2016

Re: Polled mode: Interfacing GPS in Pmod Zedboard

Jump to solution

Hi, I converted the sample output into image file to directly viewed. Thanks

sampleOutput.png
0 Kudos
Scholar austin
Scholar
2,006 Views
Registered: ‎02-27-2008

Re: Polled mode: Interfacing GPS in Pmod Zedboard

Jump to solution

Check your logic analyzer setup,

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Participant glennparaiso
Participant
1,986 Views
Registered: ‎10-11-2016

Re: Polled mode: Interfacing GPS in Pmod Zedboard

Jump to solution
hi @austin, which logic analyzer did you mean? I already tried in a Saleae Logic Analyzer software and successfully decoded the correct data. Photo was attached in my first message. My problem is, the data come out in the sdk does not much against in the logic analyzer.
0 Kudos
Scholar austin
Scholar
1,943 Views
Registered: ‎02-27-2008

Re: Polled mode: Interfacing GPS in Pmod Zedboard

Jump to solution

Which is correct?

 

Correct as in what you think should be there, or what is actually there?

 

How do you know?

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Participant glennparaiso
Participant
1,920 Views
Registered: ‎10-11-2016

Re: Polled mode: Interfacing GPS in Pmod Zedboard

Jump to solution
Hi @austin,

Thanks for your feedback.
The correct output is in the Saleae Logic Analyzer software. The generated Hexadecimal data are consistent within the protocol specification manual of the ublox M8U gps (e.g. Header tag-2 bytes, class id-2 bytes, length of data - 2 bytes, array of data). And also, the generated hex data are also the same if using the u-center software from u-blox.
I can say that is correct since, my expected array of hex data bytes that is based on the protocol specification are also the same data coming out from the Saleae Logic Analyzer/U-center.
Maybe, I have some coding error in the sdk part?
Your expert advice/comments is highly appreciated.

Thanks.

Best regards,
Glenn





0 Kudos
Scholar austin
Scholar
1,857 Views
Registered: ‎02-27-2008

Re: Polled mode: Interfacing GPS in Pmod Zedboard

Jump to solution

Yes,

 

A coding error is most likely if actual results are wrong.

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Participant glennparaiso
Participant
2,892 Views
Registered: ‎10-11-2016

Re: Polled mode: Interfacing GPS in Pmod Zedboard

Jump to solution
@austin

Yeah, your right. Its working now, just need to edit the data bytes size in the sdk.

Thank you.

Best regards,
Glenn
0 Kudos