[casper] Update to github valon code
Hi everyone, I've added a new branch to the github repository, entitled "experimental", for some new development ideas I've been tossing around. Within, so far, I've added a way to set all the register fields present on the valon via the Python interface (only, for the moment). These were previously inaccessible without using the windows interface or doing your own bit-banging. I cannot emphasize how utterly and completely untested this code is. I don't have access to a valon anymore, so this is not even close to approved for production. That said, I hope that somebody with a valon will take the time to review the code, verify that I haven't made a horrible typo in the bitfield definitions or the main class, and maybe throw caution to the wind and use it to read and write some registers. The register definitions are in valon_registers.py, and derive their names from the register map in the interface document Dan sent around. I don't know what many (most) of the options do, or what the valid values they can be set to are. Once again, buyer beware. I'd love to hear that people use this, but I don't want to be the guy who bricked a bunch of synthesizers. There is a new method, _get_all_registers, which returns 5 structure like objects (of type registerX_t). Inside each are the named contents of the register. e.g., >>> r0, r1, r2, r3, r4, r5 = vs._get_all_registers(SYNTH_A) >>> type(r0) >>> r0.ncount 160 >>> type(r1) >>> r1.mod 0 There is a matching method for setting all registers, _set_all_registers, which takes 5 of the same types returned from _get. _set will overwrite all the current settings with whatever is specified, so I'd highly recommend only using it with _get and making sure you know what you're doing. :) I've also turned on the verification of checksums, which I originally completely forgot about handling in the Python code. Oops. Cheers, --Patrick
[casper] Xport configuration
Hello CASPER, I'm trying to work with the x-port on one of NRAO Green Bank's ROACH boards. We have the xport connected to a private network, and I need to change it's IP address. I found some information at these two links: http://casper.berkeley.edu/wiki/ROACH_Bringup http://casper.berkeley.edu/wiki/Roach_monitor_and_management_subsystem I haven't figured out how to actually change the IP address, though. Connecting to the xport directly via telnet (similar to how the Python script from the second link does) gives me access to the registers, but I don't know what the commands for changing the IP address are. Does anyone have experience with this? Thanks, --Patrick
Re: [casper] Xport configuration
Hi Henry, The web interface worked beautifully, thanks. --Patrick Henry Chen wrote: Hi Patrick, It's been a while since I've attempted this, but IIRC the xport has some web-based configuration capabilities. Can you connect to it from a browser? Thanks, Henry
[casper] Linux Valon Synthesizer Interface
Hi everyone, I've created a linux-compatible interface to the Valon 5007 synthesizer. This library attempts to provide all the capabilities of the Windows program created by Valon. At the moment it is a programmatic interface only (non-graphical) available in Python and C++. The code can be found on github at: https://github.com/patbrandt/ValonSynth Any questions, comments, suggestions, improvements, patches, etc are welcomed. --Patrick Brandt, NRAO
Re: [casper] Linux Valon Synthesizer Interface
Patrick Brandt wrote: Hi everyone, I've created a linux-compatible interface to the Valon 5007 synthesizer. This library attempts to provide all the capabilities of the Windows program created by Valon. At the moment it is a programmatic interface only (non-graphical) available in Python and C++. The code can be found on github at: https://github.com/patbrandt/ValonSynth Any questions, comments, suggestions, improvements, patches, etc are welcomed. In order to add this project to the NRAO organization, I had to fiddle with ownership of the project, which changed the URL. Below is the new one. If you are watching the project, it should still appear in your "watched" list with the new link (e.g. https://github.com/YOURNAME/following). https://github.com/nrao/ValonSynth Sorry for the inconvenience. --Patrick
[casper] Roach IIc
Hi everyone, The team at the Green Bank NRAO has opted to use IIc on the ROACH board (ROACH1 for the short term, but ROACH2 in the future). Does anyone have experience with IIc on ROACH, primarily from the software side? Thanks, --Patrick Brandt
Re: [casper] Roach IIc
David George wrote: Hi Patrick. First up; are you using IIC driven from the PPC or the FPGA? We plan to use the IIc driven by the PPC. If you plan on using the PPC, the easiest way to go about it initially would be to use the i2c commands in u-boot which are very user friendly: i2c probe #list all the device on the iic bus i2c md# read a register on a given device i2c mw# write a register on a given device Uboot will be very useful initially for debug/testing but you will need kernel support for the final app. You have two options here. Either write/use a kernel driver to export the IIC function to userspace e.g. a GPIO device or hw sensor exported to sysfs or use the i2c-dev driver to access the raw IIC device from userspace. I would probably go for i2c-dev. Have a look the kernel doc below: http://www.mjmwired.net/kernel/Documentation/i2c/dev-interface For anyone else who may be interested in doing this: Getting i2c-dev working was trivial. All that was needed was to create the device file. $ mknod /dev/i2c-0 c 89 0 However, for some reason the SMBus commands described in David's link are reserved for kernel space only in the /usr/include/linux/i2c.h file. I was still able to use the standard read and write just fine. I was also able to easily add KATCP commands for reading and writing IIc under the tcp borph server. Thanks, --Patrick Brandt
Re: [casper] ROACH memory mapped IO
Tom Kuiper wrote:
It appears that there is something I don't understand about memory
mapped IO.
I'm trying to write directly to a firmware register. I have tried in
Python in binary mode with various options regarding buffering. I have
also tried the command line 'echo 1 > register'. Whatever I try, the
length of the register 'file' changes from 4 to 0.
In python, you'll want to use the 'binascii' module functions 'b2a_hex' and
'a2b_hex' (or the colorfully aliased equivalents, 'hexlify' and 'unhexlify',
respectively) to encode the data before writing it to the firmware register.
ex:
>>> unhexlify('04') # data going into the file
'\x04'
>>> hexlify('\x04') # data coming out of the file
'04'
Obviously this is using hexadecimal representation. There are probably ways to
handle plain integers, but I didn't stumble upon it when I was writing my
control code.
Re: [casper] Any experience with the katcp-C interface?
Ryan Monroe wrote:
It does help, thanks! I'm interested in how you broke down the call
though. I would have parsed it differently: In telnet, the command
would be typed like this
"?write"
where is a string containing the register name,
is a string containing the offset, and
is raw binary data containing the value.
So I was trying to do:
?write
= "trig_sel" (string)
= "0" (string)
= 0x (ulong)
That is the correct ordering (if memory serves), but the "write" command only
accepts binary data. I think manually "encoding" them works in telnet by using
the \x escape, e.g. "\x00\x00", otherwise you end up with the binary
representation of ASCII "0". "wordwrite" accepts a 32-bit unsigned long, which
is a little confusing... I had some issues with this and 64-bit IIRC. It might
be trivial to fix but would make updating the KATCP library a pain.
Actually, I get it now: the offset is placed at the /end/ of a write
command through the C interface, not the beginning. Do I have that right?
I'm browsing a slightly outdated version of the VEGAS spectrometer code. It
uses the send_katcp commands rather than the rpc_katcl calls, but here's an
example (hopefully sans typos):
bool setValue(const char *reg, uint32_t value, uint32_t offset) {
// ...
// 'kd' is the katcp dispatch object
send_katcp(kd, KATCP_FLAG_FIRST | KATCP_FLAG_STRING, "?writeword",
KATCP_FLAG_STRING, reg,
KATCP_FLAG_ULONG, (unsigned long)offset,
KATCP_FLAG_ULONG | KATCP_FLAG_LAST, (unsigned long)value);
// ...
}
bool setValue(const char *reg, const uint8_t *buffer, int32_t length, uint32_t
offset) {
// ...
send_katcp(kd, KATCP_FLAG_FIRST | KATCP_FLAG_STRING, "?write",
KATCP_FLAG_STRING, reg,
KATCP_FLAG_ULONG, (unsigned long)offset,
KATCP_FLAG_BUFFER | KATCP_FLAG_LAST, buffer, length);
// ...
}
Also, Is there more documentation to be had somewhere?
My memory is a little fuzzy but if you open a telnet session as Marc mentioned,
just do a "?help" and all the available commands will show up, with
descriptions of the parameters (ordering, optional or mandatory, etc). Or you
can dig really deep and look at the tcpborphserver code that runs on the roach
to serve the requests you're making.
--Patrick
Thank you very much...
--Ryan Monroe
On 11/28/2012 02:16 AM, Marc Welz wrote:
Hello
(write command which fails quietly)
result = send_rpc_katcl(l, 5000, KATCP_FLAG_FIRST | KATCP_FLAG_STRING,"?write",
KATCP_FLAG_STRING, regName, KATCP_FLAG_STRING, "0", KATCP_FLAG_LAST|KATCP_FLAG_ULONG,
0,NULL);
So this usage isn't quite correct. A "?write" request expects 3 parameters,
a name (which you have and looks correct), and offset (which you have
at 0, also ok), and then *binary* data - what you happened to send is
a text integer which will be interpreted as the binary string ascii
"0". Not only isn't that all zeros, it also is only one byte wide,
while roach registers are generally 32 bits wide.
So there are two ways of solving this: Use the "?wordwrite" command
which accepts a hex integer as third parameter which is written as
32bits, or write out binary data, using "?write" and a binary buffer,
with a length parameter.
Here is an example of how wordwrite could work. Note that for
wordwrites, the offsets are in multiples of words.
result = send_rpc_katcl(l, 5000, KATCP_FLAG_FIRST | KATCP_FLAG_STRING,
"?wordwrite", KATCP_FLAG_STRING, "sys_scratchpad", KATCP_FLAG_STRING,
"0", KATCP_FLAG_LAST | KATCP_FLAG_XLONG, 0, NULL);
Also in case of failure the result of send_rpc_katcl should be
nonzero, in particular *greater* than zero if the katcp request failed
on the remote side (which it has in your case), and *less* than zero
for local or internal errors.
In case you wish to diagnose problems like that in future, you can
telnet to a roach while you are running your C program. On that
separate connection you can increase the log verbosity to help you see
where your code is failing - to do that issue a "?log-level trace" on
the interactive connection. When I run your code I see
#client-connected 192.168.64.1:58345
#log warn 1354095081805 raw
start\_0\_and\_length\_1\_have\_to\_be\_word\_aligned
#log trace 1354095081805 raw writing\_1\_bytes\_to\_sys_scratchpad
#log error 1354095081806 raw write\_on\_sys_scratchpad\_returns\_zero
#log debug 1354095081806 raw wrote\_-1/1\_bytes\_to\_sys_scratchpad\_at\_0
#log error 1354095081806 raw write\_failed\_-1\_instead\_of\_1\_bytes
Hope that helps
marc
Re: [casper] Any experience with the katcp-C interface?
Ryan Monroe wrote: -the bytes returned from all read processes are endianness-reversed. Yes, this is also true for writes using data encoded in a binary stream. In general it is good practice to ensure network byte-ordering when marshalling or unmarshalling data. At worst the byte-ordering calls are simply NOPs. --Patrick
Re: [casper] Corr Package for C++
I wrote a simple C++ client for VEGAS which wrapped/used the C library Jason linked to. I don't know if it is still in use or available for distribution. It was far from a complete implementation of CORR, just a simple FPGA client for loading bofs and setting register values. Jason Manley wrote: I don't know of any c++ clients. But there is a c-based katcp server and client in the tcpborphserver github repo, that you could probably rip out and use as a base. I think most people use the python client. https://github.com/ska-sa/katcp_devel Jason On 06 Mar 2014, at 1:33, Prajwal Mohanmurthy wrote: Hello, Is there a C++ version of the [python] corr package? I've just been using the python version until now! Thanks for any input, Prajwal -- ___ Prajwal Mohanmurthy Laboratory for Nuclear Science Massachusetts Institute of Technology 77 Massachusetts Avenue 540 Building 26 Cambridge, MA 02139 USA Voice: +001 662 546 0508 EMail: praj...@mohanmurthy.com Web: www.mohanmurthy.com ___
