I have an input to a Threshold block, which I have verified is working with a QT GUI number sink.
I want to print the output of the Threshold block to console, preferably using the Message Debug block.
However, the output of the Threshold block is a float stream, which doesn't match the input of the Message Debug block.
Is there a way to convert a float stream into message, or am I going down the wrong hole?
My general aim is: when the input exceeds a certain threshold, print to console. Another program will monitor the console and when there is a print out, this triggers another action. I'm also not sure how to output ONLY when the threshold is exceeded, but one problem at a time.
I'm also not sure how to output ONLY when the threshold is exceeded, but one problem at a time.
Yes, but that problem is a blocker: Std output is a shared thing across all things in the GNU Radio process, so you can't generally guarantee exclusivity.
Let's not go down that route!
Instead, use something designed for exactly for this kind of things decades ago in UNIX!
Named pipes. These are FIFOs that you can handle like files.
So, use a file source to write to a FIFO, and pipe that FIFO into your other program.
It's really simple:
mkfifo /path/to/where/you/want/to/named/pipe
add a file sink that writes to /path/to/where/you/want/to/named/pipe
either make your other software open that /path/to/where/you/want/to/named/pipe, or do something like other_program < /path/to/where/you/want/to/named/pipe (that actually makes the standard (==console-equivalent) input of your other program what you write to that file sink)
Related
I'm working with gnuradio 3.10.4 and usrp B200mini.
My flowgraph is very simple:
usrp source -> head block -> file sink
I want to store a fixed amount of data to file sink, then reconfigure usrp and start it to store again.
My Python program likes:
tb.start()
tb.wait()
tb.lock()
...reconfigure usrp...
tb.unlock()
tb.start()
...
But the second time when tb.start() is used, the file can be created successfully but no data is written to it.
Can anyone tell me what's wrong with the program or provide any relevant docmutation becaouse I find little about it.
Thanks for your support.
When you're not sure how to get a block to do what you want, or if it can, it can be useful to consult the source code of the block, because GNU Radio blocks are not always thoroughly documented.
Starting from this wiki page on Head we can see all the code. It's C++, but fairly simple, and you can ignore all the setup and just look at the lines that seem to be doing the work.
In head_impl::work in head_impl.cc, we can see that the way the block works is counting the number of items it has passed in d_ncopied_items and comparing that against d_nitems (the value you provided). There's nothing here that restarts the count.
We have to also check the header file, head_impl.h, because code may be there too. And there we find what you need:
void reset() override { d_ncopied_items = 0; }
So, call reset() on the head block and it will forget about how many items it has already copied.
I have written a console application in D programming language. It executes some process and reads from its stdout (I use ProcessPipes):
foreach (line; pipes.stdout.byLine)
{
writeln(line);
}
I'd like to detect a 10 seconds timeout (no new lines received). What approach should I use?
I would probably use select if your are on a unix box and WaitForSingleObject on Windows to check for available input on the stdin handle, specifying a timeout value. The return value of the calls will tell you if input was available or if it actually timed out.
It might not work right with the buffering that byLine (and underneath that, FILE*) does inside... but it might, I'd say try it first. Just put the call to select/WaitForSingleObject at the end of the loop and see if it fails when it isn't supposed to.
But to be really sure, you can use the lower-level read functions on the input yourself, and break it into lines yourself (or better yet, avoid breaking it into lines if you don't really have to and just use random sized blocks of data as returned from the lower level read functions). Then there will be no weird buffering that the wait functions don't know about, so all will work brilliantly.
You can find examples for these functions from C easily like the official docs https://learn.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-waitforsingleobject or random stack overflow questions with relevant examples How to use select to read input from stdin?
just in D it is import core.sys.posix.unistd; or import core.sys.windows.windows; instead of the C #include<unistd.h> etc.
I am working on TI-TM4C129X ARM board and trying to write a LOG mechanism.It works good when I call it from the Tasks although I faced a problem when I called it with a timer.As I understand that, printf like functions works with Hwi and this causes the error. My aim is to format strings together with the operations like sprintf(),vsprintf(),memcpy() and memset(). How can I solve this problem ? Is there any equivalent methods that success sprintf() operation ?
Thanks for your answers,
Best Regards.
It sounds like the printf is the problem, not sprintf. Assuming your Log message uses an interrupt (UARTs do), and your timer is called from an interrupt, then your options are limited.
I would set a flag in the timer that your task code can check, once outside the context of the timer. This flag could indicate one of several messages to print, even include a time stamp if that helps to resort things afterwards, since your printed messages will not be in order.
Or, with SWO output (like the Segger j-link), you should be able to just send the data. But to avoid scrambled sentences, you need to halt interrupts while sending out a debug message, which obviously can affect the real-time behavior.
MPI seems to automatically designate 0 as the master process. But I want to be able to designate another process (e.g. process with rank 10) to be the master process.
Also, the function scanf only works in the master process: other processes simply ignore it and go to the next statement. Why is this happening?
When mpiexec starts MPI processes, only one of them receives stdin. The rest will not have that descriptor open, so reading from it will just return an error. If you check the return value from scanf it will probably be EOF. Technically there could be an implementation that would copy the contents of stdin and forward to all processes, but I don't think any MPI does this.
stdout on the other hand is usually collected from all processes by the launcher, and printed on the terminal, but the order in which things get printed is next to impossible to control. The common solution is to collect the data at one rank manually and have it print everything, as pyCthon suggested.
Finally, OpenMPI's mpiexec can do the things you asked for: specify which rank will get stdin, and even launch certain ranks in a separate xterm. This might be useful for debugging, but I wouldn't rely on these features for core functionality: you might want to use your code with a different MPI implementation some day. Besides, say you are running on a large cluster - do you really want a thousand terminals open? :)
Yes and no.
You can create a separate communicator world subgroup with MPI_Comm_create or MPI_Comm_split.
As for scanf, I think, if you run them, say, on a different rank, it will output that rank process. Say, if you have a sperate terminal on that rank, but your terminal is most likely on rank 0, hence you only seeing the output there, but then your not running the program on the other ranks, so I don't think it will work.
To print from separate nodes you need to use sprintf, and store the result in memory, and then send it back to rank 0 to printf to your terminal.
Good news, my c64 ist still running after lots of years spending time on my attic..
But what I always wanted to know is:
How can I automatically load & run a program from a floppy disk that is already inserted
when I switch on the c64?
Some auto-running command like load "*",8,1 would be adequate...
Regards
MoC
You write that a command that you type in, like LOAD"*",8,1 would be adequate. Can I assume, then, that the only problem with that particular command is that it only loads, but doesn't automatically run, the program? If so, you have a number of solutions:
If it's a machine language program, then you should type LOAD"<FILENAME>",8,1: and then (without pressing <RETURN>) press <SHIFT>+<RUN/STOP>.
If it's a BASIC program, type LOAD"<FILENAME>",8: and then (without pressing <RETURN>) press <SHIFT>+<RUN/STOP>.
It is possible to write a BASIC program such that it automatically runs when you load it with LOAD"<FILENAME>",8,1. To do so, first add the following line to the beginning of your program:
0 POKE770,131:POKE771,164
Then issue the following commands to save the program:
PRINT"{CLR}":POKE770,113:POKE771,168:POKE43,0;POKE44,3:POKE157,0:SAVE"<FILENAME>",8
This is not possible without some custom cartridge.
One way to fix this would be getting the Retro Replay cartridge and hacking your own code for it.
I doubt there is a way to do it; you would need a cartridge which handles this case and I don't think one like that exists.
A better and more suitable solution is EasyFlash actually. Retro Replay is commonly used with its own ROM. Since it is a very useful cartridge by default ROM, I would never flash another ROM to it. Also it is more expensive than EasyFlash if you don't have any of those cartridges.
At the moment, I have Prince Of Persia (!) ROM written to my EasyFlash and when I open my c64, it autoruns just like you asked for.
Not 100% relevant, but C128 can autoboot disks in C128 mode. For example Ultima V (which has musics on C128 but not on C64 or C128 in C64 mode) autoboots.
As for cartridges, I'd recommend 1541 Ultimate 2. It can also run games from module rom images (although Prince of Persia doesn't work for me for some reason, perhaps software issue?), but you also get rather good floppy emulator (which also makes it easier to transfer stuff to real disks), REU, tape interface (if you order it) etc.
If you are working with a ML program, there are several methods. If you aren't worried about ever returning to normal READY prompt without a RESET, you can have a small loader that loads into the stack ($0100-$01FF) The loader would just load the next section of code, then jump to it. It would start at $0102 and needs to be as small as possible. Many times, the next piece to load is only 2 characters, so the file name can be placed at $0100 & $0101. Then all you need to do is set LFS, SETNAM, LOAD, then JMP to it. Fill the rest of the stack area with $01. It is also rather safe to only save $0100-$010d so that the entire program will fit on a single disk block.
One issue with this, is that it clears out past stack entries (so, your program will need to reset the stack pointer back to the top.) If your program tries to do a normal RTS out of itself, random things can occur. If you want to exit the program, you'll need to jmp to the reset vector ($FFFC by default,) to do so.