Здравствуйте. Кто читал предыдущую мою тему "MSP430 - вопросы от чайника", тот поймет - это снова я Тему закрыли, слишком долго висела. А вопрсов все больше.
Если кому-то вдруг окажется не влом разбираться, то
Вот кусок проги:
int flag;//глобальные переменные
int cindex;
испульзуемые функции(write_flash - пишет число во flash, read_flash - считывает)
void write_flash(float* value, float *addr)
{ while(FCTL1 & BUSY);
_BIC_SR(GIE);
FCTL1 = FWKEY + ERASE;
FCTL3 = FWKEY;
*addr = 0;

while(FCTL1 & BUSY);
FCTL1 = FWKEY + WRT; for (int i=0;i<=3;i++)
{ *addr = value[i];
addr++;
}

_BIS_SR(GIE);
while(FCTL1 & BUSY);
FCTL1 = FWKEY;
FCTL3 = FWKEY + LOCK;
}

void read_flash(float* addr, float* pfO)
{
for (int i=0;i<=3;i++)
{ pfO[i]=*addr;
addr++;
}
}
Чего хочу сделать - Если присылаю 0, то должны считаться два показания с выводов P6.3 и P6.4, присылается 0хАА - т.е. "считалось", записываются первые элементы двух массивоы данных.
Когда набирается по четыре элемента, индекс сбрасывается
Если присылаю 0xFF, то должна выполнится функция calibrovka_hmc, если она выполняется неверно, то присылается 0хСС, иначе из flash считывается и присылается вычисленная с помощью этой функции константа.
Внутри функции main
ADC12CTL0 = ADC12ON + REFON + SHT0_8; //настройка АЦП
ADC12CTL1 = CSTARTADD0 + CSTARTADD1 + ADC12SSEL_1+ CONSEQ_1;
ADC12MCTL3 = INCH_3;
ADC12MCTL4 = INCH_4 + EOS;

float temp[4];
flag=0;
cindex=0;
for(;;)
{
for(delay = 0; delay <20000; delay++);
if( flag==0 )
{send_int(0x0);
}
if( flag==1 )
{

if (calibrovka_hmc(CVx, CVy, temp)==0)//calibrovka_hmc - имеет параметрами два массива и вычисляет четыре константы(нужные для калибровки устройства)

{
send_int(0xCC);
flag=0;
}
else
{
float pfO[4];
read_flash((float*)0x1000,pfO);
r=(int)(pfO[0]+0.5);
send_int®;
flag=0;
}

flag=4;
}

if (flag==2)
{
ADC12CTL0 |=ADC12SC + ENC; CVx[cindex] = ADC12MEM3; CVy[cindex] = ADC12MEM4;
ADC12CTL0 &= ENC;
cindex++;
send_int(0xAA);
flag=0;
}

if (cindex>3)
cindex=0;
}
}
#pragma vector=UART0RX_VECTOR
__interrupt void usart0_rx ( void)
{
if( RXBUF0==0xFF)
flag = 1;
if (RXBUF0==0x0)
flag = 2;
}
В ЧЕМ ПРОБЛЕМА:
Перед выполнением калибровки присылаю элементы массива, полученного при считывании показаний с выводов, - оказывается, что в массив записываются по два-три раза одно значение, хотя этого не может быть. Соответственно, из-за этого не работает и все остальное
Может, неправильно настроен АЦП? Или в чем может быть дело?
И, если кому-то вдруг не влом разбираться - функции записи во flash и чтения flash - можно ли сделать как-то поумнее?

Некоторое (продолжительное) время не заглядывал в форум, а когда заглянул оказалось, что вашу тему прикрыли.
По поводу Flash.
Проверять готовность к записи во Flash (бит BUSY) при выполнении программы записи прямо из Flash нет необходимости. Вот такая вот продвинутая технология у MSP430 Почему так, объяснять еще раз не буду. Читайте внимательно User's Manual. Проверка готовности нужна только в том случае, если ваша функция записи исполняется из ОЗУ (SRAM), а не из Flash.
Запись во внутреннюю Flash MSP430 может производится 16-и разрядными словами и/или байтами. float имеет размерность 32 бита, т.е. 2 слова/4 байта. Так что, для записи переменной float нужно как минимум две команды записи 16-и битных слов или четыре команды записи байта. У вас указатели value и addr указывают на тип float. Поэтому команды типа addr++; увеличивают значение такого указателя на 4 байта и во Flash пишется какая-то фигня. Пишите тогда уж пословно, делая явное приведение типа к 16-и битному целому.

Назначение функции чтения из Flash я вообще не очень понимаю. У MSP430 фон-Неймановская архитектура с общим адресным пространством для команд и данных. Встроенного EEPROM тоже нет. Так что выделять копирование в отдельную функцию (если только она не вызывается несколько раз) я не вижу смысла. Да и ее тоже можно оптимизировать на одну команду (выкинув addr++; ), если в теле цикла писать
Насчет всего остального.
Может у меня сложилось неверное впечатление, но похоже вы не осознаете, что такое синхронные и асинхронные события. Просто не владеете таким уровнем абстракций. Попробую объяснить на бытовом примере.
Вы когда-нибудь видели как подъемный кран работает? Внизу на земле стоит стропальщик, который крепит к крюку крана груз, а наверху в кабине крана сидит крановщик, который управляет движением крюка, стрелы и платформы крана. Причем крановщик не сам-по-себе управляет, а подчиняется управляющим командам стропальщика. Только после того как груз
- прицеплен,
- надежность крепления проверена,
- стропальщик подал команду "вира!"
крановщик включает двигатель, приводящий к движению крюка и стрелы крана. До подачи команды "вира!" крановщик просто ждет готовности груза.
У вас в системе присутствуют асинхронные процессы (измерение АЦП, прием/передача UART), а вы работаете с ними как Бог на душу положит. Стропальщик убил бы просто такого крановщика, если бы остался жив после его несанкционированных действий.
Эта иллюстрация синхронных действий. Для иллюстрации же асинхронных процессов к картине работы башенного крана нужно добавить несколько КАМАЗов с кирпичем, которые приезжают на стройку асинхронно работе крана, когда у них получится, и сваливают кирпич в общую кучу. Которую потом стропальщик с крановщиком общими синхронными действиями перемещают на строящийся уровень дома
Эта моя пространная тирада относится в частности к строке

Где вы запускаете преобразование АЦП и тут же, не дожидаясь окончания выполнения преобразования, считываете результаты оцифровки непонятно чего. Раз вы не используете прерывание от АЦП, ну подождите для приличия установки флага готовности что ли

То же самое относится к модификации флага в прерывании UART. Если вы посылаете последовательности из двух команд 0xFF и 0x00, и снова 0xFF и 0x00, но не успели считать значение какого-то флага, то его значение потеряется и вы получите дублирование команды 0xFF или 0x00. Потому, что прием через UART асинхронен выполнению основного тела программы, где эти флаги анализируются. Для того чтобы команды, принятые через UART не терялись, их нужно буферизировать, т.е. складывать в некий массив из которого в основном теле программы они будут извлекаться.
Буферы бывают линейные (типа FIFO) и циклические. По-моему для вашего случая больше подходит циклический буфер. Пример.


где-то в начале программы нужно инициализировать структуру этого буфера

В прерывании от приемника UART запись в буфер

В теле программы считывание из буфера. Для атомарности доступа к буферу на время доступа к нему временно запрещаем прерывание от приемника UART

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

Пока везет. В данном случае строка:

*addr = value[i];
скорее всего, транслируется компилятором как

