мега16 в DIP40 и TQFP44 исполняют код по разному !?

[Black]

Проблема: Есть код на СИ, написан в CVAVR. В протеусе работает адекватно, в AVR Studio работает адекватно, в макетке с мега16 в DIP40 работает адекватно, в целевом устройстве с мега16 в TQFP44 небольшая часть кода работает не правильно. Железо целевого устройства и макетки сделано аналогично, фьюзы и прошивка используются одни. Менял мегу16 в TQFP44 из последних партий (с широким диапазоном питания) на более старую - результат то-же. Отключал неиспользуемые части схемы, промывал плату - не помогает, в самом простом варианте оставлял только ЖКИ, на котором и видно как работает программа - бесполезно. Переписывал не работающую часть кода по другому варианту - бесполезно. Вопрос к знатокам: встречаются отличия работы МЕГИ 16 в различных корпусах, как они могут проявляться? Подробности пока не привожу, в первую очередь интересует в принципе наличие такой проблемы.

[ARV]

в принципе - это по-разному корпусированные одни и те же кристаллы.

[Black]

с даташитом я ознакомился. поэтому и не понимаю в чем заморочка...

[Goldsmith]

В документации описаны отличия, касающиеся АЦП. Не с ним ли связана проблема?

[Black]

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

[Kavka]

Может JTAG виноват? На порту С.

[O-LED]

Goldsmith

В документации описаны отличия, касающиеся АЦП. Не с ним ли связана проблема?

это какие отличия? может вы с 8 мегой путаете?Kavka

Может JTAG виноват? На порту С.

Ну раз человек на дипе не забывает выключать JTAG, то и на TQFP наверное тоже.

[Goldsmith]

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

это какие отличия? может вы с 8 мегой путаете?

Не, я числа хорошо различаю. Особенно 8 и 16.

Качаем даташит: http://www.atmel.com/dyn/resources/prod ... oc2466.pdf

На первой же странице находим:

– 8-channel, 10-bit ADC
8 Single-ended Channels
7 Differential Channels in TQFP Package Only

Далее, на странице 4:

10-bit ADC with optional differential input stage with programmable gain (TQFP package only)

Так что не все корпуса одинаково полезны. Хотя в данном случае, наверное, причина не в этом.

[Black]

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

[Black]

Суть проблемы: при опросе матричной клавиатуры 4х8 три столбца опрашивались без проблем, четвертый никак, если в коде делать переназначение пинов, то проблема переходила на последний столбец в коде с уже новым назначенным пином, т.е. напрашивался вывод, что обвязка в порядке, выходы МК в порядке (после переназначения пинов в коде кнопки, которые не работали, начинали работать, и наоборот), при этом в макетке работало ВСЁ! Впечатление, что после сдвигов (использовал long int) после опроса столбцов происходила потеря данных в последнем опросе, в коде необходимые задержки для смены уровней сигналов были предусмотрены.... Потом, конечно, начал изменять код, пробовал различные варианты, и начались глюки - в некоторых случаях МК при начале опроса клавы вылетал в неконтролируемое (мной) состояние (на ЖКИ пропадала вся информация), а в макетке тот же код работал! в одном варианте кода я оставил только ЖКИ в обвязке, клаву отключил и имитировал её прямо на ножках МК, глюки были непонятные, а в макетке их не было... И всё таки проблема оказалась в обвязке - в клавиатуре! Последний (один из вариантов после переделки) опробованный код работал на грани стабильности (как я потом понял), на макетке из за практически полного отсутствия проводников на пинах это не проявлялось, а в девайсе оставались печатные дорожки до места подключение клавиатуры, это сбило с толку еще больше. ПРОБЛЕМА ЗАКЛЮЧАЛАСЬ в очень большой ёмкости мотажа клавиатуры (многослойная плата с контактами под резиновые кнопки), и моих мер для смены уровней было не достаточно, путем проб увеличил задержки (нопы) в коде по совокупности примерно в 15!!! раз. Опыт в программировании у меня очень не большой, это второй девайс в моей практике, поэтому описанные глюки я не смог адекватно оценить с ходу, но, блин, и глюки то с подвохом, хотя на то они и глюки.... Вопрос исчерпан, тему можно закрыть, хотя готов послушать комментарии опытных товарисчей ...

