Продвинутое самодельное универсальное ЗУ на МК

[Кass]

тем более что всё что я пишу вы, ДАЖЕ НЕ ВДУМЫВАЯСЬ, тут-же записываете в фейки. Так зачем мне бисер метать?

Александр, ну это уже откровенный плагиат.

I2C стандартный протокол обмена информацией.

Это не протокол, а интерфейс.

Это и относится к 1% потребности. Но еще раз замечу, что т. как шины в I2C двунаправленные они создают определенные проблемы в гальв. развязке.  Она возможна, но проще и удобнее применить например UART, а самый удобный (и дешевый) это радиоканал. Хотя сегодня даже на USB есть гальв. развязка.

Тут соглашусь. В пром автоматике есть такой интерфейс, как RS485. Для его реализации есть много микросхем с гальванической развязкой. К примеру в ПЛК, что на стенде именно так реализован обмен между контроллерами в сети.

[KIE]

В пром автоматике есть такой интерфейс, как RS485. Для его реализации есть много микросхем с гальванической развязкой.

Многих пугает слово "промышленный". Хотя, на самом деле и в железе и в софте он простой как тыква.  Стоимость самого железа копеечная, дороже м\схемы с уже встроенными преобразователями питания для гальв. развязки. Но простота изделия оправдывает эту цену.
Эта моя конструкция с гальванической развязкой RS458<->COM232<->китайский шнурок USB. На самом-самом распространенном ширпотребе.

Только не стоит забывать, что COM232 отлично работает на шнурках длинной до 20м\п (в реальности и больше), чаще этого хватает с головой.

[Кass]

Многих пугает слово "промышленный". Хотя, на самом деле и в железе и в софте он простой как тыква.

Именно, что довольно простой интерфейс, и очень надежный. Главное достоинство, что может работать на больших дистанциях, до 1.5 км, и скорость по нему может быть разной. А самое главное, что он поддерживается практически всеми заводскими изделиями, и довольно просто по нему по протоколу MODBUS RTU прочитать данные от котла, чилера, кондиционера и многих других домашних приборов.

У меня в ПЛК используется ADM2483, в старых контроллерах ADM485 или IL485. Я думаю, что и к Ардуине довольно просто их можно прикрутить, и автоматом получить гальваническую развязку.

[KIE]

Я думаю, что и к Ардуине довольно просто их можно прикрутить, и автоматом получить гальваническую развязку.

Конечно.
Ранее зубную боль доставлял преобразователь питания, с его трансформатором. Хотя это чисто психологическая отмазка. Такие простенькие трансы за 20мин мотаются, но.... дольше собираешься, чем делаешь.
Не хочется с трансом связываться, то цена и габариты готовых, монолитных преобразователей сейчас маленькая. Обвязки мизер.
Если поставить м\схему со встроенным трансом конструкция получается из трех деталей.
Дольше коробочку делать, чем плату.
Вот тут https://radiokot.ru/konkursCatDay2017/36/ моя статья "Гальваническая развязка компьютера и периферийных устройств" Описание популярных м\с и готовое решение на ширпотребе. Большой перечень ссылок на статьи и даташиты.

[Alex_Soroka]

I2C стандартный протокол обмена информацией. Он присутствует практически во всех м\к.

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

Очень, кстати, интересный и удобный для связи по ДВУМ проводам массы периферийных узлов.

агащаз.
Особенно эти "удобства" начнут вылетать при реалтайм управлении.  "лебедь рак и щука" в полной красе с непредсказуемыми задержками.

[SanSanich]

и точно знаете "что там внутри"?   да ?

А на асме слабо? Да, точно знаю что внутри! Да и общение у нормального программиста в такой же среде таких же черепов. Так что и библиотеки и куски неоднократно проверенного кода всегда имеются. Но вот с кем точно нельзя я знаю наверняка.

[KIE]

готовы поручиться что при коллизиях в шине МК не уйдет в себя на вечность?

Не уйдет.
Вы видимо не достаточно хорошо знаете протокол работы этого интерфейса. В нем учтены практически все возможные ошибки обмена информации. И в документации приводится реакция на эти ошибки. Остальное уже зависит от желания программиста, как программа будет реагировать на флаги ошибок.
Пишите сами п\программы, ничего на самом деле сложного в I2C нет, все уже вложено в м\с и м\к в процессе разработки этого интерфейса.
В этом все и удобство.
Кроме бла-бла-бла, у Вас есть конкрентный, незадокументированного случай отказа этого интерфейса?
Очень в этом сомневаюсь. Не дилетанты его разрабатывали.

А на асме слабо? Да, точно знаю что внутри!

Согласен 100%.
Берешь болванку и правишь  под себя. Но с разумением, что делаешь, а не как попугай. Всегда полезно начать не с рождества Христова, а глянуть как уже сделано до тебя.

[Кass]

Особенно эти "удобства" начнут вылетать при реалтайм управлении. 