MOV.W @R12+, 0(R13)
MOV.W @R12+, 2(R13)

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

*addr = 0;

транслируется в

MOV.W #0x0, 0(R13)
MOV.W #0x0, 2(R13)

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

а как тогда написать? Такая строка была в примере, который я скачала с ИАРовского сайта, - "фиктивная запись". Как тогда написать фиктивную запись ?
И вот еще ВОПРОС- понимаю, что, наверное, глупый, но -
Когда гружу прогу с помощью IAR Kickstart - работает нормально, считает четко все - я проверяла. Но так как код уже превышает 4кБ, гружу с помощью полной версии - на COM приходит полная ересь. С чем это может быть связано? Код такой же - один в один.
Я думала, может дело в доступе к библиотекам, но не ругается же на код, на #include <math.h>, работает, считает, пишет... только фигню
Вот. Не ругайтесь! - уж такая я глупая
Вот сама функция, она принимает два массива и на их основании вычисляет и пишет во flash 4 четыре константы
int calibrovka_hmc( float* V1, float* V2, float* calibr)
{

float x[4], a[3][3],d[4];
float Ox,k,Oy,kx,ky;
for (int i=0;i<4;i++)
{ a[i][0]=2*(V1[i]-V1[i+1]);
a[i][1]=2*(V2[i]-V2[i+1]);
a[i][2]= -((V2[i])*(V2[i])-(V2[i+1])*(V2[i+1]));
a[i][3]= ((V1[i])*(V1[i])-(V1[i+1])*(V1[i+1]));
d[i]=((V1[i])*(V1[i])-(V1[i+1])*(V1[i+1]));
}

if (gauss(x,a,d,3)==0) return 0;
else
{
Ox=x[0];
k=x[2];
if (x[2]!=0) Oy=x[1]/x[2];
else Oy=0;
}
kx=sqrt((V1[3]-Ox)*(V1[3]-Ox)+k*(V2[3]-Oy)*(V2[3]-Oy));
ky=sqrt((kx)*(kx)/k);
calibr[0]=Ox;
calibr[1]=Oy;
calibr[2]=kx;
calibr[3]=ky;
write_flash( calibr, (float*) 0x1080);
return 1;
}

gauss( ) - решение системы методом Гаусса, она точно работает, не буду приводить - к тому же вряд ли кому-то будет охота в ней разбираться
Такие вопросы

Конечно фиктивная запись, вот только в примере скорее всего был указатель другого типа (unsigned int или unsigned char). Как поступить в данной ситуации я вам уже выше подсказал - используйте явное приведение типа. Раз у вас указатель на float, то при фиктивной записи преобразуйте его к указателю на unsigned int.

Версии IAR одинаковы? Настройки проекта одинаковы? И вообще, спрашивается зачем использовать KickStart при наличии полной версии? Если вы не пользуетесь дебаггером, то для загрузки прошивки в кристалл использовать IAR вообще не обязательно. Пользуйтесь специальными программами. MSPFET Programmer от Kurt-а или FET-Pro430 Lite от Elprotronic или вот тут же в форуме zltigo свою утилиту AT430 предлагает.
А вообще правильность работы алгоритма программы можно проверить в симуляторе. Тем более, если у вас есть в наличии результаты работы алгоритма по известным данным.

И версии, и настройки. А кикстарт - потому что сначала был только он
FET-Pro430 Lite у меня есть. но не очень-то удобно компилироваться, а потом грузить через нее - проще и быстрее же все делать в ИАРе
Дебаггером, кстати, пользуюсь, но проверить алгоритм не получается - он не показывает текущие значения моих переменных, только регистры контроллера - то же касается симулятора

Кстати, если настройка АЦП
ADC12CTL0 = ADC12ON +REFON + SHT0_8+MSC;
ADC12CTL1 = CSTARTADD0 + CSTARTADD1 + ADC12SSEL_1+ CONSEQ_1+SHP;
ADC12MCTL3 = INCH_3;
ADC12MCTL4 = INCH_4 + EOS;
а потом
ADC12CTL0 |=ADC12SC;
ADC12CTL0 |=ENC;
while(ADC12IFG & BIT3);
CVx[cindex] = ADC12MEM3;
while(ADC12IFG & BIT4);
CVy[cindex] = ADC12MEM4;
ADC12CTL0 &= ENC;
так нормально? Или опять грузовики с кирпичами понаехали?

Не проще. C-Cpy грузит "дебажную" версию прошивки, а в реальное устройство вы будете компилировать другую версию, без дебаговских примочек. Не нравится FET-Pro430, используйте программатор Курта. Её (программу) кстати можно интегрировать в IAR, т.к. в ней имеется поддержка командной строки. Tools->Configure Tools->New обзываете ее и заполняете необходимые поля параметрами запуска программы MSPFET Programmer. Только для нее нужно использовать Release-ную настройку с форматом выходного файла TI-TXT или HEX.
Ну здрасте! А ручками в окно View->Watch имя интересуемых переменных или структур забить лень что ли? Или окно View->Locals открыть и наблюдать за автоматическими переменными.
А зачем вы включаете опору, если ее не использует е при измерении? А так... сойдет Только я бы перед запуском преобразования флаги ADC12IFG почистил бы на всякий пожарный.
Опс! Тока сейчас заметил, неверно все-таки. Нужно так.
while((ADC12IFG & BIT3)==0);
Пока флаг не установлен, нужно ждать. А у вас инверсное условие. В моем примере выше я тоже ошибся, но поправить уже не могу.

Галочка в project->options->linker->output "debug information for C-Spy" стоит?

rezident, ну вы меня уж за совсем-пресовсем тупую держите! Конечно, не лень! Но состояние переменных почему-то не отображается, вместо этого error стоит. Только состояние регистров. Я думала, это так всегда


не, это я тоже ошиблась, когда вам писала - на самом деле я, конечно, while(!(ADC12IFG & BIT3)) пишу. Ага? Тож на тож ведь. или все же не очень корректно?




А вот не знаю. Посмотрю, спасибо

Ну зачем же сразу такие эпитеты? Я просто делаю скидку на женскую альтернативную логику. Извините, если обидел.
=DS=, указал вероятную причину.
Да пишите себе на здоровье, раз вам такой стиль нравится! Просто я лично при проверке условий предпочитаю явное сравнение с нулем. Для меня так нагляднее и понятнее. Но в свою "религию" я никого насильно не обращаю

Так вот. Галочка стоит. А состояние переменных все равно error
По поводу ошибок в программе - у меня, кстати, все-таки разные версии, Kickstart 5.0, a Evolution 4.0. Но разве это может повлиять.? Ведь не ругается, все считает... Что-то не так с #include <math.h>? А, еще - они стоят вместе. Могут, перепуться библиотеки?
Теперь такие вопросы:
rezident, вы вот давно обещали помочь разобраться с таймером Так, как я это делаю(по переключению флага ) - не пойдет "Камазы с кирпичами", да и только При большой скорости пересчета, в принципе, можно забить на некоторые неточности, но, когда нужно выполнять что-то четко по команде...
Вы говорили, что можно использовать выход таймера. Как? Ведь мне не нужно постоянно переключать вывод, нужно долго держать его в единице, а потом короткое время в ноле.
Еще- если я запущу еще и таймер В - это не будет излишней перегрузкой программы? Дело в том, что мне надо постоянно фиксировать состояние переменной azimut и где-то раз в секунду смотреть, не изменилась ли она, если изменилась - отсылать команду на COM. Что, если делать это по таймеру В?
Короче - помогите, спасите

