vitis

[ejc]

I have just successfully completed  the getting started with ip integrator and even changed some things to make the leds do something different.

So I have a general idea of how you use the ip integrator from start to programming the board.  However, I have a question.

Normally in C you use a printf statement to print on the console, but in vitis you use xil_printf.    If I didn't have a C program already made for me, as in the tutorial,

I would have used the printf statement?   However, you have to use the Xil_printf statement.  Is there a place you can point me to that would have statement syntaxes that are unique  for C as used in Vitis so I would know how to talk to the circuit I design in ip integrator?    

 

Another example in the tutorial was that you had to initialize the GPIO.   How would I have known this unless some instruction told me you have to do this.

So this is the information that I am looking for, something that explains to me what special C commands or initializations you have to in order  to talk to your ip design.

 

ejc

[zygot]

5 hours ago, ejc said:

However, you have to use the Xil_printf statement

Xil_printf is preferred. If you look you can find out why in the documentation.

5 hours ago, ejc said:

Another example in the tutorial was that you had to initialize the GPIO.

Actually, you have two choices with C and Xilinx software libraries. You can call Xilinx library functions to access the hardware, which generally requires initialization as a first step, or you can just reference the hardware according to the address map in the system.mss. Fortunately, Xilinx provides example project code samples for most of its libraries.

5 hours ago, ejc said:

How would I have known this unless some instruction told me you have to do this.

Uh, you could read through the Xilinx documentation on how to use the SDK or Vitas. Admittedly, this isn't always a satisfying route. You can also build example projects and look through the code, but expect them to use the formal library function method of accessing hardware resources. If you are really stuck, you can post a question on this forum. Be aware that the answer you are looking for might not be the one that's best to help you develop your skills; that is the answer you get might be better help than what you think might be a good answer.

[JColvin]

Hello,

In terms of not explaining that you need to initialize the GPIO, that is an unfortunate drawback of having Digilent engineers with limited to no teaching experience create the material; they've spent a number of years in college (and now in the workforce at Digilent) working with these boards (and Arduino styled boards) where initializing the GPIO was nearly always a requirement, so it's become second nature and we don't think about it as much. Zygot is correct though on the Xilinx documentation being the best resource in the end for using their material since in the end, that's all Digilent did when we were creating our own material. Then there's the reality that cramming/imparting years of experience into a few tutorials is difficult to do, otherwise schools and universities would probably look and act a bit different than they do currently.

Regardless, I will let our content creators know about this feedback so we can put these sort of details in our Getting Started guides.

Thanks,
JColvin

[zygot]

3 hours ago, JColvin said:

there's the reality that cramming/imparting years of experience into a few tutorials is difficult to do

For most of the projects that I've posted to the Project Vault I provide instructions for users on how to use the source code to re-create and build the project. My usual process is to create a zip archive of the project, un-zip it on a different computer and go through the instructions to make sure that they are correct and I can recreate my own work based on the contents of the archive. I still manage to miss things and post projects needing some more TLC. I use the code in those projects, or at least versions of the code, and even though I am pretty careful about verifying the source have found errors or necessary improvements while trying to re-use the sources in different ways. I admit to being particularly mad at editing my own writing, I sometimes read what I though I wrote rather than what's there. A company like Digilent can always have a second person vet a tutorial but as @JColvin has pointed out it's very easy to subconsciously do a missing step without realizing that the documentation is wrong or missing important steps that might not be obvious to people new to what's a very complex set of tools and devices.

Also unfortunate is that vendor documentation is often wrong, or out of date, or refers to features from an earlier version of tools that have been depreciated, etc. etc. So, my point is that while I do understand your frustration ( we all get frustrated with the same types of problems at some point or other ) this is an unfortunate part of the deal. In the end, struggling a bit pays off in the long run as it develops perseverance which is a key requirement for doing difficult things.  If you start a tutorial with the expectation that there will be problems you will find that instead of being focused on missing or wrong information and being frustrated you will be more likely to start your own research for answers and take it in stride.

I should point out that the Xilinx software development tools are pretty complicated and it's easy to get lost. If you take the time to explore, and get used to what's provided you'll find that there is actually extensive help and documentation available, right from within the IDE. It's just easy to miss if all you are worried about is completing your project. Understanding the tools is a prerequisite, just like about everything other endeavor.