Вопросы от начинающих по МК

[my504]

При прошивке микрочиповских контроллеров они тактируются по входу ICSPCLK (PGC), поэтому никаких кварцев на них вешать не нужно.

Алексею. Вообще то с 18-х все только начинается... А при письме на Си всякие "ньюансы" младших семейств не существенны...

90

[Реклама]

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

[Alexeyslav]

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

На Си писать для мелких контроллеров - кощунство... потом люди жалуются что простейшая программа "не влазит" в память контроллера.

[Реклама]

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

[my504]

ICSPCLK - это все, что нужно для тактирования контроллера в режиме программирования. Ничего более.

В отличие от атмелов, у пиков используется полноценный и полнофункциональный интерфейс программирования-отладки ВСЕГДА. А у АВР в основном используют обычный последовательный интерфейс и лишь при полнофункциональном параллельном программировании реализуется в том числе и отладка камня.

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

[Реклама]

Выбираем схему BMS для корректной работы литий-железофосфатных (LiFePO4) аккумуляторов

 Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ, также как и для других, очень важен контроль процесса заряда и разряда, а специализированных микросхем для этого вида аккумуляторов не так много. Инженеры КОМПЭЛ подготовили список имеющихся микросхем и возможных решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[Alexeyslav]

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

[my504]

Производительность??? Да Вы о чем??? :lol:

В 99,99% случаев максимальная частота системы вообще не нужна. Народ вешает 20 МГц кварц просто так, совершенно не понимая для чего.

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

Но даже если это напрягает, то всегда можно перейти на 18-ые, цена на которые едва ли не ниже, чем на 16-ые. А в 12-х вопрос с адресацией ОЗУ вообще не актуален из-за специфики задач для малоногих контроллеров.

Вы, Алексей, просто не в теме...

По поводу отладчика я вообще не понял... Отладчик (дебаггер) - это РЕАЛЬНЫЙ живой контроллер с возможностью останова по брекпойнтам или пошаговым исполнением и просмотром всех внутренних регистров, включая даже те, которые не доступны программно. Ничего более натурального придумать невозможно. Протеус вообще не способен симулировать реальные сигналы. И дело тут даже не в моделировании, а в нашем незнании КАКОЙ это будет сигнал. О симуляции сложных интерфейсов или не имеющих готовых моделей внешних устройств я уже молчу... Кроме того, такой инструмент, как DMCI в МПЛАБе позволяет видеть в отладке данные в ОЗУ, как диаграмму-график, и на ходу управлять переменными. Это исключительный для написания сложных алгоритмов инструмент...

Чрезвычайно странный у Вас взгляд на проектирование МК устройств... Это все катит только для часов-частотомеров-термометров.

Изменено 27 ноября, 2011 пользователем my504

[Alexeyslav]

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

[kvlads]

Уважаемые умельцы, помогите барану в МК. Как с помощью CodeVisionAVR зашить в камень HEX файлы? Заранее благодарен.

[my504]

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

Да нет, как выясняется не вполне в теме...

Это не отладчик, это СИМУЛЯТОР. Разница весьма существенная...

Спроектировать без дебага (аппаратного внутрикристалльного отладчика) НИКАКУЮ серьезную схему невозможно. Как бы аккуратно не писать алгоритм и код. Об этом я ранее и писал.

Это происходит от частичной или полной неопределенности сигналов. Это происходит из-за ограниченных сведений о периферии (особенно если это НОВЫЕ приборы, с которыми нет опыта использования).

Изменено 27 ноября, 2011 пользователем my504

[Alex]

Как с помощью CodeVisionAVR зашить в камень HEX файлы?

Вообщето, hex зашивают с помощью программаторов.

Вам сюда.

[Alexeyslav]

Если использовать дебагер в разработке это дает ложную уверенность что все будет работать. Дебагер нужен только в особо сложных случаях. Для остальных случаев достаточно симулятора.

Спроектировать без дебага НИКАКУЮ серьезную схему невозможно.

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

[my504]

Цифровую и/или аналоговую схему и раньшеи сейчас разрабатывают с помощью разнообразных приборов. Только раньше сразу после расчета паяли схему, а сейчас сначала смотрят симулятором по частям или все вместе.

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

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

[Alexeyslav]

Обойтись без него нельзя, но использовать его при разработке устройства - плохой тон.

Зачем ведь отладчик нужен? Чтобы искать ошибки. Искать ошибки проектирования при помощи отладчика - это плохая работа. А вот искать ошибки в реализации алгоритмов, ну там регистр не тот использовал, банк забыл переключить - такие ошибки позволяет выявить отладчик. Или убедится что все работает правильно. Впрочем, всего этого можно избежать - просто быть предельно внимательным. Но правда, какая же внимательность когда постоянно торопят и ставят дедлайн вчерашним числом... вот и становится отладчик инструментом с которым проводишь 90% времени.

[my504]