Ну я не знаю. Попробовал я в своем текущем проекте убирать "птички" в опциях проекта везде, где только встретил "Generate debug ...". В режиме отладки пропала возможность "шагать" по Сишному исходнику. Только по ASM-овому тексту теперь шагает. Но значения глобальных переменных в окне Watch и локальных переменных в окне Locals все равно показывает. Может вы пытаетесь в окне Watch значение локальной переменной посмотреть? Тогда понятно почему ошибку выдает.
В один каталог крайне не рекомендуется устанавливать разные версии одного продукта. Если только с одинаковой версией IDE, но для разных целевых платформ (например, EWAVR и EW430). Устанавливайте версии KickStart и Evalution в разные каталоги, тогда путаницы не будет.
У таймеров MSP430 имеется режим compare (сравнения), в котором содержимое регистра TAR/TBR (которое постоянно инкрементируется по тактовым импульсам TACLK/TBCLK) сравнивается с capture-регистрами CCRx. При совпадении CCRx и TAR/TBR происходит установка флага CCIFG в соответствующем регистре CCTLx, а если разрешено прерывание для этого регистра (установлен бит CCIE), то еще и генерируется вызов прерывания по соответствующему вектору. Векторов для каждого таймера по две штуки. Один для CCR0, второй вектор расшарен для всех остальных CCRx. Манипулируя содержимым CCRx, вы можете генерировать прерывания для разных отметок времени. Кроме этого, для каждого блока compare имеется выходной модуль, который по возникающим событиям таймера может управлять состоянием бита OUT в CCTLx и ассоциированного с ним пина (или пинов, т.к. для TimerA эта функция выведена на несколько пинов) TAx/TBx. По событию совпадения TAR/TBR и CCRx бит OUT может быть сброшен, установлен, проинвертирован. Совпадение TAR/TBR и CCR0 действует на состояния всех битов OUT во всех выходных модулях таймера. По этому событию (от CCR0) бит OUT также может быть сброшен, установлен, проинвертирован. Таким образом можно генерировать ШИМ. Например, если для TA1 выбрать режим выходного модуля "сброс/установка", то по совпадению TAR и CCR1 вывод TA1 сброситься в лог.0, а по совпадению TAR и CCR0 установиться в лог.1. Режим выходного блока задается для каждого регистра индивидуально. Исключение составляет только CCR0, т.к. он действует сам на себя дважды за период, если выбран режим счета CountUp или Up/Down в которых период счета определяется содержимым этого CCR0.
Я предлагал вам использовать TimerA в режим счета Continious (с переполением). Выходной модуль TA0 или TA1 использовать для генерации выходного управляющего импульса, который одновременно запускает преобразование АЦП в непрерывном режиме последовательности каналов. Вам нужно только в прерывании от CCR0 или CCR1 вести счетчик и при достижении предпоследнего интервала отсчета импульса перепрограммировать режимы выходного блока и вовремя остановить АЦП для нового запуска по другому фронту TA0 или TA1.
Вот. Утомился я что-то "на пальцах" пересказывать содержимое User's Manual. Если еще непонятно, то пояснения будут уже завтра.
Кстати, не помню, давал ли я ссылку на русскоязычный переводной вариант User's Manual? На всякий случай продублирую ссылку на Компэловскую библиотеку.
Нет особой разницы на какой таймере вести счет временных отметок (пауз). Если вам так удобно, то задействуйте TimerB. Хотя необходимости в этом я не вижу. У вас уже имеется счетчик на TimerA. Просто добавьте в процедуру прерывания еще один счетчик с удобным весовым коэффициентом. Я предпочитаю вести счет времени в миллисекундах. Например, используя WDTimer и ACLK от часового таймера.

В основном теле программы я беру абсолютную разницу (беззнаковую разность) между двумя считанными значениями переменной TMTick и получаю прошедший интервал времени. Учитывая необходимость атомарности доступа к переменной системных тиков, выбираю ее тип unsigned int. Этот тип позволяет определять интервал времени до 65,5 секунд (период переполнения переменной). Если нужны бОльшие интервалы времени, то нужно брать 32-х битную переменную, но тогда придется запретом/разрешением прерывания или другими способами обеспечить атомарность доступа к ней.
Еще замечание насчет примененной корректировочной таблицы. Поскольку период частоты, полученной от деления частоты часового кварца (32768Гц) на делитель WDTimer (512), не является целой величиной миллисекунд (15,625мс), то я корректирую точность системных тиков с помощью таблицы. И на периоде 250мс получаю целое число миллисекунд.

Ничего подобного Все же не совсем, не совсем я даунито, я уже говорила. Локальные переменные смотрю, где надо
Об остальном - rezident, какой же вы все-таки хороший! Так все подробно и хорошо. Та функция, которую хотела сделать, вроде работает, а про таймеры... В принципе я пыталась сделать нечто подобное, но возникли проблемы Какие именно, напишу чуть позже, когда еще раз попробую переделать, руководствуясь вашими комментариями Спасибо, конечно, огромное. буду разбираться

Здравствуйте, снова я

Все же я какая-то непонятливая допустим, режим Continious и режим "сброс/установка", по совпадению TAR и CCR1 вывод TA1 сброситься в лог.0, а по совпадению TAR и CCR0 установиться в лог.1. Но максимальное число. которое я могу записать в CCR0 - FFFF. А мне нужно держать лог. 1 долго. Как быть? Может, установить сначала режим "установка", в прерываниях от CCR0 вести счетчик, а в последнем переключить режим на "сброс". В следующем за ним прерывании опять "установка". Можно так сделать? Вы об этом говорите?
Да, а по поводу версий IAR - дело было просто в глючности самой ломаной версии 3.2

Да, режим сброс/установка только для формирования сигнала длительность которого меньше периода перезагрузки таймера и для более точного формирования времянки сигнала. Хотя. если задержка на вход в прерывание от таймера у вас детерминирована и по времени вполне устраивает, то вовсе не обязательно формировать сигнал аппаратно. Можно оставить все как у вас сейчас уже работает. И запуск АЦП делать прямо в таймерном прерывании.

Сейчас не очень хорошо. Понадобилось вот стыковаться, а у меня с синхронностью выявились большие проблемы Надо, чтобы все было четко-пречетко. И без камазов с кирпичами То есть, можно сделать так, как я говорю?
а вот по поводу АЦП:
Мне сказали, что цикл while(ADC12IFG & BIT3); - это некорректное использование процесссора. типа, чего он будет столько тиков в пустую ждать. Надо работать с прерываниями. и вот вопрос -
Прерывания. как я понимаю, приходят после установки флагов ADC12IFGx, которые устанавливаются после заполнения ADCMEMx. Если режим повторно-последовательный, то прерывания будут после обработки каждого канала?
А вот в найденном примере в прерывании пишется
static unsigned int index;
resault[index] = ADC12MEM0;
resault[index] = ADC12MEM1;
resault[index] = ADC12MEM2;
index=(index+1)%8;
как же так? ADCMEM0 заполнен. пришло прерывание, а в прерывании считывается и ADC12MEM1, и ADC12MEM2... они же могут быть еще не заполнены? Нужно было бы по идее писать
if (ADC12IFG & BIT0)
resault[index] = ADC12MEM0;
if (ADC12IFG & BIT1)
resault[index] = ADC12MEM1;... разъясните, пожалуйста.
И вот еще вопрос - index объявляю глобальным, массивы СV1[], CV2[] - тоже. В прерывании веду счетчик(index++), заполняю массивы. В теле проги, если index>=10, ADC12CTL0 &= ENC;
Отправляю сразу по заполнению себе на COM элементы массива - вроде все нормально, заполняются. А после остановки АЦП они пустые, и счетчик 0. В чем тут дело?
Подскажите, помогите.

Верно. Глупый простой получается.
Количество прерываний зависит от установленных флагов разрешения прерываний в регистре ADC12IE. Если вы используете непрерывный режим преобразования по кольцу, то достаточно установить только один бит, соответствующий последнему каналу. И при возникновении прерывания одним чохом считывать все регистры ADC12MEMx. Одно преобразование ADC12 занимает 13 тактов ADC12CLK. Да плюс еще время сэмплирования каждого канала. Максимальное количество каналов преобразования у ADC12 - 16, время на считывание одного канала не более 5 тактов MCLK, так что если частота MCLK не слишком низкая (у вас вроде 8Мгц была?), то вполне можно успеть считать результаты всех преобразований до того, как обновится результат преобразования ADC самого первого в очереди. Если же не будете успевать (например, MCLK значительно ниже ADC12CLK), то можно два, три бита разрешения прерываний в ADC12IE установить, но с некоторым интерливом. Частоту вызова прерываний надо стараться делать поменьше и время нахождения в прерывания соответственно тоже.
Не совсем понял суть проблемы. Видимо опять на код нужно взглянуть. Могу только предположить, что вы неправильно управляете остановом АЦП. Прочитайте внимательно в User's Manual как нужно корректно останавливать преобразование когда используется непрерывный режим преобразования последовательности каналов. Просто сбросить бит ENC в этом случае недостаточно. Останов произойдет, только после завершения всей последовательности преобразований
http://www.gaw.ru/html.cgi/txt/doc/micros/msp430/arh/17.htm

Ага, ясно. Спасибо


да читала, читала, и не один раз. Соображение, видимо, хромает. Как говорил Винни-Пух - "оно хорошее. Только почему-то хромает" Ну и пусть останов произойдет после завершения последовательности, этого и хочу- последний канал обработал и остановился. А прямо из прерывания остановить нельзя? А то как-то неудобно получается. Хочу считать только десять выборок. если вести счетчик в прерываниях, а потом if index>=10, то реально больше считает, пока проверит, пока остановится. понятно, что если массивы задать жестко [10], то остальные значения по фиг. Но зачем же лишнее время работать. Или тогда уж не повторно-последовательный режим делать, а просто однократный последовательный, и ровно десять раз запускать? тоже как-то странно.
Подскажите!

Можно. Первой же командой в прерывании установите CONSEQ=0 и ENC=0. Преобразование остановится немедленно.
А режим однократной последовательности каналов вас не устраивает? Там правда битом ENC нужно "тогглить" после окончания каждой последовательности.

Так. Ну вот, как-то не выходит ничего
Если в прерывании тормозить
#pragma vector=ADC_VECTOR
__interrupt void ADC12ISR (void)
{
CV1[cindex] = ADC12MEM3;
CV2[cindex] = ADC12MEM4;
ADC12CTL0 &= ENC;
index++;
if (index==9)
{ ADC12CTL1 &= CONSEQ_3;
ADC12CTL0 &= ENC;

}
}
То все равно долго тормозится, несмотря на сброс ENC. успевает прийти еще куча прерываний. Ну и, естественно, если в теле проги сбрасывать, то тоже долго останавливается. Как быть?
И, главное
if (flag==2)
{
ADC12CTL0 |= ADC12SC;

if (index>=9)
{
//АDC12CTL0 &= ENC;
flag=0;
CVx[cindex]=filter(CV1,10);
CVy[cindex]=filter(CV2,10);
index=0;
cindex++;

}
}
if (cindex>3)
cindex=0;
После старта АЦП до того, как успевает прийти 10-е прерывание, условие if (index>=9) уже проверяется, после остановки АЦП выход из последнего прерывания на строке if (cindex>3), потом - к началу проги, попадая сверху-вниз снова на строку if (flag==2), входит в if и запускает АЦП То есть в условие if (index>=9) просто никогда не попадает.
Как быть? Подскажите темной непросвещенной женщине, как грамотно это написать - нужно набирать массив, останавливать АЦП и усреднять данные набранных массивов. Блин, с циклами while все было просто и понятно

Может так?

Что такое cindex++ и почему не в прерывании? Можно его заменить на index++ ?
.

Все дело в том, что вы маски неверно накладываете. Команда

сбрасывает все биты кроме CONSEQ0 и CONSEQ1, а нужно наоборот - сбросить только эти два бита. Вот так

или вот так

Следовательно ваш обработчик прерывания будет выглядеть так.

Насчет остального не совсем понятно. Что за index, что за cindex и что за flag? Опишите реализованный вами алгоритм более полно.

Daria,
(хм, мою внучку так зовут ),
предлагаю идею алгоритма.

Главное правило - ничего не усложнять, и не делать сложных условий и ожиданий.
У MSP430 быстрый АЦП, хорошо работающий в режиме последовательного измерения всех каналов.
Инициализируется вот так (у меня тактируется от таймера B, в качестве опорного берется напряжение питния):



После этой инициализации в регистрах ADC12MEM0...ADC12MEM7 результат последнего измерения соответствующего канала. Берите его в любой момент времени и используйте.

Хм. Серьезно? Вот просто так и ничего больше не надо? Надо попробовать, большое спасибо. А прерывания АЦП запретить?
Но вот по поводу прерываний - я переделала прогу и получилось гораздо хуже, чем с циклами while
Вот код:
Настройка АЦП(еще раз, на всякий случай)
ADC12CTL0 = ADC12ON + SHT0_8+ MSC;
ADC12CTL1 = CSTARTADD0 + CSTARTADD1 + ADC12SSEL_1+ CONSEQ_1 + SHS_1 + SHP ;
ADC12MCTL3 = INCH_3;
ADC12MCTL4 = INCH_4 + EOS;
ADC12CTL1|= ENC;
После всех настроек
for(;;)
{send_int(azimut);
}
}

#pragma vector=TIMERA0_VECTOR
__interrupt void TimerA0(void)
{ _BIC_SR(GIE);
i++;
if (i >= 2000)

{ i = 0;
P1OUT = 0;
TACCR0 = 0;

ADC12CTL0 |= ENC;
Vs[0] = ADC12MEM3;
Vs[1] = ADC12MEM4;
ADC12CTL0 &= ENC;
TACCR0 = 2000;
}
if (i == 1)
{
TACCR0 = 0;
P1OUT = BIT5;
TACCR0 = 5000;
}

_BIS_SR(GIE);
}

#pragma vector=ADC_VECTOR
__interrupt void ADC12ISR (void)
{_BIC_SR(GIE);
if (P1OUT & BIT5)
{
ADC12CTL0 |= ENC;

while(ADC12IFG&BIT3);
Vr[0]= ADC12MEM3;
while(ADC12IFG&BIT4);
Vr[1] = ADC12MEM4;

ADC12CTL0 &= ~ENC;


offset[0] = (Vs[0] -Vr[0])/2;
offset[1] = (Vs[1] -Vr[1])/2;

Vx = Vr[0] - offset[0];
Vx = Vr[1] - offset[1];

float F[2];
azimut = calculation (Vx,Vy,F);


}

_BIC_SR(GIE);
}
Делается то же. что и всегда Вывод в единице, постоянно по переключению таймера снимаются показания с датчика Vr и ведется счетчик прерываний. после 2000-го прерывания вывод переключается в ноль и снимаются показания Vs. Вычисляются смещения и calculation - основное вычисление.
в чем проблема - получается, что постоянно сижу в прерываниях, работает все очень медленно и глючно Индексы глобальные. но если попытаться перенести все эти if в цикл for(;;), то ничего не работает. Может оттого, что выход из прерывания происходит в то место, из которого в это прерывание ушли, и проверка условий просто постоянно "проскакивает". Короче попытка перенести любой из if в цикл for не работает, а так, как у меня - работает, но ужасно Да, наверное не обязательно постоянно дергать битом ENC, но без этого тоже не работает беда, да и только
Вот то, что Вы, уважаемый Dog Pawlowa, сказали про АЦП - это оч хорошо, проблема только в том, что надо четко отличать, когда преобразование АЦп относится к короткому импульсу(P1OUT=0), а когда rк длинному (P1OUT= BIT5)/
Вот такой огромный вопрос

