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?

[rezident]

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

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

Код

#ifndef UART0_H
#pragma pack(2)
typedef struct st_uart  //тип структуры данных буфера UART0
{ unsigned int cntr;    //счетчик буфера
  unsigned int idx;     //индекс буфера
  unsigned char buf[10];//буфер UART
} st_uart;
#pragma pack()
#define UART0_H
#endif

main.c

Код

#include "uart0.h"

unsigned int adcRes;//результат преобразования АЦП, который нужно передать
st_uart uart;           //структура данных буфера UART0

void main( void )
{
  while(1)
  {
//  ...
    if ((IE1&UTXIE0)==0); //проверяем готовность UART0 к передаче, бит UTXIE0
    { uart.idx=0;         //используем еще и как признак окончания передачи пакета
      uart.cntr=0;
      uart.buf[uart.cntr++]='*';  //символ начала пакета
      uart.buf[uart.cntr++]=adcRes>>8;  //старший байт результата
      uart.buf[uart.cntr++]=adcRes&0xFF;//младший байт результата
      uart.buf[uart.cntr++]='#';  //символ конца пакета
      IFG1|=UTXIFG0;     //установим флаг, чтобы инициировать прерывания UART0
      IE1|=UTXIE0;        //разрешим прерывания UART0
    }
//  ...
  }
}

#pragma vector=USART0TX_VECTOR
#pragma type_attribute=__interrupt
void UART0TX_ISR(void)
{ if (uart.cntr>0)    //проверяем количество символов в буфере
  { U0TXBUF=uart.buf[uart.idx++]; //передаем текущий символ
    uart.cntr--;      //уменьшаем счетчик количества символов
  }
  else
    IE1&=~UTXIE0;     //если буфер пуст, то сбрасываем бит разреш.прерыв. UART0
}

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

Код

st_uart uart;           //структура данных буфера UART0

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

Интересен вызов функция GetKey(). Вро де бы все ясно -- функция должна вернуть код клавиши. А что делать, если ни одна клавиша не нажата? Получается, функция

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

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

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

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

[zhevak]

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

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

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

[rezident]

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

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

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

[zhevak]

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

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

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

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

[Daria]

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

[Daria]

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

[rezident]

можно же тогда и с циклами while, правильно?

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

Могу я написать так:
ADC12CTL0&= ~ ENC;
ADC12CTL1 &= ~ CONSEQ_1
ADC12CTL1 |= CONSEQ_3
Ну и после калибровки
ADC12CTL0&= ~ ENC;
ADC12CTL1 &= ~ CONSEQ_3
ADC12CTL1 |= CONSEQ_1
Нет тут какого-нибудь недопустимого действия? А то мало ли, чего мое альтернативное мышление натворит

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

Код

ADC12CTL1 &=~CONSEQ_3;

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

[Daria]

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

Спасибо!

[Daria]

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

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

[rezident]

для чего делается вот это
#pragma pack(2)
...
#pragma pack()
Как я понимаю, это выравнивание?

Да, это выравнивание структуры.

т.е. #pragma pack(2) - теперь структура будет иметь четное количество байтов,

Нет, не "иметь четное количество байт", а члены структуры будут выровнены на границу 2-х байтового слова.

а #pragma pack() - возвращение к установке "по умолчанию"?

Да.

А зачем тогда именно pack(2)?

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

Если написать pack(1) - то будет ровно то количество байт, которое задается, т.е. четыре.

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

? Объясните чуть подробнее, пожалуйста.

Объясняю. Имеем вот такую структуру, выровненную на размер 1 байта

Код

#pragma pack(1)
typedef struct qqq_t
{ char a;
  int b;
  long c;
  char d;
} qqq_t;
#pragma pack(1)

qqq_t QQQ;

qqq_t *pQ=&QQQ;

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

Код

pQ->b += 1;

И мы получим полный облом - обращение к 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-и разрядного слова.
В случаях когда мы сами себе хозяева, а состав структуры данных нам не "спущен сверху", то можно перетасовать элементы структуры так, чтобы они располагались в памяти более оптимально, без "дырок", образующихся при выравнивании. Лучше располагать их в порядке убывания размеров переменных. Например.

Код

#pragma pack(2)
typedef struct qqq_t
{ long c;
  int b;
  char a;
  char d;
} qqq_t;
#pragma pack()

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

