p_v

Это из методологии разработки, которую лет 20 назад пришлось экстренно изучать. К сожалению, теперь даже имен авторов не смог в интернете найти. Мне с тех пор не попадались явные рекомендации "заниматься данными и не лезть в события". Что странно, т.к принцип невероятно полезный.

1. Покрывает. Если брать повышенный ток (который получается сам собой если ставить делитель) 2. Когда не покрывает, часто оверсамплингом добивают, но тут не особо требуется. Чудес не бывает. Огромный динамический диапазон упирается в шумы. Иначе бы все делали 100-битные АЦП. Измерение времени заряда не имеет физических преимуществ по шумам перед АЦП. Разве что за счет топологии, если в этом хорошо разбираться (лично я не настолько крут). Но на практике, если есть возможность оверсамплинга, то на АЦП виртуальная рязрядность нагоняется без особых проблем, и даже без источника белого шума. Следите за руками :). В диапазоне 0-300C напряжение делителя покрывает 1/4 питания. Пусть будет 1/8, чтобы наверняка. Итого у нас из 12 разрядов остается 9. То есть, чуть больше разряда на градус. Пожалуйста, не воспринимайте мои слова как то, что вы говорите ерунду. Вы предложили интересную вещь, просто конкертно в моих обстоятельствах (требования в первом посте) в том что вы предложили действительно нет особой нужды. Но я буду иметь в виду на будущее.

IMHO не ставить "лишние" детали - может быть рационально. Не юзать АЦП который и так уже есть - нет. С самим АЦП и обработкой сигналов у меня проблем нет. Вопросы касаются непосредственно датчика.

А можно как-то понять, на сколько градусов уплывут показания при 1.5ма? Желательно для 2 случаев - когда просто в воздухе и когда на плите (с активным отводом тепла). Если там 1-2 градуса, мне не критично совсем. Интересно. А чем питание импульсно коммутировали?

Там 12 бит. Сомневаюсь что не будет звенеть, если в лоб, но фильтром нагнать чистые 12 бит точно не проблема - частота измерения низкая, запас огромный. Я плохо выразился. Имелось в виду, что если датчик на плите, то она все отклонения на себя заберет, и выровняет. А если датчик прилеплен к плате, то "как повезет" - почти то же самое что если просто в воздухе болтаться будет. Да не, это ж говнище дешевое, там без изысков :) Ну по АЦП я на глаз прикинул еще до создания темы, срослось. А наводки и самонагрев считать не умею. Могу только с готового проекта сэкстраполировать, если кто инфой поделится.

Раз в секунду. Выключить на полупериод нагрузку в принципе не вопрос. Интересная мысль. Сейчас гоняю приехавшие столики на родных пидах, они "тугие". Нагрев ~1С/сек, остывание самоходом ~0.5С/сек там 1000 ом, я хочу не PT100 а PT1000, и просто делитель 1К + 1К с 3.3v на ацп в stm32, без всяких источников тока. А можно как-то порядок наводок на газ оценить? В принципе, цифрой прочистить не проблема, просто хочется понять, стоит ли заморачиваться, или "и так сойдет". Я думал просто параллельно датчику привернуть 10-100nF (не считал), а дальше слегка дочистить если надо А конкретно для моего случая нельзя на это просто забить болт :) ? Там же 30см провода, вроде на фоне 1К с датчика не должно быть заметно. Датчик тот что по ссылке в первом посте.

Спасибо. Извините за предыдущей ответ, если что. Показалось что экзамен хотите устроить :). Был неправ.

Биг сенькс. Очень дельная инфа для быстрых грубых оценок. А есть соображения насчет ущербного подключения, которое я описывал? Мне точности в градус хватит за глаза, но хотелось бы понять: не поплохеет ли PT1000 от увеличенного тока (1.5ма) видимо, на самонагрев датчика на люминевой плите можно забить, а как поплывет свободно болтающийся в воздухе? если подключение по 2 проводам не длиннее 30см (наверное 15-20), по ним какая-то бяка может прилететь или при моей точности не париться?

Мммм... дайте подумать... наверное то что перед тем как создать тему я это прикинул и результат меня устроил? У меня встречный вопрос. А что мешает прочитать первый пост и ответить на те вопросы которые в нем?

