01-17-2007 11:07 AM
01-17-2007 11:37 AM
01-18-2007 09:55 AM
Hello Lee,
Regarding your previous questions:
1) You are wondering how the example code knows that the board is not a 6509 so that it doesn't try to configure more ports than are present on the 6519. Which example are you using? Of those 5 examples downloaded from the MHDDK page for this board, all but 1 example configures only one port. The 5th example configures 3 ports. Are you using a different set of examples? Based on these examples, you should be able to put together a simple example that writes to two ports and reads from two ports.
2) You are curious about the difference in the base addresses. When I get my hands on a board, I can respond to this.
3) It sounds like you are unsure about how to physically connect this device. If so, I recommend switching over to a Windows machine so you can install the NI-DAQmx driver (link below) in order to help you figure out the physical connections. NI-DAQmx provides very simple tools like test panels that will allow you to test the functionality of your board and verify your signal connections before we try to develop your own driver. At this point, we don't know if the problem is in your code or with your physical connections. Using NI-DAQmx would allow you to focus on the physical connection part. Once you understand that, then we can focus on your software.
NI-DAQmx 8.3.1
Jeremy
01-18-2007 11:00 AM
Hi Jeremy and thanks.
I will try the windows application and try to get the board working.
As for the 5 examples you mentioned, you are correct that 4 write to only 2 ports. The problem is that the code during initialization actually initializes 11 ports which means assumes 6509 board. I verified this with debugger doing single step. I am pretty sure my code is correct and I am not sure what impact the code has on 6519 board when it initializes 11 ports. Doing that obviously will be writing to memory locations beyong the 4 ports and who knows what happens when it does that.
I commented out the driver code for ports 4 thru 11 but then the program crashes. This may have to do with C++ classes that exists for all 11 ports.
Can you check into this and maybe talk to someone who worked or developed code for driver and maybe you can poit me to the right direction so I have a starting point to get going and know where in code I need to focus and change? At this poit I don't really know where to start in DDHK code to make it work for 6519.
I am curious as how come the developers didn't put in a FLAG and initialize the board for the correct board that is running or some kind of switch statement to see what board they need to initialize. This would have been very easy checking the device ID.
Thanks and I will wait for your response.
Lee Khadivi
Curtiss Wright Embedded Control
01-18-2007 02:13 PM
Lee,
I now understand the initialization code you are referring to is the _initialize function that is called in the constructor of the chip object (tstaticDIO.cpp). Yes, this (and the reset function) does appear to address non-existent ports when used with the 6519. The thing to keep in mind here is these functions are simply resetting the individual objects to a known value. These objects are the soft copies of the actual registers on the board. Resetting the soft copies has no effect if the corresponding registers do not exist on that particular board. So, for these examples, it doesn't matter that we reset the soft copy of ports 4-11. With that said, you should be able to yank out the references to the extra ports if you really want to. These chip object files are auto generated, so I wouldn't necessarily recommend modifying them manually unless you had a good reason to do so.
If you have the VxWorks OS layer working, you should have everything you need to get an example working. I used VISA to communicate with the hardware on Windows, but the chip objects and examples are the same as you are using. Without modifying tstaticDIO.cpp, I modified digex1.cpp to reference my particular board, commented out the line to configure the port direction (since that isn't necessary for these boards with unidirectional ports), and changed IOPort0Data.writeRegister to IOPort2Data.writeRegister to write to port 2. That was enough to successfully toggle some digital lines on port 2. I hope this helps. Let me know if you have any specific questions.
01-18-2007 02:31 PM