Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some clarifications on the OmniView functionality #7

Open
R-Abbasi opened this issue Dec 7, 2023 · 5 comments
Open

Some clarifications on the OmniView functionality #7

R-Abbasi opened this issue Dec 7, 2023 · 5 comments

Comments

@R-Abbasi
Copy link

R-Abbasi commented Dec 7, 2023

Is this a correct understanding?

  • Streams of data called chunks are coming from devices and consumed by the Epoch
  • Chunks are pointers to void
  • Devices are the exported API/functions of a shared library
  • Epoch allocates memory for the pointer then hands it back to the device and the device will fill it in turn, e.g., using iota in 256-char ranges - each range analogous to a time domain. Afterwards, the consumer (Epoch) picks the data and forwards it to other parts to be viewed/analyzed.
@MaxClerkwell
Copy link
Contributor

a) Streams get chopped into chunks by the UaDI. Empty chunks get allocated by the consumer. Empty chunks get handed to the library at claim and via push_chunk. Chunks get handed back from the Library via the callback.

b) chunks are the things themselves. A chunk_ptr is implemented as unsigned char* according to @odinthenerd s advise. See: https://github.com/skunkforce/unified-abstract-dataproducer-template/blob/4b1d17670bc2fd8f5ff7fe798d1facd9396a0d00/src/UaDI_template.h#L77

c) A Device is every thing that produces data, fills a chunk and calls the callback.

d)

  • epoch allocates memory: yes
  • hands it to the device: yes
  • the device fills it: yes
  • when done filling one chunk, the device calls the callback with the chunk_ptr
  • the iota simulates an oscilloscope measuring a saw-tooth function
  • the epoch doesn't pick the data up, its callback get's triggered by the device
  • the epoch forwards it (or saves it): yes

I hope I make sense. Please ask for more clarification if needed. This explaination shall be added to the product vision.

@R-Abbasi
Copy link
Author

R-Abbasi commented Dec 7, 2023

Please explain the following terms too. The code doesn't seem complicated but at times the terminology makes things a little dark.

  • What is or what parts of the code (the DLL and the source using it) do stand for "the consumer"? Is it the init(...) and deinit(...) functions or is it the DLL consumer, source/main.cpp?
  • Many times the term library is used in the comments. Do you refer to the DLL by that, please?
  • The uadi_status function with 9 parameters may be hard to use and reason about I suppose.

@MaxClerkwell
Copy link
Contributor

Sure!

  1. The consumer has to call init before it can claim a device. init creates a connection-object inside of the DLL-main. The location of the connection-object is the libhandle. This needs to be done, since a DLL could be potentially called by multiple consumers. Therefor the Library/DLL has to keep track of who it is connected to. When the consumer shuts down, it shall deinit its own connection to the library. Thus the consumer has to call deinit and the connection-object inside the DLL-main shall be freed.

  2. Sorry for the confusion here: Yes - lib, library, DLL - these have been synonymous in my communication. I will try my best to only use DLL from here on

  3. Do you mean claim - it needs so many parameters because we want to initialize a device in one step and it doesn't have valid state unless all of these options have benn set.

@R-Abbasi
Copy link
Author

R-Abbasi commented Dec 8, 2023

A consumer is what that consumes the DLL. Now things are clearer. Thanks.

I guess if you add a line at the beginning of the comments at the top saying: "By library we mean the shared library (.so/DLL)", and then only use the name library, no confusion remains regarding that.

As for the function name, sorry, yes, I meant claim. I suggest taking its functionality and giving it to several other functions each with up to three parameters. Many number of functions makes more sense than a function with many number of parameters, I suppose.

@MaxClerkwell
Copy link
Contributor

Well, I understand your concern about claim, but: if you would call those three functions in the same order anyways, it can also be one function. Without all there parameters, the claimed device would be in an illegal state.

The trade-off here is:
I will have to explain, that when a device is being claimed, 3 functions with 3 paramters each have to be called in the exact order.

Or

Call this one function that takes 9 parameters.

First approach is what Qt does, but this doesn't make any sense. If you don't use the one function correctly, you'll get a compiler-error. If you don't use the three functions correctly, you could end up having a program that compiles, but crashes at run-time.

I'd love to here @odinthenerd opinion on that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants