A R T

Здравствуйте, Сергей! Спасибо за участие и дельные советы!!! Зарелизил обработку прерывания ТА1, как Вы предложили. Теперь выглядит так: #pragma vector=TIMERA1_VECTOR __interrupt void ta_interrupt_routine(void) { unsigned uTAIVcopy=TAIV; switch(uTAIVcopy) { case 0x04: fTime=fTimeCounter; fTimeCounter=0;//обнуляем счетчик таймера. fTime0=fTime1; fTime1=TACCR2; cFreqFalse++;//Задержка для выравнивания fTime,fTime0,fTime1. break; case 0x0a: fTimeCounter++;//инкрементируем счетчик таймера. default: _NOP(); } } Расчет частоты сделал так: void main(void) { … //Определяем частоту: if(cFreqFalse>3) //Задержка для выравнивания fTime,fTime0,fTime1. { _DINT(); fFreq=1/(2*(fTime*3.90625e-3+(fTime1-fTime0)*30.517578125e-6)); cFreqFalse=0; _EINT(); } … } Ошики стали появляться реже… Поставил точку останова после расчета частоты и при 50Гц их вообще не обнаружил, однако в реальном времени ошибки периодически случаются (всмысле при 50Гц). На частоте 20Гц ошибки появляются ~2...3 через 5…7 отсчетов. Т.е. при снижении частоты ошибки появляются чаще… Что еще можно сделать???

Доброго времени суток ВСЕМЪ!!! Измеряю частоту синусоидального сигнала в диапазоне от 20 до 50Гц. Периодически (примерно один раз на пять замеров) происходит ошибка измерения (отклонение от реальной в 2…3 раза в обе стороны!!!). Инициализация, обработка препывания и расчет частоты приведены ниже: void timera_init() //Clock source=ACLK //Divider=1 //TIMACLK=32,768KHz //Frequency=258,0Hz ( 3,88mS) { TACTL=0x00; //stop timer //channel0 TACCTL0=0x00; TACCR0=0x7F; //channel1 TACCTL1=0x64;//TAOM1.1,TAOM1.0,TAOUT1 TACCR1=0x7F; //channel2 TACCTL2=0x4110;//TASCS2,TACAP2,TACCIE2 TACCR2=0x00; TAR=0x0000;//clear timer counter TACTL=0x116;//TASSEL.0,TAMC.0,1,TAIE } #pragma vector=TIMERA1_VECTOR __interrupt void ta_interrupt_routine(void) { if(TACTL&TAIFG)//Если таймер досчитал до 125 { fTimeCounter++;//инкрементируем счетчик таймера. TACTL&=~TAIFG;//Чистим флаг! } if(TACCTL2&CCIFG)//Если фронт сигнала, { fTime=fTimeCounter;//снимаем количество переполнений ТА. fTime0=fTime1;//состояние ТА на начало процесса. fTime1=TACCR2;//состояние ТА на конец процесса. fTimeCounter=0;//обнуляем счетчик переполнений ТА. TACCTL2&=~CCIFG;//Чистим флаг! } } void main(void) { … //Определяем частоту: float fFreq=1/(2*(fTime*3.90625e-3+(fTime1-fTime0)*30.517578125e-6)); … } Также имеются прерывания ADC (неповторяющаяся последовательность каналов, в прерывании перезапуск). Реализую на MSP430F1122. Тактируюсь от часового кварца (32768Гц). Частота тактирования стабильная. Пожалуйста посоветуйте, что можно предпринят. Зарание спасибо всем ответившим!!!

Все понятно! HARMHARM, БОЛЬШОЕ СПАСИБО за помощь!!! Тема закрыта...

Сорри за спам... виновен... стыдно... Т.е, если я правильно догнал, OSCF актуален только при работе LFXT1 в режиме HF??? Странно, я работал с MSP430F449 с аналогичным кварцем (32768Гц), но при этом удавалось сброить OSCF без каких-либо проблем...