Вы видимо не достаточно хорошо знаете протокол работы этого интерфейса. В нем учтены практически все возможные ошибки обмена информации. И в документации приводится реакция на эти ошибки. Остальное уже зависит от желания программиста, как программа будет реагировать на флаги ошибок.

Александр изучал металловедение. Так что ничего страшного. У него есть свое мнение, что он при этом лучший программист в мире. Никто вообще не способен написать никакой протокол. Но тут то еще смешнее. Дело в том, что I2C не протокол, и даже не интерфейс. Это просто шина для внутреннего обмена для медленных внешних устройств. Разработана ну очень давно Филипсом, в 80-х годах. Проста как угол дома. Что там можно накосячить в библиотеках для Ардуины, я не знаю.

Почему я упомянул именно 485-й протокол? Лишь потому, что вы упомянули шину I2C для соединения различных устройств в некой системе умного дома, а I2C разрабатывалась для связи внутри устройства, а не устройств. Именно поэтому это шина, а не интерфейс. Поэтому и предложил лучше использовать таки интерфейс для таких вещей, так как и особо сложного в нем ничего нет, а при современной элементной базе реализация обойдется в копейки. А вот уже на интерфейс можно положить любой из имеющихся протоколов, или написать свой. Это уже кому как больше по душе. Вот тут уже можно выбирать библиотеки по реализации этих протоколов, и обсуждать конкретные реализации. К примере для Ардуины полно различных версий протоколов MODBUS RTU. Выбирай на любой вкус. Код открыт, можно смотреть как там и что реализуется.

[Alex_Soroka]

Не уйдет.

бумагу с печатью и финансовыми штрафными санкциями, в вашу сторону, подпишите ? да-нет ?

Вы видимо не достаточно хорошо знаете протокол работы этого интерфейса.

Видимо кому? Вам? так вот я хорошо знаю этот протокол.
и сам писал протоколы связи, когда вы еще в школе учились.

В нем учтены практически все возможные ошибки обмена информации.

"практически все" ага 
повторяю: БУМАГУ выдают? о том что "если будет ошибка протокола ИЗ НАШЕЙ БИБЛИОТЕКИ и потеря денег то вернем и выплатим"?

И в документации приводится реакция на эти ошибки. Остальное уже зависит от желания программиста, как программа будет реагировать на флаги ошибок.

с этого надо было начинать.
Ошибка это "стоп + перепосылка пакета(данных)", и снова Протокол, тайминги, ожидание.
РЕАЛТАЙМ ГДЕ ТУТ ? Попросим ракету повисеть в воздухе, пока мы тут с коллизиями и ошибками и переприемом пакетов разберемся? да?
Какого вы спорите со мной , если сами понимаете что я тут прав на 100%?

Берешь болванку и правишь  под себя.

что именно "под себя" ? чужие библиотеки кода выданные в уже скомпилированном виде?
а "еррата" куда засовывать тем разработчикам железа ваших "очень хороших микросхем"?

[KIE]

сам писал протоколы связи, когда вы еще в школе учились

К моему большому сожалению, я в школе учился когда Вы еще под себя ходили. Зачем писюнами мериться?
Чего Вы так распалились? Не нравится I2C, это личное дело, не применяйте.

бумагу с печатью и финансовыми штрафными санкциями, в вашу сторону, подпишите ?

Есть более обьективное предложение. Лучше напишите авторам I2C (или правоприемникам), что они полные лохи и неучи.  Ответ думаю интересен будет всем.
...............................
По существу.
Боитесь зацикливания - примените собаку. Строго синхронизированно время - игнорируйте ложные данные и выходите из п\прогр. Итд, итп. Совершенно стандартные методы. Вариантов масса как грамотно обойти проблему.
Многие м\с вообще заточены под I2C. Часы реал. времени практически все популярные с I2C и что делать?
Не пугайте народ. Все там в порядке и давным давно все глюки определены и устранены.

[Alex_Soroka]

Лучше напишите авторам I2C (или правоприемникам), что они полные лохи и неучи.  Ответ думаю интересен будет всем.

НЕт, мне именно интересен от РАЗРАБОТЧИКОВ ответ на бумаге с печатью, о том что они КОМПЕНСИРУЮТ мои потери в случае проблем(ошибок) в ИХ реализации протоколов (библиотек) I2C. 
слова и рассказки - не интересуют вообще.
Про АКБ тоже муркетологи продающие "солнечные решения" в рекламе рассказывают про "прослужит 15 лет", а ГАРАНТИЙНЫЙ талон на АКБ выдают на 18 месяцев, и да - с синей печатью и подписями. 
Так что мечтать можно про 15 лет, а реально предьявить можно только бумагу с 18 месяцев в ней вписанными.
А про "софт" вообще забудьте про "гарантии": открывает "лицензионные соглашения" и внимательно читаем до конца - там написано что разработчик НИ ЗА ЧТО НЕ ОТВЕЧАЕТ, и все что вы делаете с его софтом и хардом это ваша личная инициатива на ваш собственный риск.
Так что не надо мне про реальную жизнь рассказывать. 

