Dmitriy_V

Хотел использовать данную микросхему для переходника com-bluetooth. Однако полного описания в интернете найти не удалось. Частично схема включения была рассмотрена для демонстрационной платы. Все файлы, которые удалось найти, легко погуглить по названию: BGB203_ShortDatasheet_V1_0.pdf наиболее полное описание из найденных BGB203_SPP_UserGuide.pdf - описание команд, используемых для конфигурации S06 Документы, где приведена разводка: SparkFun-Bluetooth-v23.pdf LPC2104_Color_LCD_Game_Users_Guide-Version_1.1_Rev_A.pdf Если кто-либо уже работал с этой микросхемой, большая просьба поделиться информации о типовом подключении выводов для spp режима и полноценной документацией. Заранее благодарю за помощь.

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

С volatile все заработало. На самом деле в симуляторе я смотрел cof файл. В этом, наверное, и кроется результат несовпадения.

У нас разные понятия о листинге программы. Поскольку я не силен в ассемблере (знаю только в общих чертах), то для меня листинг - это то, что я написал на C. Спасибо за разъяснения по ошибке. Теперь более понятно, получается, что CVAVR по-умолчанию считает все переменные volatile и поэтому работает правильно. Удручает при этом, что в симуляторе обе программы ведут себя одинаково. Впредь буду все глобальные переменные, используемые в прерывании, отмечать как volatile. Еще раз спасибо. Мне нужна всего одна переменная типа int. Спасибо за разъяснения, теперь понятно где чего резервировать.

Огромное спасибо, буду пробовать. Листинг, конечно, смотрел, я его сам и писал . По поводу while(flag); : если он неправильно ассемблируется, то что можно использовать вместо него для задержки до срабатывания прерывания? По поводу ошибки: никогда не думал, что оптимизация может зайти так далеко. :crying: Можно еще вопросик не по теме? У меня в целевой программе есть переменная типа Int. При передачи нужно как можно быстрее передавать побайтно значение этой переменной. В настоящий момент данные передаются следующим образом: PORTA=A_int; ... PORTA=(A_int>>8) ... . Как мне кажется, такая передача не оптимальна. По-идее, можно зарезервировать определенные регистры под переменную и выводить уже регистры: PORTA=r15; ... PORTA=r15 . Подскажите пожалуйста, будет ли такой алгоритм более быстрым по сравнению с первым и каким образом можно зарезервировать регистры под переменную? Когда я пытался осуществить резервирование, IAR говорил что-то о необходимости в изменении каких-то настроек. Заранее благодарен. P.S. За большие вставки извиняюсь, не знал, больше не повторится.

Спасибо за участие и советы. Привожу код для CVAVR и IAR. Код, по-моему, проще не куда. Я его сделал после того, как два дня убил на отладку своей программы. В общем, то что мне надо, я уже переделал под CVAVR, но в симуляторе IAR заметно лидировал по тактам выполнения работы программы. Жалко терять скорость выполнения, она и так близка к критичной. IAR: ... CVAVR: ... Исправил, больше так не делайте. IgorKossak src.rar

В CVAVR был с помощью CodeWizardAVR проект, в котором по таймеру менялось значение одного из портов. Практически без изменений этот же проект был перенесен в IAR. При тестировании в AVRStudio4 обе программы вели себя полностью одинаково и корректно. Однако в микроконтроллере корректно работала только программа, написанная в CVAVR. В IAR программа выполнялась, но без вызова прерывания. Контроллер прошивался в обоих случаях через CVAVR STK200. Поскольку в симуляторе обе программы работали корректно, то ошибка скорее всего возникает при создании hex файла. Формат вывода выставлен как Intel standart. В чем может быть проблема и какие настройки надо изменить, чтобы все работало нормально?

Proteus с ATMega8535 не работает, код на C не воспринимает и выполнение программы в тактах не выводит. Но программа хорошая, сам пользовался для 90S8525.

