- Create a new test stub to allow the output from the stream_pulse_data module to be viewed conveniently on the scope (as we discussed yesterday, and as I described in my last post).
- Study the datasheet for the DACs and write a module to set the threshold levels. Alternatively (or in addition), write an interface module to the DACs that allows the Nios system to set the threshold levels by bit-bashing in the C code.
- Alternatively (or before #2 is completed), Sachin's design can be temporarily re-integrated with ours, for purposes of using it to set the DAC levels. However, to be able to access it from LabView, we'd have to get one of the XP systems up and running again. Juan's most recent suggestion was to reinstall XP.
- After either #2 or #3 is finished, a real analog input source can be hooked up to the PMT inputs and digitized using the input capture datapath (together with one of our diagnostic output stubs).
- I need to create a shared folder (with no spaces in the pathname) so we can all work on Nios system development. I need to start pulling in code from my previous Nios app (the GPS app). When this framework is ready, the students can help working on C code development. -- See below for status.
I created a subfolder q91\ for development in Quartus II 9.1 (32-bit), so that in case eventually we upgrade our license to a newer version of Quartus, we can create a different parallel folder to work in with the new version, and avoid screwing things up with incompatibilities between the versions.
I copied all the project files from the shared Dropbox folder "FEDM_design\Our new gelware" into the new folder C:\SHARED\FEDM_code\q91\.
Now, I have also mapped this folder as a "network drive", "Q:\" (Q for Quartus). Of course, since it's a local folder, the "network" is really just a loopback in this case. But, this will allow this to use the same pathname to refer to this folder on other computers in which it really is mapped as a network drive. That way we won't constantly have to be changing pathname settings when compiling in different places.
The "software\" subfolder (C:\SHARED\FEDM_code\q91\software, accessed via the name "Q:\software") will be used for Nios system firmware development. It already contains a "hello_world_0" subfolder left over from some earlier development experiment. Starting the Nios II IDE (v.9.1) and setting the workspace to that folder (using the name "Q:\software").
Now creating a new "Nios II C/C++ Application". The project name is "FEDM_ctrl_fw" (for Front-End Digitizer Module control firmware). Selecting the appropriate .ptf file, "Q:\FEDM_NiosSys.ptf" (this was created during system generation in SOPC Builder). Using "Hello World" as the project template.
Doing a "Build All" on the newly-created software project, just to make sure the system library and everything builds correctly. (That's fine, although you have to close other programs in order for there to be enough memory to compile some of the modules.)
Added the FEDM_NiosSys instance back into the top-level schematic; recompiling the Quartus design...
Ah, I notice this version of the Nios system doesn't yet have the PIOs - that version was in my LOCAL folder; I'll grab it and put it back in here in a bit... First though I just want to do the "Hello World" test.
Compilation was successful; now programming board... FIFO test is still working. Starting SOPC Builder -> Nios II -> Nios II Command Shell. Typed "nios2-terminal"; it auto-detected the JTAG UART through the ByteBlasterII [LPT1] cable, and displayed the "Hello World" console output. So the Nios system is working as well.
Switched the current revision we are working in (in this q: folder) over to COSMICi-mods. I'd like us to do all our work in this revision (or successors to it), so as to keep our new pin assignments separate from all the older pin assignments as much as possible. That way, we can also safely delete assignments we aren't using, without worrying that they will be lost & gone forever, oh my darling, Clementine.
Changed the top-level entity for the COSMICi-mods revision to COSMICi_top5, which was the one we were most recently working in (over in the Stratix_TDC_v1 revision).
Imported settings from Stratix_TDC_V1 revision into the COSMICi-mods revision.
Recompiling the project again, to make sure I didn't screw anything up when switching revisions. I did have to remove a test file "testout.vhd" from the project.
New revision COSMICi-mods works, and "Hello World" still works. Now it's time to import my newer version of the SOPC system.
Went to C:\LOCAL\FEDM_gelware\COSMICi-mods\, which is the folder I had been working in before, so as not to interfere with the students' work in the shared Dropbox folder. Grabbed the FEDM_NiosSys.sopc file, copying it over to Q:\. Opening SOPC Builder. Yes, my three PIOs are in there: icdp_ctrl, icdp_stat, and icdp_data. Now regenerating the system.
System generation was successful. Now doing the equivalent of "make clean; make all" on the software code - i.e., in Nios II IDE, Project -> Clean..., with "Start a build immediately" checked. This is because the system library has to be rebuilt since the set of devices in the system has changed. Compiling now...
That worked. Now back in Quartus, I am updating the symbol for the FEDM_NiosSys instance back in the COSMICi_top5 schematic, so the ports for the PIOs will appear. Great, there they are. Now I am wiring buses to them, called icdp_data[31..0], icdp_stat[7..0], and icdp_ctrl[7..0]. In my blog post from Monday, I documented the meaning of the bits in the stat and ctrl registers. Connecting them up to appropriately named wires in the COSMICi_top5 schematic.
Next, I spent a while just straightening up the top-level schematic and adding comments, so we can all settle back in more easily after getting back from our long 4th-of-July weekends, 2-week vacations, etc. Recompiling now to make sure I didn't eff anything up in the process.
OK, "Hello world" still works in the new system (with the PIO devices added).
Next, let's see if we can run interactively within the Nios II IDE environment. Creating a new Nios II hardware run configuration. Everything looks good; hitting the Run button. OK, that restarted the firmware appropriately.
Now referring back to my old GPS application firmware, in C:\f\DE3\S3\SB+SOPC\GPS_FPGA_app\Nios2IDE_Workspace\nios2_gpsapp_v2\main.c, for reference, to see things that need to be pulled into this new application.
Adding <system.h> to includes, needed for IRQs. Recompiling to make sure that's found. It's fine and the IRQ #define macros are in it. That worked fine. Adding other #includes from the GPS app. Those are found too.
I need to change the main source filename from "hello_world.c" to "main.c". But Nios II IDE keeps crashing when I click on the C/C++ Build properties! Oh well, I just coped the file to the new name, and then deleted hello_word.c from the project.
Now, I have copied main.c from the GPS app folder to the new software dev folder, Q:\software\FEDM_ctrl_fw\GPSapp_main.c, for easier reference while we are putting the new firmware together. Perhaps the students can start working on this over the next couple of weeks (if they get other tasks done first). I will do as much of it as I can before I leave today, but my time is limited. At least I have created the program template, file header, etc. The GPSapp_main.c shows how to do everything (set up interrupts, access PIOs, etc.) and can be used as a model.
I'm basically filling in code in main.c in top-down fashion, putting in lots of comments as I go along, as placeholders for stuff that has not yet been written. So, what I've done is basically a partially-filled-in program outline. That way, if the students get to the point of working on the C code, they can (theoretically at least) just pick up wherever I left off, and continue filling in the details.
No comments:
Post a Comment