Добрый день ВСЕМЪ! Работаю с процессором MSP430F1122. После инициализации основного модуля тактирования флаг OSCF остается установленным (т.е. модуль не работает или работает с ошибками). Флаг не удается снять не руками, не обработкой прерывания. Инициализирую модуль так: void clock_init() { DCOCTL=0xE0;//DCO.2,DCO.1,DCO.0 BCSCTL2=0x87; BCSCTL1=0x00;//RSEL.2,RSEL.1,RSEL.0 } Расшифровка регистров: DCOCTL: DCOx=0x07 восьмая частота (по максимуму) MODx=0x00 модулятор не задействован BCSCTL1: XT2OFF=1 ХТ2 выключен (его нет) XTS=0 LFXT1 в режиме низкой частоты DIVAx=0x00 ACLK не делим XT5V=0 всегда сброшен RSELx=0x07 седьмое сопротивление вн. резистора (частота по максимуму) BCSCTL2: SELMx=0x00 MCLK=DCOCLK DIVMx=0x00 MCLK не делим SELS=0 SMCLK=DCOCLK DIVSx=0x00 SMCLK не делим DCOR=0 внутренний резистор для DCO. Использую резонатор GEYER QRZ 0.032768 KX-38T. На кварце колебания 32768 Гц - все нормально... Снял с ноги P2.0/ACLK/A1 - тоже все путем. На ноге P1.4/SMCLK/TCLK (читай DCOCLK) ~20Гц (м.б. JTAG). Пожалуйста объясните в чем ошибка и как конфигурировать??? Зарание ВСЕМЪ спасибо!

Вот! Хорошая ссылка!!! http://display.compel.ru/cntrl/index.php?menuid=4

Доброго времени суток ВСЕМЪ!!! Возникла необходимость применения купюроприемника. В настоящий момент определяюсь с выбором. Выбираю из изделий, производимых CashCode или JCM Japan Cash Mashine и ICT. Основной критерий выбора на данный момент – простота реализации протокола обмена (планирую подключать к микроконтроллеру). Из неудачного опыта предшественников знаю, что у изделий фирмы CashCode черезвычайно сложный протокол (описание протокола CCNet занимает порядка 50 страниц с описанием команд и способов отсылки этих команд, в то время как у дивайс ICT всего 10 команд). Прошу помочь определитсья с выбором и поделиться опытом реализаци. Заранее благодарен!

Спасибо! Ситуация ясна. Думаю тему можно закрывать...

Andrew2000, спасибо за ответ! 1) Вопрос исчерпан! 2) Я понимаю так, что при использовании MFC я получаю код, не требующий для исполнения виртуальную машину. Думаю, что установка платформы .NET может вызвать дополнительные трудности (соответствие версии платформы, дополнительная оплата платформы, наличие свободных ресурсов) при поставки программы клиенту, в то время, как программа, написанная c использованием MFC (на C++ например) может выполняться в чистой винде...

Здравствуйте! Я начинающий программист. В наст. время занимаюсь разработкой приложений для микроконтроллеров на языке С/С++. Возникла необходимость научиться писать приложения под Вынь. Определяюсь с выбором языка. Заинтересовался языком С#. Однако сомнения вызвал такой факт: При использовании компонентов FCL и CLR компиляторы создают модули на промежуточном языке MSIL (Microsoft Intermediate Language). Фактически компиляторы создают так называемый управляемый модуль - переносимый исполняемый файл (Portable Executable или PE-файл). PE-файл, имеющий уточнение exe, хотя и является exe-файлом, но это не совсем обычный, исполняемый Windows, файл. При его запуске он распознается как специальный PE-файл и передается CLR для обработки. Т.е., если я правильно понял, 1) для работы проги, написанной с использованием FCL и CLR необходимо наличие установленной платформы Microsoft.Net; 2) в языке С# невозможно (или затруднительно) использовать библиотеку MFC. Верны ли мои утверждения? Заранее спасибо всем ответившим! С уважением, A R T

