MSP430 - снова вопросы от чайника, Вопросы от чайника про MSP и магнитный компас Опции

[Daria]

Здравствуйте. Кто читал предыдущую мою тему "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 - можно ли сделать как-то поумнее?

[rezident]

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

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

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

[Daria]

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

[zhevak]

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

... Так что совершенно зря разразились такой тирадой

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

Впрочем, не зря, ...

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

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

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

[Daria]

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

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

Daria, не останавливайтесь на полпути!

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

Мы все за Вас переживаем

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

Всех благ!

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

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

[rezident]

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

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

[Daria]

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

[zhevak]

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

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


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

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

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

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

Код

  while (1)
  {
    GetKey();
    DoSomething();
    DisplayResult();
  }

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

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

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

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

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

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

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

Код

  while (1)
  {
    GetKey();
    DoSomething();
    DisplayResult();
    GetCurrentTime();
    DisplayTime ();
  }

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

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


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

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

Код

while (1)
{
  if (IsKeyHit())
  {
     GetKey();
     DoSomething();
     DisplayResult();
  }
  if (IsTimeChanged())
  {
    GetCurrentTime();
    DisplayTime();
  }
}

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

Код

  unsigned char msg;

  while ()
  {
    if (GetMessage(&msg))
      switch (msg)
      {
        case MSG_KEYPRESS:
          DoKey();
          break;

        case MSG_TICK:
          DisplayCurrentTime();
          break;
  
        case MSG_ADCREADY:
          SendResult();
          break;

        case MSG_TXD:
          SendNextByte();
          break;

        ...
      }

      // а здесь вот -- самое удобное место пинать собаку (WDR)
  }

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

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

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

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

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

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

Сообщение отредактировал zhevak - Aug 17 2008, 15:42