Согласен - к счастью в случае с аппендиксом существует естественное ограничение на спрос. Однако - даже в этом случае правило "издержки ниже - спрос выше" выполняется. Если вы сейчас соберетесь в долговременную экспедицию в отрыве от медицинской службы (например, в антарктику) - то вам могут поставить условие сделать превентивную аппендоэктомию. Хотя "прямщас" показаний нет. Или как в 70-е годы было поветрие в военных авиационых училищах: хочешь учиться дальше - иди рви гланды... А во время эпохи великих географических открытий, конечно же, никому и в голову не приходило потребовать у моряков вырезать аппендицит перед отплытием на три года в кругосветку. Потому что при том уровне наркоза и септики - это почти гарантированная смерть еще до начала путешествия...
То есть, вы лично можете и не предъявлять повышенный спрос на удаление аппендикса - но посколько теперь это быстро, дешево и безопасно, общественный спрос растет....
Вот в этом весь ужас. Вы не можете представить себе социальную норму, где народ вокруг вас постоянно умирает (а детей до трех лет вообще за людей не считают и не привязываются - ибо "бог дал, бог - взял"). А социальная норма была именно такой! В тех же средневековых (и чуть более современных) армиях - от болезней умирало больше людей на круг, чем от воздействия противника.
Статистика по браку, для смеха (сквозь слезы). Библейская клятва "пока смерть не разлучит нас" - это по европейской статистике до промышленной и медицинской революции - около 7 лет. Либо жена умрет в очередных родах, либо муж получит травму либо ранение, либо заболеет. И это мы еще не считаем войны и эпидемии...
Да нет же - читайте классический учебник экономики! Пока у вас цена выше себестоимости - это гарантирует только то, что предложение (в кратком горизонте) не будет падать. То есть, медицинский бизнес не будет разоряться на текущих расходах по предложению услуги. В долговременном - таких гарантий нет. Ибо амортизацию никто не отменял, и инвестиции на восполнение основных средств тоже. У вас может быть цена выше себестоимости, но прибыль такова что предпринимателю проще деньги на депозит положить, чем строить новый медицинский центр (или обновлять оборудование в существующем).
А вот спрос при снижении цены у вас увеличится. Причем, это гарантированное увеличение спроса: вы лечите людей, они живут дольше, в старости они больше болеют - и все опять идут лечиться. Разумеется, без постоянного роста инвестиций в доступность всё более сложных и дорогих методов лечения - у вас будет дефицит. Чудес не бывает!
Пока вы (или кто-то другой) не предложит более разумный способ регулирования - остается только рынок. В ценах заложена информация о редкости ресурсов. Если вы хотите чтобы кто-то принес ресурсы в медицину - вам придется показать что этими ресурсами в медицине вы распорядитесь лучше (прибыльнее) чем в других отраслях. Это не идеально, это дополнительно искажено усилиями государства (например, патентная монополия - икусственное ограничение предложения силами государства и за счет налогоплательщиков). Но другого-то ничего нет!
Ну и хорошо - допустим мы с вами согласились, и призвали государство. А оно как это должно сделать ?! Нельзя просто махнуть рукой, чтобы везде появилась доступная медицина. Можно ограничить цены - при этом возникнет дефицит... Можно увеличить предложение - но это не просто финансирование существующей медицины. Это инвестиции в медицину! С каких отраслей вы хотите снять деньги ? Ладно - в РФ понятно, воевать надо меньше. Но в развитых странах - это прямо вопрос-вопрос...
Для осознания масштабов северного белого лиса я рекомендую цикл лекций Александра Поволоцкого на ютубе (там большинство про военную медицину - но она же тесно переплетается с обычной). Кейс "натер ногу туфлей" - это сын президента США (кажется Рузвельта - но могу уже и ошибаться). Играл в теннис, небольшая рана, инфицирование стафилококком, не решились вовремя ампутировать (!) ногу, спасен экспериментальным лекарством - теми самыми сульфаниламидами. И это - цвет тогдашнего общества, имеющий доступ ко всем традиционным (и более современным) средствам антисептики... Чего же говорить о простом работяге из барака или крестьянина в поле ?...
Мы говорим "безусловно снизили смертность" - но мы уже третье или четвертое поколение, которое не видело ту смертность, которая была - и соответственно, не понимающее величия совершенного чуда.
Тогда надо понять - чем они должны регулироваться? Медицинские услуги как любые другие блага - сами из воздуха не рождаются. Надо откуда-то выделить ресурсы на их производство, а тем более - под их расширенное воспроизводство!
Государство не предлагать - государство само блага не создает, оно (довольно неэффективно) распределяет то, что сумело собрать при помощи налогов. При этом, налогов уже и так не хватает на все хотелки: пенсии, пособия по безработице, содержание бюрократии, школы и прочую социалку...
Проблема рынка медицинских услуг должна рассматриваться как часть глобального кризиса ценности человеческой жизни:
Простые и дешево устранимые причины смерти - медициной полностью устранены. Напомню, что рифма "Веретеном уколешься, мой свет - и умрешь во цвете лет!" - это не фигура речи, а бытовая норма до изобретения сульфаниламидов и особенно, антибиотиков. Раньше народ умирал массово от того что натер ногу или схватил воспаление легких...
Теперь медицина лечит сложные случаи, и пытается как можно дольше поддерживать в активном состоянии дряхлеющие организмы. Разумеется, это стоит прогрессивно дороже.
При этом, кожаные мешки все-равно не молодеют - и увеличение долголетия приводит только к увеличению количества людей на пенсии и удлинению срока в течение которого они там находятся.
В результате - общества сами себе не могут ответить на вопрос: кого лечить, и по каким критериям. И в этом смысле, становится понятно почему новые продвинутые технологии не дешевеют - производителю, в целом, безразлично - лечить одного больного за миллион долларов, или тысячу больных за тысячу долларов. Однако, пенсионная система чувствует себя лучше, если до 100 лет на пенсии доживет один пенсионер, а не тысяча.
Соответственно, в отсутствии общественного согласия - работает самый простой метод: лечат тех, кто платит.
Путей выхода пока не видно, потому что нет даже содержательной дискуссии по этому вопросу. Пенсионные и социальные системы идут вразнос, но политики (и их избиратели) упорно пытаются делать вид что "оно само рассосется". И да, оно рассосется - путем разрушения существующей системы здравоохранения и ценой возврата дурной смертности в трудоспособном возрасте от "туфли натерли ногу, стафиллококовая инфекция, ой - всё!".
Это понятно. Более того - TWI в архитектуре AVR для упрощения жизни уже реализован как аппаратный конечный автомат - достаточно только дергать его флагами в регистрах. То есть, нижний уровень уже реализовали. НО! Эти регистры (и ноги с аппаратным I2C - они одни на весь микроконтроллер). Я хочу посмотреть - как конкретно этот автор предлагает синхронизировать между собой два КА (дисплей и термометр), которые во время своей работы хотят менять состояние разделяемого ресурса - шины I2C (и связанных с ней регистров МК). Я не говорю что это нельзя сделать - есть разные способы. Пусть автор покажет как это решается с его точки зрения правильным способом и на его библиотеке. Моя изначальная претензия была в том, что преимущества автоматного программирования показываются ровно на том простом примере, где они очевидны - а недостатки отсутствуют. А в реальности (в современной реальности!) вы не сможете выделить по одной ноге контроллера на каждый датчик и исполнительное устройство, придется мультиплексировать. И мой опыт показывает, что "простое и понятное" устройство программы как графа с дугами - чего-то перестает быть и простым и понятным. И выясняется что потоки и межпоточную синхронизацию люди не от нечего делать придумали...
Мсье решил выкинуть в мусор принцип инкапсюляции, и дает возможность каждому автомату бесконтрольно читать состояния других автоматов ? Мсье - тонкий извращенец... Как бы уже лет 40 известно что нужно различать интерфейс (внешний контракт) и внутреннее состояние программного модуля...
Я полагаю, что публике хабра мало интересно сколько вагонов документации и схем вы нарисовали. Вообще как-то не по-детски вас шатает: от ПЛК и установок водоподготовки до ардуино... Но мы тут люди "от сохи" - поэтому покажите пожалуйста код - как на вашем автоматном подходе можно одновременно общаться с дисплеем и датчиком температуры по I2C шине ?
И еще раз - я не говорю о невозможности реализаци чего бы то ни было на конечных автоматах. Более того, что и как бы вы не написали в абстракциях высокого уровня - в конце концов на кремнии в системе ДКА и будет исполняться.
Я говорю о другом - логика развития инженерии идет от (!) ДКА на кремнии к примитивам более высокого уровня (потокам, корутинам, и т.д.). Потому что описание процесса через потоки и примитивы синхронизации является более удобным (и компактным!) для понимания и дальнейшей модификации. В некоторых (!) случаях автоматное представление имеет право на жизнь: либо для задачи ДКА является естественным представлением, либо просто нет ресурсов для более сложной формы.
А адепты, которые нашли что ДКА можно потенциально применить к любой задаче - и поэтому автоматное программирование сейчас вытеснит все другие форматы - на хабре появляются каждые 6-9 месяцев. Глушко еще вспомните с циклограммами Энергии и язык "Дракон" - а то давно еще по этому поводу не срались...
Хотя, конечно, я могу ошибаться - и вдруг вы действительно совершили прорыв в этой области... Но только сначала код покажите для сколько-то реальной задачи, а не автомат из двух состояний и трех ножек ардуины... Желательно не из области водоподготовки, а из того с чем мы хоббийно каждый день имеем дело. Общение с переферией по I2C шине - вполне подойдет...
То есть решения сколько-то похожей на реальную задачи на своих КА вы предъявить не только не можете, но даже и не собираетесь. Дальнейшая дискуссия смысла не имеет. Это будет спор о том, сколько ангелов помещается на кончике иглы. Идите со своими идеями к теологам, а Хабр - пока все-же технический ресурс...
Во-первых, вам не надо оценивать мой уровень. Это вы сюда пришли проповедовать автоматное программирование, и это мы будем оценивать полезность того, что вы предлагаете.
Во-вторых, моя гражданская специальность была 220100 - выч маш, системы и сети. Поэтому автоматы Мура/Мили, их перевод в переключательные функции, минимизация и синтез в базисе - это примерно наш хлеб с зимы первого по зиму третьего курса. Дальше начиналось микропрограммное управление и ассемблер...
В третьих, в последний раз говорю - покажите на примере своей распрекрасной библиотеки и распрекрасного автоматного программирования решение реальной задачи - общение с несколькими устройствами по I2C шине ? На ардуино у вас есть все необходимые исходники и протоколы - хотя, разумеется, не в виде конечных автоматов. Практика - критерий истины, короче...
А если вы только агитировать можете за коммунизм и автоматное программирование - ну тогда ой! С зелотами ругаться - только время терять...
Не надо говорить "Arduino", надо говорить о конкретном семействе микроконтроллеров. Если мы имеем в виду классическое ардуино - то это AVR. Никаких ограничений по кодогенерации там нет. По стандартной библиотеке - да, есть (с учетом того что оригинальная libc была для POSIX-систем, чего же вы хотите от MCU?!). По архитектуре памяти (например, вам надо заранее решить - хотите ли вы чтобы константа лежала в .data и занимала RAM или в .flash - но тогда использовать специальные функции чтобы ее доставать) - тоже есть. Но никаких ограничений именно по стандарту языка - я не помню. Пока вы влазите в память и стек - творите что хотите!
Есть еще один важный принцип: эффективность всегда достигается за счет устойчивости. Или, в более наглядных аналогиях - паровой котел наиболее эффективен в последние миллисекунды перед взрывом!
Проблема в том, что у вас теряется независимость автоматов. В идеальном мире - у вас КА дисплея и КА термометра понятия не имеют о существовании друг-друга. В реальном мире - они пересекаются на физически неразделяемом устройстве - шине и управляющих ей регистрах микроконтроллера. Если вы в середине транзакции с дисплеем вставите обмен с термометром (не проведя корректного освобождения шины и новой инциализации посылки) - то у вас команды термометра поедут в дисплей, чем собьют ему протокол и вызовут артефакты. Если вы будете монопольно захватывать шину до окончания обмена с устройством - то в обмене с дисплеем есть минимальные промеждутки между командами - и вы будете занимать шину когда она вам не нужна.
Я не говорю, что это нерешаемая проблема - я хочу посмотреть, как конкретно этот адепт автоматного программирования хочет их решать. И насколько это решение хуже/лучше отдельных процессов/потоков на каждое из устройств с примитивами синхронизации...
Не надо мне возвращать обезьянку. Это вы утверждаете что автоматная форма лучше/удобнее чем синхронизационные примитивы. Я, как человек, поевший и то и другое - утверждаю что это сильно не так (по крайней мере, сильно не везде и не всегда). В качестве модельной задачи я вам предлагаю вещь совершенно обыденную и широко распространенную: I2C шину и символьный дисплей (и любое простое устройство на ней же). Не хотите эту задачу - покажите решение любой другой, но аналогичной сложности. Чтение ног микроконтроллера меня лично не впечатляет.
Дополнительно скажу, что вы не первый кто прибегает с идеей автоматного программирования. И почему-то все прибегают и показывают как она замечательно работает на простых примерах. К сожалению, на простых примерах вообще всё работает. Вы покажите на достаточно сложной реальной задаче!
Не будете защищать свою точку зрения - добро пожаловать, как я написал выше - не вы первый, не вы последний. А я ради вашего удобства дополнительный код писать не собираюсь... Вот когда я к вам прийду с дурной идеей и буду агитировать - тогда и просите...
Ну вообще-то кодогенерация для Ардуино - это обычный gcc/g++. Все что там есть - всё доступно... Другое дело что под какую-нибудь ATTINY13 писать на C++ с темплейтами и исключениями - довольно странно, да можно и в память не войти!
Нет, у меня это есть на автоматах - поэтому я и спрашиваю. Оно сделано на автоматах не потому что это лучшее решение, а потому что по-другому в условиях ограниченных ресурсов не влезет. Был бы у меня под эту задачу Linux - я бы запустил задачи в разных процессах, и синхронизировал через семафор.
Покажите на библиотеке достаточно сложный пример взаимодействия ? I2C - это очень распространенный стандарт с миллионом разных датчиков которые на нее вешаются. Интересно именно как вы собираетесь в ДКА синхронизировать работу с общим ресурсом, и как вы будете обслуживать транзакции на шине когда устройству надо послать несколько команд, проверить ответы, и т.д.
Потому что рассказывать о преимуществах автоматного подхода в задаче чтения состояния ножки - это каждый может. Покажите насколько выразительно реализуются сложные протоколы взаимодействия в такой парадигме. HD44780 и PCF8574 можете посмотреть в библиотеках того же ардуино. Это как грязь распространенные микросхемы (точнее, их текущие китайские no-name аналоги), и найти на них документацию и примеры - не должно быть проблемой...
Согласен - к счастью в случае с аппендиксом существует естественное ограничение на спрос. Однако - даже в этом случае правило "издержки ниже - спрос выше" выполняется. Если вы сейчас соберетесь в долговременную экспедицию в отрыве от медицинской службы (например, в антарктику) - то вам могут поставить условие сделать превентивную аппендоэктомию. Хотя "прямщас" показаний нет. Или как в 70-е годы было поветрие в военных авиационых училищах: хочешь учиться дальше - иди рви гланды... А во время эпохи великих географических открытий, конечно же, никому и в голову не приходило потребовать у моряков вырезать аппендицит перед отплытием на три года в кругосветку. Потому что при том уровне наркоза и септики - это почти гарантированная смерть еще до начала путешествия...
То есть, вы лично можете и не предъявлять повышенный спрос на удаление аппендикса - но посколько теперь это быстро, дешево и безопасно, общественный спрос растет....
Вот в этом весь ужас. Вы не можете представить себе социальную норму, где народ вокруг вас постоянно умирает (а детей до трех лет вообще за людей не считают и не привязываются - ибо "бог дал, бог - взял"). А социальная норма была именно такой! В тех же средневековых (и чуть более современных) армиях - от болезней умирало больше людей на круг, чем от воздействия противника.
Статистика по браку, для смеха (сквозь слезы). Библейская клятва "пока смерть не разлучит нас" - это по европейской статистике до промышленной и медицинской революции - около 7 лет. Либо жена умрет в очередных родах, либо муж получит травму либо ранение, либо заболеет. И это мы еще не считаем войны и эпидемии...
Да нет же - читайте классический учебник экономики! Пока у вас цена выше себестоимости - это гарантирует только то, что предложение (в кратком горизонте) не будет падать. То есть, медицинский бизнес не будет разоряться на текущих расходах по предложению услуги. В долговременном - таких гарантий нет. Ибо амортизацию никто не отменял, и инвестиции на восполнение основных средств тоже. У вас может быть цена выше себестоимости, но прибыль такова что предпринимателю проще деньги на депозит положить, чем строить новый медицинский центр (или обновлять оборудование в существующем).
А вот спрос при снижении цены у вас увеличится. Причем, это гарантированное увеличение спроса: вы лечите людей, они живут дольше, в старости они больше болеют - и все опять идут лечиться. Разумеется, без постоянного роста инвестиций в доступность всё более сложных и дорогих методов лечения - у вас будет дефицит. Чудес не бывает!
Пока вы (или кто-то другой) не предложит более разумный способ регулирования - остается только рынок. В ценах заложена информация о редкости ресурсов. Если вы хотите чтобы кто-то принес ресурсы в медицину - вам придется показать что этими ресурсами в медицине вы распорядитесь лучше (прибыльнее) чем в других отраслях. Это не идеально, это дополнительно искажено усилиями государства (например, патентная монополия - икусственное ограничение предложения силами государства и за счет налогоплательщиков). Но другого-то ничего нет!
Ну и хорошо - допустим мы с вами согласились, и призвали государство. А оно как это должно сделать ?! Нельзя просто махнуть рукой, чтобы везде появилась доступная медицина. Можно ограничить цены - при этом возникнет дефицит... Можно увеличить предложение - но это не просто финансирование существующей медицины. Это инвестиции в медицину! С каких отраслей вы хотите снять деньги ? Ладно - в РФ понятно, воевать надо меньше. Но в развитых странах - это прямо вопрос-вопрос...
Для осознания масштабов северного белого лиса я рекомендую цикл лекций Александра Поволоцкого на ютубе (там большинство про военную медицину - но она же тесно переплетается с обычной). Кейс "натер ногу туфлей" - это сын президента США (кажется Рузвельта - но могу уже и ошибаться). Играл в теннис, небольшая рана, инфицирование стафилококком, не решились вовремя ампутировать (!) ногу, спасен экспериментальным лекарством - теми самыми сульфаниламидами. И это - цвет тогдашнего общества, имеющий доступ ко всем традиционным (и более современным) средствам антисептики... Чего же говорить о простом работяге из барака или крестьянина в поле ?...
Мы говорим "безусловно снизили смертность" - но мы уже третье или четвертое поколение, которое не видело ту смертность, которая была - и соответственно, не понимающее величия совершенного чуда.
Тогда надо понять - чем они должны регулироваться? Медицинские услуги как любые другие блага - сами из воздуха не рождаются. Надо откуда-то выделить ресурсы на их производство, а тем более - под их расширенное воспроизводство!
Государство не предлагать - государство само блага не создает, оно (довольно неэффективно) распределяет то, что сумело собрать при помощи налогов. При этом, налогов уже и так не хватает на все хотелки: пенсии, пособия по безработице, содержание бюрократии, школы и прочую социалку...
Проблема рынка медицинских услуг должна рассматриваться как часть глобального кризиса ценности человеческой жизни:
Простые и дешево устранимые причины смерти - медициной полностью устранены. Напомню, что рифма "Веретеном уколешься, мой свет - и умрешь во цвете лет!" - это не фигура речи, а бытовая норма до изобретения сульфаниламидов и особенно, антибиотиков. Раньше народ умирал массово от того что натер ногу или схватил воспаление легких...
Теперь медицина лечит сложные случаи, и пытается как можно дольше поддерживать в активном состоянии дряхлеющие организмы. Разумеется, это стоит прогрессивно дороже.
При этом, кожаные мешки все-равно не молодеют - и увеличение долголетия приводит только к увеличению количества людей на пенсии и удлинению срока в течение которого они там находятся.
В результате - общества сами себе не могут ответить на вопрос: кого лечить, и по каким критериям. И в этом смысле, становится понятно почему новые продвинутые технологии не дешевеют - производителю, в целом, безразлично - лечить одного больного за миллион долларов, или тысячу больных за тысячу долларов. Однако, пенсионная система чувствует себя лучше, если до 100 лет на пенсии доживет один пенсионер, а не тысяча.
Соответственно, в отсутствии общественного согласия - работает самый простой метод: лечат тех, кто платит.
Путей выхода пока не видно, потому что нет даже содержательной дискуссии по этому вопросу. Пенсионные и социальные системы идут вразнос, но политики (и их избиратели) упорно пытаются делать вид что "оно само рассосется". И да, оно рассосется - путем разрушения существующей системы здравоохранения и ценой возврата дурной смертности в трудоспособном возрасте от "туфли натерли ногу, стафиллококовая инфекция, ой - всё!".
Это понятно. Более того - TWI в архитектуре AVR для упрощения жизни уже реализован как аппаратный конечный автомат - достаточно только дергать его флагами в регистрах. То есть, нижний уровень уже реализовали. НО! Эти регистры (и ноги с аппаратным I2C - они одни на весь микроконтроллер). Я хочу посмотреть - как конкретно этот автор предлагает синхронизировать между собой два КА (дисплей и термометр), которые во время своей работы хотят менять состояние разделяемого ресурса - шины I2C (и связанных с ней регистров МК). Я не говорю что это нельзя сделать - есть разные способы. Пусть автор покажет как это решается с его точки зрения правильным способом и на его библиотеке. Моя изначальная претензия была в том, что преимущества автоматного программирования показываются ровно на том простом примере, где они очевидны - а недостатки отсутствуют. А в реальности (в современной реальности!) вы не сможете выделить по одной ноге контроллера на каждый датчик и исполнительное устройство, придется мультиплексировать. И мой опыт показывает, что "простое и понятное" устройство программы как графа с дугами - чего-то перестает быть и простым и понятным. И выясняется что потоки и межпоточную синхронизацию люди не от нечего делать придумали...
Мсье решил выкинуть в мусор принцип инкапсюляции, и дает возможность каждому автомату бесконтрольно читать состояния других автоматов ? Мсье - тонкий извращенец... Как бы уже лет 40 известно что нужно различать интерфейс (внешний контракт) и внутреннее состояние программного модуля...
Я полагаю, что публике хабра мало интересно сколько вагонов документации и схем вы нарисовали. Вообще как-то не по-детски вас шатает: от ПЛК и установок водоподготовки до ардуино... Но мы тут люди "от сохи" - поэтому покажите пожалуйста код - как на вашем автоматном подходе можно одновременно общаться с дисплеем и датчиком температуры по I2C шине ?
И еще раз - я не говорю о невозможности реализаци чего бы то ни было на конечных автоматах. Более того, что и как бы вы не написали в абстракциях высокого уровня - в конце концов на кремнии в системе ДКА и будет исполняться.
Я говорю о другом - логика развития инженерии идет от (!) ДКА на кремнии к примитивам более высокого уровня (потокам, корутинам, и т.д.). Потому что описание процесса через потоки и примитивы синхронизации является более удобным (и компактным!) для понимания и дальнейшей модификации. В некоторых (!) случаях автоматное представление имеет право на жизнь: либо для задачи ДКА является естественным представлением, либо просто нет ресурсов для более сложной формы.
А адепты, которые нашли что ДКА можно потенциально применить к любой задаче - и поэтому автоматное программирование сейчас вытеснит все другие форматы - на хабре появляются каждые 6-9 месяцев. Глушко еще вспомните с циклограммами Энергии и язык "Дракон" - а то давно еще по этому поводу не срались...
Хотя, конечно, я могу ошибаться - и вдруг вы действительно совершили прорыв в этой области... Но только сначала код покажите для сколько-то реальной задачи, а не автомат из двух состояний и трех ножек ардуины... Желательно не из области водоподготовки, а из того с чем мы хоббийно каждый день имеем дело. Общение с переферией по I2C шине - вполне подойдет...
То есть решения сколько-то похожей на реальную задачи на своих КА вы предъявить не только не можете, но даже и не собираетесь. Дальнейшая дискуссия смысла не имеет. Это будет спор о том, сколько ангелов помещается на кончике иглы. Идите со своими идеями к теологам, а Хабр - пока все-же технический ресурс...
Вы код покажите, пожалуйста. А то будет как в анекдоте: "... а мой сосед говорит, что три раза за ночь может! // Ну так и вы говорите!..".
Во-первых, вам не надо оценивать мой уровень. Это вы сюда пришли проповедовать автоматное программирование, и это мы будем оценивать полезность того, что вы предлагаете.
Во-вторых, моя гражданская специальность была 220100 - выч маш, системы и сети. Поэтому автоматы Мура/Мили, их перевод в переключательные функции, минимизация и синтез в базисе - это примерно наш хлеб с зимы первого по зиму третьего курса. Дальше начиналось микропрограммное управление и ассемблер...
В третьих, в последний раз говорю - покажите на примере своей распрекрасной библиотеки и распрекрасного автоматного программирования решение реальной задачи - общение с несколькими устройствами по I2C шине ? На ардуино у вас есть все необходимые исходники и протоколы - хотя, разумеется, не в виде конечных автоматов. Практика - критерий истины, короче...
А если вы только агитировать можете за коммунизм и автоматное программирование - ну тогда ой! С зелотами ругаться - только время терять...
Не надо говорить "Arduino", надо говорить о конкретном семействе микроконтроллеров. Если мы имеем в виду классическое ардуино - то это AVR. Никаких ограничений по кодогенерации там нет. По стандартной библиотеке - да, есть (с учетом того что оригинальная libc была для POSIX-систем, чего же вы хотите от MCU?!). По архитектуре памяти (например, вам надо заранее решить - хотите ли вы чтобы константа лежала в .data и занимала RAM или в .flash - но тогда использовать специальные функции чтобы ее доставать) - тоже есть. Но никаких ограничений именно по стандарту языка - я не помню. Пока вы влазите в память и стек - творите что хотите!
Не надо задавать мне вопросы. Покажите код. Ссылку на гитхаб, например. Я посмотрю и скажу что думаю по этому поводу.
Есть еще один важный принцип: эффективность всегда достигается за счет устойчивости. Или, в более наглядных аналогиях - паровой котел наиболее эффективен в последние миллисекунды перед взрывом!
Проблема в том, что у вас теряется независимость автоматов. В идеальном мире - у вас КА дисплея и КА термометра понятия не имеют о существовании друг-друга. В реальном мире - они пересекаются на физически неразделяемом устройстве - шине и управляющих ей регистрах микроконтроллера. Если вы в середине транзакции с дисплеем вставите обмен с термометром (не проведя корректного освобождения шины и новой инциализации посылки) - то у вас команды термометра поедут в дисплей, чем собьют ему протокол и вызовут артефакты. Если вы будете монопольно захватывать шину до окончания обмена с устройством - то в обмене с дисплеем есть минимальные промеждутки между командами - и вы будете занимать шину когда она вам не нужна.
Я не говорю, что это нерешаемая проблема - я хочу посмотреть, как конкретно этот адепт автоматного программирования хочет их решать. И насколько это решение хуже/лучше отдельных процессов/потоков на каждое из устройств с примитивами синхронизации...
Не надо мне возвращать обезьянку. Это вы утверждаете что автоматная форма лучше/удобнее чем синхронизационные примитивы. Я, как человек, поевший и то и другое - утверждаю что это сильно не так (по крайней мере, сильно не везде и не всегда). В качестве модельной задачи я вам предлагаю вещь совершенно обыденную и широко распространенную: I2C шину и символьный дисплей (и любое простое устройство на ней же). Не хотите эту задачу - покажите решение любой другой, но аналогичной сложности. Чтение ног микроконтроллера меня лично не впечатляет.
Дополнительно скажу, что вы не первый кто прибегает с идеей автоматного программирования. И почему-то все прибегают и показывают как она замечательно работает на простых примерах. К сожалению, на простых примерах вообще всё работает. Вы покажите на достаточно сложной реальной задаче!
Не будете защищать свою точку зрения - добро пожаловать, как я написал выше - не вы первый, не вы последний. А я ради вашего удобства дополнительный код писать не собираюсь... Вот когда я к вам прийду с дурной идеей и буду агитировать - тогда и просите...
Ну вообще-то кодогенерация для Ардуино - это обычный gcc/g++. Все что там есть - всё доступно... Другое дело что под какую-нибудь ATTINY13 писать на C++ с темплейтами и исключениями - довольно странно, да можно и в память не войти!
Нет, у меня это есть на автоматах - поэтому я и спрашиваю. Оно сделано на автоматах не потому что это лучшее решение, а потому что по-другому в условиях ограниченных ресурсов не влезет. Был бы у меня под эту задачу Linux - я бы запустил задачи в разных процессах, и синхронизировал через семафор.
Покажите на библиотеке достаточно сложный пример взаимодействия ? I2C - это очень распространенный стандарт с миллионом разных датчиков которые на нее вешаются. Интересно именно как вы собираетесь в ДКА синхронизировать работу с общим ресурсом, и как вы будете обслуживать транзакции на шине когда устройству надо послать несколько команд, проверить ответы, и т.д.
Потому что рассказывать о преимуществах автоматного подхода в задаче чтения состояния ножки - это каждый может. Покажите насколько выразительно реализуются сложные протоколы взаимодействия в такой парадигме. HD44780 и PCF8574 можете посмотреть в библиотеках того же ардуино. Это как грязь распространенные микросхемы (точнее, их текущие китайские no-name аналоги), и найти на них документацию и примеры - не должно быть проблемой...