Comments 16
количество проводов от пульта можно было бы сократить до двух, если воспользоваться voltage ladder (кнопки перемежаются резисторами разных номиналов, аналоговым входом контроллера вы определяете, какой по счёту кнопкой замкнуло цепи).
Светодиод в пульте не ослепляет? Может быть, стоило взять вместо него вибромоторчик как в сотовом телефоне?
Светодиод в пульте не ослепляет? Может быть, стоило взять вместо него вибромоторчик как в сотовом телефоне?
Ну, наверное все такие до 5? Кнопки + светодиод + потенциометр + 5V + GND?
В общем можно конечно, но я не инженер, сам не догадался, а подсказали уже когда схему вчистую отрисовывал :)
Еще позже узнал про I2C, тогда было бы всего 4 провода. Сейчас активно применяю в другом проекте. Но тогда пришлось бы в пульт ставить что-то подобное. Телефонный кабель и разъемы RJ11.
Про сведиод — с нашим светлым небом и паразитной засветкой — не особо, хотя я уже подумывал его ограничить. Не обязательно выводить светодид на полную мощность. По большому счету, он нужен только для того, чтобы беря пульт в руки понять на какой я скорости, дабы не крутануть случайно фокусер при точном доведении. По этой же причине не представляю как мне поможет вибромоторчик — узнать скорость желательно не трогая ни кнопки, ни ручку потенциометра.
В общем можно конечно, но я не инженер, сам не догадался, а подсказали уже когда схему вчистую отрисовывал :)
Еще позже узнал про I2C, тогда было бы всего 4 провода. Сейчас активно применяю в другом проекте. Но тогда пришлось бы в пульт ставить что-то подобное. Телефонный кабель и разъемы RJ11.
Про сведиод — с нашим светлым небом и паразитной засветкой — не особо, хотя я уже подумывал его ограничить. Не обязательно выводить светодид на полную мощность. По большому счету, он нужен только для того, чтобы беря пульт в руки понять на какой я скорости, дабы не крутануть случайно фокусер при точном доведении. По этой же причине не представляю как мне поможет вибромоторчик — узнать скорость желательно не трогая ни кнопки, ни ручку потенциометра.
На базе тех же компонентов сделал себе пуль для монтировки, вместо сгоревшего: фото, теперь вот задумался об электрофокусере.
Я сейчас сталкиваюсь ежедневно с arduino, и наконец-то могу выразить, чем же она плоха. Как модуль — отличная штука с завышенной ценой. Но вот коммунити — это ужас. Ужасные схемы, ужасные алгоритмы. Причем, люди учатся по урокам таких же новичков как и они сами и еще больше вырождаются. А полноценный С/С++ еще и позволяет без труда стрелять в ногу.
Для попробовать свои силы — штука отличная, а если бы в моем детстве была подобная плата — я был бы самым счастливым ребенком. Но никто же в серьез не думает, что можно, например, жить в доме построенном из конструктора Lego.
Это предисловие, которое объяснит мысль: если вам понравилось, и хочется продолжать — попробуйте сделать что-нибудь, на той же arduino uno, но без использования библиотек arduino. Сначала AVR покажется кучей непонятных регистров, но очень быстро придет понимание самого контроллера, и вот тогда можно будет делать потрясающие вещи. Даже готов лично объяснить непонятные моменты, если возникнет необходимость.
Для попробовать свои силы — штука отличная, а если бы в моем детстве была подобная плата — я был бы самым счастливым ребенком. Но никто же в серьез не думает, что можно, например, жить в доме построенном из конструктора Lego.
Это предисловие, которое объяснит мысль: если вам понравилось, и хочется продолжать — попробуйте сделать что-нибудь, на той же arduino uno, но без использования библиотек arduino. Сначала AVR покажется кучей непонятных регистров, но очень быстро придет понимание самого контроллера, и вот тогда можно будет делать потрясающие вещи. Даже готов лично объяснить непонятные моменты, если возникнет необходимость.
Спасибо большое за развернутый комментрий!
У меня просто пока эйфория от того, как все легко и просто получается :) Я лет 20 жил в виртуальном компьтерном мире (лет 10 работал прикладным программистом) и представить себе не мог, что смогу программировать на привычном С++ предметы реального мира :)
Да, я согласен с тем, что качество многих примеров, решений и библиотек оставляет желать лучшего и уж точно не может быть использовано в промышленном масштабе — сам натыкался на перепосты типа «библиотеку можно взять вот эту, но примеры там не рабочие» :) То есть не то чтобы не оптимальные, а вообще не рабочие! :)
С другой стороны, это же хобби :) Сообщество «не профессионалов».
Хотя, к слову о доме из лего, вот вопрос безопасности собственного дома меня очень беспокоит. Следующий проект — оранжерея для жены. Она будет работать 7х24. Там кроме пары десятков датчиков, еще и управление светом, а это 6 ЭПРА и нехилое тепловыделение. В общем, немного стремно. Буду с кем-нибудь консультироваться.
По поводу прямого программирования AVR — мне когда-то приходилось программировать на асме под 386/486, так что не думаю что меня AVR испугает. За совет и предложение спасибо — буду иметь ввиду! :) Пока у меня есть только одна проблема, которая поддталкивает к этому шагу. В дгуром проекте мне критически важно конролировать время выполнения опреция, Loop не должен быть дольше 130 микросекунд. И все бы хорошо, если бы не Serial — любая посылка — это 200-300 микросекунд. Причем, не важно какая выставлена скорость порта, сколько байт я пересылаю — 260-280 микромсекунд, если ничего не путаю. Подскажите куда двигаться?
PS Честно говоря, я тоже не очень то страдал перфекционизмом, когда работал над этим проектом, и код там еще чистить и чистить :)
У меня просто пока эйфория от того, как все легко и просто получается :) Я лет 20 жил в виртуальном компьтерном мире (лет 10 работал прикладным программистом) и представить себе не мог, что смогу программировать на привычном С++ предметы реального мира :)
Да, я согласен с тем, что качество многих примеров, решений и библиотек оставляет желать лучшего и уж точно не может быть использовано в промышленном масштабе — сам натыкался на перепосты типа «библиотеку можно взять вот эту, но примеры там не рабочие» :) То есть не то чтобы не оптимальные, а вообще не рабочие! :)
С другой стороны, это же хобби :) Сообщество «не профессионалов».
Хотя, к слову о доме из лего, вот вопрос безопасности собственного дома меня очень беспокоит. Следующий проект — оранжерея для жены. Она будет работать 7х24. Там кроме пары десятков датчиков, еще и управление светом, а это 6 ЭПРА и нехилое тепловыделение. В общем, немного стремно. Буду с кем-нибудь консультироваться.
По поводу прямого программирования AVR — мне когда-то приходилось программировать на асме под 386/486, так что не думаю что меня AVR испугает. За совет и предложение спасибо — буду иметь ввиду! :) Пока у меня есть только одна проблема, которая поддталкивает к этому шагу. В дгуром проекте мне критически важно конролировать время выполнения опреция, Loop не должен быть дольше 130 микросекунд. И все бы хорошо, если бы не Serial — любая посылка — это 200-300 микросекунд. Причем, не важно какая выставлена скорость порта, сколько байт я пересылаю — 260-280 микромсекунд, если ничего не путаю. Подскажите куда двигаться?
PS Честно говоря, я тоже не очень то страдал перфекционизмом, когда работал над этим проектом, и код там еще чистить и чистить :)
Подскажу конечно, двигаться на прерывания. Если знаете asm — то, должно быть знаете, что это за штука. Но поясню на всякий случай. При общении с любым блоком периферии (будь то ADC, UART и еще много какой) могут генерироваться прерывания, это когда процессор бросает текущую задачу и отправляется выполнять код связанный с произошедшим событием. В AVR с этим все очень неплохо. Например, что касается Serial или модуля UART — он полностью аппаратный, и пока передатчик выплевывает биты в компьютер — вы можете заниматься своими делами. Сама отправка очередного байта в UART- занимает единицы тактов, ну может пару десятков, если требуется как-то хитро достать из памяти. На скорости в 16МГц — это 1-2 микросекунды, обычно меньше. Но тут опять же мешает реализация библиотеки Serial на arduino.
Обычно алгоритм такой — вместо serial.write() данные записываются в некий буфер, и отдается команда начать передачу, после этого управление возвращается обратно в код и вы продолжаете заниматься полезной работой, как только передатчику UART требуется новый байт — он генерирует соответствующее прерывание и обработчик этого прерывания отправляет ему следующий байт и тут же выходит. Для основного цикла программы это происходит прозрачно. Тоже самое происходит и с приемом данных: как только получен новый байт данных — генерируется прерывание и его обработчик решает, что с этим байтом делать.
P.S. на самом деле не обязательно писать на ассемблере. Это очень полезно, в рамках обучения, но довольно сложно. Тем более, если имеется огромный опыт C++, глупо не было бы не воспользоваться. Arduino IDE использует тот же самый и самый распространенный компилятор gcc-avr, просто библиотека libarduino (или как она правильно называется) делает некий HAL. Но лишняя абстракция на кристалле в котором нет ни памяти, ни ресурсов вызывает больше проблем, чем пользы.
Кстати, для Eclipse есть вполне рабочий плагин для AVR. И все плюшки, например автодополнение. А еще некоторое чипы, например atmega16 позволяют проводить отладку на кристале, с breakpoint, просмотром/изменением регистров, памяти. И это еще далеко не все печеньки, которыми заманивают на правильную сторону.
Обычно алгоритм такой — вместо serial.write() данные записываются в некий буфер, и отдается команда начать передачу, после этого управление возвращается обратно в код и вы продолжаете заниматься полезной работой, как только передатчику UART требуется новый байт — он генерирует соответствующее прерывание и обработчик этого прерывания отправляет ему следующий байт и тут же выходит. Для основного цикла программы это происходит прозрачно. Тоже самое происходит и с приемом данных: как только получен новый байт данных — генерируется прерывание и его обработчик решает, что с этим байтом делать.
P.S. на самом деле не обязательно писать на ассемблере. Это очень полезно, в рамках обучения, но довольно сложно. Тем более, если имеется огромный опыт C++, глупо не было бы не воспользоваться. Arduino IDE использует тот же самый и самый распространенный компилятор gcc-avr, просто библиотека libarduino (или как она правильно называется) делает некий HAL. Но лишняя абстракция на кристалле в котором нет ни памяти, ни ресурсов вызывает больше проблем, чем пользы.
Кстати, для Eclipse есть вполне рабочий плагин для AVR. И все плюшки, например автодополнение. А еще некоторое чипы, например atmega16 позволяют проводить отладку на кристале, с breakpoint, просмотром/изменением регистров, памяти. И это еще далеко не все печеньки, которыми заманивают на правильную сторону.
Ага, очень интересно! То есть в общих словах, от Serial полностью не отказываемся, но вместо метода Serial.write() инициируем отправку напрямую через UART, отдавая данные через обработчик прерывания, так?
О, еще вопрос вспомнил! :)
Мне нужно очень точно измерять время в микросекундах. Пишут, что встроенные методы типа micros() не точные, особенно если МК сильно загружен (как раз мой случай, подозреваю). Попробовал RTC на DS3231 и DS1307. Все бы хорошо, но библиотеки, что мне удалось найти выдют время с точностью до секунды, а мне нужны микросекунды. Как раз сооружаю стенд, чтобы понять на сколько часы ардуино не точные по сравнению с RTC. И видится мне пока только один «штатный» путь — засинхрить ардуионвские часы с RTC и надеяться, что micros() от этого станет работать точнее (правда как проверить — не придумал). Куда посоветуете двигатья?
О, еще вопрос вспомнил! :)
Мне нужно очень точно измерять время в микросекундах. Пишут, что встроенные методы типа micros() не точные, особенно если МК сильно загружен (как раз мой случай, подозреваю). Попробовал RTC на DS3231 и DS1307. Все бы хорошо, но библиотеки, что мне удалось найти выдют время с точностью до секунды, а мне нужны микросекунды. Как раз сооружаю стенд, чтобы понять на сколько часы ардуино не точные по сравнению с RTC. И видится мне пока только один «штатный» путь — засинхрить ардуионвские часы с RTC и надеяться, что micros() от этого станет работать точнее (правда как проверить — не придумал). Куда посоветуете двигатья?
Да именно так, причем все это скорее всего можно сделать из Arduino IDE.
По второму вопросу:
Если требуется считать события длительностью в единицы микросекунд — тогда надо точнее всю задачу, если просто получить время с точностью до микросекунды между двумя какими-то событиями (например между импульсами с DS1307) — заводим таймер, прерывания от него приходят через строго определенное время, плюс есть непосредсредственный доступ к регистру счетчика таймера.
Т.е. по стартовому событию, запускаем таймер, и начинаем считать прерывания от него и ждем стоп. Как только приходит стоп, сохраняем значение счетчика таймера (в нем будут недосчитанные тики), и добавляем к нему количество посчитанных прерываний ну и перемножаем на соответсвующие коэффициенты. Таким образом можно получить точность в 1 такт или (примерно) 62.5 наносекунды на 16МГц, если заморочиться. Примерно, потому что частота кварца тоже плавает и без калибровки результаты будут в попугаях.
По второму вопросу:
Если требуется считать события длительностью в единицы микросекунд — тогда надо точнее всю задачу, если просто получить время с точностью до микросекунды между двумя какими-то событиями (например между импульсами с DS1307) — заводим таймер, прерывания от него приходят через строго определенное время, плюс есть непосредсредственный доступ к регистру счетчика таймера.
Т.е. по стартовому событию, запускаем таймер, и начинаем считать прерывания от него и ждем стоп. Как только приходит стоп, сохраняем значение счетчика таймера (в нем будут недосчитанные тики), и добавляем к нему количество посчитанных прерываний ну и перемножаем на соответсвующие коэффициенты. Таким образом можно получить точность в 1 такт или (примерно) 62.5 наносекунды на 16МГц, если заморочиться. Примерно, потому что частота кварца тоже плавает и без калибровки результаты будут в попугаях.
По работе с СОМ-портом — грубыми мазками все понятно, буду разбираться с UART`ом. Большое спасибо!
По поводу точного отсчета времени тоже вроде все понял. Мне нужно достаточно точно контролировать скорость вращения ШД на низкой скорости. Там, где это действительно важно — скорость достаточно низкая, я делаю примерно 50 шагов в секунду. В приципе, мне даже микросекундная точность не нужна, достаточно миллисекундной. Но RTC дает только целые секунды (в тех библиотеках, что я нашел), поэтому «влоб» перейти с micros() на RTC не получается. В общем, идея понятна — привязываюсь к RTC, а между импульсами с него считаю время описанным вами методом по прерывания. Тут конечно вопросы еще будут :) Спасибо, буду разбираться!
По поводу точного отсчета времени тоже вроде все понял. Мне нужно достаточно точно контролировать скорость вращения ШД на низкой скорости. Там, где это действительно важно — скорость достаточно низкая, я делаю примерно 50 шагов в секунду. В приципе, мне даже микросекундная точность не нужна, достаточно миллисекундной. Но RTC дает только целые секунды (в тех библиотеках, что я нашел), поэтому «влоб» перейти с micros() на RTC не получается. В общем, идея понятна — привязываюсь к RTC, а между импульсами с него считаю время описанным вами методом по прерывания. Тут конечно вопросы еще будут :) Спасибо, буду разбираться!
спасибо за подробное изложение.все никак не закончу свой драйвер на stm32 для тал125, а самодельный фокусер считал слишком сложным в механике, ибо я даже редуктору шестерни еле нашел
Если цена вопроса не критична, то
можно просто через RS232 или USB с писюка рулить шаговиком.
Например типа вот такой коробочки:
onitex.ru/solutions/stepmotor/kontroller-shagovogo-dvigatelya/osm-17u
Со всем перечисленным функционалом.
можно просто через RS232 или USB с писюка рулить шаговиком.
Например типа вот такой коробочки:
onitex.ru/solutions/stepmotor/kontroller-shagovogo-dvigatelya/osm-17u
Со всем перечисленным функционалом.
Sign up to leave a comment.
Электрофокусер на базе отладочной платы Arduino Uno, часть 2