Жажда приключений и желание разобраться с чем-то новым. Хобби же. Под термопару уже готово https://easyeda.com/reflow/Mini-reflow-soldering-heater, с покупкой микросхем проблем нет. Столик маленький, шланг термопары короткий. Не хочется лишних приключений по компенсации холодного спая - никогда не знаешь, кому к какому столику и как подобную плату захочется пришурупить.

Ну наконец-то пошли советы по существу. Оказывается надо подумать! Вот спасибо-то! Вы не могли бы, чтобы меня окончательно растоптать, ответить на те вопросы, которые меня волнуют, а не на те которые вы самостоятельно придумали и героически преодолели?

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

Если это еще актуально, platformio отчасти решает некоторые наболевшие моменты по управлению проектом:контроль и версионирование зависимостей простота установки тулчейнов обертки для автодетекта портов программаторов (приятно для разработчиков, и вдвойне приятно для конечных юзеров) у них там есть еще какие-то платные навороты по автоматическому тестированию на реальных железках, но я туда не вникал - не надо ну то что оно сразу умеет во все популярные stm32/avr/esp8266 - не знаю стоит ли выделять, в принципе это много кто умеет. Если вас устраивает подчеркивать свое "разработческое мастерство", прописывая в репе зависимости субмодулями и ручками устанавливая компиляторы - вполне можно обойтись и без platformio. А если хочется чтобы любой сторонний разработчик с минимальными усилиями поднял среду на любой операционке и не отвлекался на суету - очень удобный вариант. Факстически, после того как откроете в paltformio проект, оно по конфигу само всосет все чего не хватало. Короче, нужность зависит от задач проекта и ваших личных предпочтений. Я перечислил то что бросилось в глаза, а дальше решайте сами. У себя использую, доволен. Правда, не с VScode а с Atom, исторически сложилось.

Хочу "дешево и сердито" подключить RTD в самопальную reflow-паялку на основе термостола. Актуальный диапазон измерений 100-300C. Точность 1С (лучше нет смысла). Провода не более 30см. Как "правильно" с мостом и полумостом я знаю. Как попроще, 2 провода с усилителем - видел. Хочу совсем "из говна и палок", делитель напрямую на вход АЦП. Интересно же. Датчик конструктивно хотелось бы такой, видимо PT1000, "класс 2B" (самый хреновый и самый дешевый). Но если просто поставить в плечо 1К, получится ток 1.5ма. А рекомендуемый ток 0.1-0.3ма. Вопросы такие: Можно ли так делать? Можно ли пренебречь саморазогревом или надо все-таки в делитель ставить 4К и дальше вытягивать точность измерений на цифровом фильтре после АЦП? Основной датчик будет прикручен к аллюминиевой пластине. Дополнительный (опциональный, не факт что нужен) - скотчем к плате, для экспериментов. Надо ли датчик "шунтировать" конденсатором, если желательно, то каким? На глаз вроде должно прокатить, но я ни разу не имел дела с такими вещами, не знаю, какие там проблемы бывают (например, актуально ли бодаться с наводками на такой точности и с таким проводом). Да, я отдаю себе отчет, что в "правильных" девайсах так не поступают, но тут хобийный проект, простота предпочтительнее, если это не сильно в ущерб качеству. Мне не жалко десяток центов на усилитель, интерес больше спортивный, чтобы упростить до максимума. Помогите пожалуйста прикинуть, можно ли поступить как описал, и что еще может быть полезно учесть. Термостол типа такого. Толстая пластина с 2 трубчатыми нагревателями ближе к краям. Сейчас там в центр ввернута К-термопара. Думаю заменить болтом с прижимной планкой.

Наверное потому что вы цитировали мои сообщения, или творчески интерпретировали их смысл, вкладывая то что я не говорил. А мне не очень нравится, когда пытаются приврать от моего имени или втянуть в спор на левые темы, до которых мне нет дела. Пример, когда вы обращались ко мне и пытались сочинить за ТС-а, я вам тоже приводил. Лично мне было бы гораздо проще без вашей "помощи". Я вполне в состоянии выражать мысли связно, и читать тоже обучен. Вы не знаете всего что я делаю. И написанное про методологию тоже не очень понимаете. Но беретесь судить. И решать за других. В очередной раз. Это не профессионально. Рассуждения об элементарной вежливости пропущу, о профессионализме наверное должно быть понятнее.

У ВАС на ВАШИХ задачах - свой опыт. У МЕНЯ на МОИХ задачах - свой. Я не вижу тут предмета спора. Мой опыт не делает бесполезным ваш, а ваш не делает бесполезным мой. Потому что и там и там это реальный многолетний опыт, а не высосанный из пальца. Моделировать диаграммы состояний мне вообще не требуется, они рисуются очень редко, и я пытался объяснить почему обычно (возможно вы - необычный) практичнее начинать с диаграмм данных (после майндмапов). Я отвечал для TC-а, потому что сам был в подобной ситуации, только на более крупных вещах, в софтовом варианте. Позвольте ТС-у самому решить, будет ему полезно написанное или нет. Или хотя бы покажите справку с треугольной печатью, что ТС доверил вам представлять его интересы. Ну и кроме ТС-а и нас с вами есть другие посетители, которые вполне способны сами высказаться, если им что-то не понравится или не понятно. Зачем решать за всех? Попробуйте добавлять в то что пишете слова "как мне кажется", и "на моих проектах", тогда написанное не будет выглядеть безапелляционным сектанством. Уверен, у вас есть опыт и вам есть что сказать. Но ваша манера выражать мысли очень сбивает с толку. Я даже ни разу не написал, что визио говно и пользуются им только упоротые лохи. Более того, я так не считаю. В чем проблема-то? Вас браузер покусал?

Теперь по инструментам. Лично у меня очень экстремальные требования по доступности. Такие далеко не у всех, но опыт может оказаться полезным на перспективу - кто знает как жизнь обернется, будете иметь в виду направления, куда можно копать. Проекты опенсорсные: Надо максимально быстро и просто донести информацию до другого человека. На любой платформе. У человека может просто под настроение возникнуть желание помочь. Если начать его грузить пургой про правильное проектирование - он просто плюнет и пойдет дальше, в какой нибудь другой проект. В итоге вы будете офигенно круты и правы, но в гордом одиночестве :). Идеальный вариант - когда человек может прямо в браузере посмотреть что нужно. Картинки и pdf неплохо прокатывают, но у них неудобство с ручной актуализацией после каждого изменения. Поэтому стараюсь выбирать именно вебовские тулзы, если это возможно. В перспективе плюсов больше (если вам не надо раздавать другим людям - плюсов меньше :)). Абстрактно, локальные тулзы обычно более навороченные. Но у них проблемы с шарингом результатов. Если общаемся с разработчиками один на один, то часто каждый делает в том что удобнее, а потом финальный результат переколачиваем во что-то типа draw.io - его в нашем случае проще раздавать и поддерживать. То есть, если у вас уже есть инструмент, который вы хорошо знаете - конечно начинать лучше с него, а дальше разберетесь. Лично я со временем навострился сразу в draw.io рисовать, но у меня весьма богатая практика, как обходиться без лишних телодвижений. Не уверен что прям с нуля draw.io будет идеальным вариантом. Но штука по-своему прикольная. В любом случае, владение методологией (многобукф из предыдущих постов) важнее, IMHO. Я не могу выделить какую-то конкретную рисовалку, которая чудесным образом решает все проблемы. Могу только обратить внимание на майндмапы и диаграммы данных, и что конкретно для них есть вебовские решения. Будут ли они оптимальны для вас - решайте сами. Диаграммы классов я не рисую - за десять лет активной разработки софта как-то не понадобилось. По той же причине агитировать за UML не вижу смысла. Другой пример комбинированного подхода (про веб, но не совсем про диаграммы) - доносить до людей поделки через EasyEDA очень удобно. Потому что какой-нибудь слессарь (конечный юзер) может в два клика заказать и платы и детали. Шарить по ссылке схемы для обсуждения тоже очень клево. Но разводка плат там "трохи специфичная", и симуляция простовата. Решали дешево и сердито - знакомый делал предварительную расстановку и 3D-модель в кикаде, а когда правки заканчивали, я уже делал окончательный вариант в EasyEDA. Честно сказать, пока в любом приличном трассировщике двигать дорожки удобнее, особенно с переходными отверстиями. Но в плане "донести опенсорсный продукт до конечного юзера" EasyEDA рулит и педалит. В масштабах "проекта" напряги могут потом отбиться многократно. Это на примере моих поделок, у кого-то другого может быть иначе, настаивать не буду. Конкретные тулзы, которые удобнее для моих случаев, уже называл - coggle.it и draw.io. Но то что удобно для меня - не обязательно удобно для всех или для вас лично. Рассматривайте просто как информацию для расширения кругозора. Я объясняю только некоторые принципы и подходы, а не раздаю "валшэбные рицепты".

Теперь пройдемся еще раз по диаграммам. А точнее, по диаграммам данных (data flow). Допустим, с майндмапами вам уже все понятно (или с проектом все понятно и без них) и хочется двинуть дальше. Далее, все что рассказываю, касается разработки софта, как оно в железе - не знаю. Таких сложных железок, чтобы требовали отдельных диаграмм у меня не было. Вообще, существует много диаграмм (данных, состояний, классов, use cases и т.п.). Мало кто делает полный набор, а генерация по диаграммам кода обычно работает только в идеальном шарообразном мире, или в воображении менеджеров по продажам, которые хотят вам втюхать очередную волшебную тулзу за дохрелион денег. Возможно на очень больших проектах, где толпа людей, причем сомнительной квалификации, есть смысл прорисовывать все до деталей (потому что выхода нет). Но в ситуациях попроще обычно удобнее отрисовать и верифицировать "самое мясо", и переключиться непосредственно к программированию: По мере роста деталей затраты времени на диаграммы возрастают, и эта зависимость не линейна. Когда в код вносятся изменения - синхронизировать диаграммы это куча лишней работы. Примерно как возня с исправлением тестов, если их нафигачить "из принципа", до того как внутренние API достигли определенной стабильности. Нет смысла упираться в абстрактные принципы. Важен баланс. Нам ведь не надо рисовать диаграммы ради вселенской справедливости или красивого вида. Мы обычно хотим с минимальными усилиями "правильно" разбить систему на части, чтобы не подставляться под дорогие переделки. Что будет балансом в конкретно вашем случае - можете решить только вы. Здесь универсальных советов, к сожалению, нет. Конечно, всегда найдутся исключения, но я рассказываю про основной подход, с чего хотя бы начать, когда от страха дрожат ручки и дергается глазик. Если задуматься, то суть большинства систем - обработка данных. Есть черный ящик, у которого на входе ручки, за которые дергает безумный юзер, а на выходе (допустим) индикатор. Если проектируем библиотеку, то входы и выходы обзывают словом API. Как-то так, если совсем кратко и с упрощениями. Обращаю особое внимание, не надо путать данные с событиями. Данные можно какбэ "потрогать руками". В событиях проще запутаться. Пример исключения, когда выбирать не приходится - конечный автомат. Там без событий никак. Но не стоит усложнять себе жизнь раньше времени. Диаграммы данных вам понадобится рисовать практически всегда. Остальное - по обстоятельствам. Профит: если вам удалось сделать корректную диаграмму данных, то налажать потом в коде практически невозможно :). Имейте в виду, что процесс дизайна итеративный. Не бойтесь ошибиться. Нарисовать правильную диаграмму с первого раза практически невозможно. Делается набросок, потом верифицируется, что данные нигде не профукали и не намагичили, вносятся коррекции и уходим на второй круг. Итак, начинаем с того, что фиксируем входы и выходы. Т.к. если мы не знаем, "что обрабатывать", то и внутренние блоки станут перемалывать какую-то туфту, и ничего хорошего не выйдет. На самом верхнем уровне входы и выходы называются "use cases" - как юзер захочет подергать ручки, как ему будет удобно дергать API и что он захочет получить взамен. Обычно use cases сначала выглядят несколько сумбурно, поэтому проще их выписать в столбик, чтобы найти что-то общее. Или откатиться на шаг назад и прогнать через mind map для особо тяжелых случаев. Итого, у нас должно получиться: Исходные точки Стрелочки (данных), которые выходят из этих точек или приземляются в них. Ну и остается дорисовать блоки, которые эти данные как-то переколбасят. На что стоит обратить внимание: На "стрелочках" обязательно должны быть именно данные. В идеале - подписать. В крайнем случае вы как минимум должны быть готовы ответить до мельчайших деталей, что гонится по стрелочке. Если по стрелочке гонится фик знает что - хрен вам, а не полезная диаграмма в результате. Надо постоянно верифицировать, что данных на входе (стрелочек) будет достаточно для работы блока, чтобы выплюнуть то что хочется. Если что-то пропустили - дорисовываем (или помечаем отдельно). Если не подумав нарисовали лишнее - убираем. Бывает, что данных очень много. Например конфиг с 20 параметрами. Такую часть иногда удобнее записать сразу в виде кода, чтобы не превращать чертеж в месиво. Но верификацию целостности все равно надо проделывать. Содержимое стрелок - основа для API (внешний или внутренних). Еще один повод отнестись к ним серьезно, а не использовать их в качестве декоративных соединителей. Примеры "стрелок":Фиговый вариант - "устройство ввода". Непонятно, какие данные и как оно выплевывает. Дельный вариант - "коды клавиш, байты, с клавиатуры". Примеры очень упрощенные, только чтобы продемонстрировать суть объяснений. По блокам внутри диаграммы. Тут универсального рецепта нет. Могу только посоветовать придерживаться некоторых ограничений: Избегайте большого количество блоков. Если диаграмма распухает - уводите "лишнее" в иерархии. Обычно советуют не превышать 7-9 блоков, но это субъективно. Если у вас сверхмозг - рисуйте хоть 20, раз можете объять разумом :). Главное - не забывайте верифицировать входы-выходы у каждого блока. И не забывайте, что если планируете показывать диаграммы другим - у них может быть не такой сверхмозг как у вас. Избегайте "пустых" преобразований форматов данных и бездумных шаблонов. Типичная ошибка программиста - нарисовать класс с красивым названием "потому что так правильно", и потом пытаться подогнать стрелочки под этот класс. С надеждой, что в итоге все сойдется как надо. Если вас в качестве гарантий устраивает молитва и вера в лучшее - на здоровье. Если нужны гарантии посерьезнее - стоит опираться на содержимое "стрелочек", и дорисовывать блоки под них а не наоборот. Результат может получится абсолютно не такой, как вы предполагали в начале. Причем проще и лучше :). Убеждался несколько раз. Возможно, в конце у вас получится совсем простая диаграмма из пары-тройки блоков, и вы подумаете "неужели из-за такой тривиальщины я страдал фигнёй". Но ведь смысл именно в том, чтобы понять, как сделать просто, а не наворотить чумную вундервафлю. На практике у меня получались рисунки с 3-5 блоками, и очень редко - с подуровнем для одного-двух блоков. Просто я не вижу смысла упираться в диаграмму как в самоцель. Рисую только до той степени, которая позволить двинуться дальше - продолжить в коде. Можно делать иначе, сложнее и т.п. Все зависит от мастерства, потребностей и т.п. Я описал один из вариантов, с чего можно начать. Очень часто этого оказывается достаточно.

Это ваше право. Но оно не делает автоматически ваши утверждения как-то весомее или умнее. Я бы не рискнул столь навязчиво советовать какой-то инструмент, не поинтересовавшись задачами проекта. И тем более не стал бы лезть с фанбойскими заскоками в уже готовые проекты, в чьих потребностях авторы ориентируются намного лучше вас :) . Ваш способ ведения дискуссии не является конструктивным. Возможно, у вас переизбыток времени, и вам нравится его тратить на подобные развлечения. Но пожалейте хотя бы мое время, пока у меня есть настроение чем-то делиться. ============================================== Кто знает про майндмапы и активно использует - можно смело пропускать. Кто не уверен - можно глянуть примеры и прикинуть насколько это имеет смысл лично для вас. <tl;dr> Касательно майндмапов. Бывает так, что непонятно с какой стороны подступиться. То есть, проблема не в том что именно рисовать, а в том что мы не до конца понимаем что вообще хотим от девайса (или программы) :) . То есть, перед тем как описывать устройство, надо хоть немного уложить мысли, летающие внутри головы и стукающиеся о стенки черепа. Если требования к девайсу (проекту) четко сформулированы - это прекрасно. Но наверняка многие сталкивались с обратным, и тогда рисовать графики несколько преждевременно (можно, но менее эффективно чем майндмапы). Далее пара примеров. WiFi-конфигурилка (конкретно мне - для приводов), когда не хочется возиться с менюшками в прошивке и т.п. Результат, если кому надо проследить к чему это привело. GUI на Rust для эмбедов. Пока просто пытаемся договориться, что делать и как попилить работу. Это конечно только частные примеры. Возможно у вас более простые задачи, которые проще прокрутить в уме и сэкономить время. Но возможно кому-то это поможет понять, пора ли фигачить диаграммы или все-таки сначала лучше разобраться на более высоком уровне. Чем выше уровень проектирования, на котором произошла ошибка, тем дороже обходится исправление по прошествии времени. Поэтому перескакивать не желательно. Насчет конкретных рисовалок - смотрите в чем удобнее. Если разработка идет в одно рыло, то вообще наплевать на многие вещи. Другой крайний случай, когда разработка это вероятностный процесс. То есть состав разработчиков может меняться, причем внезапно. Тогда крайне важно донести информацию до незнакомых людей с минимальными усилиями. То есть, если вы начинаете рассказывать "надо поставить программу" - это сразу фейл (по моим меркам). Поэтому я предпочитаю вебовские решения. Варианты с выкладыванием скриншотов (и постоянным обновлением после изменений) мне показались недостаточно удобными. Но это исключительно мое личное мнение, которое касается моих проектов. И конечно же это не "единственно верный путь", наверняка есть и другие, просто я делюсь тем, что лично мне и для моих случаев понравилось больше всего. Если это окажется кому-то полезным - ну и славно. Если кому-то не будет пользы - плакать тоже не стану :)

