All the work is on my next branch, see here: http://gnuradio.org/cgit/jblum.git/log/?h=next
################################################## # Write gnuradio blocks in python ################################################## This work, formally known as grblock was on my github. The project has now been integrated into gnuradio-core on my next branch. So basically, all of the facilities of a gr_block are now available in python. Overload work, scheduler integration, stream tags, and also the message passing I will mention below. See this wiki page for relevant docs and examples. http://gnuradio.org/redmine/projects/gnuradio/wiki/WriteBlocksInPython ################################################## # Useful message passing ################################################## I have create a message passing framework that fits in with the existing gnuradio. Basically, each block can accept messages, and can post messages to other blocks. The coordination of who can post messages to who is handled by the the msg_connect() call which is the message equivalent of the connect() call used on streams. Messages can be used to pass arbitrary serialized data between two blocks. The unit of message passing is the same as the stream tags, which is the pmt library. See gruel/pmt.h for basic usage. I have also extended the pmt blob type (memory container type) to manage memory. This allows blocks to pass messages with bulk data; effectively allowing for a mac/packet layer inside of gnuradio. ################################################## # New blocks - gr_blob_to_stream/gr_stream_to_blob ################################################## These blocks provide a cross over between the streaming domain in gnuradio and a kind of packet-based stream of message blobs. This is useful for testing the various blocks mentioned below: ################################################## # New blocks - gr_blob_to_socket/gr_socket_to_blob ################################################## These blocks read and write sockets (TCP or UDP) and output/input a stream of message blobs. This has a few advantages of the current UDP source/sink: - respects packet boundaries, each blob corresponds to a packet. Consider integration with gstreamer or VLC's udp socket streamers - implements TCP as well, which can offer backpressure when communicating between flowgraphs ################################################## # New blocks - digital packet framer/deframer ################################################## Basically that horrid packet framer in tunnel.py. I took the same packet utils, its the same code, but the important distinction: - the packet framer input messages - the packet deframer outputs messages The blocks are in grc if anyone cares to play. ################################################## # New blocks - tuntap ################################################## A tuntap interface with message input and message output, also available in grc. This is the thing that implements the tunnel in tunnel.py Sorry, linux only, unless someone wants to take a whack it for mac os, or windows (however you do that). ################################################## # Conclusions ################################################## The message passing and making blocks in python work supersedes the need for the old style message queues as the gateway between c++ and python. Someone could make the equivalent of tunnel.py in GRC using the new packet framer/deframer and tuntap block. The implementation would be clearer and smarter. Feedback and testing is welcome! -Josh _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio