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!