Daria, извините за откровенность, но у вас какой-то бред получается Вы вообще понимаете суть и механизм работы прерываний? Я не знаю вашего возраста и семейного статуса, но надеюсь что "детская" ассоциация разъяснения сути прерываний будет вам понятна.
Представте себе, что вы - мама. Сидите на лавочке с подругой и беседуете. Рядом в песочнице ковыряется и бегает возде нее ваш малыш. И вот в произвольный момент времени малыш подбегает к вам и, прерывая ваш разговор с подругой, спрашивает: "мама, а правда, что море мокрое?" "Правда", отвечаете вы. Малыш, удовлетворенный ответом, убегает, а вы возвращаетесь к разговору с подругой. Через некоторое (опять недетерменированное время) малыш снова подбегает к вам и, прерывает разговор, очередным вопросом: "мама, а небо голубое?" "Конечно голубое, сынок. Подними голову и убедись сам", отвечаете вы. Малыш, задрав высоко голову, долго рассматривает проплывающие в голубом небе облака, а вы по-прежнему продолжаете отложенный разговор с подругой.
Такая аналогия вам понятна?
Развиваю мысль дальше.
Запрет прерываний. "Сынок, перестань отвлекать маму вопросами. Дай маме с тетей спокойно поговорить."
Разрешение прерываний. "Сынок, у тебя там все нормально? Никто тебя не обижает? Ну если что-то случится сразу беги ко мне и скажи."
Тот исходник, что вы привели можно переложить на детский сюжет так.
Мама, вместо того, чтобы разговаривать с подругой, отпускает малыша в песочницу и внимательно следит, чтобы он не упал и не перепачкался. Как только ребенок падает, она, отряхнув его одежду, говорит: "Ну вот, смотри как ты перепачкался! Не ходи больше в песочницу, поиграй рядом с мамой, пока я с этой тётей побеседую". Усадив ребенка рядом, продолжает беседу.
А эта аналогия понятна?
Вы запускаете преобразование АЦП и, не выходя из прерывания, ждете окончания преобразования и установки бита готовности. Спрашивается ЗАЧЕМ? Факт возникновения прерывания УЖЕ является свидетельством о том, что преобразование выполнено и в регистре ADC12MEMx находится готовое значение. После перехода по вектору прерывания вам нужно только считать это значение и при необходимости (пере)запустить или остановить цикл последующих преобразований АЦП. Ждать готовности преобразования, находясь прямо в прерывании нет никакой необходимости!

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

И еще просьба. Оформляйте, пожалуйста, ваш текст исходников в теги code. Это такая решеточка над полем редактирования сообщения. Так сохраняются все отступы и код получается более удобным для восприятия.

2rezident: я восхищен силой вашего воображения ))

+1
резиденту зачот!

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

Если вы еще раз заглянете в User's Guide и внимательно прочитаете главу 2.2.3 Interrupt Processing -> Interrupt Acceptance, то там пункт №6 гласит

Бит GIE находится к статусном регистре SR, который при переходе по вектору прерывания очищается (за исключением бита SCG0). Т.е. переход на программу обработки прерывания запрещает все маскируемые прерывания автоматически. Поэтому дополнительно запрещать все прерывания в обработчике прерывания нет необходимости. Находясь в прерывании можно разрешить прерывания, если вы контролируете размер стека и готовы к ситуации с вложенными прерываниями.
Вы можете запустить преобразование АЦП синхронно с переключением выхода, но выкинуть из расчета результат первого преобразования, используя время, затраченное на это преобразование, как временнУю паузу. Либо использовать этот же таймер (CCR2, например) для генерации временнОй отметки запуска преобразования АЦП. Ожидать в прерывании возможности запуска АЦП имеет смысл только, если требуемая пауза совсем небольшая, не более полусотни тактов MCLK. ИМХО.

Ясно, спасибо

Ух-х, какие крутые виражи! Ух, как человека мысли колбасят:

И сразу же, не давая осознать -- ба-бах!


Rezident -- восхищаюсь Вашим терпением. Буду счастлив, если даму удастся выдернуть из девичьего восприятия мира. Да, длинный путь предстоит, долго ей топать. Но, человека надо вытаскивать. Тем более, сам чел этого хочет.

Daria, не останавливайтесь на полпути! Мы все за Вас переживаем и хотим получить полноценного товарища. Глупой Вас никто не считает, просто склад ума/логика мышления у Вас несколько иные. Это не плохо и не хорошо, это -- просто имеет быть.

"Не важно -- кто ты и где ты сейчас. Важно -- куда ты живешь" (С) не помню чье.
Всех благ!

Я сама восхищаюсь его терпением Я бы себя уж давно послала, причем с громкими выкриками

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

Надеюсь, аппетит не пропал?

И Вам!! Спасибо за мнение

Rezident, по поводу буфера, пример которого вы приводили. А что, если cbuf.rIdx будет равен cbuf. wIdx +1? Т.е. если считывание "обгонит" запись? Может, стоит поверять if((cbuf.cntr< max_bufsize)&(cbuf.rIdx !=cbuf. wIdx +1))?
Или опять мойс клад ума/логика мышления меня подвел? тогда - ой, беда, беда - огорчение.

Вы про циклический буфер? Считывание не может обогнать запись, т.к. перед считыванием должен проверяется счетчик записей. Если счетчик равен нулю, то буфер пуст. А если при этом имеется "разбег" индексов, то его нужно обнулить, установив оба индекса в начало буфера. Только при этом конечно же нужно соблюдать атомарность доступа, чтобы не произошло сбоев записей при одновременном доступе к переменным индексов и счетчика. Атомарность доступа можно обеспечить временным запретом прерываний.
В дополнение. Ситуация когда cbuf.rIdx будет равен cbuf. wIdx +1 не исключена. Но она может быть только в случае, когда весь буфер заполнен. При этом счетчик элементов буфера должен иметь значение равное размеру буфера.
Хотя пожалуй нет. Я ошибся. Счетчик в этом случае будет равен размер_буфера-1. Т.к. для полностью заполненного (и для пустого) циклического буфера значения индексов д.б. равны.

Ага, будем считать с буфером приема разобрались Теперь что касается передачи. Во-первых, все-таки мой старый вопрос - как в этом случае обойтись без этих циклов while, которые ждут установки флага о готовности? ведь тут тоже пустой простой... Что касается буфера, то у меня как-то не получилось и даже наверное не буду приводить код, опять будете смеяться Хотя бы принцип верный? -
Запись в буфер идет в прерывании АЦП, считывается постоянно в цикле for(;;); так как вообще говоря передача должна идти посылками по 4 байт (стартовый символ"*", два байта данных (int) и стоповый "#"), то считывается сначала в массив [4], а этот массив передается по байтам через регистр U0TXBUF. Но, когда передается, как обойтись без этих while?

О-хо-хо... Ну да ладно!

