![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ex0_planetЛюблю человекочитаемые протоколы. Можно подсоединиться телнетом и поизучать внимательно что происходит.
Как следует из upd к прошлому посту, проблема проявила себя и в raw tcp mode, где в принципе нет никакого rpc, а есть простой текстовый (протоколом это трудно назвать) обмен: туда команды в ascii, обратно такие же ответы (ну иногда с примесью binary, но это неважно). И, собственно, если поставить развертку помедленнее, внимательно смотреть за происходящим на экране скопа и сопоставлять это с тём, что печатается в терминале и появляется оттуда, можно выяснить пару интересных подробностей.
Короче говоря, похоже что никакой "проблемы short reads" не существует в принципе. Авторы libsigrok приняли за проблему совершенно штатное поведение скопа, а именно, что пока идет развертка, то полному кадру данных взяться НЕОТКУДА, эти события еще не произошли. Поэтому отдается ровно то что есть на момент прихода команды. Ну а если скоп в этот момент только ждет триггера (или набралось меньше половины кадра, потому что pretrigger, да), то отдается ПОСЛЕДНИЙ полный кадр. Т.е. если sigrok'у по какой-то причине именно полный кадр и нужен, придётся либо останавливать развертку и читать из background memory как сказано в мануале, либо же как-то переделать работу с триггером чтобы гарантированно дожидаться окончания кадра. Вероятнее первое, поскольку если мы хотим работать со скопом как с LA (триггер-записали-вычитали награбленное), то так и надо делать, а чтение "по-живому" из front buffer оставить для live view (или как там эту функцию могли бы назвать маркетологи).
Окей, гугл, как объяснить девелоперам что у них ВСЁ сделано неправильно???
PS. Блин, как неохота загружать в голову еще три бегамайта исходников...
UPD Родные тулзы скопа (Ultraview или как его там) делают ровно то что я описал: нет данных — рисуют кусок графика.
Как следует из upd к прошлому посту, проблема проявила себя и в raw tcp mode, где в принципе нет никакого rpc, а есть простой текстовый (протоколом это трудно назвать) обмен: туда команды в ascii, обратно такие же ответы (ну иногда с примесью binary, но это неважно). И, собственно, если поставить развертку помедленнее, внимательно смотреть за происходящим на экране скопа и сопоставлять это с тём, что печатается в терминале и появляется оттуда, можно выяснить пару интересных подробностей.
Короче говоря, похоже что никакой "проблемы short reads" не существует в принципе. Авторы libsigrok приняли за проблему совершенно штатное поведение скопа, а именно, что пока идет развертка, то полному кадру данных взяться НЕОТКУДА, эти события еще не произошли. Поэтому отдается ровно то что есть на момент прихода команды. Ну а если скоп в этот момент только ждет триггера (или набралось меньше половины кадра, потому что pretrigger, да), то отдается ПОСЛЕДНИЙ полный кадр. Т.е. если sigrok'у по какой-то причине именно полный кадр и нужен, придётся либо останавливать развертку и читать из background memory как сказано в мануале, либо же как-то переделать работу с триггером чтобы гарантированно дожидаться окончания кадра. Вероятнее первое, поскольку если мы хотим работать со скопом как с LA (триггер-записали-вычитали награбленное), то так и надо делать, а чтение "по-живому" из front buffer оставить для live view (или как там эту функцию могли бы назвать маркетологи).
Окей, гугл, как объяснить девелоперам что у них ВСЁ сделано неправильно???
PS. Блин, как неохота загружать в голову еще три бегамайта исходников...
UPD Родные тулзы скопа (Ultraview или как его там) делают ровно то что я описал: нет данных — рисуют кусок графика.
