On 08/28/2012 01:30 PM, Larry D'Addario wrote:
I noticed your thread on this subject on the CASPER list. (Although I subscribe to the list, I'm unable to post to it for some reason that I have not yet figured out.)That's strange. An e-mail to Mark Wagner may resolve that. Hopefully he'll see this.
I have used both the pseudo-files under /proc and the katcp server to communicate with registers in the FPGA, and both work fine. I think the best approach depends a lot on whether you are wanting to change the low-level things interactively by typing commands, or whether you want to do it from within a program. I have done both.I tend to begin using the interactive Python (ipython) command line. Then as things are worked out I copy the commands into a Python program in an editor. Even as I'm building the program I try things out or debug errors using the ipython command line. Sometimes the command line is just plain handy. For example, except that I was really busy, I should have done this when I got your e-mail about CRAFT yesterday:
In [1]: from Ephem import *
In [2]: p = Pulsar('J0332+5434')
In [3]: p.period
Out[3]: 714.51969972580105
and you might want to do this:
In [4]: d = DSS(13)
In [5]: p.compute(d)
In [6]: print(p.a_ra, p.a_dec)
(3:32:59.39, 54:34:43.4)
In [7]: print(p.ra, p.dec)
(3:33:59.59, 54:37:04.5)
Mind you, this is Python enhanced with my own modules but you get the idea.
For something that's fairly complicated, the CASPER people tend to write Python programs which work via the katcp server on the PPC. The same thing can be done in C; you don't need Python unless you want to re-use some existing code, but so far I've found the existing code too complex, convoluted, and undocumented to make it worth the bother.I agree. I tried to find out how they actually write to registers and I dug through layer after layer only to get to some 'request' method that I could not locate. By the way, there is some documentation I generated automatically and put on
http://dsnra.jpl.nasa.gov/software/Python/python-modules/corr/At the moment you can only get at it from within JPL because we closed outside access, pending an investigation, after the website was hacked a few days ago.
If you can do your control via katcp commands, then you can put a list of them in a file and execute the file like a script using my katcp interpreter.To do that I need to run katcp on the ROACH host which is behind a firewall (JPL's for now, FlightOps in the future). It can be done but is clumsy. Glenn's solution is more elegant. Mine is primitive but has the advantage of not depending on software (corr) someone else wrote.
To minimize network traffic, the file with the commands could be on the local host rather than on a remote machine; then the only thing that goes over the network is the file name. I also have a small program that allows you to run individual katcp commands but is far more user-friendly than trying to type those commands directly to the server over a telnet connection.That's a front end to katcpComm, I guess. I'm not sure how I could grow from that into a complex interactive graphical program, except very painfully using the Motif library or something like that. There is a good reason for languages like Python and Matlab.
I have the feeling that the file length going to zero on a simple write is unintended and been lurking in the borph code since no one ever tried such a simple OS-level write. I'm guessing that the file pointer, which is reset to zero before the write, is not advanced after the write.
Cheers, Tom