Даша, я предполагаю, что Вы только-только подходите к понятью принципов работы событийно-управляемых (event-driven) автоматов. Вы уже освоили линейное и процедурное
программирование, теперь перед Вам открывается совершенно другой мир. Другая планета. Здесь все не так.


Извините, маленькая лекция.

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

Во первых, это бесконечный цикл, тело которого состоит из вызова трех функций. Пусть они будут называться так:
GetKey()
DoSomething()
DisplayResult()
чтобы не усложнять, аргументы функций пока опустим из рассмотрения. А вот названия функций говорят сами за себя -- получить код нажатой клавиши, выполнить какое-то действие, вывести результат.

Вот основной цикл нашей программы:


Рассмотрим вызов функция GetKey(). Вроде бы все ясно -- функция должна вернуть код нажатой клавиши. А что делать, если ни одна клавиша не нажата? Значит, функция не вернет управление. Допустим, что это так. Тогда получается, что наше устройство постоянно как-бы зависает на этой функции.

И действительно, посчитать результат и вывести его -- занимает не так уж и много времени по сравнению с тем, что юзер нажимает кнопочки. Юзер вообще может вообще пойти попить кофейку.

Но для этого устройства такое построение программы допустимо. Поскольку предопределенные действия выполняются только тогда, когда юзер соизволит нажать кнопочку. С другой стороны, нет нажатия -- значит, и делать ничего не надо! Пока все срастается.

Так было раньше, когда программы были маленькие, процессоры глупенькие, а деревья большие. Но мир изменился. Сейчас МК стали обладать многими периферийными устройствами и интерфейсами, которые зачастую работают одновременно.

Противоречие в современных устройствах заключается в том, что периферийных устройств много, а "думатель" (АЛУ) -- один.

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

Добавляя в цикл две функции GetCurrentTime() и (), мы не решим проблему.


Понятно, что управление, зависая в GetKey(), будет блокировать всю программу. Понятно, что часы будут подновляться только при нажатии какой-либо кнопочки. Страшно неудобно. Такое изделие никто не купит. Что делать?

Можно пойти двумя путями. (Сразу скажу, Вы, Daria, как мне кажется, в своей программе идете первым путем.)


Путь первый (а-ля-DOS): добавить еще пару функций IsKeyHit() и IsTimeChanged(), которые будут возвращать управление сразу. Такие функции еще называют неблокирующими. Эти функции "говорят" только о том, что нажата ли вообще какая-нибудь клавиша или нет, изменилось ли время или еще нет.

Теперь наш цикл будет выглядеть так:



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

Второй путь (а-ля-Windows): Это то, о чем я говорил в самом начале поста, это событийно-управляемый автомат. Работает эта штука следующим образом.

В таком автомате (системе) есть два дуальных механизма.

Первый -- регистрирует происходящие в системе изменения (события) и записывает в очередь соответствующее сообщение об этом событии. Очередь надо понимать чисто в компьютерном смысле -- т.е. бесконечный (кольцевой) буфер.

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

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


Итак, возвращаемся к событийно-управляемым системам. Поставщиками событий в первую очередь являются не что иное, как всевозможные прерывания от периферийных устройств. Во вторую очередь, это могут быть какие-то результаты работы программы. (Я догадываюсь, сейчас это несколько сложно понять. Но что делать? Ведь не всегда бывает легко с первого раза въехать в какие-то новые понятия. Тем более, если эти понятия очень емкие и не вписываются в установившиеся, привычные для нас рамки. Терпите. Учитесь. Другого пути нет.)

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

Еще пару-тройку раз для уяснения:

Произошло перещелкивание секунды в таймере -- возникло прерывание. Заходим, записываем сообщение в очередь, выходим.

Закончил АЦП измерение -- прерывание. Заходим, сообщение в очередь, выходим.
Очередной байт отправлен (по USART-у) -- прерывание. Заходим, сообщение в очередь, выходим.

Думаю, идея понятна?


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

Теперь нам не надо периодически пробегать (говорят – заниматься поллингом) по всем нашим ПУ, опрашивать каждое – есть ли нажатие кнопочки или нет, говов ли АЦП или нет, тикнул ли таймер или нет.

Вместо всего этого, теперь имеется единственная функция GetMessage() и вслед за ней располагается так называемый кракер сообщений (т.е. расшифровщик). Задача этой "парочки" -- вытянуть из очереди сообщение, и вызывать соответствующую функцию по его обработке.

Выглядит это намного приятнее:


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

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

Не надо также забывать, что обработчики сообщений не должны долго работать, т.е. они не должны узурпировать процессорное время. Я как-то занимался одним проектом. Там нужно было выводить инфу на графический LCD, одновременно нужно было оперативно реагировать на кнопочки и держать связь с компом и дюжиной периферых устройств, подцепленных к двух UART'ам. Сложность состояла в том, что LCD подключался по квадратной (I2C) шине. Длина шлейфа была метра полтора. Я не рискнул, "зажигать" его на 400 кГц. А на 100 кГц, обновление экрана занимало почти четверть (или даже более, не помню точно!) секунды. Если бы обновление LCD было реализовано в одной функции-обработчике, то это легко бы привело к переполнению очереди сообщений. В моменты перерисовки дисплея реакция на клавиатуру отсутствовала бы, связь бы с ПУ нарушалась бы. Приятного мало.

Я сделал так, я разбил LCD на несколько областей, и для перерисовки каждой области создавал свое индивидуальное сообщение. В результате, перерисовка LCD выполнялась как серия перерисовок его отдельных областей. Эта серия сообщений, понятно что, могла быть "разбавлена" сообщениями от клавиатуры и от других ПУ. В целом это создало картину практически мгновенной реакции на нажатие клавиш, способности устройства рисовать на экране и одновременно (и без задержек) заниматься периферией, отвечать компу на его запросы.

Не знаю, что еще можно добавить. С одной стороны, сказать еще много чего можно, а с другой... а то-ли это место (форум), где надо много говорить?

Насчет критики. Я, вобщем-то, как-то не рассчитывал на нее. Просто писал и все. Даже не столько пытался ответить Daria, сколько вообще хотел поделиться своим опытом. Но поскольку я тут много чего сказал, критика должна быть.

Дык точно также как вы с АЦП делаете. Использовать передачу по прерываниям.
uart0.h

main.c

Я использовал в примере typdef на случай, если вы разбиваете проект на отдельные модули. Если же у вас вся программа в одном файле, то можно объявить структуру uart прямо перед main-ом. Вместо строки

Бит разрешения прерывания от передатчика UART0 я использовал как флаг готовности буфера передатчика. Он устанавливается в main, одновременно разрешая прерывания от передатчика и сбрасывается в обработчике прерывания по завершению передачи буфера. Для передачи 4-х байтного пакета будут 5 прерываний от передатчика UART0. В последнем прерывании передачи символа не будет, а будет лишь сброшен UTXIE0.

Извините, но у вас ерунда написана. Функция GetKey() никогда не циклится на опросе, а всегда и в любом случае возвращает код нажатой клавиши, иначе она бы называлась не GetKey, а WaitKey Только в случае когда ни одна клавиша не нажата функций GetKey возвращает скан-код NULL. А если идет запись в буфер клавиатуры, то просто запись туда не производится. Поэтому бесконечный цикл вовсе не зависает на опросе клавиатуры, а крутится себе как и положено Естественно, что в функции DoSomething() должна быть предусмотрена обработка скан-кода с кодом NULL.

Не, не! Не стоит так сильно реагировать на имя!

