I said earlier that I'm following along with an opal kelley XEM3005 board. While there is a JTAG connector on the breakout board (well, a place to solder it in on your own...), the primary way of banging bits is via USB - over their "FrontPanel" software.
First, you load FrontPanel, then you click the load button. Once you do that, you browse to the *.bit file of interest. When select the file, it squirts it into the board for you.
One of the things I find interesting about this is that they have an API behind all this stuff, too - this way, when I get to one of my "real" projects, I should be able to keep the bit file on the host computer, and bang those bits at every startup. This makes life a little easier for firmware updates (maybe) for a system that's connected directly to a PC.
It's also nice that their API handles bidirectional comms - I'm hoping to someday have a couple projects that make good use of this capability. I'm hoping that their API is loadable by LabWindows, as that's my preferred tool for buiding instrumentation software (I really like their GUI interfaces)
Duane Benson 7/27/2012 12:23:56 PM User Rank Blogger
Re: LCD
SimonC - For my next steps, I'm going back to the manual again to put some more of it in context based on what I've done so far. After that, I'm going to start adding in to the code I have and just exploring the I/O.
thanks for the help, we were able to configure our virtex 5 ml507 education platform, finally ;)
I have already done some programming and testing with the LED's and the switches, but I would like to use some of the other features of the board. For example the 16 character x 2- Line LCD or input from an RS-232 into the fpga (for example to light some leds). So far I have no idea how to do this.
Any ideas for the next step in my FPGA learning process? :)
Duane Benson 7/23/2012 4:23:07 PM User Rank Blogger
Re: What did I miss?
Of course, one of the difficulties of being a rookie is that I can't always figure out the warnings and determine if they're innocuous or not. I will at some point, but haven't yet. It bugs me to leave something like that hanging.
@Duane, I agree. I guess the real underlying principle is: Good practice dictates that we pay attention to the warnings, and document our decisions/conclusions somehow.
Duane Benson 7/22/2012 8:08:38 PM User Rank Blogger
Re: What did I miss?
rfindley - I have certainly left warnings in code before, but I really don't like to. I'd much rather understand what's going on and code is such a way that the tools and the chip are happy with what I've built.
It's always great to see people not ignore compiler warnings! I often do maintenance work on existing projects, and not many FPGA projects have absolutely no warnings. Even when the warnings turn out to be a non-issue, a persistent warning icon makes it too easy to miss any new warnings that crop up.
Some of the FPGA tools have started adding an option to only show 'new' warnings, making it easy to spot them as they crop up. I would much rather see a method where, in the source code, the engineer can acknowledge and suppress specific instances of warning triggers (i.e. "Hush, I meant to do that!"). Better yet, make the code unambiguous enough that no warning is triggered in the first place, though sometimes that is easier said than done.
Duane Benson has decided the FPGA fabric in the Zynq All Programmable SoC will handle the short-term obstacle avoidance navigation in real-time. The Linux OS will handle longer-scope activities like point-to-point navigation.
Duane has decided that the time is ripe to get his ZedBoard bolted onto his robot with a Linux distribution up and running. That was the ultimate plan anyway, so why wait?
To save this item to your list of favorite All Programmable Planet content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.