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" <regname> <offset> <data> where <regname> is a string containing the register name, <offset> is a string containing the offset, and<data> is raw binary data containing the value.So I was trying to do: ?write <regname> = "trig_sel" (string) <offset> = "0" (string) <data> = 0x0000 (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
