cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
474 Views
Registered: ‎08-21-2019

Enable UART Input in PS for ZCU102

Jump to solution

Hi all,

I have a Rev 1.1 ZCU102 and am wondering how to enable UART input to a baremetal (or FreeRTOS) application. I see UART output, and have my serial port configured in tera term such that:

Baud Rate: 115200
Data: 8 bit
Parity: none
Stop: 1 bit
Flow control: None

What do I need to do in the PS to enable UART input? I am trying to add a CLI to my application.

Running @ver in the system controller menu gives July 5 2017, 11:32:33. My IDCODE_HEX under device properties in Vivado is:

IDCODE_HEX 24738093

 

Thanks

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Adventurer
Adventurer
463 Views
Registered: ‎05-08-2018

Hi @candlejack,

When you say you can see UART output, I assume that you are able to run a small 'hello world' kind of program, and sucessfully see the output on your terminal from your 'xil_printf' statements. 

If this is the case, it means that the uart is configured correctly. 

Now, getting input from the UART is slightly different. I don't know what's your level of knowledge with all this, so I will assume you are a truly getting started with all this stuff.

As you may (or not) know, UART data can be received in two ways, polled or by interrupt (as pretty much anything in informatics). The PS UART baremetal driver implements two functions : inbyte and outbyte. They are the building blocks for higher level functions like xil_printf (the lightweight xilinx equivalent of the stdlib printf). As a mater of fact, stdlib functions such as printf, scanf, etc will work just fine because your bsp will provite the functions inbyte and outbyte. Those two functions are polled. So when you call xil_printf, then a while loop will call outbyte for every character of your string you want to print. Outbyte will block waiting for the previous byte to be sent, so if you do a lot of xil_printfs with long strings, you will slow down considerably your program. 

Now for input, things are a bit more complicated. The bare 'inbyte' function will block until a byte is received. The more complex input functions like scanf or getline will block too... possibly indefinitely ! So if your inputs are not very deterministic, then you encounter big risks.

I prefer, like any professional, to use the interrupt method. It is more complicated, of course, but yields the best perfosmance. 

Take a look at the psuart driver in the bsp project in SDK. Right click and open examples. 

Basically, here are the steps : 

- Initialize the interrupt controller (GIC)

- Initialise the PS UART

- Register a callback function to the interrupt number of the uart to the gic.

- Enable the interruption in the GIC

- Activate the different interrupt source in the UART.

 

Then, inside the interrupt callback, you will put code to retreive the received bytes and put them in a circular buffer. If you use freertos, then you would put the bytes in some form of buffer of message buffer. If you have a task waiting for data on that queue, it will be woken up.

 

All in all, if it's for a CLI, you should check the CLI page of freertos and get their example task function that implements the CLI, and replace the function that retreives a byte by a function that retreives a byte from a freertos queue that is itself feed by your interruption.

Simon 

View solution in original post

1 Reply
Highlighted
Adventurer
Adventurer
464 Views
Registered: ‎05-08-2018

Hi @candlejack,

When you say you can see UART output, I assume that you are able to run a small 'hello world' kind of program, and sucessfully see the output on your terminal from your 'xil_printf' statements. 

If this is the case, it means that the uart is configured correctly. 

Now, getting input from the UART is slightly different. I don't know what's your level of knowledge with all this, so I will assume you are a truly getting started with all this stuff.

As you may (or not) know, UART data can be received in two ways, polled or by interrupt (as pretty much anything in informatics). The PS UART baremetal driver implements two functions : inbyte and outbyte. They are the building blocks for higher level functions like xil_printf (the lightweight xilinx equivalent of the stdlib printf). As a mater of fact, stdlib functions such as printf, scanf, etc will work just fine because your bsp will provite the functions inbyte and outbyte. Those two functions are polled. So when you call xil_printf, then a while loop will call outbyte for every character of your string you want to print. Outbyte will block waiting for the previous byte to be sent, so if you do a lot of xil_printfs with long strings, you will slow down considerably your program. 

Now for input, things are a bit more complicated. The bare 'inbyte' function will block until a byte is received. The more complex input functions like scanf or getline will block too... possibly indefinitely ! So if your inputs are not very deterministic, then you encounter big risks.

I prefer, like any professional, to use the interrupt method. It is more complicated, of course, but yields the best perfosmance. 

Take a look at the psuart driver in the bsp project in SDK. Right click and open examples. 

Basically, here are the steps : 

- Initialize the interrupt controller (GIC)

- Initialise the PS UART

- Register a callback function to the interrupt number of the uart to the gic.

- Enable the interruption in the GIC

- Activate the different interrupt source in the UART.

 

Then, inside the interrupt callback, you will put code to retreive the received bytes and put them in a circular buffer. If you use freertos, then you would put the bytes in some form of buffer of message buffer. If you have a task waiting for data on that queue, it will be woken up.

 

All in all, if it's for a CLI, you should check the CLI page of freertos and get their example task function that implements the CLI, and replace the function that retreives a byte by a function that retreives a byte from a freertos queue that is itself feed by your interruption.

Simon 

View solution in original post