модульное программирование и отладка сначала модулей, затем верхний уровень.
Прекрасен подход только на бумаге, в реальности полуается не так как задумывалось и всё резко становится хуже.
К тому же, подход применим только когда поставлено чёткое Т.З. в деталях и изменений не предвидится.
[uquote="Feruz",url="/forum/viewtopic.php?p=3335397#p3335397"]Не могу понять почему протеус криво компонует исходник? При пошаговом выполнении вылетает "No source code in this line". Или я что-то делаю не так.[/uquote]
Кстати, а по адресу 0х0046 не должго быть какого-то прерывания или команды RETI, а так получается адрес никуда, а просто так на прерывание без вызова протеус не даст выйти, насколько мне известно Спойлер
Если я чего-то не знаю, это не говорит о моем невежестве, а только о том, что раньше этот вопрос лежал вне сферы моих интересов.
[uquote="Alexeyslav",url="/forum/viewtopic.php?p=3336097#p3336097"]...[/uquote]
С МК AVR я начал работать с 2007 года. Сначала писал на асме, затем перешел на си. В студии работаю с самого начала. В протеусе неоднократно пробовал работать. В итоге на последней попытке плюнул и забил на протеус.
С одной стороны протеус как бы удобен тем, что накидал схему и можно эту схему просимулировать. Такой подход может быть и удобен на небольших схемах.
Приведу в качестве примера один свой проект. Блок управления термоформовочным станком. Состав: МК, регистры ввода-вывода 74HC165 - 3 шт, 74HC595 - 2 шт. 24 входа, 16 выходов. Символьный дисплей 20х4. Матричная клавиатура. "Сейчас мы со всей этой хренью попытаемся взлететь". Я попытался как-то сделать на протеусе. Компьютер так завис на этой схеме, что я прекратил дальнейшие попытки работать в протеусе и весь проект отлаживал как и прежде в студии.
Да, непросто. Но если приноровиться, то все не так уж и сложно.
Алгоритм простой. Как работают микросхемы регистры ввода-вывода нам прекрасно известно, тем более, что SPI аппаратный. Написали программный модуль, сделали тестовый проект, проверили в железе. Если что, отладили в симуляторе. Теперь этот модуль можно смело выкидывать из головы. Беремся за следующий модуль, скажем, символьный дисплей. Тут все аналогично. Я с такими дисплеями работаю без флага ожидания. Только на запись. Проверили работоспособность, что-то вывели для проверки. Этот пункт теперь тоже выкидываем из головы. Матричная клавиатура. Написали модуль, сделали тестовую программу. Вывели коды кнопок на дисплей, выкинули из головы. Дальше остается только сама программа. Алгоритм работы самого устройства в целом.
Спор ни о чем. С таким же результатом можно спорить что лучше ВАЗ 2102 или 2103. Если хотите продолжать, проще создать ветку "Что круче:........ или ..........", и там разводить срач.
Если я чего-то не знаю, это не говорит о моем невежестве, а только о том, что раньше этот вопрос лежал вне сферы моих интересов.
2 Jetetex когда то помогло в случае "No source code in this line" - разместил файл протеуса там где исходник, правда на Си это было
Если что, отладили в симуляторе
хм. AVR Studio 4.19 хэлп: Simulator Modules
USI is not supported.
TWI is not supported.
Analog Comparator is not supported.
Analog input is not supported.
лучше эмулятор имхо, правда у Atmel было дорого всегда, но народ извращался - HappyJTAG2 JTAG и ISP для AVR: http://microsin.net/programming/avr/happyjtag2.html
з.ы. в коментах есть чтоб AVR Studio не падала
модульное программирование и отладка сначала модулей, затем верхний уровень.
Прекрасен подход только на бумаге, в реальности полуается не так как задумывалось и всё резко становится хуже.
К тому же, подход применим только когда поставлено чёткое Т.З. в деталях и изменений не предвидится.[/uquote]
Вполне нормально получается - подход древний, с самого рождения ассемблера применяется.
Другое дело, что модульная (многофайловый проект) программа несколько специфична в отношении написания самих модулей и правил работы с ними. О многих приемах можно только догадываться или своими "шишками" осваивать на практике.
Или вспоминать "давно забытое" старое для I8080/Z80/I8086.
Дальше остается только сама программа. Алгоритм работы самого устройства в целом.
А потом оказывается что эти самые модули которые выбросили из головы начинают конфликтовать друг с другом. Где-то одинаковые регистры задействовали, где-то выходит за границу выделенной памяти и портит соседний участок...
Такой подход предполагает очень тщательное документирование каждого модуля, согласование всех модулей в рамках проекта и это отбирает по времени и ресурсам едва ли не больше чем на реализацию самой программы. И самое ужасное что это позволяет только УМЕНЬШИТЬ количество очевидных ошибок.
Тогда как метод научного(не полностью же рандомно писать программу) тыка с последующей симуляцией работает гораздо быстрее.
Дело было вечером, делать было нечего... решил я я по свободе перечитать тему с самого начала, и вот что заметил: темы повторяются каждые 10-15 страниц. И в попытке как-то систематизировать сделал что-то вроде навигации или содержания. Получилось или нет, судить Вам:
- Вопрос в следующем, пришел тот злащасный день когда мне понадобилась работа с не целыми числами типа 1,5 в ассемблере, ести ли какие либо стандартные варианты работы с такими числами или нужно чегото мудрить, если мудрить то как??? http://radiokot.ru/forum/viewtopic.php?p=56246#p56246
Категорически не соглашусь с вами! Ассемблер изначально предполагает тщательное планирование. И документирования в том или ином виде. Написание отдельных документов, комментарии, рисование алгоритмов. А также следование определённым правилам. Стиль и свод правил каждый программист вырабатывает сам. Есть и общепринятые правила.
Регистры. Нужно сразу и жестко, раз и навсегда определить, как и какие регистры использовать. Глобальные, часто используемые, служебные, временные.
Модульность. Нет ничего хорошего в том, что вся программа представляет из себя огромную простыню. Это как минимум затрудняет чтение программы. Программа должна быть разбита на логические блоки. В идеале следует добиться следующего: каждый модуль должен быть максимально самостоятельным. У такого подхода следующие преимущества:
В разы ускоряется создание проектов. Проекты собираются как конструктор из кубиков-модулей.
Чтобы не было проблем с регистрами нужно следовать правилам и тщательно отслеживать регистры в каждом модуле. Сохранять и восстанавливать контекст при необходимости.
Память. Максимально исключить ошибки можно единственным способом: использование не абсолютных адресов, а меток. И, естественно, тщательно проверять все операции с памятью, чтобы не выйти за пределы диапазонов.
Для работ под ассемблером есть два варианта
полная проработка программной модели "с нуля" для малой прикладной задачи
и
модульная сборка из заранее подготовленных библиотек для больших проектов.
Что не исключает и комбинированного стиля.
При модульном варианте каждый из модулей получает дополнительное обрамление функциями хранения используемых ресурсов и обязательными правилами генерации имен используемых ресурсов.
Особых общих правил не имеется.
Примеры из "полнофункциональных" компиляторов (имеющих в составе ассемблер, линкер и библиотекарь) для avrasm2 (как и для c51asm от атмела для mcs51) не применимы из-за специфики отсутствия линкера и библиотекаря в самом составе компилятора.
Однако работа в любом из вариантов вполне реальна.
Всем здрасте. Собираюсь в проекте использовать ШИМ, но где-то вроде как читал, что регистры сравнения OCR не могут иметь крайние значения (0 и 255). Так ли это???
Симулятор не ругается, но как бы потом в железе не возникло проблем. ШИМ планируется на вкл/выкл, + кнопка без фиксации на функцию вкл/выкл этого безпредела.
[uquote="Jetetex",url="/forum/viewtopic.php?p=3337232#p3337232"]Всем здрасте. Собираюсь в проекте использовать ШИМ, но где-то вроде как читал, что регистры сравнения OCR не могут иметь крайние значения (0 и 255). Так ли это???...[/uquote]
А подумать ... ?
0 - не имеет смысла, а 255 в принципе вполне применимо, только это то же самое, что и прерывание по переполнению.
Т.Е. ШИМ там не будет - непрерывный сигнал либо 0 либо 1.
Кстати... В Кривом Рогу раньше неплохая контора по кассовой технике была - "резонанс" называется.
Неплохие аппараты делала...
Это да. Так даже лучше. Сомнения именно в том - не возникнет ли каких то конфликтов на контроллере.
Смысл в том, что бы по нажатию на кнопку включить одной ногой блок питания, после этого плавно зажечь светодиодные ленты. После повторного нажатия сделать все наоборот, т.е. сначала плавно потушить свет, а потом выключить блок питания.
Сразу отвечу - блок питания на 250 Ватт, на котором висит около 40 метров ленты, поэтому и нужно его отключить что бы не жрал лишнего.
Кстати... В Кривом Рогу раньше неплохая контора по кассовой технике была - "резонанс" называется.
Неплохие аппараты делала...
Не знаю, но название знакомое.
Если я чего-то не знаю, это не говорит о моем невежестве, а только о том, что раньше этот вопрос лежал вне сферы моих интересов.
Протеус в осцилографе показывает именно непрерывный сигнал - при OCRA=0 низкий, а на OCR0A=255 высокий. Именно это меня немного и смущает, ведь ему каг бы надо время на переключение пина, а при 0 он должен одновременно и включить и выключить ногу . Просто нехоцца без особой необходимости увеличивать код сравнениями. Оно в общем то и не критично, но все таки..
Если я чего-то не знаю, это не говорит о моем невежестве, а только о том, что раньше этот вопрос лежал вне сферы моих интересов.
Кто подскажет как сбросить флаг DOR в UART, именно с помощью команд,а не на словах как пишут обычно:Бит DOR очищается (сбрасывается в 0) когда данные приняты и пересланы в UDR.,лично у меня не получаеться его скинуть,почему то когда он устанавливается никак не прочитать данные.(((
если смотреть по ATMega16, то никак. Он доступен только для чтения. В даташите на Вашего таракана посмотрите на UCSRA (в 16). под табличкой регистра написаны буквы W и R. Они обозначают возможности регистра:
R (read)- чтение
W (write)- запись
W/R (read/write)- чтение/запись
PS: с USART не знаком, но в ДШ написано, этот бит установлен пока буфер приема (UDR) не будет СЧИТАН.
PPS: Люди добрые, когда вы, крича громко хелп ми научитесь нормально оформлять вопрос? Не понятно какой контроллер, не известен код программы, нет никакой информации, от которой можно оттолкнутся для решения ВАШЕГО вопроса. Здесь нет телепатов