Hi all,
I’ve added documentation on the new polymorphic type in GNU Radio, PMT,
to the GNU Radio wiki:
http://gnuradio.org/trac/wiki/TypePMT
It has full details of many of the methods, how to use a PMT, how to
assign it values, how to do type conversions, etc…
For more difficult PMT types (lists, dictionaries, etc…), I have added
detailed sections.
This is all part of my attempt to make a better wiki…
http://gnuradio.org/trac/wiki/WikiStartNew
… I’m branching out from the m-block info, slowly but surely!
George,
Thanks for coming up with the doc so fast. This helped a lot!
A few comments:
-
In section “Constructing / Assigning a PMT”: isn’t pmt_list part of
this too?
-
In “PMT Conversion Methods”: what’s the difference between using a
“construction method” and a “conversion method” to generate a PMT type?
For example, one can use either pmt_integer(long) or pmt_from_long() to
get a pmt long type.
-
I have to check, but I think so
-
Actually, this is a slight mis-conception from my documentation
which I need to fix tonight. pmt_integer() is not a public member of
the PMT class. You need to use pmt_from_long(X) which will return you a
pmt_t which is an instance of a pmt_integer. I need to make this clear
and update my documentation.
If you look at any of the inband code or my MAC examples, you will
always see pmt_from_long() and pmt_to_long()
On Mon, Apr 28, 2008 at 10:11:47AM -0700, David Li wrote:
- In section “Constructing / Assigning a PMT”: isn’t pmt_list part of
this too?
FWIW, there’s no list type. A list is built from the empty list
(PMT_NIL) and pairs (conses). It’s pretty much isomorphic to scheme
and lisp data types.
To save George some typing, you may want to just look at
the doxygen header comments in pmt/src/lib/pmt.h or
http://gnuradio.org/doc/doxygen/pmt_8h.html
Eric
This was one of the 2 major catches I mentioned in an earlier e-mail.
This is not implemented yet and is a major m-block limitation.
Eric, George:
I have another question. According to the mblock design documentation
(from BBN) it’s capable of handling both message blocks and gr blocks at
the same time. Is this true in the current implementation? Does this
mean we can utilize the existing gr DSP blocks inside a mblock?
On Tue, Apr 29, 2008 at 02:01:24PM -0700, David Li wrote:
Eric, George:
I have another question. According to the mblock design documentation
(from BBN) it’s capable of handling both message blocks and gr blocks at
the same time. Is this true in the current implementation? Does this
mean we can utilize the existing gr DSP blocks inside a mblock?
At this moment, there’s no standard way to use them together.
As part of the work on the thread-per-block scheduler, they will be
integrated.
Expect this in the next couple of months.
Eric