Алексей. Вы вообще говорите не о том. Отладка - это не толькои не столько поиск ошибок, это РАЗРАБОТКА алгоритма и программы. Даже теоретически невозможно расписать алгоритм сигнального обнаружителя, когда нет достоверных сведений о сигнале и сигнальные дампы нужно просто накопить опытным путем. Кроме того, в синхронных системах так же невозможно достоверно просчитать все временные интервалы. Только опытным путем возможно обнаружить в РАЗУМНЫЕ сроки возможные баги совместной работы нескольких процессов.

В процессе отладки возникают НОВЫЕ ИДЕИ по обработке в результате анализа промежуточных состояний.

Даже простые ошибки , которых НИКОГДА не избежать, просто и быстро выявляются именно дебагом. Теоретическое пожелание быть внимательным не стоит ломаного гроша, посколько в программе объемом в пару десятков килослов завсем не уследишь, как ни старайся. Есть сложные логические построения и разрешить их корректно через дебаг много быстрее и проще. Заниматься мазохизмом и вчислять баги через вывод маркеров на пины может только глубокий любитель от огромного и извращенного желания.

И вообще. Зачем терять драгоценное время от слепых методов, когда есть простой и надежный инструмент???

[Alexeyslav]

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

Очень странно, как это нет достоверных сведений о сигнале? а тогда что должна делать разрабатываемая программа? Нет техзадания - отсюда и всевозможные сложности по воплощению проекта. Вот сейчас делаю проект, принимает данные с линии и тактируется от встроенного RC-генератора с погрешностью до 10%. Все было рассчитано изначально и реализовано в виде алгоритма допускающего отклонение скорости передаваемых данных до 5%. При этом прекрасно рассчитываются все временные интервалы, единственное что это все сложно держать в голове - но обычный листок бумаги и карандаш спасает с последующим вводом в виде электронных диаграмм(чтобы не потерялось).

[my504]

Алексей. Вы слишком самоуверены...

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

Нет никаких правил для гарантированных и абсолютно безошибочных решений в любой ситуации. Исследовать взаимодействие в общем работающей программы и реальных обстановок без доступа к данным так же невозможно. При этом конечно можно создавать различные дополнительные интерфейсы для таких целей. Только ЗАЧЕМ? когда есть готовый и недорогой инструмент.

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

Техзадание по моим работам конечно имеется. Его писал я сам. Как это и положено в НИОКРах. Заказчик лишь пишет ИСХОДНЫЕ ДАННЫЕ по проекту. И эти исходные данные, как правило, вообще не радиотехнического характера. Заказчику по барабану мои формализованные требования к продукту. Заказчику нужен результат работы оборудования. Только специалист может поставить в соответствие нерадиотехнические исходные данные и радиотехническое ТЗ.

Характер моей деятельности не имеет для вас никакого значения. Но поверьте, Вы занимаетесь достаточно простой по меркам нашей профессии задачей (о которой Вы упомянули). Оттого я и говорил в начале о Вашей самоуверенности...

ЗЫ. Есть еще одна область, где крайне нужен дебаггер. Это ИЗУЧЕНИЕ работы интерфейсов. Сложных интерфейсов. Часто невнятно описаных в даташитах. Даташиты пишут для знающих эти даташиты... Как правило. В техписателях мало талантливых преподавателей. Их там вообще практически нет. Поэтому, даже зная английский в масштабах техперевода, часто для понимания работы железа нужно просто посмотреть на практике как оно функционирует. Это много быстрее и эффективнее муторных исследований происхождения и значений некоторых терминов...

Скажем я сейчас делаю USB HID устройство для которого не потребуется писать специальный драйвер в Винде.... Ранее я этим не занимался. Без контроля за данными в МК это сделать в короткие сроки, мягко говря, затруднительно...

Изменено 28 ноября, 2011 пользователем my504

[Goodefine]

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

[my504]

Для отладки в реалтайме достаточно часть ОЗУ выделить под логгер. Все таки существует, как правило, повторяющийся цикл в программе (суперлуп или некое множество проходов суперлупа). Т.е. не пошаговая отладка, а интервальная с брекпойнтами.

Повторяю, дело не в сложности контроллера, а в алгоритме и в неполном представлении выполняемой задачи по ОБЪЕКТИВНЫМ причинам. Бывает нужно сделать РАЗОВЫЙ проход цикла, чтобы просмотреть конечные состояния и зафиксировать осциллограмму внешних сигналов. Бывает нужно изменить промежуточные результаты для получения некоторого эффекта... Расстановка ловушек-брекпойнтов для вылавливания несанкционированных исполнений (по самым разным причинам, в том числе и независимых от человека). Да мало ли ситуаций бывает...

Изменено 28 ноября, 2011 пользователем my504

[Goodefine]

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

[my504]

И даже не буду спорить-возражать...

В подобных описанным выше программам, где без РТОС не обойтись, консоль удобнее. Мои же программы не требуют РТОС. Поэтому уровень абстракций не столь высок. Мне вполне хватает графики DMCI в МПЛАБе.

[woiow]

