Форум РадиоКот

Ой. Да! Спасибо! С6 не туда прикошачил. Исправляю.

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

Не знаю, что за устройство, по названию темы не понять. Однако резисторы на MOSI, MISO, SCK можно смело выкинуть, если программатор хоть чуть вменяемый. Включать внешнее питание параллельно батарее неверно, ее следует отключать.

Как происходит программирование МК, не расскажете? а то я вообще понятия не имею, его прошивать после сборки схемы или же до сборки как флешку забить и все?

maglev писал(а):Не знаю, что за устройство, по названию темы не понять. Однако резисторы на MOSI, MISO, SCK можно смело выкинуть, если программатор хоть чуть вменяемый.

У меня, например "невменяемый" программатор, - 5 проводков+ponyprog, без подтяжки ругается, мол, неизвестное устройство, но все равно шьет, если нажать игнор

maglev писал(а):Не знаю, что за устройство, по названию темы не понять. Однако резисторы на MOSI, MISO, SCK можно смело выкинуть, если программатор хоть чуть вменяемый. Включать внешнее питание параллельно батарее неверно, ее следует отключать.

Не спорю, можно и выкинуть. Только это не есть гуд! Вернее хороший тон конструирования. У человека вобще нет программатора и неизсвестно каой он его найдет, вменяемый или нет. А подтяжка всегда пригодится! Эти ноги в воздухе висеть не должны. В этом проекте пофигу конечно, а в серьезной конструкции наводки и помехи могут дрючить МК и потом поди разберись что да почему.

А топикстартеру настоятельно рекомендую заглянуть в обучалку и прочитать http://radiokot.ru/start/mcu_fpga/avr/
А то уже тут три страницы одних разговоров, а толку нет. Читай, вникай, потом будешь вопросы задавать.

EmilЕЛ писал(а):Как происходит программирование МК, не расскажете? а то я вообще понятия не имею, его прошивать после сборки схемы или же до сборки как флешку забить и все?

Сначала пишется программа (предположим, на ассемблере -- именно его использование позволяет лучше всего изучить микроконтроллер, посему лучше с него и начать). Обычно это делается прямо в AVR Studio. После написания программа транслируется и, если ошибок не обнаружено, её можно прошивать. Для этого программатор подключается к компьютеру (поскольку у Вас ноут, то нужен программатор, подключаемый к USB, ну или покупать ещё переходник USB-COM, чтобы программатор для COM-порта можно было прицепить), а к выходу программатора подключается микроконтроллер. Когда всё присоединили, нажимается нужная кнопочка -- и АВР Студио записывает код программы в память программатора. Ну или ругается, что не может этого сделать

SII писал(а): Сначала пишется программа...

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

"Обычно это делается прямо в AVR Studio."

Тоже рекомендую АВР студию, для начала необходимо написать простую программу чтоб что то делала, выдавала какие либо данные куда либо, например мигала светодиодом или посылала данные в ком/усб порт, хотябы тупо 0. Т.е. всегда начинайте писать проэкт с минимально простой функции, и завершите её отладку до конца и только тогда навароты постепенно добовлять имеет смысл.

В АВР студии можно легко отладить по шагам, а так же поглядеть как будут работать те или иные настройки переферийной аппаратуры.

Для простоты настройки переферии типа таймеров и тд можно скачать CodeVisionAVR там есть мастер настройки переферии и инициализации, с помощью него гораздо проще настраивать слодные штуки типа таймеров, UART и тд, т.к. есть готовый мастер который который спрашивает то что ты хочеш и выдаёт в итоге значения регистров которые нужно загрузить в управление таймеров, уарт и тд. Это в 100 крат проще чем побитово смотреть по даташитам и ручками прописывать. Хотя для изучения и это неплохо было бы сделать.

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

Лучше уж самому научиться. А если спалить опасаетесь, то проще взять готовую плату и с ней возиться.

stas00n писал(а):

SII писал(а): Сначала пишется программа...

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

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

SII писал(а): Чтобы программно что-то спалить, это очень постараться надо (да и сама схема должна быть не шибко корректная для этого).