Функция GetKey() -- это моя функция, не библиотечная. Про библиотеки не говорю. Более того, я не писал готовый коупи-пэйст код, а излагал парадигму. Жаль что Вы зацепились за эту мелочь. Если Вас это очень смущает, ну замените что-ли название функции на GetPressedKey().

Да меня вообще не волнует названия функций , а "прицепился" я как раз а вашей "парадигме", то бишь к описанию алгоритма "вечного цикла". Я бы еще понял зацикливаение на опросе клавиатуры, если бы перед этим MCU ушел в режим "спячки" для энергосбережения. Вы же описали другой алгоритм, который я не считаю оптимальным в частности и верным в общем. А если вы хотели описать "парадигму" расслоения на os, driver и application, то извините, сделали это не очень внятно.

не надо -- Я не описывал расслоение. Я описывал только парадигму событийно-управляемой системы. Т.е. ситему, которая работает на принципе реагирования на какие-либо события. Система не занимается поллингом. Система ждет событий, в свободное от работы время совершает холостые циклы. Если хотите -- может вообще спать. Не проблема!

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

Изложенная мною (но не я автор!) парадигма построения программ, предполагает, что она применяется к устройствам, которые намного сложнее, чем простой генератор прямоугольных импульсов. Да, действительно, там проще и легче в основном цикле программы сначала проверять конкретное ПУ (UART, ADC, таймер,...) и, если оно готово, вызывать соответствующую функцию. После чего переходить к проверке следующего ПУ. И т.д. до конца цикла.

Да-а-а утром отправляю вопрос, иде себе спокойненько по своим делам, захожу вечером, а тут!... Целая переписка Маркса и Энгельса! Я, когда защищалась на своем матфаке, то у меня доп. диплом был по квалификации "преподаватель" Этот диплом представлял собой цикл лекций по истории развития теории вероятностей. Там тоже было много всяких примеров, баек и исторических справок. к чему это я? А к тому, что вам, господа, особенно вам, zhevak, можно не только диплом защищать по специальности "преподаватель программирования контроллеров" , а целую кандидатскую по теме "история развития программирования контроллеров и ваще программирования"
Но - если чел находит столько времени, сил и желания помочь и рассказать, то - большое спасибо, заходите еще, буду рада и все такое. Rezident, ваша лекция про детей и песочницы тоже была просто класс
Да, rezident, я давно знала, что вы хороший, но вы - ПРОСТО СУПЕР! Большое спасибо за помощь. Даже не знаю, как вас благодарить за месяцы мучений со мной(а еще сколько предстоит... )
На досуге подумаю об этом (ну, ну - утихомирьтесь, случайно заглянувшие сюда пошляки) Будут пожелания - высказывайтесь Есть пара непоняток по вашему коду, но пока не буду спрашивать - вдруг в процессе внедрения сама пойму
заходите обязательно еще!
Эх, кто бы мне еще по поводу датчиком HMC помог - непонятки все же с калибровкой... т.е. самый простой способ понятен и почти работает, но при таком ТЗ он никак не годится... В разделе "датчики, метрологи и т.п." все на эту тему молчат но это так, мысли вслух, и к теме не отностится

здравствуйте снова. Такой вопрос - во время работы проги, для того, чтобы выполнить калибровку, хочу перенастроить АЦП из однократно-последовательного режима в повторно-последовательный. И для калибровки работать без прерываний. Это ведь делается редко и при выполнении калибровки все остальное вообще не работает, можно же тогда и с циклами while, правильно? Дело в том, что все остальное делается теперь по прерываниям и, запрещая их, очень легко и просто все останавливаю. Так вот. Могу я написать так:
ADC12CTL0&= ~ ENC;
ADC12CTL1 &= ~ CONSEQ_1
ADC12CTL1 |= CONSEQ_3
Ну и после калибровки
ADC12CTL0&= ~ ENC;
ADC12CTL1 &= ~ CONSEQ_3
ADC12CTL1 |= CONSEQ_1
Нет тут какого-нибудь недопустимого действия? А то мало ли, чего мое альтернативное мышление натворит

Можно. Даже нужно. Чтобы не переопределять основной алгоритм измерения в прерывании.
Можно, только аккуратнее с битовыми масками. Чистить биты CONSEQx лучше всегда так

чтобы каждый раз не задумываться и случайно не "пролететь", ошибившись с предыдущим режимом измерения ADC12. Ну и конечно после изменения режима, не забыть вновь разрешить преобразование, установив ENC. А так, все верно, за исключением того, что хорошо бы изменить порядок сброса CONSEQx и ENC. Сначала останов последовательности преобразований сбросом CONSEQx, а потом сброс ENC. Это может быть существенным когда вы используете (разрешили) прерывание ADC12.

Спасибо!

Здравствуйте. rezident, по поводу примера буфера передачи, который Вы написали
для чего делается вот это
#pragma pack(2)
...
#pragma pack()
Как я понимаю, это выравнивание? т.е. #pragma pack(2) - теперь структура будет иметь четное количество байтов, а #pragma pack() - возвращение к установке "по умолчанию"? Так или не совсем? А зачем тогда именно pack(2)? Если написать pack(1) - то будет ровно то количество байт, которое задается, т.е. четыре.
? Объясните чуть подробнее, пожалуйста. И еще - почему именно buf[10], чем обусловлено 10 и как его выбирать?

И вообще мне не понятно, при таком протоколе, а это вроде довольно распространенный: *, данные, #- как быть при приеме? Вот цифровое значение # - 35, а если приходит такое число? Вот азимут у меня, допустим, 35 - тогда же путаница получится?
Вот у меня такой флажок 0хFF - уникален, учитывая, что передаю по 6 бит А как обычно делают?

Да, это выравнивание структуры.
Нет, не "иметь четное количество байт", а члены структуры будут выровнены на границу 2-х байтового слова.
Да.
Потому, что MSP430 16-и разрядный микроконтроллер и доступ к переменным структуры по невыровненному на границу 16-и битного слова указателю может привести к очень неприятным ошибкам.
Общее количество байт занимаемое данной конкретной (упоминаемой ранее) структурой будет то же самое, т.к. она уже сама по себе выровнена за счет подбора порядка следования переменных внутри структуры. Но на архитектуре большей разрядности, при другом размере выравнивания размер структуры может увеличиться.
Объясняю. Имеем вот такую структуру, выровненную на размер 1 байта

Допустим, что компилятор расположил структуру, начиная с адреса 0x0200, выровняв ее на границу байта. Тогда структура займет в памяти 8 байт.
QQQ.a расположена по адресу 0x0200 - нормально, 1 байт
QQQ.b расположена по адресу 0x0201 - внимание! слово по нечетному адресу!!!, 2 байта
QQQ.c расположена по адресу 0x0203 - опять внимание!!!, 4 байта
QQQ.d расположена по адресу 0x0207 - допустимо, т.к. переменная 1-но байтовая, 1 байт
Теперь, если мы захотим изменить значение, например, элемента b, то в указатель будет загружен ее адрес 0x0201.

И мы получим полный облом - обращение к 16-и битному слову по нечетному адресу!!! Но поскольку архитектура MSP430 такого не позволяет, то этим оператором будет считано значение слова по четному адресу (0x0200, вместо 0x0201) и увеличенное на единицу значение будет записано по этому же адресу (0x0200). В результате изменится не только значение переменной под именем b, но и значение переменной a тоже.
Если же мы предусмотрительно сделаем выравнивание на границу 16-и разрядного слова, то структура расположится в памяти, заняв правда уже 9 байт, так.
QQQ.a по адресу 0x0200 - нормально, 1 байт
неиспользуемый 1 байт по адресу 0x0201
QQQ.b по адресу 0x0202 - нормально, 2 байт
QQQ.c по адресу 0x0204 - нормально, 4 байт
QQQ.d по адресу 0x0208 - нормально, 1 байт
Но зато при этом выравнивании не будет никаких проблем при обращении с помощью указателя к любому члену структуры, т.к. все адреса членов структур четные и выравнены на границу 16-и разрядного слова.
В случаях когда мы сами себе хозяева, а состав структуры данных нам не "спущен сверху", то можно перетасовать элементы структуры так, чтобы они располагались в памяти более оптимально, без "дырок", образующихся при выравнивании. Лучше располагать их в порядке убывания размеров переменных. Например.