Давайте допустим такой вариант, что я могу как минимум неплохо разбираться в том, о чем пишу :). И что за моим выбором инструментов стоят более серьезные причины, чем необразованность и нищебродство :). Я пытаюсь объяснить довольно непростые вещи по методологии. Упрощать их до выбора редактора и тем более сталкивать в УГ лозунгами про визио не очень конструктивно. Если что-то вызывает трудности - ну переспросите, постараюсь детализировать. Это будет новая информация, от которой толку намного больше, чем от развлечений с "доказыванием правоты".

"Шарик, ты балбес" (с) Матроскин. Еще раз прошу не выдавать свое личное мнение за мнение автора, и пытаться представить свои оценки как едиственно верные, тем более за чужой счёт. Общение есть обмен информацией и эмоциями. На техническом форуме информация предпочтительнее. Чего либо полезного по сути вы в своих ответах на мои посты не добавили. Ну а остальное пусть останется на вашей совести.

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

Давайте начнем с нуля. Для начала, вы должны четко представлять, какой осязаемый профит вы хотите (можете) получить от рисования картинок. Иначе это будет рисование ради рисование. То есть: Что вы потом станете с этими картинками делать :) Где рисование картинок будет эффективнее других подходов Например: Рисование железок на блок-схемах - обычно фиговая идея, потому что в редактарах схем группировку можно сделать быстрее и нагляднее. Рисование алгоритмов - фиговая идея, потому что это жутко неудобно Короче, рисовать надо (полезно) DATA FLOW. То есть, протекание данных и их трансформацию. Данные - это стрелочки с подписями, блоки - куски девайса которые данные трансформируют. Что это нам дает: Можно быстро добиться, чтобы соединения между блоками были максимально простые Проверка целостности - выходы должны генериться на основе входов, а не магически Фиксирование API - для каждой "стрелочки" станет понятно, какие данные внутри. Документация, если требуется донести суть до кого-то другого Единственное правило, которому стоит сдедовать - никогда не смешивать данные и события на одной диаграмме. На самом деле, любую (практически) систему можно целиком представить как диаграмму данных или диаграмму событий. Проблема с событиями в том, что их можно по ошибке зациклить или напихать лишних. С данными подобного не случится или будет сразу видно. Например, у нас есть АЦП, с которого 100 раз в секунду снимаются данные. Рисовать "таймер" - очевидная идея. Но глупая :) . Потому что таймер генерирует события, а нам надо рисовать диаграмму данных. "Правильно" будет просто нарисовать стрелочку, на которой подписать что это данные от АЦП (подробности - по обстоятельствам) Еще один пример - https://github.com/nodeca/relimit/tree/master/docs#data-flow. Кучерявый распределенный rate limiter, где надо гарантировать отсутствие коллизий. Обратите внимание, на диаграмме нет алгоритмов. Там именно протекание данных. Но по такой диаграмме потом криво закодить невозможно :) . Тот случай, когда задача может взорвать мозг, но если проектировать грамотно, то получается очень просто. Обратите внимание - это кажущаяся простота, результат грамотного подхода, а не того что задача плевая. Инструменты: Для диаграмм использую draw.io, потому что все работы совместные и надо быстро шарить. Кстати, дополнительный стимул, рисовать кратко и только суть :) . IMHO редакторы UML для data flow скорее вредны чем полезны, т.к. забивают мозг псевдополезными вещами. Если задача слишком сложная и в голове совсем вакуум - тогда сначала в mind maps разложить что вообще хочется. Вот это https://coggle.it/ - очень приятная рисовалка, с возможностью делиться ссылками.