WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2016-May-05 05:28:06

alice_warp
Member
From: Italy
Registered: 2015-Sep-08
Posts: 53

Print output driver

Hi,

Is there a way to print the driver outputs?
For example: if I add a xil_printf at the begin of ad_init() function, I don't see any output in putty.
Thanks,

Alice

Offline

 

#2 2016-May-05 07:55:30

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: Print output driver

Two things:
-Are you using the 802.11 ref design? If so make sure you've selected the correct UART (High or Low) via the DIP switch.

-The ad_init() function is part of the driver for the w3_ad_controller core. You cannot modify divers directly in the SDK. The SDK re-generates source code for drivers in the BSP whenever the BSP is re-built. This re-generation will overwrite any changes to the code in the bsp libsrc folder. To modify driver source code you must:
-Edit the source in the edk_user_repository (in <core_name>/src/)
-In the SDK select Xilinx Tools -> Rescan Repositories
-Right-click on an application that uses that BSP (wlan_mac_dcf for CPU Low, for example) and select Clean

This will trigger a rebuild of the BSP including your driver source code changes.

That said, we definitely do not recommend modifying the source code to the hardware support drivers in the reference designs. You can override any of the defaults set in ad_init() by calling other w3_ad_controller driver functions after ad_init() has run.

Offline

 

#3 2016-May-06 03:59:14

alice_warp
Member
From: Italy
Registered: 2015-Sep-08
Posts: 53

Re: Print output driver

I'm thinking to generate a new IP core for another purpose, and I didn't know how to print some information.
Ok, it's clearer now.
Thank you

Offline

 

#4 2016-May-06 21:44:53

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: Print output driver

I'm thinking to generate a new IP core for another purpose, and I didn't know how to print some information.

Ah, that makes sense.

One suggestion- if your custom IP has a complicated driver that requires lots of code iterations, it's much faster to develop that code as normal (non-driver) application code first. This allows easy editing and auto-re-compiling in the SDK (vs the edit/rescan/clean/compile process for drivers). This is how we developed the drivers for our custom pcores.

Offline

 

Board footer