Спасибо за ответ. А то я уж грешным делом подумал, что это не в программе ошибка, а у меня (в ДНК) :a14: . А есть какая-нибудь другая программа эмуляции, или patch к AVRStudio, чтобы все работало корректно? А то тестирование работы сразу на реальной плате может иметь фатальные последствия.

Для решения моей задачи требовалось использовать fast PWM TOP=ICR1 для ATMega8535. После написания программы запустил эмуляцию в AVRStudio, при этом результат "немного" отличался от описанного в datasheet. Счетчик, не доходя до значения ICR1, начинал считать в обратном направлении. Причем, какие бы режимы fast PWM я не ставил, ситуация повторялась. Вместо того, чтобы по достижении значения TOP обнуляться, счетчик производил счет в обратном направлении. В CVAVR с помощью CodeWizard создал чистые файлы для различных режимов fast PWM, получается таже фигня. Сам запрограммировал регистры в IAR, эмуляция ничем ни отличалась от предыдущих случаев. Данная ситуация повторилась как минимум на 3 компьютерах, т.е. конфликты с другим программным обеспечнием маловероятны. Кто-нибудь сталкивался с подобной проблемой?

А где можно достать подробное описание и купить эту замечательную микросхему? (версия для перобразования RS232<->bluetooth) На сайте nxp я описание по этой микросхеме найти не смог.

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

Спасибо за ссылку. Оказывается не только у нас тех. описания делают через не голову. Характеристики по ИОН есть, но они пропорциональны BANDGAP, приводятся не в цифрах, а только в виде графика на странице 287 описания, и об этом можно узнать из другого описания. Ограничение преобразование связано с ЦАП используемым для преобразования, но как связано под вопросом. Для BANDGAP - в худшем случае температурная зависимость - 0.003%/oC, по напряжению - 1%/В. А запихивать это все хозяйство куда? И так места мало. Я понимаю это был бы Tiny, а то МЕГА на 40 - 44 лапы. Идея с внешним АЦП была, но ставить дополнительно внешний без сильной необходимости не хочется. Кроме того реально можно поменять алгоритм коррекции. Т.е. сделать разделение каналов управления по времени. Снимать с частотой 10кГц один сигнал, потом делать коррекцию ШИМ, дальше снимать другой сигнал и т.д., но при этом увеличивается общее время реакции.

Другого не нашел. :cranky: А какой посоветуете? Необходимы встроенные АЦП (не менее 10 бит), ШИМ (не менее 10 бит), встроенный UART, минимум навесных элементов (в данном случае нет вообще), приемлемая цена, простота пайки, разрешение к применению в военной технике. Задача на уровне аналоговой схемы стабилизации по трем каналам с возможностью быстрого изменения постоянной времени по каждому каналу в отдельности и синхронным детектором. Задавал вопрос в форуме по поводу микроконтроллеров, выпускаемых в РФ: См. здесь Разброс не страшен. В конце концов, все параметры стабилизации зашиваются после калибровки. Больше беспокоят зависимости от температуры и напряжения питания.

Откуда такая информация? На сколько я понял, заряжать этот конденсатор после переключения канала я могу сколь угодно долго. А вот после запуска АЦП он отсоединяется от вывода. Выход у меня и так идет с операционника. Практически любая аналоговая измерительная схема требует усилительных каскадов. Еще вопрос по поводу АЦП. Сейчас у меня следующая схема опроса: 1. Таймер запускает преобразование с частотой 30кГц (частота дискретизации АЦП 70кГц). 2. По окончанию преобразования я переключаю канал. 3. От времени переключения до времени следующего запуска проходит 16мкс. В этой схеме сильно нервирует прерывание от АЦП. В описании есть строчка по поводу того, что если преключение канала производить в процессе преобразования, то переключение не произойдет до тех пор, пока преобразование не завершится. Если после установки флага начала преобразования сразу переключить канал, то это будет означать, что после преобразования он переключится? Или эта фраза означает, что я должен повторно переключить канал после преобразования, а до этого времени любая запись в ADMUX игнорируется?