Here are a couple of helpful web pages on the subject.
This page floats theories about the exact nature of the one-way valve, and that the cyst is not so much a structure of its own but simply a gap in adjacent tissues:
http://www.eatonhand.com/hw/hw013.htm
Here are some photos of mine. It's apparently termed "Volar"
http://www.eatonhand.com/img/img00036.htm
Here is one of the usual "the condition is ideomatic" sites:
http://www.mdbonedocs.com/tabid/20192/mid/37487/ContentPubID/743/ContentClassificationGroupID/-1/Default.aspx
Friday, October 29, 2010
Making wxWidgets do my damn bidding
In order to match the functionality of my Opal Kelly FP display using wxWidgets, I have to figure out how to make a numerical control. None of the Opal Kelly samples that used wxWidgets seem to have this capability, and I suspect that it's because this is harder than it looks, particularly with needing to do hexadecimal entry limited only to the hex characters. The PipeTest sample in particular seems to wimp out by using wxComboBoxes, which seem to be listboxes according to the wxWidgets Wiki (This may not be a correct impression, if only because the examples that I've seen so far don't show listbox initializations).
http://wiki.wxwidgets.org/WxComboBox
http://docs.wxwidgets.org/2.8/wx_wxcombobox.html
Data entry in wxWidgest seems to be only through wxTextCtrl objects. I find that hard to believe! This seems even more unbelievable if these objects are multiline???
Here is the basic argument list for wxTextCtrl, in the helpful wiki "docs" format. Oddly, I don't think that it mentions validators:
http://docs.wxwidgets.org/stable/wx_wxtextctrl.html.
Here is an example where capitalization is enforced in a wxTextCtrl object, by setting an event for any editing, reading the contents, mashing the retrieved contents into all caps, and writing them back, apparently instantaneously:
http://wiki.wxwidgets.org/WxTextCtrl#In-place_Input_Capitalization
Here is a similar example of home-grown validation which waits for the user to hit enter, and then checks the result and rejects it back to the text box:
http://www.daniweb.com/forums/thread303734.html
Earlier in the helpful wiki page, it suggests using controls that I can't find. Apparently they are "contributed" which means they probably have to be downloaded from some other site and compiled etc.
http://wiki.wxwidgets.org/WxTextCtrl#Allowing_Only_Certain_Kinds_of_Input
The following forum thread, although about Python, references the same non-canonical objects:
http://programming.itags.org/python/34536/
Finally, this thread, only two answers long, not only references the unoffical objects, but also shows code for an event handler for a TextCtrl that responds to *each keypress* and judges it.
http://stackoverflow.com/questions/1369086/is-it-possible-to-limit-textctrl-to-accept-numbers-only-in-wxpython
The big problem with these lovely custom versions of TextCtrls is that they all seem to be written in Python. Here is the only page so far that has a link to a C++ version of a masked text control. The FTP link is to a zip file that contains an older style .dsw project file, a copy of the control, and two layers of a demo application which is actually quite a nice demo. I hope that I can somehow compile this and play with it. My ambivalence about this code is that the control itself is about 20 freaking pages long!
http://ftp.sunet.se/wmirror/wxwidgets.org/contrib2.htm
It really seems like the missing piece might be "validators", but I have no idea if they work the way I want or not. The following thread seems to indicate that they might not even have worked as recently as 2008. It seems to show people writing wxWidgets classes on the spot!
http://www.blitzbasic.com/Community/posts.php?topic=79872
The above makes reference to filters that are part of wxTextCtrl, like ALPHANUMERIC. Here is more info (oddly, can't find the same page in the "stable" docs tree?):
http://docs.wxwidgets.org/2.8/wx_wxtextvalidator.html#wxtextvalidator
And here's probably the most complete example of validator setup that I've been able to find so far:
http://forum.wxformbuilder.org/index.php?topic=229.0;wap2
Here's an example of building up a validator list using entirely custom adds. The author of the post admits to his code's crudity:
http://old.nabble.com/wxTextValidator-question-td8761160.html
Finally, the validator docs guide from the stable docs tree, showing those various ready-to-use options:
http://docs.wxwidgets.org/stable/wx_wxtextvalidator.html
A realization from the Clue-by-four is to compile the TextCtrl and Validator samples from the install directory. I'll try that and see if they contain examples of getting a numerical value using a TextCtrl widget.
http://docs.wxwidgets.org/trunk/page_samples.html
So, I did that, and decided to use the SetMaxLength method of the wxTextCtrl to limit the number of characters, and use a validator with wxFILTER_INCLUDE_LIST to limit to the hex characters. Eventually I figured out that using wxFILTER_INCLUDE_LIST or'd with wx_NUMERIC doesn't work, and so I just used wxFILTER_INCLUDE_LIST by itself and added the ten number characters to the include list. The two text controls look very nice and show the default value, but their contents couldn't be edited! Eventually I figured out that the problem was that they weren't getting "focus". After a while, I discovered that I could use SetFocus() in my code to make one of them start off with focus, and then I stumbled into the realization that I could use the tab character to get the focus to each text control and was able to edit them when they had focus, but I can't figure out how to get the focus on the controls with a mouse click. You'd think this would be simple. I found a clue here, finally:
http://thedailyreviewer.com/compsys/view/click-events-for-wxtextctrl-11147227
This opened up a new avenue of investigation. Originally, my take-away from the above was that (due to the fact that I'm using a frame with text controls on it) mouse click events on the text controls are not propagating up to the frame, which I presumed was supposed to be the parent. The actual answer turned out to be simplicity itself, basically PEBWAC. Because I had coded my main program from one example, but had taken the code for the TextCtrls from a different example, the TextCtrls were "on" the wrong part of the screen. Specifically, they were members of the "frame", and not the "panel". All examples that I looked at defined an application, a frame, and a panel. My first example defined all the widget pointers as members of a frame, but when it defined them it first created a panel right in the initializer for the frame and assigned that panel as the parent of each widget. My second example defined the frame and panel as two separate objects, and made each widget pointer a member of the panel, and they were defined using "this" as their parent. Thus when I pasted the code into my code which had been derived from the first example, they used "this" rather than the panel pointer to define their parent, and consequently their parent was defined as the frame. By simply recoding the wxTextCtrls to have the panel as their parent, it restored the behavior of mouse clicking on the control to allow it to get focus. This all has to do with the fact that MouseEvents don't propagate up to the frame; I didn't have to define a whole new class derived from the wxTextCtrl and do some kind of trick to push the class's event handling to the frame, as the above forum suggests. The text controls with validators in the validator example worked because they were defined on a dialog, which is apparently like a panel.
http://wiki.wxwidgets.org/WxComboBox
http://docs.wxwidgets.org/2.8/wx_wxcombobox.html
Data entry in wxWidgest seems to be only through wxTextCtrl objects. I find that hard to believe! This seems even more unbelievable if these objects are multiline???
Here is the basic argument list for wxTextCtrl, in the helpful wiki "docs" format. Oddly, I don't think that it mentions validators:
http://docs.wxwidgets.org/stable/wx_wxtextctrl.html.
Here is an example where capitalization is enforced in a wxTextCtrl object, by setting an event for any editing, reading the contents, mashing the retrieved contents into all caps, and writing them back, apparently instantaneously:
http://wiki.wxwidgets.org/WxTextCtrl#In-place_Input_Capitalization
Here is a similar example of home-grown validation which waits for the user to hit enter, and then checks the result and rejects it back to the text box:
http://www.daniweb.com/forums/thread303734.html
Earlier in the helpful wiki page, it suggests using controls that I can't find. Apparently they are "contributed" which means they probably have to be downloaded from some other site and compiled etc.
http://wiki.wxwidgets.org/WxTextCtrl#Allowing_Only_Certain_Kinds_of_Input
The following forum thread, although about Python, references the same non-canonical objects:
http://programming.itags.org/python/34536/
Finally, this thread, only two answers long, not only references the unoffical objects, but also shows code for an event handler for a TextCtrl that responds to *each keypress* and judges it.
http://stackoverflow.com/questions/1369086/is-it-possible-to-limit-textctrl-to-accept-numbers-only-in-wxpython
The big problem with these lovely custom versions of TextCtrls is that they all seem to be written in Python. Here is the only page so far that has a link to a C++ version of a masked text control. The FTP link is to a zip file that contains an older style .dsw project file, a copy of the control, and two layers of a demo application which is actually quite a nice demo. I hope that I can somehow compile this and play with it. My ambivalence about this code is that the control itself is about 20 freaking pages long!
http://ftp.sunet.se/wmirror/wxwidgets.org/contrib2.htm
It really seems like the missing piece might be "validators", but I have no idea if they work the way I want or not. The following thread seems to indicate that they might not even have worked as recently as 2008. It seems to show people writing wxWidgets classes on the spot!
http://www.blitzbasic.com/Community/posts.php?topic=79872
The above makes reference to filters that are part of wxTextCtrl, like ALPHANUMERIC. Here is more info (oddly, can't find the same page in the "stable" docs tree?):
http://docs.wxwidgets.org/2.8/wx_wxtextvalidator.html#wxtextvalidator
And here's probably the most complete example of validator setup that I've been able to find so far:
http://forum.wxformbuilder.org/index.php?topic=229.0;wap2
Here's an example of building up a validator list using entirely custom adds. The author of the post admits to his code's crudity:
http://old.nabble.com/wxTextValidator-question-td8761160.html
Finally, the validator docs guide from the stable docs tree, showing those various ready-to-use options:
http://docs.wxwidgets.org/stable/wx_wxtextvalidator.html
A realization from the Clue-by-four is to compile the TextCtrl and Validator samples from the install directory. I'll try that and see if they contain examples of getting a numerical value using a TextCtrl widget.
http://docs.wxwidgets.org/trunk/page_samples.html
So, I did that, and decided to use the SetMaxLength method of the wxTextCtrl to limit the number of characters, and use a validator with wxFILTER_INCLUDE_LIST to limit to the hex characters. Eventually I figured out that using wxFILTER_INCLUDE_LIST or'd with wx_NUMERIC doesn't work, and so I just used wxFILTER_INCLUDE_LIST by itself and added the ten number characters to the include list. The two text controls look very nice and show the default value, but their contents couldn't be edited! Eventually I figured out that the problem was that they weren't getting "focus". After a while, I discovered that I could use SetFocus() in my code to make one of them start off with focus, and then I stumbled into the realization that I could use the tab character to get the focus to each text control and was able to edit them when they had focus, but I can't figure out how to get the focus on the controls with a mouse click. You'd think this would be simple. I found a clue here, finally:
http://thedailyreviewer.com/compsys/view/click-events-for-wxtextctrl-11147227
This opened up a new avenue of investigation. Originally, my take-away from the above was that (due to the fact that I'm using a frame with text controls on it) mouse click events on the text controls are not propagating up to the frame, which I presumed was supposed to be the parent. The actual answer turned out to be simplicity itself, basically PEBWAC. Because I had coded my main program from one example, but had taken the code for the TextCtrls from a different example, the TextCtrls were "on" the wrong part of the screen. Specifically, they were members of the "frame", and not the "panel". All examples that I looked at defined an application, a frame, and a panel. My first example defined all the widget pointers as members of a frame, but when it defined them it first created a panel right in the initializer for the frame and assigned that panel as the parent of each widget. My second example defined the frame and panel as two separate objects, and made each widget pointer a member of the panel, and they were defined using "this" as their parent. Thus when I pasted the code into my code which had been derived from the first example, they used "this" rather than the panel pointer to define their parent, and consequently their parent was defined as the frame. By simply recoding the wxTextCtrls to have the panel as their parent, it restored the behavior of mouse clicking on the control to allow it to get focus. This all has to do with the fact that MouseEvents don't propagate up to the frame; I didn't have to define a whole new class derived from the wxTextCtrl and do some kind of trick to push the class's event handling to the frame, as the above forum suggests. The text controls with validators in the validator example worked because they were defined on a dialog, which is apparently like a panel.
Wednesday, October 27, 2010
Doing wxWidgets the hard way
Down the open source rabbit hole again... here is a running record of what it took to get myself the ability to build wxWidgets projects.
Mistake #1: Using the 2010 version of Virtual C++. Nearly all of the documentation on the wxWiki, and all of the source and sample code and projects that were installed for 2.9.1, and the Opal Kelly projects all expect that I am using VCpp 2008. Sadly, it's just too late for me to back 2010 out considering all that I've built with it so far for the Opal Kelly.
The alpha article on wxWiki that has saved my ass dozens of times so far:
http://wiki.wxwidgets.org/Microsoft_Visual_C%2B%2B_Guide#Visual_Studio_C.2B.2B_2010.
From this guide, I learned the supposedly obvious fact that once wxWidgets is downloaded, it has to be built. Duh. Doing this makes the wxWidgets libraries which are then linked into applications at compile time, which I suppose would be more efficient than just recompiling wxWidgets each time.
From this guide I followed the trail to where to download a version of the libraries project that somebody made in order to fix the Express 2010 problems which made it impossible to compile the wxWidgets library projects which were distributed with 2.9.1: "Microsoft.CppCommon.targets Invalid command line switch for "cmd.exe". The path is not of a legal form."
http://forums.wxwidgets.org/viewtopic.php?t=27630
The fixed library projects compiled perfectly. So, next I tried compiling one of the samples. The samples all seemed really fractional, mostly just demonstrating single features each. Since the guide suggests basing my own projects on "internat" I started with that. It failed to find the rather central setup.h file. More googling revealed that this turns out to be a failing of this particular sample and has been encoutered by many people. The solution is to add the path to setup.h in the include files directories under preprocessor properties, according to the following dense but helpful looking other guide page on the wiki:
http://wiki.wxwidgets.org/Compiling_using_MS_VC%2B%2B
After that, I begin having problems finding header files and then finding libraries. What I discovered is that all the library files that I'd made were under mswud instead of mswu. I figured out that what had happened was that when I compiled the libraries, I must have only compiled the debug configuration. So, for a while I relied on a workaround of compiling samples in debug configuration. I began to have success in compiling samples and demos, including the clone of the "minesweeper" game.
After that, I took the next step of moving a sample to my own directory structure to compile it there. To perform this step, I used the technique of opening up a .vcproj file from the original samples director in wordpad (it turns out it's just an XML file), and changing all of the relative paths in the file to hard-coded paths to the wxWidgets install directory. This is where having that environment variable set was important, although I often just got lazy and hard-coded the path directly in the .vcproj file rather than use the environment variable.
After that, I got started trying to compile the Opal Kelly counters project. Since I now distrust the project files distrubted by OK, I tried building a new project from scratch using a new empty project. I opened up one of the sample project files in wordpad and tried to transfer as much of the wxWidgets environment over as I could. However, the information in the project file is widely distributed and I missed a bunch of stuff, like the preprocessor directives for the resource files. I was clued into this by this page which had dummy-followable steps on to how to build up the wxWidgets environment in a fresh project file. I loved this page until I noticed that it doesn't make a distinction between Debug and Release configurations, and seems in fact to be configuring a Debug compile:
http://rhyous.com/2009/12/16/how-to-compile-a-wxwidgets-application-in-visual-studio-2008/
The following section of the alpha Guide is more dense, and seems to miss the setting up of resources, but at least provides some background on why to use or not use various preprocessor flags and libraries:
http://wiki.wxwidgets.org/Microsoft_Visual_C%2B%2B_Guide#Creating_a_New_Project_by_Hand
Anyhow, as Counters began to compile, I ran into a problem with one line in the program where it attempted to pass a string argument using a member of an wxWidgets string container. It appears as though this is a compatibility issue between wxWidgets 2.9.1 and 2.8.x, at least according to the spirited debate in the comments to this bug report:
http://trac.wxwidgets.org/ticket/9507
I fixed it by adding a direct cast, although I had to do it slightly differently than described in the trouble ticket, because the destination type was different in the OK code.
So, suddenly I had a clean compile, except when I took it to the target system it complained about a missing debug DLL. So in the end, I had to just build the Release versions of all the libraries, fill in everything in the project setup for a release configuration, and boom it works.
Mistake #1: Using the 2010 version of Virtual C++. Nearly all of the documentation on the wxWiki, and all of the source and sample code and projects that were installed for 2.9.1, and the Opal Kelly projects all expect that I am using VCpp 2008. Sadly, it's just too late for me to back 2010 out considering all that I've built with it so far for the Opal Kelly.
The alpha article on wxWiki that has saved my ass dozens of times so far:
http://wiki.wxwidgets.org/Microsoft_Visual_C%2B%2B_Guide#Visual_Studio_C.2B.2B_2010.
From this guide, I learned the supposedly obvious fact that once wxWidgets is downloaded, it has to be built. Duh. Doing this makes the wxWidgets libraries which are then linked into applications at compile time, which I suppose would be more efficient than just recompiling wxWidgets each time.
From this guide I followed the trail to where to download a version of the libraries project that somebody made in order to fix the Express 2010 problems which made it impossible to compile the wxWidgets library projects which were distributed with 2.9.1: "Microsoft.CppCommon.targets Invalid command line switch for "cmd.exe". The path is not of a legal form."
http://forums.wxwidgets.org/viewtopic.php?t=27630
The fixed library projects compiled perfectly. So, next I tried compiling one of the samples. The samples all seemed really fractional, mostly just demonstrating single features each. Since the guide suggests basing my own projects on "internat" I started with that. It failed to find the rather central setup.h file. More googling revealed that this turns out to be a failing of this particular sample and has been encoutered by many people. The solution is to add the path to setup.h in the include files directories under preprocessor properties, according to the following dense but helpful looking other guide page on the wiki:
http://wiki.wxwidgets.org/Compiling_using_MS_VC%2B%2B
After that, I begin having problems finding header files and then finding libraries. What I discovered is that all the library files that I'd made were under mswud instead of mswu. I figured out that what had happened was that when I compiled the libraries, I must have only compiled the debug configuration. So, for a while I relied on a workaround of compiling samples in debug configuration. I began to have success in compiling samples and demos, including the clone of the "minesweeper" game.
After that, I took the next step of moving a sample to my own directory structure to compile it there. To perform this step, I used the technique of opening up a .vcproj file from the original samples director in wordpad (it turns out it's just an XML file), and changing all of the relative paths in the file to hard-coded paths to the wxWidgets install directory. This is where having that environment variable set was important, although I often just got lazy and hard-coded the path directly in the .vcproj file rather than use the environment variable.
After that, I got started trying to compile the Opal Kelly counters project. Since I now distrust the project files distrubted by OK, I tried building a new project from scratch using a new empty project. I opened up one of the sample project files in wordpad and tried to transfer as much of the wxWidgets environment over as I could. However, the information in the project file is widely distributed and I missed a bunch of stuff, like the preprocessor directives for the resource files. I was clued into this by this page which had dummy-followable steps on to how to build up the wxWidgets environment in a fresh project file. I loved this page until I noticed that it doesn't make a distinction between Debug and Release configurations, and seems in fact to be configuring a Debug compile:
http://rhyous.com/2009/12/16/how-to-compile-a-wxwidgets-application-in-visual-studio-2008/
The following section of the alpha Guide is more dense, and seems to miss the setting up of resources, but at least provides some background on why to use or not use various preprocessor flags and libraries:
http://wiki.wxwidgets.org/Microsoft_Visual_C%2B%2B_Guide#Creating_a_New_Project_by_Hand
Anyhow, as Counters began to compile, I ran into a problem with one line in the program where it attempted to pass a string argument using a member of an wxWidgets string container. It appears as though this is a compatibility issue between wxWidgets 2.9.1 and 2.8.x, at least according to the spirited debate in the comments to this bug report:
http://trac.wxwidgets.org/ticket/9507
I fixed it by adding a direct cast, although I had to do it slightly differently than described in the trouble ticket, because the destination type was different in the OK code.
So, suddenly I had a clean compile, except when I took it to the target system it complained about a missing debug DLL. So in the end, I had to just build the Release versions of all the libraries, fill in everything in the project setup for a release configuration, and boom it works.
Friday, October 15, 2010
M$ "Sleep" function for C/C++
There is no "sleep" function in C, but (apparently similarly to one provided in unix) there is one that's part of the Windows libraries. If the correct .h file is included, it does sleeps in milliseconds. It's apparently not very precise, and must be capitalized, i.e. "Sleep(i)" where i is in milliseconds. Apparently, this is all very well known, but also still one of the most asked questions on forums. See the followoing links, all filled with entertaining flail:
http://cboard.cprogramming.com/c-programming/111229-how-use-sleep-function.html
http://forums.devshed.com/c-programming-42/using-visual-studio-2005-and-the-sleep-function-418938.html
http://stackoverflow.com/questions/3379139/sleep-function-in-windows-using-c
http://cboard.cprogramming.com/c-programming/111229-how-use-sleep-function.html
http://forums.devshed.com/c-programming-42/using-visual-studio-2005-and-the-sleep-function-418938.html
http://stackoverflow.com/questions/3379139/sleep-function-in-windows-using-c
Issues related to compiling a control program from the Opal Kelly API
For some reason, there are painful issues with compiling a stand-alone executable from C code to make an OK API-based control program. When I started a new project, added the OK API .h and .cc files and made my executable, and then took it over to the PC where it was going to be run, it complained about the lack of a "MSVCP100D.DLL" file. That's when I noticed that I'd made a debug build accidentally and went back and compiled a "Release" build. After that it complained about a missing "MSVCP100.DLL" file. This problem does not occur when building the flashloader.exe.
I began comparing the compile options between my project and the flashloader project. There is a preprocessor options entry that's full of flags corresponding to ifdef's in the OK code for the flashloader project, so I added the same flags to my own project, but it didn't mitigate the DLL issue.
I found out that the DLL is the C++ standard library, as shown here:
http://msdn.microsoft.com/en-us/library/8kche8ah.aspx
Obviously, there's something in the way that the flashloader executable is linked that includes the library in the executable, but my freshly-started project is linking in such a way that it requires dynamic access to the DLL. Downloading DLLs from sites returned by Google is a pretty bad idea, so I went about figuring out how to find it on my system or get it from M$.
The following site hints that this DLL should have been installed on my system at a particular location (C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages). However, it wasn't. I think that this was because I am using VS Express, not the full version.
http://cboard.cprogramming.com/windows-programming/128217-msvcp100-dll.html
Navigating a series of links from the above and other hits from Google (here is some entertaining flail: http://code.google.com/p/nulldc/issues/detail?id=109), I learned that what DLLs can be "redistributed" by developers is a big hairy deal, and there's a confusing list of what can and can't, but no direct link to how to get any of them. Here is the M$ list:
http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx
That would seem to hint that distribution of this DLL is frowned on, but in spite of that, M$ will give you a download that installs this DLL and several others on any target system. It's called vcredist_x86.exe, and can be had from here:
http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84
So, once I had vcredist_x86.exe, I put it on the system in the lab and was able to run my executables (rather than find what I was doing wrong with the linker).
Edit: The answer might be in a post that I missed in the cboard thread above. One of the lower posts says:
"Also you can statically link the runtime libraries by changing your project settings:
Configuration Properties -> C/C++ -> Code Generation -> Runtime Library
If you want to statically link the runtime, don't choose one of the DLL options."
I began comparing the compile options between my project and the flashloader project. There is a preprocessor options entry that's full of flags corresponding to ifdef's in the OK code for the flashloader project, so I added the same flags to my own project, but it didn't mitigate the DLL issue.
I found out that the DLL is the C++ standard library, as shown here:
http://msdn.microsoft.com/en-us/library/8kche8ah.aspx
Obviously, there's something in the way that the flashloader executable is linked that includes the library in the executable, but my freshly-started project is linking in such a way that it requires dynamic access to the DLL. Downloading DLLs from sites returned by Google is a pretty bad idea, so I went about figuring out how to find it on my system or get it from M$.
The following site hints that this DLL should have been installed on my system at a particular location (C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages). However, it wasn't. I think that this was because I am using VS Express, not the full version.
http://cboard.cprogramming.com/windows-programming/128217-msvcp100-dll.html
Navigating a series of links from the above and other hits from Google (here is some entertaining flail: http://code.google.com/p/nulldc/issues/detail?id=109), I learned that what DLLs can be "redistributed" by developers is a big hairy deal, and there's a confusing list of what can and can't, but no direct link to how to get any of them. Here is the M$ list:
http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx
That would seem to hint that distribution of this DLL is frowned on, but in spite of that, M$ will give you a download that installs this DLL and several others on any target system. It's called vcredist_x86.exe, and can be had from here:
http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84
So, once I had vcredist_x86.exe, I put it on the system in the lab and was able to run my executables (rather than find what I was doing wrong with the linker).
Edit: The answer might be in a post that I missed in the cboard thread above. One of the lower posts says:
"Also you can statically link the runtime libraries by changing your project settings:
Configuration Properties -> C/C++ -> Code Generation -> Runtime Library
If you want to statically link the runtime, don't choose one of the DLL options."
How to compile Opal Kelly's flashloader.exe
The XEM-3005 has a serial configuration EEPROM (I guess its actually Flash RAM? The XEM-3005 UM refers to it as an SPI PROM) from which the Spartan 3E 1200 can be self-configured at power-up. Self-configuration setup is easy, you just set the tiny switch from the "USB Config" position to the "PROM Config" position, and remember to include a line in the VHDL to set the MUXSEL pin to '0' after configuration is complete to allow the USB port to still work for all other regular communication. However that EEPROM is not on the JTAG chain, so you can't just push a bitfile into it like you normally would with a Xilinx serial PROM. Apparently, the only way to program the bit file into the EEPROM is through the FPGA itself. The XEM-3005 says "This PROM may be programmed using the Opal Kelly FrontPanel Application or through API calls from your own software. NOTE: This feature is not yet available in FrontPanel." Later, the UM says "Opal Kelly’s FrontPanel application software and API both provide methods to program the SPI Configuration PROM." (Meaning that the API can be used to program the PROM, since this feature is not yet available in FrontPanel.)
The Opal Kelly Front Panel UM talks about the EEPROM used to store parameters for the PLL (which I'm not utilizing) but does not mention what methods are used to write to the boot PROM. However, in the Samples directory installed with the FrontPanel software, there is a folder called "flashloader". The README.TXT file in this directory explains the SPI PROM loading process in a roundabout way. The process is that you set up flashloader.exe in a directory with a bitfile supplied by OK, and the DLL that has all the OK API stuff in it, and the bitfile to be loaded to the PROM. You then run flashloader.exe from a DOS command line, and it will configure the OK FPGA with the bitfile supplied by OK, and then communicate with the configured FPGA to load your bitfile to the PROM.
However, OK does not supply flashloader.exe. Instead they helpfully supply just the source code. So you have to compile it yourself for whatever platform you're running on. Now, you can always compile in Cygwin, which requires you drag around their runtime DLL on a ball and chain with your executable. However, I found that M$ also supplies a C compiler, naturally wrapped up in the "Express" version of their huge, bloated do-everything development platform called "Visual Studio". Visual Studio Express can be downloaded from here: http://www.microsoft.com/express/ . When you click through to Download, it seems that you are offered four separate pieces, including VB, C#, C++, and "Web Developer". I picked just the C++ piece.
What I discovered is that it turns out that you'd better use Visual Studio, because that's how Opal Kelly did it. Their "source code" also comes with a VS project file that has all of the preprocessing directives and other compile options all set up perfectly. Once you've installed VS, you can compile flashloader.exe in two ways. First, you can use a DOS command window that's launched from a shortcut in the VS start menu folder, and follow the instructions in this M$ tutorial: http://msdn.microsoft.com/en-us/library/bb384838.aspx. Or, you can just open VS, go get a snack while it opens, and then from File->Open->Project/Solution select the .vcproj file in the "Cxx" subdirectory of the source code folder and (after converting to a .vcxproj file because nothing is allowed to be backwards compatible after 2010) just right-click on the flashloader project top level to get "Build". It will first build a "Debug" version because that's VS's default setting. Then you can set the build type to "Release" and build it again. The debug executable is placed in a "Debug" subfolder, and the release executable is placed in a "Release" subfolder. Both seem to run fine, and it is now possible to follow the procedure given in the README.TXT file.
The Opal Kelly Front Panel UM talks about the EEPROM used to store parameters for the PLL (which I'm not utilizing) but does not mention what methods are used to write to the boot PROM. However, in the Samples directory installed with the FrontPanel software, there is a folder called "flashloader". The README.TXT file in this directory explains the SPI PROM loading process in a roundabout way. The process is that you set up flashloader.exe in a directory with a bitfile supplied by OK, and the DLL that has all the OK API stuff in it, and the bitfile to be loaded to the PROM. You then run flashloader.exe from a DOS command line, and it will configure the OK FPGA with the bitfile supplied by OK, and then communicate with the configured FPGA to load your bitfile to the PROM.
However, OK does not supply flashloader.exe. Instead they helpfully supply just the source code. So you have to compile it yourself for whatever platform you're running on. Now, you can always compile in Cygwin, which requires you drag around their runtime DLL on a ball and chain with your executable. However, I found that M$ also supplies a C compiler, naturally wrapped up in the "Express" version of their huge, bloated do-everything development platform called "Visual Studio". Visual Studio Express can be downloaded from here: http://www.microsoft.com/express/ . When you click through to Download, it seems that you are offered four separate pieces, including VB, C#, C++, and "Web Developer". I picked just the C++ piece.
What I discovered is that it turns out that you'd better use Visual Studio, because that's how Opal Kelly did it. Their "source code" also comes with a VS project file that has all of the preprocessing directives and other compile options all set up perfectly. Once you've installed VS, you can compile flashloader.exe in two ways. First, you can use a DOS command window that's launched from a shortcut in the VS start menu folder, and follow the instructions in this M$ tutorial: http://msdn.microsoft.com/en-us/library/bb384838.aspx. Or, you can just open VS, go get a snack while it opens, and then from File->Open->Project/Solution select the .vcproj file in the "Cxx" subdirectory of the source code folder and (after converting to a .vcxproj file because nothing is allowed to be backwards compatible after 2010) just right-click on the flashloader project top level to get "Build". It will first build a "Debug" version because that's VS's default setting. Then you can set the build type to "Release" and build it again. The debug executable is placed in a "Debug" subfolder, and the release executable is placed in a "Release" subfolder. Both seem to run fine, and it is now possible to follow the procedure given in the README.TXT file.
Subscribe to:
Posts (Atom)