И еще - почему именно buf[10], чем обусловлено 10 и как его выбирать?

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

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

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

[Daria]

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

[Daria]

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

Код

int filter1(int input[], int in)
{    float result = 0;                  
    int i;
    if (in>0)
    {
        for (i = 0; i < 30; i++)    
            result += input[i];
            result=result/in;
        for (i = 0; i < 30; i++)    
            input[i] = input[i+1];    

        return (int)(result);
    }
}

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

Код

if((index>=29)|(f==1))//если уже набрался массив  из 30 элементов для усреднения
    {               f=1;
        Vr[0][29]= ADC12MEM3;
        Vr[1][29] = ADC12MEM4;
                    
        ADC12CTL0 &= ~ENC;    
                
        buf[0] = filter1(Vr[0], 30);    //фильтр
        buf[1] = filter1(Vr[1], 30);
                    
        offset[0] = (Vs[0] -buf[0])/2;     // вычисляются смещения на основе Vset, Vreset
        offset[1] = (Vs[1] - buf[1])/2;
        Vx = buf[0] - offset[0];        //координаты вектора маг. индукции
        Vy = buf[1] - offset[1];
                        
        index=0;            
                        
                    
            float F[2];
            azimut = calculation (Vx,Vy,F);
            send_int(azimut);
    }
                
if ((index<29)&(f==0))// пока массив не набрался
                
               {
                   Vr[0][index]= ADC12MEM3;
                   Vr[1][index] = ADC12MEM4;
        index++;
        ADC12CTL0 &= ~ENC;    
               }

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

[rezident]

Делаю усреднение по по тридцать отсчетов

Что-то не совсем понятно, что за сдвиг вы формируете при усреднении? Вы пытаетесь фильтровать скользящим средним что ли? Или просто накапливаете 30 значений, а потом среднее арифметическое берете? Тогда зачем сдвиг элементов буфера?

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

Вычисления и фильтрация в прерывании??? Эх, Дарья, ничево вы видимо не поняли

if((index>=29)|(f==1))//если уже набрался массив из 30 элементов для усреднения

Сразу же ошибка. Оператор | это "побитовое ИЛИ". Более уместное в логическом выражении "логическое ИЛИ" записывается как ||.

...

Поскипано. Мне грустно видеть как жуткие вычисления с плавучкой в прерывании транжирят драгоценное время

if ((index<29)&(f==0))// пока массив не набрался

Опять аналогичная ошибка. "Логическое И" записывается как &&. Одиночный амперсанд & это "побитовое И".

Кривовато?

Не то слово!

Дело в том, что почему-то для 30 отсчетов работает, для 35 - тоже, а для 40 - уже нет, передача данных не идет. Хотя в отладчике все вроде происходит нормально, хоть до ста отсчетов давай.

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

И все-таки по поводу буфера,rezident.
Выравнивание #pragma pack(2) почему-то дает какой-то жуткий эффект - данные перепутываются и вообще не идут. А если по одному байту выравнивать, то нормально...но и данные ведь по одному байту пишутся.

Что перепутывается? Кто куда не идет? Про какой именно буфер речь? Если про буфер UART, то что там не так с выравниванием? Вынесите сам буфер (массив) типа unsigned char наружу структуры, как самостоятельный глобальный массив переменных. Его-то выравнивать не нужно. А в структуре только указатель на начало этого массива оставьте.

И вообще-то, зачем делать счетчик буфера int? Буфер же однобайтовый...

Потому, что в Си тип int является машинно-ориентированно-оптимальным. Поскольку MSP430 16-и разрядный микроконтроллер, то 16-и битовое слово является для него оптимальным. А, например, на ARM тип int 32-х битный. Нет, вы конечно же можете имеете право и unsigned char для счетчика использовать, если стоит задача экономии ОЗУ. У MSP430 есть команды для работы с байтовыми операндами. Я же совершенно не против

[Daria]

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

[rezident]

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

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

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

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

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

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

Код

#define MAXNUMFLTRBUF  30

