Hello > 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.
Yes. > So I was trying to do: > ?write > <regname> = "trig_sel" (string) > <offset> = "0" (string) > <data> = 0x0000 (ulong) Almost. Raw binary data doesn't look like "0x0000", raw binary data looks like what you get when you do "cat /bin/ls". Here in this mail, nul bytes are unlike to to show up, so raw binary data, using C escapes would be "\0\0\0\0". And it turns out, that is also what you would have had to type using the telnet interface, eg "?write trig_sel 0 \0\0\0\0". Now, the C interface does the escaping for you, but you still need to provide the data as a buffer (pointer to a memory region) and length. This typically involves interesting casts or a memcpy which people who are not that familiar with C find confusing, so for manipulation of single 32bit registers is probably easier using wordwrite. If you wish to use buffers, then the syntax (from memory... ) is "KATCP_FLAG_BUFFER, buffer, len", alternatively there should be an append_buffer function, which allows you to construct a message in steps (used by the higher level rpc layer). > 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? No, the C interface doesn't know about parameter ordering for individual commands. The C library speaks katcp, not the tcpborphserver command set layered on top of it. > Also, Is there more documentation to be had somewhere? I believe in examples/*.c there is a case in the server example which shows how a message is constructed which contains a binary message. Alternatively, do a "?read regname 0 4" to retrieve 4 binary bytes from a system. > Thank you very much... No problem, regards marc
