Hey Patrick, thanks for the reply: As it turns out, the offset is *ascii-encoded*, whereas the data is (presumably) binary-encoded (possibly with some kind of escape characters added when necessary). In any case, it turns out that I will only need to * *read* *from the C interface, which I can do...so I'll be fine. I'll table the C-interface for now.
A couple of things I've observed figuring all this out (so that other people won't have to learn again): -the bytes returned from all read processes are endianness-reversed. So, you'll have to this to the output buffer: unsigned int dataRead[8192]; int len, i; //read fills buffer, sets len for(i=0;i<len;i++) dataRead[i]=ntohl(dataRead[i]); for the MATLAB KATCP interface: Looks like there are a lot of bugs here. I've fixed a handful of them (but don't know how to easily push my fixes back) - the open command waits for an 'OK' response that never comes - if you send many commands sequentially, one will get nothing while the other will get multiple responses. - The "write" command has several errors, all of which I have fixed (that I've found). - Use the "hex2dec( : ) command to convert "read" and "wordread" to uint32 values - There's a lot of timeouts caused by delays. If you're hanging somewhere, do a keyboard interrupt and figure out what it's doing. I'd bet katcp is waiting for a response that'll never come - the "open" command only wants an IP address, and assumes port 7147 Hopefully this will be helpful somewhere down the line :-) --Ryan On Wed, Nov 28, 2012 at 10:52 PM, Marc Welz <[email protected]> wrote: > 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 >