unsigned int funcSMA(unsigned int val)
{ static unsigned int fltrBuf[MAXNUMFLTRBUF];
  static unsigned int idx;
  static unsigned long sumBuf;
  sumBuf-=fltrBuf[idx];     //вычитаем из суммы значение самого старого элемента
  sumBuf+=val;              //прибавляем к сумме значение нового элемента
  fltrBuf[idx]=val;         //записываем в буфер значение нового элемента
  if (idx<(MAXNUMFLTRBUF-1))//сдвигаем индекс
    idx++;
  else
    idx=0;
  return(sumBuf/MAXNUMFLTRBUF);//высисляем среднее значение
}

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

Код

#define MAXNUMFLTRBUF  30

unsigned int funcSMA(unsigned int cmd, unsigned int val)
{ static unsigned int fltrBuf[MAXNUMFLTRBUF];
  static unsigned int idx;
  static unsigned long sumBuf;
  if (cmd==0)                 //это случано не команда инициализации фильтра?
  { sumBuf-=fltrBuf[idx];     //нет, вычитаем старое значение
    sumBuf+=val;              //прибавляем к сумме значение нового элемента
    fltrBuf[idx]=val;         //записываем в буфер значение нового элемента
    if (idx<(MAXNUMFLTRBUF-1))//сдвигаем индекс
      idx++;
    else
      idx=0;
    return(sumBuf/MAXNUMFLTRBUF);//вычисляем среднее значение
  }
  else                        //да, инициализируем буфер фильтра новым значением
  { sumBuf=val*MAXNUMFLTRBUF;
    idx=MAXNUMFLTRBUF-1;
    while (idx!=0)
      fltrBuf[idx--]=val;
    return(val);
  }
}

Учитывая, что входные значения 12-и разрядные и сумма заведомо не превышает разрядности типа long, то при целочисленном вычислении среднего можно повысить точность, если перед делением сдвигать сумму до заполнения разрядности типа, а потом сдвигать обратно.

Код

return(((sumBuf<<8UL)/MAXNUMFLTRBUF)>>8UL);

[Daria]

Есть два способа решения этой проблемы. Либо на время вычислений в основном цикле запрещать прерывания от АЦП (либо останавливать его) - все равно АЦП не работает, когда вы считаете в прерывании.

А разве не тож на тож получится? Та же самая потеря времени... Единственное, что таймер не будет пробрасывать свои прерывания и будет четко вести счетчик прерываний... но лишние 10-20мс до начала короткого импульса - вроде не проблема...

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

Ух. Жестко! Ладно, спасибо, попробую.

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

Нужно. Вопрос - как

А вам приниципально усреднять уже готовые значения координат или можно усреднять непосредственно отсчеты АЦП?

Э-э... а я вроде именно отсчеты АЦП и усредняю... так мне казалось...

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

Точно! Спасибо большое! Действительно, куча лишних действий получалась!
Только немного не ясно, почему строка
sumBuf-=fltrBuf[idx];- это вычитание самого старого элемента Вы записываете новый элемент fltrBuf[idx]=val; и сдвигаете счетчик - idx++. Значит, при поступлении следующего элемента fltrBuf[idx] будет хранить значение предыдущего, а не самого старого... Поясните, пожалуйста.

Учитывая, что входные значения 12-и разрядные и сумма заведомо не превышает разрядности типа long, то при целочисленном вычислении среднего можно повысить точность, если перед делением сдвигать сумму до заполнения разрядности типа, а потом сдвигать обратно.

Код

return(((sumBuf<<8UL)/MAXNUMFLTRBUF)>>8UL);

А почему это повышает точность?
как всегда спасибо за комментарии!

[rezident]

Нужно. Вопрос - как

Как обычно. С помощью буферов. Две переменные которые будут обновляться одновременно и считывание значений из которых не будет прерываться вычислениями.

Э-э... а я вроде именно отсчеты АЦП и усредняю... так мне казалось...

Опс! Это я ошибся Извиняюсь! Почему-то отложилось в памяти, что у вас там фильтрация плавающих числе идет, а страницу с вашим кодом еще раз посмотреть поленился.

Только немного не ясно, почему строка
sumBuf-=fltrBuf[idx];- это вычитание самого старого элемента Вы записываете новый элемент fltrBuf[idx]=val; и сдвигаете счетчик - idx++. Значит, при поступлении следующего элемента fltrBuf[idx] будет хранить значение предыдущего, а не самого старого... Поясните, пожалуйста.

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

Код

         | значения