Опытов сам не проводил, но если опираться на документацию, то получается следующее.Далее в основном цитаты, смысл думаю понятен будет. Заголовок:12-bit ADC, power supply and input range conditions.Текст: AVCC (Analog supply voltage) MIN=2,2V MAX=3,6V, а максимальное внешнее напряжение подаваемое на входы ADC должно быть Vref(VREF+) (Positive external reference voltage input) MIN =1,4V MAX = V(AVCC), т.е. 3,6V. По идее ничего страшного не будет, если питание будет 3,3V а внешнее опорное для ADC 3,6V. Если я не прав, просьба поправить. Вариант с делителем на мой взгляд наиболее приемлем. chopik, спасибо за отклик! То, что ничего страшного не будет - это понятно... Мне интересно, как (и почему) это повлияет на точность измерений. Из своего опыта: задизайнил измерение температуры в диапазоне от 10 до 150 град С. Питание 2,8В; опорное 3,2В. При таком раскладе получаю разброс измеренных значений ~1 град (это при 140 град. на входе АЦП ~2,2В...). С. Снизил опорное до 2,8В. Получил разброс ~0,4 гард...

Скажите, а если опорное напряжение превысит питающее (Ucc), как это отразится на измерении???

ТI и Компэл проводят в Екатеринбурге семинар по MSP430: http://www.compel.ru/news/company/2006072801

А обучение производите? И уровень з/пл. интересен...

Сэнкс!

Пользуюсь USB эмулятором MSPFET430-UIF уже два года. Проблем ниразу не заметил. Единственный момент, нужен IAR Embedded Workbench версии не ниже 3.21а - младшие USB не поддерживают. А что это за зверь? Дайте ссылочку, плиззз! :)

Спасибо! Читал неоднократно! ;) Только вот незадача - в статье не описывается подключение 5в ЖКИ "стекла" к LDC-контроллеру MSP430x4xx, о чем и был вопрос. А если сигналы COMх раскачать на операционниках до 5в? правда потребуется небольшое отрицательное напряжение для питания операционников. И есть вероятность паразитной подсветки выключенных сегментов. Чтобы ее не было надо раскачивать и SEGx, а это неоправданно усложняет схему. Можно попробовать запитатоь контроллер от максимально допустимых 3.6в, подать на R33 напряжение Vcc + 0.3в (отключив его внутри) а на R03 минимально допустимое Vss-0.3в. Поскольку стекло обычно имеет запас по контрасту может такого расширения диапазона будет достаточно. Спасибо! Интересные решения!!! Запытаю оба варианта. По результатам отпишу!

А чем вас не устраивает MSP-PRG430??? Поддерживает все процы и жжет security fuse...

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

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

Доброго времени суток! Помогите подобрать драйвер для ЖКИ: http://electronix.ru/forum/index.php?act=A...ost&id=7036 Заранее спасибо!

BLex, расставь точки останова и посмотри на каком этапе не получаешь аккнолиджа от АЦП...

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

Можно узнать начальный уровень зарплаты, перспективы роста (в т.ч. о разработке), а также Ваш e-mail для связи

Добрый день ВСЕМЪ и спасибо за участие!!! Искреннее сорри за неполную информацию... Резидент, справедливо... Уточняю задачу: Индикатор без чипа на стекле, т.е. планирую юзать встроенным контроллером MSP. Даташит на индикатор прикладываю. Планирую использовать с MSP430F423. По поводу живучести под 5В: угу, живучесть завидная. Сам юзал 449 на 5В неделю (по 10 часов в день)!!! Только при этом перефирия работала неадекватно (что через UART передавал, то тут же обратно принималось... режим прослушивания был отключен-стопудово!!!). И после этого проц еще долго продолжал жить и трудицца под 3В. Но в данной ситуации увеличение питающего напряжения не выход... VLUK_1323_V03_REV.B.pdf