Bob I'm not qualified to comment, however, I am by no means board, by any of this. I'm sure others feel the same. Have at it. Recently someone mentioned added descriptors in the subject line. I think that would be good to consider, even if voluntary. [programming] etc.
Eric2 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert McGwier Sent: Sunday, February 19, 2006 7:34 PM To: Jim Lux Cc: [email protected] Subject: Re: [Flexradio] Surmised structure of update.c Jim: You are right on the money as far as you have taken it. A large part of the structure in that file is different from the Linux structure. It used to be more closely aligned with the Linux structure. At one time, all commands were passed through named pipes just as they were are Linux and used memory mapped file like structures just as Linux does. The threads to enable this are still in place. This has made it more confusing than it needs to be but the reasons are straightforward. The Windows named pipes have some performance issues and they are not really what we want to talk to the "whole world" of other devices anyway since Linux and Mac's do not support Windows style named pipes! We want to do something like enable sockets and/or some other message passing regime that can be opened to remote devices. The security issues are completely overlooked here so far. So what you are seeing is a hybrid of expediency. It has been kept "separated" by universal functions above the CTE processing apparatus, and windows only stuff at the bottom. Those routines that begin with Capital letters are dll interface routines that Eric calls through the C# "pseudo function calls" that are in dsp.cs. Almost all of the lower case setXXXYYYZZZ routines up top that are in the CTE list, were the original interface. Those have been preserved along with the thread that would eventually pass the commands. There are some exceptions: meter, powerspectra, and PTT since they were added late after I determined that the named pipes were not the way to go. Those functions that are available as dll components all begin with the export macro DttSP_EXP. Those should not be in our future. The correct way for us to go from here is to decide on the message construction/passing/queue/parse regime, well documented at each step, so we can all develop to this specification. If we do this, we will find the results usable across most of the platforms. You have indeed teased apart the essential nature of what is done. It is not true to Frank's original vision but that is to be remedied with our future work. Anyone that thinks we are going to do morse code key closures across any remoted distance is of course, foolish. These key presses will have to be done locally, with a local sidetone and then extremely dense compressed messages will be pass remotely to the other side. The morse code issues have absolutely nothing whatsoever to do with command processing. They have everything to do with the lag going into the portaudio and sound card device driver buffers. There was just no way around them. Future radios need a hardware solution to achieve QSK keying such as a built in electronic keyer and a separate. If lots of folks get bored with this conversation, let us know and we can take it private, but I expect that there is wide spread interest. Good job so far! Bob Jim Lux wrote: > OK, here's what I've figured out sofar. Anyone (Frank, Bob,?) who can > confirm or deny, please pitch in. > > updates.c contains a whole raft of small routines which execute various > commands. The "main" smarts of this is a routine called do_update, which > parses a string (passed as a parameter) into substrings (delimited by > whitespace). The first substring is a command, the remaining substrings > (if any) are parameters for the command. > The commands are compared against a list defined in a structure called > update_cmds, terminated by a zero sentinel. If the command isn't matched, > do_updates returns with an error code (-1). If the command IS foudn in the > table, the corresponding routine is called, passing the number of > parameters (as an int) and an array of the strings for the parameters. > > The parsing (more properly, lexical analysis) is done by routines in a > module called splitfields, and uses strtok, which I haven't found yet (is > it a library routine?). The data structures (notably, the "SPLIT") used by > the routines (and, by extenstion, do_update) are defined in splitfields.h. > > A module called thunk.c contains routines which do the comparison against > the command list. > > OK so far? > > Jim,W6RMK > > > _______________________________________________ > FlexRadio mailing list > [email protected] > http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz > Archive Link: http://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/ > FlexRadio Homepage: http://www.flex-radio.com > > -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman Laziness is the number one inspiration for ingenuity. Guilty as charged! _______________________________________________ FlexRadio mailing list [email protected] http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