значение | элементов
индекса  |  буфера
---------------------------
  0       -, -, -    - буфер пуст
  1       1, -, -    - 1 элемент, единственный и самый старый, индекс указывает на следующий, но буфер ЕЩЕ НЕ ЗАПОЛНЕН
  2       1, 2, -    - 2 элемента, самый старый 1-й, буфер ЕЩЕ НЕ ЗАПОЛНЕН, индекс указывает на следующий
  0       1, 2, 3    - 3 элемента, буфер заполнен!!!, индекс указывает на следующий (1-й элемент), который является самым старым
  1       4, 2, 3    - 3 элемента, буфер заполнен, индекс указывает на следующий (2-й элемент). который является самым старым
  2       4, 5, 3    - 3 элемента, буфер заполнен, индекс указывает на следующий (3-й элемент). который является самым старым
  0       4, 5, 6    - ну и т.д.
  1       7, 5, 6

А почему это повышает точность?

Это особенности целочисленной математики. Хотя пожалуй в данном конкретном случае (единственная операция в выражении) это рояли не играет. Я просто перестраховался. Отставить сдвиги!

[Daria]

В полностью заполненном циклическом буфере фильтра индекс указывает на тот элемент, куда нужно записать новое значение, которое замещает самое старое значение.

Ага, ясно. Спасибо за очень подробное разъяснение

Это особенности целочисленной математики. Хотя пожалуй в данном конкретном случае (единственная операция в выражении) это рояли не играет. Я просто перестраховался. Отставить сдвиги!

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

[Daria]

Ну вот, отпуск кончился, пошли суровые будни
И вопросы
Такая беда. У меня был iar, версия 4.11в - тридцатидневная демо-версия с официального сайта. Срок лицензии истек, я снесла эту версию, скачала опять и поставила снова. И вот фиг. Удаляю отовсюду, откуда только можно, но в реестр он прописался в закрытую область, которую нельзя удалить. Теперь сколько новый iar не ставь, все бестолку
Как быть? переустанавливать винду не хочется. Попробовать какую-нибудь другую версию? Где взять? У меня был ломаный iar 3.2, но он почему-то жутко глючил. Можно как-нибудь почистить и закрытые области?
Вот такая проблема, немного не по теме, но печальная

[rezident]

Вот такая проблема, немного не по теме, но печальная

Там все дело в волшебных пузырьках То бишь в лицензии которую вы скармливаете при установке. "Правильную" лицензию можно сгенерить с помощью вот этой штучки Инструкция по применению inside package.
P.S. некоторые излишне подозрительные антивирусы (например, AVAST) реагируют на содержимое архива как на вирус. Не стоит волноваться, они перестраховываются.

[Daria]

rezident, большое спасибо. Все работает. Вы хороший

[Daria]

Здравствуйте. Такие вопросы -
сейчас я прошиваю контроллер самодельной отладкой, схему которой советовали, по-моему, вы, rezident - она питается с платы, 3,3 В. В дальнейшем хочу использовать MSP-FET430PIF, так как требования - либо на свою отладку оформлять докуметацию по всем правилам, либо пользоваться готовой. и вот вопрос - у MSP-FET430PIF питание от LPT - мне сказали, что это опасно, что LPT часто горят, если программатор питается прямо от порта. Это правда? насколько часто? Может, лучше не покупать этот MSP-FET430PIF?
И еще - не совсем в по теме. Не подскажите какой-нибудь кварцевый резонатор на 8MГц, как можно меньших размеров? И, желательно, планарный Не могу найти, на такую частоту все какие-то здоровые, а нужно сокращать размеры платы

[rezident]

В дальнейшем хочу использовать MSP-FET430PIF, так как требования - либо на свою отладку оформлять докуметацию по всем правилам, либо пользоваться готовой. и вот вопрос - у MSP-FET430PIF питание от LPT - мне сказали, что это опасно, что LPT часто горят, если программатор питается прямо от порта. Это правда? насколько часто? Может, лучше не покупать этот MSP-FET430PIF?