програмно что то спалить можно. если например имееш матрицу соеденений и можно соеденить как высоковольтную пробойку на 10киловольт так и измеритель сопротивления изоляции с входом в ацп контроллера. Я не думаю что контроллер такой железный и 10киловольт выдержит. Это естественно если быть совсем дураком и ацп не защитить вообще ничем.
Отсюда вывод - делать нужно схему такой чтоб на любые глюки программы ей было всё равно а то вдруг например попросту не повезёт и наполовину горелый чип попадйёся.

SII писал(а): Я всегда отлаживаю на реальном железе, а программа пишется по ходу дела и потом достаточно долго доводится до ума (добавляются новые возможности, например, о которых сразу не подумали)

Тоже, практика показывает что если разу всё написать то повешаешся с отладки и при отладке всё равно придётся искать глюки последовательно отключая и коменнтаря функции, фишечки и прочее. А потом ещё связанные блоки править (которые вдобавок недоконца отлажены) потому что не всегда удаётся удалить косяк не изменив принципа работы программы в целом.

Smirnov писал(а):

SII писал(а): Чтобы программно что-то спалить, это очень постараться надо (да и сама схема должна быть не шибко корректная для этого).

програмно что то спалить можно. если например имееш матрицу соеденений и можно соеденить как высоковольтную пробойку на 10киловольт так и измеритель сопротивления изоляции с входом в ацп контроллера. Я не думаю что контроллер такой железный и 10киловольт выдержит. Это естественно если быть совсем дураком и ацп не защитить вообще ничем.
Отсюда вывод - делать нужно схему такой чтоб на любые глюки программы ей было всё равно а то вдруг например попросту не повезёт и наполовину горелый чип попадйёся.

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

SII писал(а): Я всегда отлаживаю на реальном железе, а программа пишется по ходу дела и потом достаточно долго доводится до ума (добавляются новые возможности, например, о которых сразу не подумали)

Тоже, практика показывает что если разу всё написать то повешаешся с отладки и при отладке всё равно придётся искать глюки последовательно отключая и коменнтаря функции, фишечки и прочее. А потом ещё связанные блоки править (которые вдобавок недоконца отлажены) потому что не всегда удаётся удалить косяк не изменив принципа работы программы в целом.

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

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

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

Применительно к МК таких ошибок у меня не было, но лишь по той причине, что я начинающим программистом уже не был Хотя были проблемы другого рода. Например, допустил ошибку в подпрограмме деления, из-за чего в некоторых случаях она давала неверный результат. Причина -- что-то из особенностей АТмеги не учёл, поскольку опыта программирования именно под неё ещё не было. Естественно, заметив ошибочный результат, я быстро нашёл и устранил причину, но тем не менее... Ну а те, кто знают только ассемлер IA-32, в этом плане ещё в худшем положении: обычно они не знают, как нужно делить вручную, поскольку там есть готовые команды деления, а на АТмеге их нет, нужно писать свою подпрограмму (что я и сделал) либо использовать готовую.

SII писал(а):Применительно к МК таких ошибок у меня не было, но лишь по той причине, что я начинающим программистом уже не был Хотя были проблемы другого рода. Например, допустил ошибку в подпрограмме деления, из-за чего в некоторых случаях она давала неверный результат. Причина -- что-то из особенностей АТмеги не учёл, поскольку опыта программирования именно под неё ещё не было. Естественно, заметив ошибочный результат, я быстро нашёл и устранил причину, но тем не менее... Ну а те, кто знают только ассемлер IA-32, в этом плане ещё в худшем положении: обычно они не знают, как нужно делить вручную, поскольку там есть готовые команды деления, а на АТмеге их нет, нужно писать свою подпрограмму (что я и сделал) либо использовать готовую.

ну это я знаю со времён Z80. Тогда все писали и деление сами и арифметику с фиксированной запятой и тд. Нераз пригождались эти знания, даже для архетектуры Inte86. Например для таких мелких модулей которые объеденяются по RS485 в сеть, и управляют промышленными объектами, я делал контроллер температуры и и скорости течения потоков, вся сложная математика в итоге была сделана на сложениях и сдвигах, фильтры, предсказание. вычисление вектора выбега температуры и тд, хоть там и стоял AMD386 аналог интелевского но с флеш диском и досом в ПЗУ и кучей плюшек типа таймера и рс порта, но он вешался на делениях и умножениях, пришлось переписать в формате фикс. запятой.

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