привет всем! Помогите мне пожалуйста в соединении двух микроконтроллеров ATMEGA16 через I2C аппаратный интерфейс. Я на стадии "начинающий" мне до этого не приходилось с таким иметь дело, умею лишь пока моргать светодиодами. Расскажите или подскажите где можно об этом почитать, всё подробно, шаг за шагом для чайников. Спасибо.

[Alexeyslav]

Обязательно ли использовать именно I2C интерфейс? UART как-то более прозрачно и быстродействие можно получить вплоть до 2мбит/сек. В микроконтроллерах реализован 9-битный UART - Не проблема организовать передачу адреса(отличить передачу адреса от данных) и синхронизирующие последовательности если есть вероятность сбоя или включения подчиненного контролелра во время передачи данных.

Нет никаких правил для гарантированных и абсолютно безошибочных решений в любой ситуации.

Я и не касался никаких решений, оно и правда - всего не предусмотришь. Но как минимум, что-то о сигнале известно. Даже когда речь идет о статистике - с алгоритмом нужно определится ДО того как начать реализовывать конкретное устройство. Если нет доступа к реальному объекту - есть возможность записать сигнал и воспроизвести в лабораторных условиях нужное количество раз - это не даст гарантии что программа будет 100% работать, но хотябы не надо будет каждый раз из-за мелочей дожидаться редкого явления.

После того как задача поставлена, все параметры определены - происходит написание программы без каких либо проблем.

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

Хотя, наверняка Вы это знаете и лучше меня...

Изменено 28 ноября, 2011 пользователем Alexeyslav

[woiow]

Почему именно I2C? Он меня прельстил малым количеством "ног" МК для организации связи и что на те же две "ноги" можно подключить не один десяток устройств (что я и планирую). Меня интересует как в программе использовать всевозможные интерфейсы связи, т.е. каждая строчка кода что означает. Прошу прощения, не рассказал что пишу в CodeVisionAVR. В Интернете находил множество примеров использования разных интерфейсов, но дела пока не дошло до практического применения. Лежит предо мной два МК ATMEGA16 вставленные в макетки, а вот что писать в коде для общения между ними - ума не приложу.

[Alexeyslav]

UART тоже по двум проводам подключается.

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

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

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

[woiow]

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

[Alexeyslav]

Надо внимательней читать даташит. Сначала надо сконфигурировать UART на определенный режим и скорость работы, затем разрешить работу приемника и передатчика. Потом только лови поступающие данные и передавай ответ...

Только парочку замечаний прежде чем реализовывать это все. Надо четко себе представлять что в отличие от компьютера в контроллере нет буффера приема - максимум он может хранить один байт и второй в это время принимать, по окончанию приема второго байта возникнет состояние "переполнение буффера" и если не считать хотябы один из них ДО того как начнет поступать третий то данные будут утеряны. Это на ПК есть аппаратных 16 байт + сколькототам килобайт в буффере драйвера. Поэтому если между приемом отдельных байт происходит сложная обработка - в т.ч. и возникающие прерывания! в передаче данных необходимо делать паузу. Порт ПК для этого имеет специальные входы(приостонови передачу, не успеваю записывать!), а в контроллере в таких случаях доступна технология XON/XOFF либо выделить отдельные выводы.

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

Вот парочку интересующих вещей:

.DEF ACCUM     = R25

.macro set_io
 LDI   ACCUM, @1  ; 1 такт
 OUT   @0,  ACCUM ; 1 такт
.endmacro


; Настройка USART
; Тактовая частота 14,745Мгц.
; Делитель USART:
; 7 = 115200
; 11 = 76800
; 15 = 57600
; 23 = 38400
; 31 = 28800
; 47 = 19200

set_io UBRRH,  0
set_io UBRRL,  7                       ; Set baud rate = 115200 @ 14,745Мгц.
set_io UCSRB,  (1<<RXEN)|(1<<TXEN)     ; Enable receiver and transmitter
set_io UCSRC,  (1<<URSEL)|(3<<UCSZ0)   ; Set frame format: 8data, 1stop bit


....


; =========  ПОДПРОГРАММЫ  =================
; скопировано с даташита!
USART_Transmit: // Передача байта
; Wait for empty transmit buffer
sbis UCSRA,UDRE
rjmp USART_Transmit
; Put data into buffer, sends the data
out UDR, ACCUM
ret

USART_Receive: // Прием байта
; Wait for data to be received
sbis UCSRA, RXC
rjmp USART_Receive
; Get and return received data from buffer
in ACCUM, UDR
ret




в программе: 

если не надо ждать когда прийдут данные:

sbis   UCSRA, RXC ; Ждем пока не поступят данные
rjmp   USART_not_Receive 
 // Есть данные в буффере приема
in  ACCUM, UDR   ; Считываем данные с буффера, первый байт
ST             X+, ACCUM
RCALL  USART_Receive      // Точно уверены что точно будет минимум 3 байта
ST             X+, ACCUM  // и сохранить их по указателю адреса X с инкрементом
RCALL  USART_Receive 
ST             X+, ACCUM

... и т.д.

:USART_not_Receive



Для передачи:

LDI    ACCUM, 0x2B ; Символ "+"
RCALL  USART_Transmit