Jump to content

    

VslavX

Свой
  • Content Count

    1046
  • Joined

  • Last visited

Posts posted by VslavX


  1. При большом количестве задач и большом числе внешний воздействий на систему, отслеживание состояний всей системы (кто чего ждет, сколько ждет и т.п) скопом, не прибегая к дополнительным ухищрениям стоит многого. Особенно если система пишется не одним человеком.

    Смотря что Вы ожидаете от отладчика. Тут в топике рассказывали про отладочный терминал в консольном режиме - такой под TNKernel в одиночку написался за несколько дней - можно смотреть списки объектов, список задач - где чего (в каком файле и в какой строке исходника) ждет и чего именно ждет. По синхрообъектам видно какие задачи ждут (очередь ожидающих задач), есть профайлер - точный (до тика процессора) и грубый быстрый (до мс) - видно какая задача сколько времени забрала. Там всего несколько сотен строк кода - вполне подъемно, причем не только для TNKernel - все системы такого уровня более-менее одинаковой сложности.

     

    Кроме того в моем случае еще играет сила привычки - коллектив до некоторых пор сидел на несовсем лицензионном :) изделии одной известной фирмы, в котором был подобный инструмент.

    А можете рассказать подробнее какими именно экстрафичами инструмента пользовались, хотя бы в общих словах?

     

  2. У PHY-источника при autonegotiation по-моему всегда установлено enable flow control по умолчанию.

    Нет, надо смотреть даташит на конкретный PHY чип. Например, MV88E1111 конфигурируется внешними ножками, что именно декларировать при negotiation. А у KSZ8031 - по дефолту после сброса стоит "No PAUSE".

     

     

  3. У меня к Вам практический вопрос. Нужно ли PHY конфигурировать на enable pause ?

    ИМХО, конфигурировать PHY нужно в той части, в которой оно сообщает своему Link Partner о поддержке Flow Control. Я понимаю это так, что самому PHY принимаемые-передаваемые фреймы PAUSE безразличны и в самом PHY ни на что не влияют. Но при установлении линка два PHY между собой проводят negotiations - меняются между собой специальными фреймами (которые на MAC не транслируются), и вот там передается информация о поддержке Flow Control MAC-ом каждой стороны. Поскольку PHY о возможностях имеющегося на его стороне MAC ничего не знает, то обычно внутри PHY имеется регистр, куда софт до разрешения линка и проведения negotiations записывает информацию о том как имеющийся в наличии MAC и его драйвер будут поддерживать PAUSE. Потом линк разрешается, PHY проводят между собой negotiations и софт на удаленном хосте может прочитать из своего PHY результаты "переговоров" и узнать, будет ли наш MAC передавать и принимать PAUSE-фреймы.

     

     

  4. Не совсем так. В одноранговых сетях peer-to-peer каждый хост должент выполнять административные функции и отслеживать общую конфигурацию сети. Например средства MS-сети, встроенные в Windows, так называемые "подключения".

    Мда, "смешались в кучу люди, кони" (с).

    Есть такая вещь - OSI - Open Systems Interconnection. Она описывает уровни сетевого взаимодействия, классической считается 7-уровневая модель. Так вот, обсуждаемый в данном топике Flow Control относится к уровню L2 (канальный, Data Link Layer). А все что Вы написали - администрирование, конфигурирование и прочее - как минимум парой-тройкой уровней модели выше и к топику имеет очень и очень слабое отношение.

    Поэтому вы ошибаетесь насчет повсеместного p2p.

    Повторюсь - p2p на канальном уровне (L2). Если используется Ethernet на витых парах, то порт каждого хоста на канальном уровне общается непосредственно с портом другого хоста или свича. И каждое такое соединение на канальном уровне - точка-точка, отдельный сетевой физический сегмент.

     

    Вы снова ошибаетесь. Вот типичный пример. Есть некий источник данных, который может формировать UDP пакеты и отправлять их по гигабитному Ethernet каналу в сеть со скоростью примерно 800 mbps.

    ИМХО, это не типичный пример, а сложности FPGA-шников при реализации нормального надежного транспортного протокола типа TCP.

     

    В этой сети, имеется приемник этих UDP-пакетов, который может принимать и обрабатывать поток данных не быстрее, например 400 mbps. Хосты соединены через гигабитный свитч. Теперь прикиньте, за какое время переполнится 32 Мегабайт буфер вашего хваленого свитча, если торомозить порт свитча и не торомозить непосредственно источник данных? Правильный ответ- за 1 минуту.

    Оставляя в стороне типичность примера и соответствие выбранной топологии задаче, а кто Вам сказал что источник не будет тормозиться? Тормозится он будет - но не конечным приемником, а по переполнению буфера в свиче. То есть - когда буфер в свиче (а не в приемнике данных) начинает переполняться - свич сам выдаст источнику PAUSE.

     

    Ничего личного, но криво читаете стандарты. Там говорится, что PAUSE умирает в bridge, но не в switch. Это сильно разные вещи.

    Нет, вот именно ethernet switch на витых парах и является bridge - поскольку он соединяет физически отдельные сетевые сегменты на уровне L2. То что эти сегменты используют физику одного стандарта (а не разных) не имеет ровно никакого значения - все равно это bridge.

     

    Я занимаюсь отправкой UDP-пакетов в гигабитный Ethernet используя в качестве контроллера FPGA. Скорости формирования и отправки данных примерно такие, как я представил в живом примере выше. Эта задача решена только за счет того, что в PAUSE пакте проставляется конкретный MAC-адрес источника данных. И представьте, этот пакет прекрасно проходит через свитч и достигает именно источника!

    Он проходит и достигает, поскольку Вы нарушили стандарт и засунули в пакет не требуемое фиксированное малтикастовое значение DA, а индивидуальное. А ведь вполне может попасться такой свич который еще и на управляющее поле пакета смотреть будет - от тогда PAUSE может и не дойти. И Вы хотите сказать, что если указать фиксированный DA в PAUSE, то возникают проблемы? ИМХО, тогда это не очень хорошее оборудование (свич).

     

    Итого, для меня результаты дискуссии такие:

     

    1. Стандарт четко описывает чего в PAUSE посылается, и как PAUSE на уровне L2 коммутируется.

    2. Распространенные микроконтроллеры не имеют средств задания индивидуального DA в отсылаемом PAUSE и не понимают индивидуальный DA в принимаемом PAUSE.

    3. Просто здравый смысл (пример с NAS, DLNA-телевизором и тестовым девайсом)

     

    Дальше, в-общем-то, обсуждать нечего.

     

    Когда я реализовывал свой сетевой стек, вопрос Flow Control на уровне L2 обдумывал тщательно, в итоге его не использую вообще. Все функции FC возложены на транспортный уровень - в моем случае TCP. Правильный выбор размера окна решает(_в общем случае_, а не только при использовании ethernet) проблему переполнения и прекрасно масштабируется, например HTTP-сервер на 8 сокетов, живет на 4К буферной памяти с окнами по 512 байт на LPC23, а искази-таргет выжимает по TCP 70Мбайт/сек с мегабайтным окном на MPC8347.

     

    У Вас в FPGA нет TCP (по крайней мере такого же быстрого как аппаратный UDP), отсюда и желание использовать Flow Control на нижних уровнях сетевой модели. Я думаю, если сделаете по стандарту (фиксируете DA в PAUSE) и возьмете нормальный свич, то ситуация хуже не станет.

  5. Читаю здесь.

    ИМХО, там какое-то народное творчество. "Не читайте до обеда советских газет" ©. Смотрим IEEE Std 802.3™-2008, Section 2, Annex 31B, называется MAC Control PAUSE operation (специально не поленился скачать редакцию 2008 года, до этого ковырялся в 2002):

     

    31B.1 PAUSE description

    The PAUSE operation is used to inhibit transmission of data frames for a specified period of time. A MAC Control client wishing to inhibit transmission of data frames from another station on the network generates a MA_CONTROL.request primitive specifying:

    a) The globally assigned 48-bit multicast address 01-80-C2-00-00-01,

    b) The PAUSE opcode,

    c) A request_operand indicating the length of time for which it wishes to inhibit data frame transmission.

    (See 31B.2.)

     

    The PAUSE operation cannot be used to inhibit transmission of MAC Control frames. PAUSE frames shall only be sent by DTEs configured to the full duplex mode of operation. The globally assigned 48-bit multicast address 01-80-C2-00-00-01 has been reserved for use in MAC Control PAUSE frames for inhibiting transmission of data frames from a DTE in a full duplex mode IEEE 802.3 LAN. IEEE 802.1D-conformant bridges will not forward frames sent to this multicast destination address, regardless of the state of the bridge’s ports, or whether or not the bridge implements the MAC Control sublayer. To allow generic full duplex flow control, stations implementing the PAUSE operation shall instruct the MAC (e.g., through layer management) to enable reception of frames with destination address equal to

    this multicast address.

     

    Я говорю не о p2p, а о некоторой локальной сети из хостов, обьединенных через свитч(и)- наиболее типичный случай для

    В случае если используется BASE-TX, то сеть на L2 именно и состоит из набора P2P.

     

    хост-источник потока данных ничего не будет занать о такой блокировке и продолжит накачивать буфер свитча

    "И это хорошо!" ©. А зачем хосту-источнику знать о блокировке приема хоста приемника, если источник как раз может чудно слать данные в буфер свича? Есть возможность - данные из хоста отправляем, ничего не ждем, а оборудование на маршруте само разберется. Я вот чудный гигабитный свичик SLM2008 прикупил - никак не могу определить сколько у него памяти на борту - по разным источникам от 4 до 32 Мегабайт. "Это жжжж - наспроста" © - имхо, Циско что-то знает, раз столько памяти в свич ставит.

     

    пока тот не переполнится. Поэтому, единственно возможный вариант выровнять скорости приема-передачи- это Flow-Control

    непосредственно на источнике данных.

    Такое было бы единственно возможным вариантом, если бы у нас был тупой провод между источником и приемником, а когда у нас посередине умное оборудование с приличным буфером, то глупо им не пользоваться.

     

    Вывод- свитч должен тупо пересылать PAUSE пакеты по назначению. И никакой самодеятельности.

     

    Нет, не так - по стандарту PAUSE тут же в свиче и умирает:

    The globally assigned 48-bit multicast address 01-80-C2-00-00-01 has been reserved for use in MAC Control

    PAUSE frames for inhibiting transmission of data frames from a DTE in a full duplex mode IEEE 802.3

    LAN. IEEE 802.1D-conformant bridges will not forward frames sent to this multicast destination address,

     

    Upd: редакция стандарта 2002 говорит тоже самое. Возможно еще более старые стандарты допускали отправку индивидуального DA, но на сегодня это не так.

     

    Upd2: просмотрел Ethernet MAC контроллеры для которых писал код (SAM7X, LPC17/23, MPC83xx, STM32F2xx) нигде не нашел в регистрах как задавать DA - везде PAUSE фреймы генерируются автоматически, с фиксированным в стандарте малтикастом. На прием аналогично - проверяется именно малтикаст. Так что - на упомянутых контроллерах фрейм PAUSE с уникальным DA это типа "закат солнца вручную" - только искусственно сформировать и отослать как обычный пакет.

     

     

    В последнем случае будут заторможены все хосты данной локальной сети, поскольку свитч разошлет паузу им всем.

    Это вообще шедевр. У меня такой свич на следующий день на помойке был бы. Типа домашние смотрят с NAS-а по DLNA фильм, а я в той же домашней сетке устройство на микроконтроллере отлаживаю, как там затык - расступись море получите фриз вместо фильма?

     

  6. Причем, Dst может указывать на конкретный хост в сети, который надо тормозить.

    Тормозить хосты в других сегментах (под сегментом я понимаю в данный момент соединение точка-точка между MAC-контроллерами - грубо говоря один прямой или кросс-кабель) нет никакого смысла - удаленный хост вполне себе может меняться с другими хостами, а не только с тем на котором затык и который высылает PAUSE. Также на маршруте может быть буферизация (например, в свичах) - тогда блокировка выглядит вообще вредной - не дает нормально пользоваться буферизацией. Поэтому пакет PAUSE именно имеет фиксированное значение dst адреса, и предназначен для приостановки передачи именно в непосредственно подсоединенном полнодуплексном сегменте (для полудуплекса там другие методы типа back pressure используются)

     

    тупо пересылать PAUSE пакеты по назначению хостам. Или я что-то неправильно понял?

    ЕМНИП, никуда PAUSE свичами не пересылается - а просто употребляется по назначению на принявшем его порту - только этот конкретный порт временно приостанавливает передачу. Другие порты банально могут быть полудуплексными - пакет PAUSE там просто не будет иметь смысла.

     

    Вот выдержка из википедии (стандарты лень копать - они там неохватные):

    Pause frame

     

    The overwhelmed network element can send a PAUSE frame, which halts the transmission of the sender for a specified period of time. Media Access Control (MAC) frames to carry the PAUSE commands using Control opcode 0x0001 (hexadecimal). Only stations configured for full-duplex operation may send PAUSE frames. When a station wishes to pause the other end of a link, it sends a MAC Control frame to the 48-bit destination reserved multicast address of 01-80-C2-00-00-01. The use of a well-known address makes it unnecessary for a station to discover and store the address of the station at the other end of the link.

     

    Another advantage of using this multicast address arises from the use of flow control between network switches. The particular multicast address used is selected from a range of address which have been reserved by the IEEE 802.1D standard which specifies the operation of switches used for bridging. Normally, a frame with a multicast destination sent to a switch will be forwarded out all other ports of the switch. However, this range of multicast address is special and will not be forwarded by an 802.1D-compliant switch. Instead, frames sent to this range are understood to be frames meant to be acted upon only within the switch.

    Вывод - адрес хоть и малтикастовый, но из зарезервированного диапазона, и если свич "правильный", то никуда PAUSE дальше не пойдет.

  7. Еще ОС РВ многопользовательская у см-4 была (RSX-11)

    Ото была вещь - я пару лет на такой поработал в 80-х. Многозадачность, асинхронный ввод-вывод (QIO(рубль)S :)), виртуальная память, разделяемые резидентные библиотеки - весьма вкусно все было для тех времен. RT-11 (SJ и FB) после работы под RSX уже не так интересно воспринимались.

  8. ВОбычные стабилитроны не в счет - у них есть тараканы в голове, даже у наших 2Г401 - много брака, в смысле бывают частотные пики в шуме.

    У меня студенческий проект был на втором курсе - собрать аппаратный RNG для использования в численном моделировании физ процессов (плазму моделировали, а то псевдогенератором накидают частиц в объем - а они там стройными рядами висят). Был взят (1988 год) обычный Д814, каскад на парочке 544УД2, и все это было в аккуратной радиолюбительской коробочке прицеплено к модулю АЦП в крейте КАМАКа. Ну и потом долго вдумчиво анализировалось (под RSX-11M, на фортране, да). Так вот, в полосе до 25кГц (это была максимальная частота оцифровки имеющегося АЦП), вылезли только вездесущие 50Гц, после программного "выравнивателя энтропии" (тогда банально скармливали физические числа псевдогенератору - ни SHA-1, ни ГОСТ 28147-89, ни DES тогда нам известны не были) на выходе уже никаких корреляций не было.

    Касательно сегодняшних дней, то, например, ДСТУ 4145-2002 стандартизует процедуру "выравниватель энтропии" и никаких особых требований к спектру физического источника не выдвигается.

     

  9. 2 rx3apf: Спор ни о чем. Если для Вас периферия закончилась на реле, светодиодах и древних символьных ЖКИ, то можете оставаться там и дальше.

    1. Древние-то они древние, зато дешевые, поэтому широко применяются, по крайней мере, в наших изделиях.. Минимальное входное высокое типовое Vih = 0.8*Vcc - то есть 4 вольта. Если подключить напрямую к выходам 3.3В контроллера - то на практике бывают глюки, не массово, но случаются. Буфер типа HCT244 ставим не просто так.

    2. Очень многие дешевые термоголовки для термопринтеров тоже 5-вольтовые CMOS, с теми же 0.8*Vcc, тоже без буфера бывают неприятности.

    3. Преобразователи RS-232 как ни странно с 5 вольтовым питанием дешевле 3.3В, но с ними хоть проблем нет - от 3.3В выхода работают.

    Ну я к тому что 5-вольтовое наследие еще есть, хотя и потихоньку умирает (и еще лет 5 минимум будет продолжать это делать)

     

  10. Возник тут вопрос непраздный... Понадобился DCC терминал чтобы в отладочном режиме устройства (наладчик на выезде) работать с stdio устройства на Cortex M3

    ...

    Может я просмотрел чего то и есть уже в природе такое чудо в готовом виде?

    На Cortex-M3 нет DCC. Только какая-нибудь эмуляция (мне удалось выкрутиться через пару неиспользуемых регистров отладчика).

     

  11. Раз сам возил Лекрой на Киевский вокзал. Покупатель договаривался с проводником, передавал ему.

    Несколько раз покупатели на такси туда приборы возили. Так что, видимо, там оптимальный путь.

    Самолетом на сегодня, как ни странно, дешевле поезда. Ясно, буду думать, если чего надумаю - отпишусь. В любом случае - такой прибор долго не залежится.

     

  12. Потому, что это портативный (переносной) прибор, а для них это обычное дело

    Ага, я работал с тектрониксом TPS-2012. Там были интересные плюшки (помимо портативности, которая мне не нужна) типа гальванически отвязанных входов - работали почти как дифференциальные пробники (не сравнить с обычным скопом два канала с вычитанием). Но его скромные 2.5К точек меня несколько напрягали.

     

  13. Ретро-БК0011М улетает за 8-10 тыс с молотка за пару дней. Спрос явно есть. На более крутую машину с обратной совместимостью тоже со временем найдутся пользователи.

    Такой вопрос - а что, в FPGA на ZX evo БК-шка не влезет? Там вроде Циклон второй стоит? Ну потолще Циклончик поставить - и все - "это и охота, и зверей убивать не надо" - сразу два РетроПК на одной платформе.

     

  14. Накидал сейчас простенькую программку (нафига козе баян зачем VslavX-у генератор :)) - чтобы померить "суслика" у своего скопа .

    Принцип такой - формируем импульс длительностью примерно 1мкс, потом ждем некоторое регулируемое время (от 1 до 100 мс), потом формируем два микросекундных импульса с интервалом тоже 1мкс. Развертка в ждущем режиме, 1 мкс/деление.

     

    Если время между первым импульсом и второй группой менее "мертвого времени", то на скопе видим один импульс:

    post-10038-1321552987_thumb.png

     

    Если же время между импульсами более "мертвого" - то видим два импульса:

    post-10038-1321552993_thumb.png

     

    Результаты такие - у Rigol два импульса появляются при паузе от 11мс - не каждый раз (изредка), и устойчиво при 20мс. От развертки эти времена зависят незначительно. Вывод - мертвое время у Rigol 1102E порядка 20мс.

     

    Для сравнения принес с работы младший LeCroy WaveJet 322. Так вот - у него это время оказалось порядка 2-3мс. В-общем, LeCroy получше, ага (а я так надеялся на китайцев :biggrin:). Правда, шумит как самолет :( (и стоит как самолет тоже :)), но то такое.

     

     

    при одном используемом канале это будет fд= 32000/0,1= 320 Квыб/сек

    Неужели там 32К всего? Тогда - печалька :05:

     

    Upd: кстати, в "режиме регистратора" (развертка на однократку) на разрешении 1мс/клетка Ригол синхронизировался по первому импульсу, поймал вторую группу (вылезла за кадр, пауза 10мс), и тысячекратно увеличив позволил четко различить оба микросекундных импульса во второй группе. На повторяющейся синхронизации по фронту такого нет, то есть - именно однократка отличается тем что пишет всю имеющуюся память. И это понятно - не надо стремиться уменьшить мертвое время - не будет больше захвата, пока пользователь кнопку не нажмет. Кстати, я этой особенности не знал и не понимал - однократкой почти не пользовался, а оно вон как.

     

  15. ну никак не можно :)

    Я не силен в схемотехнике скопов, изложу просто свои общие соображения.

    Чисто теоретически, допустим, решили сделать новый крутой дешевый скоп. Бюджет на изделие пусть $500. Есть две (упростим) основные части, назовем их грабилка (захват данных) и молотилка (обработка). Бюджет поделим "по-братски" - по $250 на каждую часть. Смотрим на рынок, так, для грабилки за $250 мы купим четыре АЦП по 250Мспс, аналоговая там еще мелочевка, итого - 1 Гспс грабилка за эти деньги делается. А молотилка? Ну пусть крутой супер-пупер DSP на 2ГГц с обвязкой (у нас типа $250 на это есть). Ой, стойте, что, 2 такта на отсчет? Не, не пойдет, там сплайн обсчитать, фильтры-коррекции программные наложить, на экран вывести итд и тпд, ну хоть 100 тактов на точку. И приходим мы к тому что никак более 20М точек в секунду обработать не сможем.

    Думаю, в каждом ценовом классе скопов ситуация примерно такая же - в пределе скорость обработки на порядок-другой от скорости захвата отстает. Грабилка может хватать данные с большой скоростью и класть их в память, но обработать в реальном времени это технологии не позволяют. Поэтому тут видятся такие варианты. Первый - обрабатывать отложенно - награбили на всю память и потом вдумчиво смотрим, это режим регистратора. Второй - грабим, стопаем, обрабатываем. Похоже что так работает большинство скопов. Вот тут то "суслик и порылся" - пока обрабатываем, данные идут мимо. Я же имел ввиду третий вариант - не стопать грабилку. Награбили на кадр, обрабатываем, грабилка параллельно грабит дальше (пока память есть). Молотилка сделала работу и смотрит, не награбила ли грабилка чего нового (не было ли нового синхрособытия в награбленном). Вот этот третий вариант - он позволил бы несколько кадров сшить, ну пока памяти хватает и пока не перезаписано новыми данными. Но, видимо, реально никому не надо (ну не открыли же мы тут на форуме Америку? :biggrin:). По-хорошему, такой вариант требует "честной" двух портовой памяти, а это денег стоит. Дешевая же массивная (большого объема) однопортовая память потребует поделить ее полосу пропускания между грабилкой и молотилкой, что снизит предельную частоту сэмплирования. В-общем, ухитриться можно, но не совсем "на шару", да и нужно ли?

     

    когда вы отлаживаете ~100...1000МГц потоки, то потери на мертвое время у вас уже достигают 99% от всего полезного сигнала

    Да, печалька. Это также видно из прикидки моего гипотетического $500 скопа. Но для скопа, имхо, уже не столь существенный вопрос как для регистратора. Вон в моем примере я ЛА привлекал, потому скоп - это скоп, а регистратор - это регистратор.

     

  16. У меня такой надобности в ZX нету.

    Вот если бы чего для БК могли реинжинирить - заказал бы.

    А чего, я такой (как вот в примере для ZX) кит для БК-шки купил бы, в пределах $100-150 - поностальгировать. Только никаких магнитофонов и телевизоров - SD-карта (или SATA/Ethernet) и VGA выход.

     

  17. мертвое время можно и на генераторе ПСП посмотреть (но не измерить). Есть у вас последовательность 25 или 26, что бы глазом увидеть?

    Да можно тест сделать, но зачем? Я признаю что между захватами, скорее всего, будет пропуск. При желании изготовители этот пропуск могли бы убрать, но когда реально это нужно? Скоп - это же многофункциональный прибор, а не чисто регистратор.

     

    Вот две типовые ситуации:

     

    1. Cижу, работаю, DDR-333 отлаживаю. Тыкаю щупом в шину данных, синхронизация по фронту. Ригол - "прости, хозяин, я всего лишь дешевый китайский скоп, у меня полоса 100МГц - завалю я тебе сигнал, и сэмплрейт у меня всего 1гспс, но ничего - я тут фазу захвата вычислю и красивую картинку нарисую. Тебе же форма сигнала сейчас важна, хозяин?". Я - "ничего, приятель, ну завалил, но форму показал более-менее, а вот тут криворукие монтажники терминирующую сборку перекосили, работу мы с тобой сделали"

     

    2. Сижу, работаю, протокол на RS-485 отлаживаю. Тыкаю щупом в шину, синхронизация по внешнему синхровходу (там изделие отладочный старт генерирует), однократка. Ригол - "прости, хозяин, я всего лишь дешевый китайский скоп, у меня памяти всего лишь 1 мегабайт, надолго я твой протокол не запомню". Я - "ничего, приятель, ты мне показал где шина освобождается, как там мастеры ее делят, а на помощь мы тебе твоего друга сейчас позовем - Дешевый Китайский Логический Анализатор - у него памяти побольше".

     

    Ну и где тут меня мертвое время парит? Работа как бы банальная, но и относительно скоростные сигналы посмотрел, и протоколы поотлаживал. Но это как бы проза жизни. А копил бы на Лекрой с "мифически мелким сусликом" - сидел, наверное, на своем студенческом C1-72 до сих пор (типа гипербола, но не так уж :biggrin:).

  18. тут я вас не понял - так вы соглашаетесь с наличием мертвого времени или нет?

    Да, соглашаюсь. Конкретно, в Риголе оно есть, но его обычно не видно. "Суслика видишь? А он - есть!" © :biggrin:

     

    я вас еще раз умоляю :) - продемонстрируйте отсутствие мертвого времени цифрового осциллографа между кадрами любым способом, пусть даже отличным от того, что просил я, если вдруг вам не нравится мой метод

    и расскажите как в вашем Риголе можно избавиться от мертвого времени между кадрами, если это о-о-чень надо

    Признаю - "суслик есть". Но я показал как пользоваться дешевым скопом в режиме регистратора - на всю имеющуюся у него память, "если это о-о-чень надо". А если данных больше чем объем памяти, то уже все равно какого размера суслик между захватами - данные-то пропали, тут никакой скоп выше своего объема памяти не прыгнет.

    И вот именно между кадрами я привел пример что суслика нет - я могу покрутить ручку триггера на оригинальной осциллограмме влево-вправо и видеть свои непрерывные данные . А между двумя "захватами на всю память", там да - "суслик". Но мне там неинтересно - данные-то у меня для медитации есть.

     

    если у вас дома нет никакого генератора, то может отложим этот эксперимент до появления генератора?

    А зачем он мне? Я занимаюсь на 99.9% цифровой техникой - нужные мне генераторы обычно находятся на платах изделий :biggrin:. Так что маловероятно что в ближайшее время у меня отдельный генератор появится.

  19. Вау! ну им теперь с такими успехами впору заняться разработкой вечного двигателя! :biggrin:

    А то :biggrin:. Ну, двигатель не двигатель, а цены на скопы китайцы подвинули, и еще не вечер!

     

    А не могли бы вы тут привести результаты следующего теста - на вход Ригола, который "такое умеет", подать треугольный сигнал частотой 1 МГц, синхронизацию поставьте по фронту, режим синхронизации "Автоматическая" и уровень запуска загоните выше уровня сигнала, это

    нужно что бы развертка работала в полностью автоколебательном режиме без условий синхронизации; зафиксируйте два

     

    В многократке ("автоматическое") "мертвое время" будет. Есть вариант как он него не избавиться, но на практике это не нужно - в этом режиме интересна именно динамическая индикация. А "избавление от мертвого времени" займет ресурсы - ту же ПСП. Я бы предпочел скоп с большим сэмплрейтом вместо "избавления", производители, видимо, думают так же :biggrin:

     

    не совпадает с экраном (в режиме "СТОП" при вращении ручки задержка, справа или слева за экраном есть еще продолжение осциллограммы), то для первого скриншота приведите конец осциллограммы, а для второй осцилограммы приведите начало.

     

    А вот в однократке - да, именно память не совпадает с экраном, У Ригола там сверху иконка даже есть - какой кусок захваченного отображается на экране в данный момент. Дома генератора у меня нету - покажу на калибровочном 1кГц.

     

    Оригинальная осциллограмма:

    post-10038-1321515588_thumb.png

     

    "Панорама" - сжатая для "обозрения окрестностей". Если еще больше сжать, то края, ессно, обрываются - на иконке сверху это видно - что окно вылезет за пределы памяти при растяжении.

    post-10038-1321515596_thumb.png

     

    А вот режим "микроскопа", даже до максимума не растягивал - просто срез сигнала для демонстрации разрешения

    post-10038-1321515602_thumb.png

     

    Ессно, это все однократка, это одни и те же данные, один раз захваченние и дальше только ручка развертки крутилась. В-общем, банальная вещь, о которой даже не задумывался.

     

    ы совпадает с началом другой :)

    Ессно, в автоколебательном режиме (да и с синхронизацией) будет "мертвое время" (Вы же на это намекаете "несовпадением" ?). Но, повторюсь, "мертвое время" для ЦЗО - это условность, миф. Если надо - от него можно избавиться, и не такими уж значительными ресурсами. Только не нужно это никому. Ну а режим регистрации "без мертвого времени" - пожалуйста, даже наидешевейший скоп это умеет.

     

    Upd: я тут упустил фишку "эквивалентная частота сэмплирования" - это когда фаза синхронизатора смещается, и набирают много измерений периодического сигнала со сдвигом по времени. Имхо, тут "мертвое время" малыми ресурсами не убрать.

  20. разработайте такой девайс, сделайте работающий макет, пусть даже и на соплях и покажите монстрам типа LeCroy, Agilent, Tektronix; я уверен, что они все это купят за о-о-очень большие деньги (поскольку сами они этого делать не умеют) и вас ждет прекрасное будующее как у Била Гейтса или Стива Возняка

    Да поздно уже - даже Ригол такое умеет :biggrin: - я изложил вывод в апдейте предыдущего своего поста.

  21. надо же иметь не просто систему пердачи каких-то данных внутри себя , а обеспечить вывод информации на экран, где 100 картинок это

    Кому мало? Пользователю? Так он эти 100 картинок в секунду разглядеть не успеет. А если там игра типа "цифровой фосфор" то пользователю все равно когда такая картинка появится - на 4 мс позже (пока захватывали типаничего не делали) - ну и что?

    мало, обеспечить проведение измерений (и не одного и не двух), потом у осциллографа еще и органы управления есть - надо и за ними приглянуть, про синхронизацию не забыть и т.п. все это создает мертвое время между кадрами в осциллогафе

    Да какие там измерения? Курсорные? Ну фильтры программные наложить, сплайн посчитать - это все и после захвата можно сделать. Синхронизация все равно сделана аппаратно - один раз отработала и пошли записывать свой кусок. Органы управления - то да, они конечно вычислительной мощности отберут :biggrin:. И в любом случае, показывать все захваченное в "реальной времени" не получится - просто ни скорости панели, ни реакции человеческой физически не хватит.

    ЦЗО - это совершенно другого принципа прибор, нет смысла городить на нем полную имитацию скопов на ЭЛТ. И, на мой взгляд, тут нет НИКАКИХ принципиальных причин для появлени "мертвого времени". То есть, реализовать режим "записали за 4мс 7М и потом полдня их рассматриваем" даже на бюджетном приборе вполне возможно. Не знаю, правда, насколько такое нужно для "малоканального" скопа, но на логическом анализаторе (весьма бюджетном, кста - 36М точек, 4гспс) у меня это обычная ситуация.

     

    Upd: я реально задумался - а почему таки режима нет, покрутил немного живой скоп, и понял - что режим-то есть. Ключевой момент - однократка. Если непрерывный захват - то да, скоп не может писать долгий кусок, ему надо писать определенное время после синхронизации (на длительность развертки), потом бросать запись, рендерить изображение, измерять чего там юзеру надо, снова взводить схему синхронизации и ждать новый кадр. Так что тут правда - есть "мертвое время", никуда не уйти.

    А вот однократный захват - это тот самый режим регистрации. Тут скоп прикольно работает - такой себе симбиоз панорамы с микроскопом. Он хватает данные за интервал примерно в 2-4 раза больше чем длительность развертки и на максимальном разрешении, которое ему позволяет имеющаяся память. И получается так что сигнал сграбили, и потом раз - развертку ужали и получили панорамную картинку - обозрели окрестности, потом два - покрутили в другую сторону ручку, растянули изображение, и увидели в микроскоп все детали. И никакого тут "мертвого времени" - сиди медитируй.

     

    Upd2: еще немного подумал и пришел к выводу что и при многократке можно от "мервого времени" избавиться - пишем себе постоянно в реальном времени (хоть банально в кольцевой буфер), а обрабатываем по возможности (ну сколько успеем) кадры по меткам синхронизации на текущий момент начала обработки. Только не нужно это усложнение никому - если включена многократка, то вероятно пользователя в данный момент интересует именно динамический режим скопа, а не "панорама с микроскопом". Правда, иногда бывает так что сидишь смотришь на экран, наблюдаешь, вдруг кидаешься к кнопке "стоп" - а все, "поезд уехал, рельсы остыли". Если памяти маловато то и панорама не поможет - именно потому что "рельсы остыли" (буфер давно перезаписан новыми данными, пока кнопку нажимали).

     

  22. У топовых моделей с памятью все в порядке - у ЛеКроя, Тектроникса, Агилента... А у бюджетных моделей пока не делают

    Так я и не понимаю почему нет в бюджетных. Память DDR2/3 дешевая, да ПЛИС за $30-40 - это все засосет поток 2Гбайта/сек аж бегом. И то - 2Гбайт/сек это верхняя граница дешевых скопов, мой Ригол 1100 всего 1Гбайт/сек генерит. На сегодня это отнюдь не фантастические цифры ПСП, реализуются достаточно бюджетно.

     

    Лично у меня надежда на USB 3.0. Жду появления USB 3.0 -осциллографов, которые смогут закинуть в компьютер длинную непрерывную выборку, т.к. USB 3.0 это позволяет.

    Не, там не так уж и радужно. Всего 5Гбит/сек кодированного потока (8/10 там или что-то подобное) если в итоге на 400Мбайт полезных данных вырулят - хорошо будет. Ну и протокол USB повторы предусматривает при сбоях обмена - паузы могут быть .

  23. это запись кадрами как у АКИП-4113, разрывы между кадрами будут всегда

    А почему они "будут всегда"?

    Мне вот не очень понятно, какие-такие препятствия мешают записать непрерывный кусок 7М после наступления синхронизирующего события. Сегодняшний типовой недорогой скоп примерно имеет 1гигасемпл*8бит*2 канала, что генерирует всего лишь 2Гбайт/сек, даже для 32-битной памяти DDR3-800 это уже вполне подъемно. На такой скорости 8М запишутся банально за 4мс - это меньше времени одного кадра на экране. Можно вообще не напрягаться и выводить данные на экран только после окончания захвата. Если же сэмплрейт ниже приведенного в пример 2*1GBps, то та же дешевая DDR3 вполне может параллельно с захватом отдавать данные на отображение (гы, и там максимум экранная панель покажет 100 картинок в секунду). В-общем, чего-то я недопонимаю - почему обязательно должны быть разрывы при захвате данных?