Энкодер китайский, глючит довольно неплохо (вместо + иногда - или проскакивают несколько значений).dth, 31 Мая 17, 20:28
Вот видео Alex Morozov вроде поборол энкодер. С 4-й минуты смотреть про него.
gol_avto
Доцент
Москва - Серпухов - Анапа
1.3K 458
Отв.861 05 Дек. 17, 16:15
Перепробовал разные скорости I2C: 4800 9600 19200 38400 76800 - короткий импульс так и не пропадает, "забить"?
OldBean
Доцент
Красноярск
1K 1.4K
Отв.862 05 Дек. 17, 18:23
Поставьте 9600 и "забейте". Скоро сделаю коррекцию скетчей и соответствующих питоновских классов. После этого, надеюсь, мы забудем об этой проблеме. Суть. К сожалению, даже при сниженной скорости обмена, все равно иногда (редко) пропадает старший бит. В принципе, применяя избыточное кодирование, эту ситуацию несложно отлавливать и исправлять. Для начала хочу реализовать самый простейший вариант. Каждый обмен между малинкой и периферией производится трижды. Приемник, получив тройку чисел, сравнивает их между собой. При отсутствии сбоев они все должны быть равны. Но, если произошел сбой (предполагаем, что один), то одно число будет отличаться от двух других. Оно и игнорируется. Как ошибочное. Запас по скорости (даже при 9600) у нас хороший. Поэтому вполне можно пойти на такую тройную избыточность кодирования обмена.
ZagAl
Доцент
Прибалтика
1.9K 916
Отв.863 05 Дек. 17, 20:07
Поэтому вставить проверку наличия ключа - весьма полезно. Ну типа if id in Ts: делаем что-тоOldBean, 05 Дек. 17, 03:04
OldBean, а как это применить на практике? Можно поподробней, на примере?
OldBean
Доцент
Красноярск
1K 1.4K
Отв.864 06 Дек. 17, 05:45
Можно поподробней, на примере?ZagAl, 05 Дек. 17, 20:07
Можно. Но, сначала немного про словари в питоне. Словарь позволяет обращаться к элементам не по индексу (номеру) как в обычном массиве или списке, а по ключу. Т.е. когда мы создаем словарь, мы заносим туда пары "ключ : значение". И потом можем получать "значение" по указанному ключу. Если мы пытаемся получить некое значение по несуществующему ключу - то интерпретатор, естественно выругается и инициирует исключение. Конечно, исключение можно перехватить и обработать. Но гораздо проще перед обращением к словарю просто проверить есть ли в нем такой ключ и уже потом попросить значение. Об этом и была речь. Команда:
конкретный_ключ in имя_словаря
возвращает True, если такой ключ (конкретный_ключ), и естественно, соответствующее ему значение есть в словаре или False - в противном случае.
За дальнейшими подробностями - запрос в google типа "Язык Python словари". Теперь конкретный, близкий к жизни пример. Комментарии - прямо в тексте этого скрипта.
#coding:utf-8 # Это позволяет использовать русские буквы в этом тексте # Присвоим переменным значения заводских ID температурных датчиков hid = 0x8000001ee27b # ID датчика температуры куба cid = 0x8000001ef6e6 # ID датчика температуры колонны did = 0x000006273720 # ID датчика температуры дефлегматора wid = 0x8000000419af # ID датчика температуры выходящей воды
# Вспомогательный массив (точнее - кортеж), чтобы обращаться к датчикам # по индексу 0, 1, 2 и т.д., а не по их заводскому ID tids = (hid, cid, did, wid)
# Допустим измерены какие-то температуры. Здесь мы забьем данные в словарь "ручками", # но в реальном скрипте это делает метод sens.DS18B20.Ts() класса DS18B20 в модуле sens Ts = {hid : 95.37, cid : 78.723, did : 78.13, wid : 33.21} # Получили вот такой словарь
# В качестве примера использования этого словаря - выдадим все температуры # на терминал в виде одной строки. Сформируем эту строку. s = "Температуры: " # Это будет начало строки for id in tids: # Пробегаем в цикле по всем ID датчиков if id in Ts: # Если датчик с таким ID есть в словаре, то выведем его температуру s += "% 7.2f" % (Ts[id]) else: # А если такого датчика нет - ставим прочерк s += " --- " print s # Теперь выведем получившуюся строку на терминал
# Теперь предположим, что датчик (например, на колонне - cid) отвалился в процессе # работы. После измерения температуры нам выдадут такой словарь (уже без cid!): Ts = {hid : 95.42, did : 78.12, wid : 33.20}
# Посмотрим что напечатается s = "Температуры: " for id in tids: # Пробегаем по всем ID датчиков if id in Ts: # Если датчик с таким ID есть в словаре пишем T s += "% 7.2f" % (Ts[id]) else: # Такого датчика нет - ставим прочерк s += " --- " print s
# А вот если не проверять наличие ключа в словаре и попытаться выдать температуры # так, как написано ниже, то интерпретатор ругнется и выдаст исключение. # Проверяем: s = "Температуры: " for id in tids: # Пробегаем по всем ID датчиков невзирая... s += "% 7.2f" % (Ts[id]) print s
Сохраните этот скрипт в файле (например, 01.py) в текущей директории, там же откройте консоль и наберите команду
python 01.py
Вы увидите результат:
Температуры: 95.37 78.72 78.13 33.21 Температуры: 95.42 --- 78.12 33.20 Traceback (most recent call last): File "01.py", line 44, in <module> s += "% 7.2f" % (Ts[id]) KeyError: 140737490384614
В первых двух случаях все отработало корректно, в третьем - ругачка интерпретатора. PS Вы спрашивайте, если что непонятно. Будет возможность - расскажу. Поначалу всегда трудно. Но потом резко полегчает. Это в любом деле так... ;)
ZagAl
Доцент
Прибалтика
1.9K 916
Отв.865 06 Дек. 17, 22:03
OldBean, вот такое изменение будет правильным или еще нужно что-нибудь подправить?
"""Добавим для выдачи текущие значения температур с датчиков""" Ts = sens.DS18B20.Ts() # Сначала их измерим for id in tids: # Теперь добавим в строки для выдачи if id in Ts: # Если датчик с таким ID есть в словаре, то выведем его температуру if id == cid: # Подкрасим температуру в колонне для консоли ss += "\x1b[32m% 7.2f\x1b[0m" % (Ts[id]) elif id == did: # Подкрасим температуру в дефлегматоре для консоли ss += "\x1b[33m% 7.2f\x1b[0m" % (Ts[id]) else: ss += "% 7.2f" % (Ts[id]) s += "% 7.3f" % (Ts[id]) else: ss += " --- " # А если такого датчика нет - ставим прочерк. s += " --- "
P.S. В работу запускается. Остается проверить в течение длительного времени если ничего больше не нужно добавлять.
OldBean
Доцент
Красноярск
1K 1.4K
Отв.866 07 Дек. 17, 03:01
ZagAl, почти все правильно. Только последнюю строчку сместите вправо. Чтобы она была в блоке "else:". Иначе в файле лога получатся сплошные прочерки. Отступы в питоне определяют программные блоки. К ним нужно относиться очень внимательно. В Вашем случае s += " --- " относится уже к внешнему циклу: for id in tids:...
Аналогичные проверки желательно использовать и в других местах, где есть обращение к словарю Ts. Например, в Вашем же тексте немного ниже:
"""Выводим информацию о разности температур в колонне и дефлегматоре""" ... if step_number == 1: T1col = Ts[cid] ...
И еще (это, конечно, зависит от логики процесса). Если "отваливается" датчик температуры, наверное, лучше прекратить процесс и выдать сообщение оператору. Ну, например, как-то так:
... if id in Ts: # Если датчик с таким ID есть в словаре, то выведем его температуру ... else: print '\nТемпературный датчик с ID = ' + str(id) + ' неисправен. Завершение работы.' ... Здесь все выключить (ТЭН, отбор - на 0 и т.п.) ... sys.exit(1) ...
makh
Профессор
Sаmara
2.1K 1.1K
Отв.867 07 Дек. 17, 12:43
прекратить процесс и выдать сообщение операторуOldBean, 07 Дек. 17, 03:01
ИМХО лучше сперва выдать сообщение, а прекратить процесс по таймауту через Икс времени -- оператор может успеть пофиксить проблему с датчиком без остановки процесса, отсутствие датчика в течение нескольких минут некритично. Сорры за оффтоп.
OldBean
Доцент
Красноярск
1K 1.4K
Отв.868 07 Дек. 17, 17:04
Да в общем-то, это - просто примеры питоновских кодов. Естественно, каждый сам себе решит какая логика процесса ему нужна. Главное - научиться объяснять эту логику малинке. На языке, понятном обеим сторонам ;). В данном случае - на питоне.
OldBean
Доцент
Красноярск
1K 1.4K
Отв.869 08 Дек. 17, 06:52
16. Ревизия софта после года эксплуатации системы
Год эксплуатации ненавязчивой автоматизации, описанной в этой ветке показал, что в целом система работает неплохо. Ну, естественно, при полностью осмысленном подходе как к железу, как к софту, так и к логике самого процесса ректификации ;). Тем не менее появилось несколько соображений, позволяющих упростить программное обеспечение и повысить его надежность. Поэтому я решил, по мере возможности, "перетряхнуть" весь софт (и в ардуинках и в малике) и, в результате, сделать новый, улучшенный релиз. В процессе "перетряхивания" я постараюсь максимально подробно комментировать код, чтобы фрагменты кода можно было бы рассматривать как некие обучающие примеры для новичков в программировании.
Мы все работаем на разных рабочих станциях, ноутбуках, планшетах и даже смартфонах. Но, поскольку в основе этой системы автоматизации лежит малинка, я решил весь новый софт разрабатывать прямо на ней. Как на нормальной рабочей станции с монитором, клавиатурой и мышкой. Это даст возможность всем (особенно важно для новичков в программировании) работать в совершенно одинаковых условиях. Поэтому наша первая задача - сделать из малинки нормальную, почти "взрослую" (ну, скажем - подростковую ;) рабочую станцию, подходящую для программирования как ардуинок, так и самой малинки (как управляющего микрокомпьютера). Этим мы сейчас и займемся.
16.1. Подготовка к работе малинки, снабженной монитором, клавиатурой и мышкой 16.1.1. Часть 1. Установка и настройка ОС Raspbian
Рабочую станцию будем делать на основе третьей модели малики (Raspberry Pi 3 Model). С аппаратной точки зрения, для превращения малинки в рабочую станцию, нам нужно всего лишь подключить к ней обычный ЖК-монитор с HDMI интерфейсом, обычную USB-клавиатуру и USB-мышку. Соответствующие разъемы на платке малинки есть. Если монитор без колонок (а звук очень хочется), то можно просто воткнуть колонки в соответствующий 3.5мм. Он тоже есть на плате малинки. Далее, малинку нужно физически подключить к Сети/Интернету (обычной витой парой или по Wi-Fi). Все необходимое для этого у малинки тоже есть. Теперь остается только установить необходимое программное обеспечение. Об этом и пойдет речь ниже. В части 1 - изложены прописи по установке и общей настройке системы, в части 2 - установка и настройка ПО, необходимого для программирования.
На первом этапе нам понадобится еще один компьютер (рабочая станция) на которой мы подготовим SD-карточку для малинки. С операционной системой Raspbian (вариант Linux/Debian). Предполагаем что такая рабочая станция есть. Первые 4 пункта прописей как раз и будут выполняться на этой рабочей станции. Все мои рабочие станции работают под Linux (Ubuntu). Поэтому, в первых 4-х пунктах, я буду ориентироваться на эту ОС. Для Mac - см. здесь. Пользователи Window легко найдут необходимую для подготовки карточки с Raspbian в Сети (в том числе и на сайте производителя). Остальные пункты (начиная с 5-го) выполняются уже на самой малинке. Там уже никакой "разношерстности" у нас не будет. Итак.
1. Идем на страницу загрузки сайта производителя и скачиваем последний релиз Raspbian. На данный момент это версия от 2017-11-29. Проверяем целостность архива командой:
sha256sum 2017-11-29-raspbian-stretch.zip
и сравниваем результат с кодом: SHA-256: 64c4103316efe2a85fd2814f2af16313abac7d4ad68e3d95ae6709e2e894cc1b Если коды совпадают - значит архив добрался до нас без потерь. Продолжаем работу - распаковываем архив. Получаем файл образа Raspbian 2017-11-29-raspbian-stretch.img. 2. В консоли вводим команду:
df -h
Теперь вставляем в кард-ридер подходяющую SD-карточку, на которую будем устанавливать Raspbian, и опять даем команду:
df -h
Сравниваем предыдущий список устройств со вновь появившимся. Новые устройства это и есть наша карточка. У меня это - целых два устройства, так как на карточке уже была раньше установлена система:
/dev/sdb1 /dev/sdb2
3. Эти устройства нужно размонтировать (от имени суперпользователя sudo):
sudo umount /dev/sdb1 sudo umount /dev/sdb2
4. Теперь, будучи в директории, где находится образ будущей системы, запускаем его копирование на карточку
Обратите внимание, что в этой команде мы указываем устройство просто как /dev/sdb. Без цифр. Ждем несколько минут (у меня получается чуть меньше 3 мин). Все. Система готова. Извлекаем карточку из кард-ридера. Дальнейшие шаги будем выполнять уже на малинке.
5. Вставляем карточку в слот малинки, включаем питание малинки и монитора. Ждем пока Raspbian загрузится. Готово. Полюбуемся немного на дорогу, уходящую в горы на горизонте, и начнем настраивать установленную систему.
6. Щелкаем по иконке с ягодой-малинкой в левом верхнем углу. В выпадающем меню выбираем пункт Preferences/Raspberry Pi Configuration. Появится диалоговое окно. 6.1. На первой закладке (System) меняем пароль (кнопка Change Password...) и устанавливаем желаемое разрешение экрана (кнопка Set Resolution...). Разрешение зависит от подключенного монитора. У каждого свое. Для моего монитора подходит разрешение: DMT mode 82 1920x1080 60Hz 16:9. 6.2. На следующей закладке (Interfaces) сделаем доступными (т.е. включим радио-кнопки Enable) интерфейсы, с которыми будем работать. Это SSH (если будем связываться с малинкой по SSH), I2C и 1-Wire. 6.3. На вкладке Performance можно указать размер видеопамяти. У нас особых требований к графике пока не планируется, поэтому можно оставить значение по умолчанию. 6.4. На следующей вкладке (Localisation) жмем на кнопку Set Locale.... На появившейся диалоговой панели в выпадающем списке Language выбираем ru (Russian). Остальные опции выберутся автоматически. Жмем OK и опять OK. Малинка захочет перезагрузиться - пусть перезагружается.
7. После перезагрузки нам нужно добавить обработчик раскладки клавиатуры на панель задач (серая полоса сверху). Для того, чтобы у нас была возможность писать комментарии к нашим программам (ну и топики на форум :) по-русски. Для этого - щелкаем (на свободном от иконок месте панели задач) правой клавишей мышки и выбираем пункт Добавить/убрать элементы панели во всплывающем меню. В появившейся диалоговой панели жмем кнопку Добавить, выбираем в списке Обработчик раскладки клавиатуры и жмем клавишу Добавить, затем - Закрыть. В правом углу панели задач появится британский флаг.
Дальше нам нужно настроить этот переключатель раскладок. По задумке разработчиков это нужно было делать так. Щелкаем правой клавишей мышки по этому британскому флагу и выбираем пункт Обработчик раскладки клавиатуры Settings. Дальше появится диалоговая панель, в которой мы смогли бы все, что нам нужно, настроить. Увы, в этом диалоге разработчики слегка "накосячили". В результате кнопка закрытия диалога и, соответственно, сохранение всех наших трудов по настройке плагина не работают. После первой же перезагрузки системы, все наши установки пропадут.
Делать настройки плагина после каждой перезагрузки системы, конечно же, можно. Но как-то не солидно. Поэтому придется поправить этот косяк разработчиков "ручками" - прописать все настройки непосредственно в конфигурационном файле плагина. Замечательная особенность Linux - он всегда дает возможность спастись бедному пользователю. При почти любых косяках разработчиков GUI-ни! :). Сейчас мы спасемся.
Открываем файловый менеджер (иконка с желтыми папками в левой части панели задач). В файловом менеджере в выпадающем меню Вид ставим галочку на пункте Показать скрытые файлы. У скрытых файлов перед именем файла стоит точка. Теперь мы их видим. Идем в папку .config (двойной щелчок по иконке), затем - в папку lxpanel, затем LXDE-pi и, наконец, в panels. Там мы увидим файл panel. В нем как раз все настройки панели задач. Это - текстовый файл и нам нужно его слегка подправить.
Двойной щелчок по иконке - содержимое файла появится в текстовом редакторе (leafpad). В самом конце файла ищем блок:
Plugin { type=xkb Config { ... } }
При "первом подходе к снаряду" (т.е. - к Raspbian) можно привести содержимое этого блока к следующему виду (как у меня):
Здесь отражены мои личные предпочтения: маленькие иконки, стандартная клавиатура, переключение раскладок при помощи левых cntr+shift). А уже потом, как-нибудь, каждый сможет сам настроить плагин. Уже и на свой вкус. Далее - сохраняем файл и перезагружаемся. Все. Теперь переключение ввода с нашего языка на импортный и обратно работает! Будем надеяться, что в следующих релизах Raspbian разработчики исправят этот косячок и избавят нас от необходимости заниматься редактирование конфигурационных файлов вручную.
Дополнение от 09.12.2017. Обратите внимание, что в раскладке (LayoutsList=us,ru) британский флаг (gb) заменен на американский. Это связано с тем, что клавиатуры (по крайне мере 3 штуки, разные, которые я пробовал) выдают некорректные коды при нажатии некоторых клавишей. Например, вместо решетки (#) выдают фунт, а вместо вертикальной черты (|) - разное, но только не черту. А оба этих символа очень важны для программистов (# - комментарий в питоне и многих других скриптовых языках, а вертикальная черта (|) - побитовое "Или" в языке Си. "Под американским флагом" все работает корректно на всех 3-х клавиатурах ;).
8. Для некоторых нужных нам опций я не нашел "графических эквивалентов" их настроек. Если кто нашел - скажите. Поэтому их придется настроить в консольном варианте. В консоли запускаем:
sudo raspi-config
Появится диалоговое окно, в котором мы можем выполнить необходимые настройки. Про эти настройки в Сети много написано. Поэтому я не буду повторяться и только отмечу что конкретно необходима настроить. 8.1. Настраиваем Wi-Fi. Если он есть в помещении, конечно. Это пункт 2 Networ Options/N2 Wi-Fi и далее по смыслу... 8.2. Раздвигаем файловую систему на всю карточку: 7 Advanced Options/A1 Expand Filesystem. При самой первой загрузке система что-то быстро "буркнула" на эту тему, но я не успел рассмотреть суть. Может уже сама все сделала. Но, не повредит, еще раз, на всякий случай... 8.3. Настраиваем аудио. Здесь, собственно говоря, нужно сказать малинке куда подключены колонки (к HDMI или к 3.5mm разъему на плате малинки). Это пункт: 7 Advanced Options/A4 Audio.
9. После перезагрузки и проверки рус/лат самое время сделать upgrade системы. Запускаем консоль (характерная иконка на панели задач слева или просто cntr+alt+t) и в консоли пишем:
sudo apt-get update sudo apt-get upgrade
Первая команда актуализирует репозитории, а вторая, собственно, и выполняет абгрейд.
10. Ну и, в заключение, отключим хранитель экрана (black screen). В консоли, от имени суперпользователя, даем команду:
sudo leafpad /etc/lightdm/lightdm.conf
В текстовом редакторе leafpad откроется соответствующий конфигурационный файл. Вставим в конец файла вот такую секцию:
[SeatDefaults] xserver-command=X -s 0 -dpms
Сохраняем файл и перезагружаем систему. Больше малинка не сможет пугать нас черным экраном. Ну вот и все. На этом первую часть подготовки малинки к работе будем считать законченной. Самое время побродить в Сети, поиграть, послушать музыку (на мой неиспорченный слух - вполне сносно :), посмотреть и перетыкать все, что еще там есть. В Raspbian-е. Ну просто чтобы убедиться в том, что малинка действительно превратилась в рабочую станцию, со вполне приемлемой производительностью и достаточно комфортным UI. Ну и порадоваться тому, что эта "крошка" у нас есть, что мы ее без особых хлопот настроили и собираемся с ней общаться дальше, и что весь софт совершенно легальный и бесплатный! :)
В заключение - скриншот, малинкиного экрана во время финального тестирования. Ненавязчивая автоматизация ректификационной установки. Автоматика. Вот так, вполне "по-взрослому" ;) выглядит теперь рабочий стол малинки. В следующем разделе мы займемся установкой и настройкой программного обеспечения, необходимого для программирования ардуинок и микроконтроллеров AVR. Предыдущий топик Вернуться к оглавлениюСледующий топик
gol_avto
Доцент
Москва - Серпухов - Анапа
1.3K 458
Отв.870 08 Дек. 17, 14:41
В планах: 1) Повысить надежность обмена малинки с контроллерами по I2C. В простейшем случае - за счет дублирования посылок и последующим "голосованием" полученных данных. А там посмотрим. Может и этого хватитOldBean, 02 Дек. 17, 09:37
Я конечно не спец в протоколах, но может быть использовать часть идеи, заложенной в сверх надежных обменах данных автомобильных шин CAN? К примеру: - идентификатор послания (приоритет) - контрольная сумма - подтверждение приёма - завершение послания. Если послание не дошло до адресата, то оно повторяется N раз, пока не превысит порог (к примеру 100-128) и уже потом выдать сообщение об ошибке. P.S. мысли вслух.
gol_avto, Там нет адресат в CAN, совсем. Там есть некий идентификатор сообщения и все кому оно нужно принимают его, кому не нужно - фильтруют.
Самое главное там - это система контроля приоритетов сообщений. Смысл примерно в том, что во тьме можно посветить фонариком (активный уровень), а если фонарик выключен, то "мы как бы светим тьмой во тьме", но можем увидеть свет от других участников.
Поэтому, когда шину хотят захаватить два сообщения с идентификатором, например: a) 111 000 000 01 и b) 111 100 000 01
где 1 - это активное состояние (светит фонарик во тьме). абонент a. при фазе передачи четвертого бита идентификатора (ноль) не "светит" в шину, но обнаруживает, что туда "светит" кто-то другой и прекращает дальнейшую передачу, т.к. у кого больше активных битов в адресе - тот имеет приоритет. В итоге и, сообщение не исказили, и абонент a. знает начало сообщения от абонента b., и сможет его принять не искаженным.
Вот тут мне идеология нравится.
OldBean
Доцент
Красноярск
1K 1.4K
Отв.872 09 Дек. 17, 10:52
gol_avto, в начале проектирования системы, при выборе протокола обмена между малинкой и модулями (на основе МК AVR), я руководствовался следующими основными критериями:
1. Нет каких-то особых требований к скорости передачи информации (да хоть 100 бит/сек! ;) 2. Расстояния между устройствами небольшие (10-20 см) 3. В системе есть явный мастер (малинка) и он постоянен. 4. Количество модулей переменное. Причем, это не один и не два, а больше. Поэтому использование дополнительных шин выбора приемника (типа chip select) нежелательно. Т.е. обращение к устройствам должно быть адресное. 5. Желательно чтобы протоколы имели аппаратную реализацию как в малинке, так и в модулях. Т.е. использование дополнительных драйверов, адаптеров нежелательно.
В результате выбор был сделан в пользу I2C.
На первой малинке все работало великолепно и абсолютно безотказно. Как и положено - на 100 кбит/сек. Проблемы начались с третьей малинкой. Некорректный алгоритм снижения скорости обмена - это была особенность реализации самого процессорного чипа малинки. Поэтому "снаружи" полностью устранить эту беду было затруднительно. Но это не дефекты самого протокола I2C, а ошибки разработчиков чипа.
На 99% проблема была решена за счет снижения скорости обмена. Оставшийся 1% практически не влияет на процесс ректификации. Ну выскочит пару-тройку раз за сутки некорректные значения. При следующей же посылке приемник получит корректное значение и успокоится. Однако, сам факт ошибки раздражает. Поэтому я и решил ее "зафиксить" окончательно. Естественно, на прикладном уровне.
Sorry, но переходить же из-за этой мелочи на физически другой протокол, ставить дополнительные адаптеры и прочее, прочее, прочее... было бы крайне неразумно ;)
Ну и второе. С учетом никаких требований к скорости обмена, нет смысла использовать какие-то сложные алгоритмы помехозащищенного кодирования. Достаточно просто и тупо сдублировать (точнее - строИть ;) посылки. Т.к. двух и более ошибок обмена подряд я никогда не наблюдал. Т.е. вероятность их ничтожна. PSВозможно, в четвертой малинке разработчики, наконец-то, уберут этот глюк. И все пройдет. Эта надежда тоже голосует против радикальных изменений в концепте или сильных усложнений протокола прикладного уровня.
OldBean
Доцент
Красноярск
1K 1.4K
Отв.873 10 Дек. 17, 11:39
16.1.2. Часть 2. Установка и настройка дополнительного ПО, необходимого для программирования
Итак, в предыдущем разделе мы превратили нашу крошку-малинку в почти "взрослую" рабочую станцию, на которой мы собираемся заняться программированием. Программировать ардуинки и микроконтроллеры AVR мы будем на языке C/C++, а саму малинку - на Python (aka питон). Одним из довольно привлекательных "бонусов", при использовании малинки в качестве рабочей станции для программирования МК, является то, что в этом случае мы можем вообще обойтись без программатора. Роль программатора может выполнить сама малинка. При помощи своих GPIO. Конечно, здесь никто не отменял простые USBasp-программаторы. Это недорогой, легкий в настройке и очень безопасный вариант. К сожалению, большие прошивки такие программаторы загружают довольно долго. Все-таки это - USB-1!. Поэтому варианты работы без программатора мы будем использовать. Но позже. А пока начнем с самых простых технологий разработки скетчей для Arduino и с USBasp в качестве программатора.
11. Программирование Arduino - Arduino IDE 11.1. Сначала установим на малинку Arduino IDE. Тут все просто. Проще некуда. В консоли выполним две команды:
sudo apt-get update sudo apt-get install arduino
Первая команда, как обычно, нужна для синхронизации информации о пакетах (вдруг уже появились какие-нибудь обновления, новые версии пакетов и т.п.). А вторая команда - собственно установка Arduino IDE. Немножко подождем пока закончится установка. 11.2. Теперь нужно проверить как все встало. В главном меню (выпадает при щелчке по иконке малинки в левом верхнем углу рабочего стола) появился пункт меню Электроника и в нем подменю Arduino IDE (в меню Программирование оно тоже появилось). Щелкаем по нему - появится штатное пустое окно Arduino IDE. Хорошо. Теперь проверим его в деле. - В меню IDE Файл/Примеры/01.Basics выберем пример Blink. В новом окне мы увидим текст скетча этого примера (мигание светодиодика на плате ардуинки, обычно подключенного к пину 13). Разбирать этот скетч мы сейчас не будем, ибо наша цель на данном этапе - только проверка функционирования установленного софта. - Втыкаем в свободный USB разъем малинки USBAsp-программатор с уже подключенной к нему платой Arduino Pro Min. - В меню IDE Сервис/Плата выбираем Arduino Pro or Pro Mini (5V, 16MHz) w/ ATmega328. - В меню IDE Сервис/Программатор выбираем USBasp - В меню IDE Файл щелкаем по пункту Загрузить с помощью программатора и немного подождем пока программатор производит прошивку. Теперь мы можем полюбоваться на светодиодик, мигающий с частотой 0.5 Гц. Все. Программировать ардуинки при помощи малинки мы теперь умеем. Фотографии ниже показывает как это примерно должно выглядеть на практике. Ненавязчивая автоматизация ректификационной установки. Автоматика.
12. Программирование микроконтроллеров AVR. В принципе, на этом можно было бы и остановиться. Для ревизии существующего кода ненавязчивой автоматизации, уже установленного софта (т.е. - Arduino IDE) вполне достаточно. Но на этой малинке мы будем программировать и прошивать не только ардуинки. Но и микроконтроллеры AVR, которые используются в новом варианте автоматизации (которая LITE). В частности, микроконтроллеры ATMega328 и ATtiny85. Поэтому дополним эти прописи соответствующими инструментами. 12.1. Установка дополнительного инструментария. Программы для них (firmware) мы будем писать на чистом C/C++. Как и в любом Unixe, компиляторы C/C++ и другие средства разработки в Raspbian уже "встроены". Поэтому нам необходимо установить только дополнительные, специфичные для AVR, инструменты. Мы их все установим сразу одной командой из консоли:
sudo apt-get install gcc-avr avr-libc avrdude
Этой командой мы установим кросс-компилятор С/С++ для AVR (gcc-avr), библиотеку для него (avr-libc) и утилиту avrdude для прошивки микроконтроллеров. К этому инструментарию неплохо было бы добавить какой-нибудь текстовый редактор, "заточенный" для программистов. Такой редактор в Raspbian уже встроен. Это - Geany. Он поддерживает работу с проектами, есть встроенные вызовы команд, которые, кстати, легко настраивать. Geany умеет подсвечивать синтаксис для многих языков программирования, сворачивать/разворачивать блоки кода, отмечать парные скобки и еще очень много чего полезного... А если вдруг кому-то чего-то не хватит - существует большое количество плагинов, которые могут расширить функциональность Geany до уровня вполне приличной, но очень "легкой" IDE. В общем - неплохой редактор.
Ну вот, в принципе, установленных инструментов в сочетании с Geany вполне достаточно для проектов любой разумной степени сложности.
12.2. Проверочный макет. После установки инструментария, необходимого для программирования МК AVR, желательно все-таки проверить его работоспособность. Для этого мы изготовим небольшой проверочный макет. Поскольку разработка варианта LITE начиналась с силовых модулей (электронных ключей) и датчика RMS с детектором нуля, в основе которых лежит маленький (но довольно "удаленький"! ;) микроконтроллер ATtiny85, то макет мы сделаем именно на этом МК. Если такового нет под рукой, можно поставить ATtiny45. Или ATtiny25. Или вообще любой МК из семейства AVR. Только не забудьте внести соответствующую коррекцию в команды, о которых речь пойдет ниже.
Схема макета и вариант его исполнения на макетной плате, не требующей пайки, представлена на следующем рисунке. Ненавязчивая автоматизация ректификационной установки. Автоматика. Схема предельно проста: сам микроконтроллер ATtiny85, пара конденсаторов по питанию, подтягивающий резистор R1 для пина "Reset", 6-пиновый ISP-разъем и светодиодик с ограничивающим резистором, подключенный к пину 3 порта B микроконтроллера. ISP означает In-System Programming - внутрисхемное программирование. В этом случае МК программируется на месте (т.е. уже вставленным/спаянным в рабочую схему). Во время внутрисхемного программирования на пин Reset подается низкий уровень. В этом случае МК переходит в режим программирования, все его ноги (кроме MISO, MOSI и SCK) переходят в высокоимпедансное состояние (т.е. как бы отключаются от внешнего мира). А в обычном (рабочем) состоянии МК на пине Reset должен быть высокий уровень. Для этого резистор R1 как раз и поставлен. Конденсаторы C1 и C2 выполняют роль фильтров. Т.е. сглаживают пульсации по питанию. Конденсатор C1 нужно располагать как модно ближе к ножкам питания МК. Он служит для компенсации высокочастотных провалов по питанию, например, когда нагрузка на пины-выходы МК возрастает. Светодиодиком мы будем мигать. Такие тесты - это своего рода "Hello world!" для программистов микроконтроллеров.
12.3. Теперь собственно настройка и проверка инструментария для программирования МК AVR по шагам. 12.3.1. Итак, проверочный макет у нас собран. Подключаем к нему USBasp-программатор и подключаем программатор к свободному USB-разъему малинки. 12.3.2. В нашей домашней директории (/home/pi) создаем рабочую папку wrk и в ней папку test_01. Это будет рабочая папка нашего первого теста. Содать папки можно либо в файловом менеджере или из консоли. В последнем случае попросим малинку так:
mkdir -p wrk/test_01
Здесь флаг -p указывает, что, если папки wrk нет, то ее нужно тоже создать. 12.3.3. В главном меню выбираем пункт Программирование и в подменю щелкаем по пункту Geany. Открывается окно Geany. 12.3.4. Настроим Geany на работу с кросс-компилятором AVR и "прошивалкой" avrdude. Для этого в меню Geany Сборка щелкаем по пункту Установить команды сборки. Откроется диалоговая панель в которой мы должны определить команды компиляции и прошивки. В двух верхних окнах редактирования (Команда) введите следующие две команды:
Разбирать мы их сейчас не будем - наша задача проверка инструментария. Только кратко суть. Первая команда составная. Сначала производится компиляция исходного текста кода. В случае успеха, на основе объектного файла формируется hex-файл, при помощи которого avrdude и будет прошивать микроконтроллер. А вторая команда - это, собственно, и есть команда прошивки микроконтроллера. После редактирования всех нужных полей этого диалога, должно получиться то, что изображено на скриншоте ниже.
Ненавязчивая автоматизация ректификационной установки. Автоматика. Для редактирования подписей на кнопках - щелкните по ним и введите нужное в появившемся диалоге. Когда все готово - закрываем диалог (OK). В меню Сборка мы увидим два пункта меню Компилировать F8 и Прошить МК F9, которые станут активны, когда мы напишем тестовую программу. Чем мы сейчас и займемся. 12.3.5. Набираем текст тестовой программы. Тут комментировать нечего - набираем в окне редактора следующий текст:
#define F_CPU 1000000UL // Заводские установки тактовой частоты - 1 МГц // Это опредение нужно для корректной работы // функции _delay_ms() #include <avr/io.h> #include <util/delay.h>
int main(void) { DDRB |= 0b00001000; // Пин 3 - на вывод while(1) { // Бесконечный цикл PORTB |= 0b00001000; // Пин 3 - на верхний уровень _delay_ms(1000); // Задержка 1 сек PORTB &= 0b11110111; // Пин 3 - вниз _delay_ms(1000); // Опять задержка 1 сек } return 0; }
Все комментарии - в тексте. Тест простейший: тинька будет мигать светодиодиком, подключенным к пину 3. Выглядеть все должно примерно так, как показано на скриншоте ниже. Ненавязчивая автоматизация ректификационной установки. Автоматика. 12.3.6. Сохраняем текст в нашей, ранее созданной папке wrk/test_01 под любым именем с расширением ".c", например, main.c и запускаем компиляцию и сборку hex-файла. Здесь три варианта на разный вкус: 1) меню Сборка/Компилировать, 2) на клавиатуре - F8 3) просто щелкнуть по кнопке с изображением пирамидки с шариком на инструментальной панели. Если текст теста набран без ошибок, Geany об этом доложит и в рабочей папке появятся объектный файл main.o и hex-файл main.hex. Проверьте на всякий случай. Если Geany ругнулся - поправьте файл (или команды, см.выше) и повторите попытку. 12.3.7. Наконец, прошиваем МК. Здесь тоже три варианта: 1) меню Сборка/Прошить МК, 2) на клавиатуре - F9 3) щелчок по кнопке с изображением коричневых боксиков на инструментальной панели. На программаторе во время мы видим наблюдаем мигание светодиодиков. После небольшой паузы любуемся размеренным миганием светодиода на макетке.
Сделал всё строго пошагово...gol_avto, 11 Дек. 17, 10:51
Значит не все строго сделали, т.к. запускается совсем другой компилятор - gcc, а не кросс-компилятор gcc-avr. См. Ваш же скриншот во вложении. Проверьте настройки Geany (пункт 12.3.4.). У Вас все как на моей картинке в этом пункте? PS Для проверки попробуйте откомпилировать "ручками" в консоли. Последовательность команд:
Исходный файл main.c, естественно, команды нужно давать в той папке, где находится main.c Если скомпилиуется и прошьется нормально, то точно косяки в настройках Geany.
Но это в Москве, хотя доставку делают. Тут много что для нас можно найти... К примеру, http://prodiel.ru/index.php?cat=156 - "нержавая" трубка по метрам.
Может что и рядом найдешь. Вообще я сам нарезал отрезным резцом на токарном из нержавеющего болта. Тонкий калибр не стал делать, но толщиной 0,5мм получилось. Отверстие калиброванное, заранее, перед резом, сверлил, на 0,8. Тоньше не получилось. Но, по факту - муторно... станок большой, ювелирные работы трудное делать. После отреза, шлифовал на тонкой наждачке ручками, пока не сравнял все заусенцы от сверления.
Добавлено через 1дн. 19ч. 30мин.:
OldBean, я тут с GPIO мудрю... Может на базе температурного сервера замутить? Аж 8 линий логического ввода можно запилить. А надо ли столько? Кроме трех датчиков, датчика протечки, аварийное давление в кубе и уровня в приемной посуде, ни чего в голову не приходит. А если это так, то и Тиньки достаточно. Что по этому поводу думаешь?
OldBean
Доцент
Красноярск
1K 1.4K
Отв.879 13 Дек. 17, 16:27
я тут с GPIO мудрю... Может на базе температурного сервера замутить? Аж 8 линий логического ввода можно запилить. А надо ли столько? Кроме трех датчиков, датчика протечки, аварийное давление в кубе и уровня в приемной посуде, ни чего в голову не приходит. А если это так, то и Тиньки достаточно.BogAD, 11 Дек. 17, 14:08
BogAD, я не сторонник тотальной автоматизации. Я сторонник ненавязчивой автоматизации. Т.е. - когда автоматизируются только те функции, ручное выполнение которых либо затруднительно, либо сильно раздражает, либо приводит к ухудшению качества продукта. Поэтому я скорее поставлю 10-литровую бутылку на прием тела, чем буду лепить какой-нибудь датчик уровня к 3-литровой банке, интерфейс к нему и соответствующий софт.
Но, тем не менее, универсальные "модульки" (Arduino Pro Mini + 7-сегментный показометр + I2C-интерфейс) вполне решают все эти задачи и, в принципе, позволяют наращивать мощность системы автоматизации до любого разумного (и неразумного) уровня. Поэтому, ИМХО, добавлять вариант модулька на тиньке, особого смысла нет. Особого выигрыша в цене не будет а "разношерсность" повысится ;).
Кстати, недавно "перешаманил" и дописал новый, более-менее универсальный, базовый скетч модулька. Скетч поддерживает разные типы индикаторов (с общими катодами или анодами), любая разрядность (до 4 разрядов), двухбайтовый протокол обмена по I2C (точнее - 14 битный) с "мастером", разные варианты впайки индикатора (как раньше и по-новому - на самом краю ардуинки). Вот как раз сегодня запустил бесконечный тест (двухбайтовые обмены между малинкой и модульком; туда-сюда в цикле). Пусть погоняется тест пару-тройку суток. Посмотрим статистику отказов. Может, все-таки, удастся "зафиксить" проблему с I2C "малой кровью". Пока, примерно за пол-суток непрерывной работы, еще ни одной ошибки не было.
