Как говорится -- на любой Ваш вопрос, любой наш ответ

---

PS по молодости я освоил, что все болезни от систематического недопивания

Редактировалось 2 раз(а), последний 2016-12-26 12:25:01

фуф, ну с Новым годом всех!
По молодости у меня даже сомнения не возникло бы, в чем причина всех болезней, а сейчас уж лет как 15 не уверен что в этом..
Не знаю у кого спросить, я тут за праздники пока болел собрал простенький контроллер шагового двигателя, сегодня проверил первой попавшейся терминальной программой, а теперь встала задача управлять шаговым движком через com-порт, и естественно на HiAsm. Посмотрел, а у нас аж целых три компонента com порта, у всех разные авторы и даже не знаю, какой из этих компонентов лучше подходит для таких задач.
Контроллер AVR, пока это ATtiny2313, потом будет скорее всего Mega8, у тиньки ног маловато, а движков будет два или три Galkov, я знаю Вы давно занимаетесь такими разработками на контроллерах, ну подскажите пожалуйста, какой компонент в данном случае больше подойдет? И если можно, то с маленьким примером. Конечно, если кто то еще что то подскажет, я также буду благодарен. Вот мой чудо-контроллер, пока не айс, зато работает

Пока ничего не скажу. Потому-что не использовал COM-порт.
Поскольку, вопрос связи с "внешним миром" был для меня решен, и мне этого хватало.
Как я отмечал выше, у меня есть контроллер Atmega8, подключенный своим портом B к шине данных LPT-порта.
То, что подключен контроллер, придает этому устройству дикую универсальность: его можно перепрограммировать не вытаскивая разъемов, в него можно зашить много программок для разных режимов, и т.п..
У меня были прошиты режим программатора, интерфейс TWI, интерфейс некого самопального отладчика.

Все великолепно, кроме одного - у меня уже нет LPT-порта. Аналогичным образом, это же происходит у моих коллег на производстве (выше я говорил про это).
Поэтому, я уже собрал небольшой девайс, подключаемый к USB. Там примерно такой каскад: FT232RL => (гальваноразвязка NME0505DC) + (опторазвязка ADUM1301ARW) => контроллер ATmega164PA-AU => (пара разъемов BH-16R) + (гальваноразвязанный драйвер для 485-го интерфейса ADM2587EBRWZ).

Это дело ждет уже отладки, и последующего воспроизводства.
Думаю, не раньше, чем через пару месяцев, я это закончу (мне еще силовые части для приводов рисовать).
Вот тут я и разберусь, какой элемент мне лучше подходит... Чего в нем хорошо, чего в нем плохо, а чего в нем не хватает.
Ничего военного, я думаю: обвязка над winapi, однако.

Скорее всего, будем вести беседу с коллегой nesco о доработке (если понадобится) его элемента

У меня тоже уже давно как нет LPT-портов, поэтому и решил использовать Com-порт.
Виртуальные com порты есть в любом компьютере, и нам я думаю на наш век их хватит.
Нужен только правильный переходник USB-UART. Я сначала тоже хотел сам собрать такой переходник, потом случайно наткнулся на инфу, что народ в этом случае использует Data-кабель от сотовых телефонов. Полез по сусекам, а они и у меня оказались лежали и ждали своего часа. Этот кабель дает правильные ТТЛ-уровни, тоесть то, что нам для контроллера и надо. У меня сейчас кабель SonyEricsson K700i. Единственное, пришлось повозиться, найти выходы GND RX и ТХ на выходе из кабеля. В инете ухекался искать распиновку этого кабеля
Пришлось методом тыка и прозвонки
Подключил напрямую в контроллер на ножки RX и ТX.
А компонент COMEX от nesco я вчера вечером уже проверил. На реальном устройстве все прекрасно передается. Проверить COMEX во всех режимах еще не успел, но пока все устраивает.

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

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

2amateur

Найти просто Rx и Tx - для меня это слишком мелкая задача. Чтобы разводить и изготавливать девайс.
Меня интересует универсальное устройство. Чтобы я мог закрыть все свои (даже гипотетические) проблемы как бы "на всю оставшуюся жизнь".

