Real-time LF sampling

[wh201906]

2167 with clear commit history and some minor improvements

Known limitations:

1. Only bits_per_sample = 8 is supported now.
2. Only USB connection is supported now. The transfer speed should be greater than 300kByte/s to support this feature.
3. When LF image is not loaded into the FPGA, the first 14 bytes could be the response of CMD_WTX rather than real samples. (Fixed in #2193)

[github-actions[bot]]

You are welcome to add an entry to the CHANGELOG.md as well

[wh201906]

@henrygab @iceman1001 Could you please review this PR?

[iceman1001]

Gentle reminder that we use calloc instead.

Some external libs still uses malloc which we don't want to fiddle with.

[wh201906]

I replaced declarations like this uint8_t bits[XXX] -> malloc() uint8_t bits[XXX] = {0} -> calloc()

Plus, all of the memory allocated by malloc() is actually initialized immediately by getFromGraphBuf() in commit 8b6a274e289cd96f16616de741f0d02fb10d1e6e, so I think it's not necessary to zero-initialize them first. Anyway, it's up to you. Would you prefer to still use calloc() for them?

[iceman1001]

I found that using calloc has helped us on different platforms, so yes, that is the prefered way.

[wh201906]

I've replaced them

[iceman1001]

Since I travelling, I will not be able to look at this PR until I get back.

[wh201906]

No problem, have a good time!

[iceman1001]

Got time to play little with this PR today.

looking good, it has some nice potential.
I found that the lf read -r didn't quite make sense. Should be smoother. end user shouldn't need to know, it should just work.

The demodulation code lfdemod.c has 512 bit limits, which now can be increased much more.

I get some freezes, indicating there are some memory issues still.

but I like it.

scrolling in the plot window is confusing when its this large..

[wh201906]

I found that the lf read -r didn't quite make sense. Should be smoother.

But the real-time stuffs has speed requirements. It's not always working, especially for the wireless connections.

I get some freezes, indicating there are some memory issues still.

You mean it's in lfdemod.c?

[iceman1001]

I would say it should be automatic..
Default sample size or less, should go the old way, if a larger sample size, it should go the alternative way. lf read isn't like real time sniffing..

Hold on with changing demodulation functions. Otherwise this PR will be become too large. Better to change that after we get this one merged

[wh201906]

OK. Is there anything I need to do for improving this PR?

Default sample size or less, should go the old way, if a larger sample size, it should go the alternative way.

Sounds reasonable

[iceman1001]

Check for memory leaks.

[wh201906]

Any steps to reproduce the memory leak bugs?

[iceman1001]

do different lf / data operations?

[wh201906]

I got a segmentation fault when running data modulation over 132000 samples. It should be fixed now. There are not too many changes to the demodulation functions, so I included them in this PR.

[iceman1001]

alright, doing some more testing, this text should be adapted to match new samples.

"data samples -n 10000"

static int CmdSamples(const char *Cmd) {

    CLIParserContext *ctx;
    CLIParserInit(&ctx, "data samples",
                  "Get raw samples for graph window (GraphBuffer) from device.\n"
                  "If 0, then get whole big buffer from device.",
                  "data samples\n"
                  "data samples -n 10000"
                 );
    void *argtable[] = {
        arg_param_begin,
        arg_int0("n", NULL, "<dec>", "num of samples (512 - 40000)"),
        arg_lit0("v", "verbose", "verbose output"),
        arg_param_end
    };

[iceman1001]

Or... data samples is a old style...

[iceman1001]

The lf search only uses the old one too...

lf search -u

[wh201906]

I'm not sure what I should do now... It looks like the data samples is only for fetching existing data from the device memory, so I guess it has nothing to do with the real-time samples. As for lf search -u, I just tested lf search -1u to use the samples from the graphbuffer(300000 samples), and it doesn't crash.

[iceman1001]

One of these days, we should refactor lf search to read once and then send through all the demodulators...

Making sure we don't do multiple reads

[iceman1001]

Lets merge,
and see what kind of bugs is coming out.

I have some suggestions for improvements as stated above.

[wh201906]

Thank you @iceman1001 and @henrygab for reviewing this PR and #2167