Микроконтроллеры и всё, что с ними связано

Николай

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

Добавлено: Fri Mar 31, 2017 1:01 pm

Ivani

Вы ненавидите Ардуино? Да вы просто не видели http://flprog.ru/index/o_programme_flprog/0-7

Добавлено: Fri Mar 31, 2017 11:49 pm

AlexDark
CyberGoth

И что?

Добавлено: Fri Mar 31, 2017 11:57 pm

Behram

Ужоснах

Добавлено: Sat Apr 01, 2017 12:01 am

sergh

Ivani, а вот система которая реально в промышленности используется, причем с распределенными по сети контроллерами и визуализацией процессов, все через CoDeSys:

https://ru.wikipedia.org/wiki/CoDeSys

- только контроллеры не "одна палка - два струна"

Добавлено: Sat Apr 01, 2017 12:04 am

TAN

Релейная логика на дурнине. Это сильное извращение. Это даже круче машины Наири-1 Ереванского коньячного завода. смех

Добавлено: Sat Apr 01, 2017 1:40 am

Николай

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

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

Добавлено: Sat Apr 01, 2017 1:50 am

TAN

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

Релейная логика - примитивный аналог того же VHDL. И в ней так же можно накосячить, когда у тебя число реле за пару десятков перевалит. И будет более-менее сложный алгоритм работы. Никогда не видел АТС старые? Или автоматику релейную для совкового табло на стадионе? Я вот видел.

Не в языке дело. Дело в правильном подходе к написанию кода.

Добавлено: Sat Apr 01, 2017 2:14 am

Руслан

У нас на работе используется Delta-V.Тоже графическое программирование.Смотрел как ребята программируют-удобно.Просто линии мышкой тянут от блока к блоку.как конструктор.И никаких символов.

Добавлено: Sat Apr 01, 2017 4:37 am

TAN

Под ПЛИС тоже так можно программировать. На верхнем уровне. Ниже - не удобно.

P.S. Это классический срач про программирование мышкой.

Добавлено: Sat Apr 01, 2017 4:46 am

Linkoln

1Николай писал(а):
избавлятся ни от каких комманд не надо. они все нужны и полезны. вот например передача 1-wire реализуется на делеях легко и непринужденно.при обмене без синхронизации без коротких задержек никак, и в конечном итоге в готовом коде их будет более чем дохуя.
И что по этому говорит теория цифровых автоматов ?
И как быть с прерываниями когда таким макаром задают временные интервалы ?
Пока такие команды (Delay) не в основном цикле программы то - почему бы и нет , инициализация периферии итд.
А так получается инженеры конвейер команд итд делают что бы "камень" быстрее молотил . А Вы его холостыми циклами грузите .
Как то не по феншую .

Добавлено: Sat Apr 01, 2017 9:49 am

Анна

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

Добавлено: Sat Apr 01, 2017 10:10 am

Ivani

Помните недавно писал про прошивку с фантомным питанием?
Вчера разбирался почему от 2х новых USBASP макет шьется но не работает, оказалось земля на другом пине, получилась прошивка с фантомной землей Smile

Добавлено: Sat Apr 01, 2017 10:23 am

Behram

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

Добавлено: Sat Apr 01, 2017 11:38 am

Анна

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

Добавлено: Sat Apr 01, 2017 11:42 am

Николай

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

>И что по этому говорит теория цифровых автоматов ?

не слушаю всяких продажных девок -) стараюсь писать просто читаемый и поддерживаемый код

>И как быть с прерываниями когда таким макаром задают временные интервалы ?

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

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

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

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

>Как то не по феншую .
зато просто, коротко, читабельно и работает.

Добавлено: Sat Apr 01, 2017 2:01 pm

TAN

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

Добавлено: Sat Apr 01, 2017 4:28 pm

Николай

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

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

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

Последний раз редактировалось: Николай (Sat Apr 01, 2017 4:46 pm), всего редактировалось 1 раз
Добавлено: Sat Apr 01, 2017 4:39 pm

TAN

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

>ардуина страшна своими быдлокодерами и быдлобиблиотеками

Дык в том-то и дело. А тут можно такого набыдлокодить, ухх! Усе возможности есть.

>карячить его на промконтроллер заводской или делать его из ардуины - какая разница

Большая разница. Во всяком случае между сименсом (что я видел) и дурниной. У дурнины железо не адаптировано под жесткие условия и надежную работу. В отличие от того же сименса.

>делай IDE с рисованием мышкой и продавай как аналог овна

Почему аналог? Самое что ни есть овно и получится смех

Ибо жылезо.

Добавлено: Sat Apr 01, 2017 4:46 pm

Electricman
Бес заземления

У нас овены юзаются на управление деаэратором. Деаэратор то обсыхает, то переписывается, то замерзает, то вступает Smile

Добавлено: Sat Apr 01, 2017 6:31 pm

Break_Neck

Да кстати зря на ардуину тут гонят ) Бывает чего по быстрому делаю в mbed - аналог ардуины для arm-ов. Инициализацию портов, таймеров, прерываний в том же стм32 (где 11 регистров для иницилизации порта Smile

) - быстро, для прототипирования вполне.

Добавлено: Sat Apr 01, 2017 7:15 pm

Ivani

Николай писал(а):
вот например как передать 8 бит в пин на заданой скорости ......................
Выбирать пин с соответствующим аппаратным обвесом не ?

Добавлено: Sat Apr 01, 2017 7:42 pm

Николай

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

Добавлено: Sat Apr 01, 2017 9:26 pm

Ivani

Тинька в 2 раза меньше меги32 размером, дешевле на 30% и ради этого нужно мучатся(акромя твоих специфичных девайсов)?

Добавлено: Sat Apr 01, 2017 11:23 pm

Николай

я специфичные не имею ввиду. а гражданское применение конечно же. в специфичных девайсах крайне специфичный протокол. про него речи нет

берем гражданское применение - датчики на 1wire с питаловом по нем же. разве мега32 умеет его? вроде как один хрен софтово рисовать.
или ты про эмуляцию 1wire через usart. ну вот если честно не нравится мне такая конструкция. костыль имхо. да и насколько понимаю принцип данной конструкции - питалово с нее не получится взять, бо у усарта аппаратного ноль это ноль а не Z. а в софтовой реализации самодельной ноль будет Z и у слейвов будет с питанием все ок

да и в чем мучение то? ну реально пять строк кода передачи и десяток приема. на это надо пять минут времени. это работает также надежно как и аппаратно.

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

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

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

Добавлено: Sun Apr 02, 2017 1:09 am