Например, тот же программатор для AVR-ок. Так у меня MOSI, MISO и SCK уже сидят на разъеме. Еще один под RST - так у меня там почти все ноги контроллера выведены.
Нужен будет (в смысле - уже сегодня нужен) I2C - так он уже есть у меня (SCL и SDA)
Нужен будет 1W (скажем, измерить много температур на DS18S20) - эмулировать придется, но нет особых проблем.
COM-порт - так он есть у меня (в Atmega164 - два UART-а)
Измерить чего-нибудь аналоговое (скажем, температуру полупроводниковыми терморезисторами) - так 8 аналоговых входов есть у меня.

Даже MODBUS... Ну видел я покупные конвертеры USB/RS485. Так их лохи делали, как оказалось. Они переключают драйвер на прием уже по началу передачи стоп-бита. Передатчик драйвера должен держать жесткую единицу как минимум один символ ДО и один ПОСЛЕ пакета. Это даже не вопрос стандартов (с которыми у них тут тоже проблемы), а элементарного знания физики...

А у меня теперь с этим нет принципиальных проблем: как надо, так и сделаю. Поскольку "Большой Брат" понятия не имеет о Real Time, то наиболее логичным, видимо, будет конвертер MODBUS-ASCII/MODBUS-RTU. Atmega164 на это вполне хватит.

---

В общем, как-то так.

Редактировалось 1 раз(а), последний 2017-01-08 13:19:49

Galkov, а можно поинтересоваться чисто из любопытства. Вы, когда дело касается разработок на AVR контроллерах - какими инструментами пользуетесь? Я имею ввиду среду разработки, язык программирования, отладчики, симуляторы ну и все такое? Мне правда просто любопытно стало, что используют профессионалы.
Я то так, любитель, это для меня скорее хобби, правда свербячка с этим хобби уже давно как началась и пока не заканчивается

Для AVR-ок:

Среда разработки - "Algorithm Builder"
Соответственно, язык программирования - ассемблер.
Без отладчиков и симуляторов - пока обходился.
Программатор - свой (писал про это).

Ага, понятно. Я как то глянул на этот Algorithm Builder и понял, что это не просто "вырви глаз", а вырви оба. Я столько травы не выкурю.., шучу, траву не курю Хотя, кому то может и HiAsm таким же представляется.
Я тоже пишу на ассемблере, точнее не совсем пишу, а рисую.. Как то наткнулся на туториал от Netspirit по FTCG и решил попробовать. Сначала не очень получалось, код компонентов писать получилось с самого начала, а вот соблюсти структуру ассемблерной программы для контроллера, никак не получалось. А потом однажды видимо не с той ноги с утра встал, и все пошло. Для себя я этот пакет справочником по ассемблеру называю, достало каждый раз лезть в даташиты, смотреть какой бит в каком регистре я забыл выставить, ну и ессно с возможностью трансляции кода компонентов в ассемблерный код. И честно говоря, ни разу не пожалел что потратил на него время. Показывать пока правда особо нечего, может чуть позже, когда чпу станочек на нем полностью будет написан(нарисован). Кстати, в том видео что чуть выше код контроллера шагового двигателя честно нарисован только в этом пакете, без ручной правки кода. Правда там ничего особенного то и нет.

Хоть один глаз вырывай, хоть оба, а цитату с сайта автора (algrom.net):-- я подтверждаю.

HiAsm, с позиций визуализации - гораздо круче.
Но, к сожалению, у нас нет эффективной технологии компиляции (генерации кода), подходящей для embeded.
Вот я вам приводил решаемую (в смысле - давно решенную) мной задачу:Вообще-то, это всего 1000 тиков проца. Укладываться надо в 700 (есть еще и прерывания по I2C, и задача по синхронизации модулей). А вычислять приходится 12-параметрическое управление (ПИД-регулятор по скорости, плюс интеграл по координатной ошибке. Это, что касается Feed Back параметров регулирования. Есть еще и Feed Forward параметры).

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

Редактировалось 1 раз(а), последний 2017-01-09 16:26:20