Еще момент. Вроде бы тут структура уже самоупорядочилась и выравнивание вроде не требуется. Но это только для того случая, когда структура сама по себе единица данных. Если же мы попробуем включить эту структуру в состав другой (невыравненной) структуры, то можем получить снова такую же ситуацию, которая описана чуть выше. Так что я за то, чтобы структуры всегда были выровнены. Причем если используется 32-х битная архитектура, то выравнивать лучше на границу 32-х битного слова (на 4 байта).
Вообще говоря, стандартом Си гарантируется только порядок следования членов структуры, а насчет занимаемого в памяти размера структуры стандарт ничего не говорит. Это отдается на откуп программисту и компилятору. Поэтому при переносе структур данных на архитектуры разной разрядности нужно быть очень внимательным.
А данном случае 10 это абстрактное число взятое мной "с потолка" Размер буфера выбирается, исходя из максимального размера пакета или, исходя из времени определяемого неравномерностью доступа к буферу. Первый случай рассматривать по-моему не стоит. Размер буфера д.б. не меньше, чем максимальный размера принимаемого пакета. Это для случая когда требуется принять весь пакет целиком и только потом начать его разбор.
Второй случай. Допустим, нам хочется организовать непрерывный поток данных через UART и для этого мы хотим использовать буфер аля FIFO - линейный буфер по принципу "первый вошел-первый вышел". Пускай отправка 1 символа UART занимает условно 10мс. А темп поступления данных на конвейер UART определяется какими-либо внешними событиями, распределенными по времени неравномерно от 0,2 мс до 20мс. Какого размера буфер требуется? Исходя из самого худшего предположения, за время отправки 1 символа (10мс) мы можем получить до 50 символов с периодом 0,2мс. Значит размер буфера должен быть (10-0,2)/0,2>=49 элементов. Конечно, это для случая нормального (гауссового) распределения задержек в указанном диапазоне. В противном случае нам может не хватить даже буфера из 1000 элементов, если на каком-то весьма продолжительном отрезке времени данные будет поступать с высоким темпом (с минимальной задержкой).
Обычно символы начала (и конца) пакета являются уникальными. При этом либо весь пакет как-то обрабатывается (кодируется) так, чтобы не допустить символ с кодом начала (конца) пакета, либо совпадающие по коду символы дублируются, либо заменяются на последовательность уникальных символов. Посмотрите, например, описание протокола Wake, там эта проблема решена вполне изящно.

Как всегда - большое спасибо! про выравнивание ясно, про размер буфера - тоже(примерно).
С протоколом буду разбираться, будут вопросы - завтра задам

Здравствуйте снова.
Вот опять вопросы_
Делаю усреднение по по тридцать отсчетов

Потом в прерывании АЦП

Массив Vr[2][30] глобальный. Преобразование АЦП разрешается в прерываниях от таймера, которые происходят через 5мс. флаг f становится равным единице, когда уже набрался массив, индекс потом обнуляется, чтобы не возрастал постоянно до максимального значения, а флаг остается.
Кривовато?
Дело в том, что почему-то для 30 отсчетов работает, для 35 - тоже, а для 40 - уже нет, передача данных не идет. Хотя в отладчике все вроде происходит нормально, хоть до ста отсчетов давай.
И все-таки по поводу буфера,rezident.
Выравнивание #pragma pack(2) почему-то дает какой-то жуткий эффект - данные перепутываются и вообще не идут. А если по одному байту выравнивать, то нормально...но и данные ведь по одному байту пишутся. И вообще-то, зачем делать счетчик буфера int? Буфер же однобайтовый...
Поясните еще, я все же видимо, непонятливая

Что-то не совсем понятно, что за сдвиг вы формируете при усреднении? Вы пытаетесь фильтровать скользящим средним что ли? Или просто накапливаете 30 значений, а потом среднее арифметическое берете? Тогда зачем сдвиг элементов буфера?
Вычисления и фильтрация в прерывании??? Эх, Дарья, ничево вы видимо не поняли
Сразу же ошибка. Оператор | это "побитовое ИЛИ". Более уместное в логическом выражении "логическое ИЛИ" записывается как ||.

Поскипано. Мне грустно видеть как жуткие вычисления с плавучкой в прерывании транжирят драгоценное время
Опять аналогичная ошибка. "Логическое И" записывается как &&. Одиночный амперсанд & это "побитовое И".
Не то слово!
А вы в отладчике посмотрите сколько циклов занимает ваш расчет и фильтрация Поделите на тактовую MCLK и выясните, как оно соотносится с 5мс таймерными прерываниями? Ведь пока вы в прерывании АЦП считаете, все остальные прерывания запрещены.
Что перепутывается? Кто куда не идет? Про какой именно буфер речь? Если про буфер UART, то что там не так с выравниванием? Вынесите сам буфер (массив) типа unsigned char наружу структуры, как самостоятельный глобальный массив переменных. Его-то выравнивать не нужно. А в структуре только указатель на начало этого массива оставьте.
Потому, что в Си тип int является машинно-ориентированно-оптимальным. Поскольку MSP430 16-и разрядный микроконтроллер, то 16-и битовое слово является для него оптимальным. А, например, на ARM тип int 32-х битный. Нет, вы конечно же можете имеете право и unsigned char для счетчика использовать, если стоит задача экономии ОЗУ. У MSP430 есть команды для работы с байтовыми операндами. Я же совершенно не против

Да знаю я, знаю, что долго сидеть в прерывании нехорошо, не ругайтесь так... Но тут какая проблема была - если вычисления делать просто в цикле for(;;), то за время, пока эти вычисления делаются, уже успевает прийти несколько прерываний, и данные обновляются прямо по ходу вычислений. И происходит такая вещь - если плавно поворачивать плату, то оцифрованый уровень меняется далеко не плавно, жутко скачет во время поворота и долго "успокаивается", если вращать быстро, то будет долгий переходной процесс - т.е. улетает сначала намного выше реального уровня, затем медленно возвращается. Вот, по-женски так объясняю, самой смешно я думаю, это происходит оттого, что допустим координата Х уже просчиталась, а У еще нет, пришло прерывание, данные обновились, У считается, и уже характеризует новое положение, а Х - еще старое, поэтому при вращении возникают большие ошибки.
Такое дело нежелательно, потому что компас может медленно вращаться во время использования, или сразу после остановки может быть обращение к нему. Я перенесла вычисления прямо в прерывание, и все стало меняться просто на заглядение плавно Кстати, на ваш вопрос - да, усредняю скользящим, среднее арифметическое - это глупо даже для меня Каждый раз дожидаться, пока наберется 30 отсчетов... Я жду, пока они наберутся только в самом начале работы, а потом каждое новое число записывается 30-м элементом массива, и массив усредняется и сдвигается.
Ну да, зато теперь тратится куча времени...
А, если все же не в прерывании считать, то как бы избавится от той проблемы, о которой я говорю? если, конечно, вы меня поняли у меня в последнее время с объяснением не лады