По существу.
Боитесь зацикливания - примените собаку. Строго синхронизированно время - игнорируйте ложные данные и выходите из п\прогр. Итд, итп. Совершенно стандартные методы. Вариантов масса как грамотно обойти проблему.
Многие м\с вообще заточены под I2C. Часы реал. времени практически все популярные с I2C и что делать?

дЧто делать? головой думать.
и под реалтайм применять не "собаку" , которая в реалтайме не всегда поможет, а свои решения, которые прописаны под случаи "когда все плохо и зависло".
и к "библиотекам" (в том числе Ардуино) относиться всегда подозрительно. Проверять и тесты гонять.
В моей практике был изумительный случай, когда на одну из карт "голосовой обработки" сервера для Линукса были поставлены некие драйвера и утилиты, "от разработчика". В реальной работе под нагрузкой, оказалось что проявляются лаги и потери данных, совершенно не предсказуемые и непонятные, совсем не "по описаниям работы".
Разработчик тоже репу чесал и ничего толком не отвечал.
При просмотре компиленного кода по-старике отладчиком, оказалось что код был тупо написан под Винду а потом "портирован" методом "перекомпилим на Линукс с другими флажками для С++" 
понятно что без всяких учетов особенностей совершенно другой операционки 
...кончилось тем что пришлось самим писать утилиты и функции, послав разработчиков подальше...

[KIE]

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

Так а я о чем пишу уже не первый раз?
Есть конкретная задача, под неё и пишется программа. Всегда можно найти разумный консенсус между желаемым и реальным.
По этому:

к "библиотекам" ................ относиться всегда подозрительно.

Которые используются как шаблон или пример. Может вполне быть, что алгоритм избыточен, а бывает и наоборот. Да и любой автор человек, а не Бог.

ответ на бумаге с печатью, о том что они КОМПЕНСИРУЮТ мои потери в случае проблем

Государство конституцию с печатями и подписями отслюнявило. И что?  Кто то решает Ваши проблемы? Проблемы индейцев, шерифа не волнует.
Опустимся на землю, поставим вопрос более прогматично.  Вы даете гарантию на свои изделия и какие компенсации на:

с синей печатью и подписями

Или тоже фигвам как и везде?

[Necromant]

Ну так мы скоро докатимся и до недоверия разработчикам самих МК. Вдруг не так транзисторы соединили? Сами начнем создавать фотошаблоны и писать загрузчики?

[Necromant]

и к "библиотекам" (в том числе Ардуино) относиться всегда подозрительно. Проверять и тесты гонять.
В моей практике был изумительный случай, когда на одну из карт "голосовой обработки" сервера для Линукса были поставлены некие драйвера и утилиты, "от разработчика".

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

[Паяка]

Ранее зубную боль доставлял преобразователь питания, с его трансформатором. Хотя это чисто психологическая отмазка. Такие простенькие трансы за 20мин мотаются, но.... дольше собираешься, чем делаешь.

Ещё можно взять готовый МИТ-4 или трансформатор управления AT/ATX.

[Паяка]

Что касается надёжного асинхронного обмена информацией при работе систем на МК, это не так трудно. Применяется конечный автомат с флагами состояний. По прерыванию, либо по детектированию установки или снятия флага, программа берёт из регистров данные, полученные с АЦП, модуля последовательного интерфейса и т.д., обрабатывает (учитывает) их, даёт периферии следующие команды. Против зависаний и сбоев есть сторожевые таймеры. Периферия, независимая от ядра, (ПНЯ), взаимодействует с микропроцессором по определению асинхронно, на то она и независимая. Это отражено в даташитах. Конечно, надо учитывать время выполнения той или иной функции ПНЯ.

Проблемы с библиотеками для МК и ЭВМ вообще появляются при нечёткости областей применений. Математические библиотеки на ассемблере из аппнотов отточены, можно сказать, до идеала. А библиотеки с открытым кодом, написанные энтузиастами, зачастую работают только в частных случаях, и требуют углублённого изучения и совершенствования для переноса в другие области применения, и тем более, для обобщённого применения.

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

[Alex_Soroka]

Что касается надёжного асинхронного обмена информацией при работе систем на МК, это не так трудно.

ага 
это видимо писал тот кто ни разу в своей жизни не писал развесистых быстрых протоколов обмена "точка-многоточка".
Канешна просто - если ты сам этого не писал 

[Alex_Soroka]

Проблемы с библиотеками для МК и ЭВМ вообще появляются при нечёткости областей применений.

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

Математические библиотеки на ассемблере из аппнотов отточены, можно сказать, до идеала.

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

А библиотеки с открытым кодом, написанные энтузиастами, зачастую работают только в частных случаях, и требуют углублённого изучения и совершенствования для переноса в другие области применения, и тем более, для обобщённого применения.

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