[Goldsmith]

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

Опыт в программировании у меня очень не большой

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

[Foks]

При матричном сканировании клавиатуры задержку nop'ами не делают. В прерывании таймера, по которому производится сканирование, сперва считывают состояние предыдущей строки (столбца), затем выбирают новый, и только по следующему срабатыванию прерывания он будет прочитан.

Лепить десятки-сотни NOP'ов в прерывание неправильно, т.к. Вы при этом зря занимаете процессорное время. (так бы во время задержки мог выполняться другой код).

[Black]

Конечно согласен, что код нужно проверять, я это делаю, и как результат - выявил вышеописанную проблему, она же у меня проявилась не в законченном девайсе... Нопы применил только для выявления проблемы, в рабочий код включу другой алгоритм, вариант с опросом столбцов отдельно по прерываниям приму к сведению, спасибо за подсказку. Нопы в моем случае не только процессорное время отжирают (хотя в этом случае это не критично, и для пользователя абсолютно не заметно, однако в целях правильного программирования этого нужно избегать), но и память МК, после компиляции размер кода увеличился на 0,5% по мнению CVAVR. Кстати, в коде я ухожу на прерывание с максим. предделителем, для антидребезга клаву сканирую два раза, во втором сканировании делаю сравнение с первым и получаю скан код, с моим кварцем скан код с учетом двойного сканирования обновляется примерно раз за 48 мсек. Имею два ухода в прерывание для обновы скан кода, а если уходить после каждого столбца, то как минимум четыре прерывания нужны, да еще антидребезг нужно учесть либо в доп. прерываниях, либо выставить приемлемый интервал таймера для четырех прерываний... Пока не успел посчитать, как оба случая влияют на процессорное время с учетом всех необходимых мер, может у кого уже есть готовый ответ?

[Goldsmith]

Конечно согласен, что код нужно проверять, я это делаю

Проверка и тестирование - совершенно разные вещи.

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

[Black]

Goldsmith, среда модульного тестирования для МК существует? Или нужно использовать программы, предназначенные для ПК и адаптировать их под задачи МК? Тема модульного тестирования меня заинтересовала, спасибо за подсказку.

[ARV]

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

[Goldsmith]

Goldsmith, среда модульного тестирования для МК существует? Или нужно использовать программы, предназначенные для ПК и адаптировать их под задачи МК?

Специально заточенных под МК вроде бы нет, но есть вполне пригодные для этого. Например, среда Unity, которую я сейчас использую, достаточно компактна, чтобы модульные тесты при необходимости умещались в памяти МК. Есть еще одна, которую надо бы попробовать, но она ориентирована на C++, а с ним возможны проблемы на младших моделях МК.

Я недавно перевел пару статей о применении современных технологий программирования для проектирования встроенного программного обеспечения. Можете для начала посмотреть их, они выложены здесь: http://club.shelek.ru/viewart.php?id=335 и http://club.shelek.ru/viewart.php?id=337 . В обозримом будущем планирую написать о собственном опыте в этой области.

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

Это действительно весьма стоящая тема, хотя ей уделяют очень мало внимания. Видимо, слишком мало программистов умеют держать в руках паяльник и слишком мало электронщиков стремятся научиться программированию на профессиональном уровне. Получается, что firmware сейчас - практически ничья территория.

[Psych]

Что то подобное было: была схема на МК --- работала, поменял МК на другой(тот же тип и рабочий) ----не пашет. Дооолго я возился и не мог понять в чем дело все одинаково, даже корпуса. Причина была в разных ревизиях(партиях), а заглянуть в эрраташит как то не додумался. Может у вас подобный случай?

[svd71]

могут быть отличие, если новый чип выполнен с индекцом "А".
Это версия, у которой исправлены мелкие недочеты.