Согласен. MSP-FET430PIF покупать не нужно в любом случае . Если вам нужен индивидуальный отладчик и программатор, то купите лучше MSP-FET430UIF или его полнофункциональный клон MSPLink. Olimex-овский USB-FET покупать не рекомендую.
Если же вы хотите передать прошивку кристаллов на производство, то лучше сразу купить MSP-GANG430. Мы покупали в Терраэлектронике.
Преимущества:
- можно программировать до 8ми кристаллов одновременно.
- все кристаллы можно запитать непосредственно от MSP-GANG430.
- поддерживает функцию прожигания fuse.
- можно загрузить прошивку в программатор и использовать его автономно, т.е. он не требует обязательного наличия компьютера. С компьютера вы только загружаете образ прошивки и конфигурацию программирования через последовательный интерфейс RS-232. Соответственно при отсутствии в компе RS-232 можно дополнить программатор любым готовым кабелем USB-COM и работать дальше. В случае же LPT-ного MSP-FET430PIF и отсутствия LPT-порта вы получите массу трудностей.
- MSP-GANG430 поддерживает все предыдущие и последующие серии MSP430, т.е. у него есть перспективы техподдержки. Например, аналогичный по функциям MSP-PRGS430 уже сейчас не поддерживает интерфейс Spy-Bi-Wire и некоторые кристаллы из серии MSP430x2xx.
- чуть не забыл упомянуть главное достоинство MSP-GANG430 для производства, на котором не всегда адекватные по знаниям люди работают У MSP-GANG430 из органов управления всего ОДНА кнопка! Из индикации два ряда светодиодов (красные и зеленые). Обучить нажатию на кнопку можно даже неквалифицированный персонал.
Кстати, раз вы планируете программировать кристаллы уже запаянные в плату, то обдумайте стоит ли для этого использовать именно JTAG? Я, например, в серийных устройствах на MSP430 вывожу для программирования сигналы BSL. Во-первых, требуется меньше контактов (всего 6). Во-вторых, BSL позволяет и в дальнейшем менять firmware, когда уже установлена защита (fuse уже пережжен) и JTAG не работает.

И еще - не совсем в по теме. Не подскажите какой-нибудь кварцевый резонатор на 8MГц, как можно меньших размеров? И, желательно, планарный Не могу найти, на такую частоту все какие-то здоровые, а нужно сокращать размеры платы

Посмотрите резонаторы фирм Geyer Electronic и Golledge. Мы часовой (32768Гц) KX-327LT от Geyer недавно начали применять, размеры его всего 1,5х7мм. Продукцией Geyer Electronic торгует Компел и Терраэлектроника, а продукцию Golledge представляет фирма ЭФО.

[Daria]

Ага, но мне, как пока неквалифицированному программисту, хотелось бы все же программить именно на плате, сразу непосредсственно смотреть сигналы с датчиков. Возможность BSL заложу, но с JTAG мне гораздо проще - удобно отлаживать все это дело, то так, то так попробовать А с полноценным отладчиком не знаю, как и работать такой парадокс. Пробовать ведь надо на реальной плате а так - вставить кристалл и... чего дальше? Мое парадоксальное мышление проявляется тут с новой силой Когда прога будет уже окончательно выверена, тогда, конечно - вставил кристалл, прошил - давай следующий. Но окончательно - это еще неизвестно когда, к тому же задание постоянно меняется
Значит PIF - не пойдет? A UIF - разве позволяет программировать прямо на плате?
Резонаторы посмотрю, спасибо

Сообщение отредактировал Daria - Sep 23 2008, 20:53

[rezident]

Значит PIF - не пойдет? A UIF - это ведь тоже отдельная коробка

Для вашего нынешнего случая (MSP430F149) подойдет и PIF и UIF. Я вам на будущее/перспективу рекомендации давал. Для отладки конечно же лучше нормальный отладчик. BSL это для серии и техподдержки.

[Daria]

Для вашего нынешнего случая (MSP430F149) подойдет и PIF и UIF. Я вам на будущее/перспективу рекомендации давал. Для отладки конечно же лучше нормальный отладчик. BSL это для серии и техподдержки.

А UIF позволяет программировать прямо на плате? Как-то он так выглядит... я думала. что нет. по его внешнему виду

[rezident]

А UIF позволяет программировать прямо на плате? Как-то он так выглядит... я думала. что нет. по его внешнему виду

Конечно позволяет. Он функционально более расширен по сравнению с MSP-FET430PIF. В принципе вы даже сами можете изготовить MSP-FET430UIF Схема его имеется в slau138, а прошивку тут в форуме где-то выкладывали.