=DS=

Это передранный и слегка модифицированный код тексасовских апнот типа slaa076, slaa280 (может и для других серий есть, не смотрел). Причем модифицирован он так, что исключает совместное использование этого кода с С и С++ , поскольку компилятор как раз использует R12-R15 как временные регистры для передачи аргументов функций. Посмотрите лучше эти аппноты, там готовый пример стыковки ассемблера и С. Только два момента - во первых, для С++ функции, обьяваленные в хедере как extern, надо обьявить extern "C", во вторых, писались эти апноты во времена компиляторов 3.хх ), а с тех пор соглашения о передаче аргументов изменились, кажется с версии 4.(что-то там)... Так что ассемблерный код надо будет слегка перековырять, предварительно проштудировав главу Assembler language interface в IAR C/C++ Compiler Reference Guide. А что касается того, что использовать - собаку или таймер - без разницы. Что свободно, то и используйте.

Не так все плохо. Там 255 ячеек памяти в инфо области, прежде чем ее стирать можно заполнить 25 - 10 блоками настроек в завистимости от их типа, что уже дает 250000-500000 часов работы, а если вы еще заранее знаете, что часть из них будет меняться очень редко, то можно их сгруппироать и выиграть еще больше. Или поставить кондер побольше по питанию и держать быстро меняющиеся настройки в ОЗУ, а во флеш их писать при пропадании питания.

Возможно, потому что вы оставили флеш в режиме записи? По завершении записи надо дать команды FCTL1 = FWKEY; FCTL3 = FWKEY | LOCK; Еще одна вещь, о которой не надо забывать - если собака работает, перед записью во флеш ее надо отключать, а то взбрыкнуть может капитально.

#define __infomem___ Pragma("location=\"INFO\"") Подмена на __infomem___ прагмы "location="INFO"" . Просто для удобства чтения и модификации. Но тут могут быть зарыты грабли. В частности, этот текст может быть несовместим с вышеописанной процедурой. Надо смотреть распределение флеш памяти для конкретного кристалла. Секция INFO включает в себя сегменты A, B (C, D в зависимости от кристалла) __infomem__ const struct info_mem_s nv_parms Разместить стуктуру nv_parms типа info_mem_s в памяти в секции INFO. Здесь надо проверить, как расположены в памяти входящие в INFO сегменты INFOA, INFOB (C, D). Компилятор расположит структуру nv_parms в начале секции INFO, а в серии 2хх там расположена секция D, например, в то время как flash_replace16 подразумевает, что данные хранятся в секции В. Можно не париться и прямо указать Pragma("location=\"INFOB\"") flash_write_int16((int *) &(nv_parms.seg_a.s.variable), nv_parms.seg_a.s.variable & ~(1 << 2)); >>получается: обявили константу во флеши и затем записали на её место что-то...верно? Не совсем так. Скорее жестко привязали имя и местоположение структуры к определенному адресу памяти. Делают так, потому что TI специально выделяют зону флеш-памяти именно для этих целей. У нее уменьшен размер страницы и увеличено количество возможных перезаписей по сравнению с основной страницей JTAG есть? Давайте ВЕСЬ код, относящися к теме, тип кристалла.

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

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

Прочитать-то просто: int x = nv_parms.seg_a.s.variable; Но Вы, кажется, не понимаете, как работает флеш. Записать значение по любому адресу в ней можно без проблем, но только один раз и в чистую (все биты равны единице). При попытке повторной записи туда же другого значения старое не затрется - те биты, что были ранее сброшены в ноль, так и останутся. Нужно снова проинициализировать (стереть) память перед записью нового значения, а сделать это можно только со всей страницей целиком, а не с отдельным байтом.

А чем Вас не устраивает МИКРОФОН-> микрофонный вход компьютера ->добавление зыуковых эффектов(программное) -> программа звукозаписи? Если уж очень хочется обязательно добавить сюда МП, и именно MSP430, то смотрите с сторону 5хх серии - память больше, частота выше и есть USB ЗЫ: 512 байт не хватит даже для эха - 100 семплов * 16 бит * 4 канала = 800 байт только буфер.

Ответ 1. В MSP430 ОДИН АЦП с мультиплексором на входе. Оцифровка будет идти последовательно, хоть и в автоматическом режиме. Пересылка по порту в комп - это, надо полагать, через USART? Тогда 16*4*44100 = 2,8 Мбит в секунду, порт не потянет. Кстати, АЦП у МСП430 12 разрядный обычно, многоразрядные сигма-дельта стоят всего на нескольких моделях, не очень мощных. С учетом сказанного, на остальные вопросы и отвечать не надо, наверное...

В последних версиях компилятора введен специальный атрибут __persistent именно для подобных целей. Переменные с этим атрибутом не инициализиуются на старте и группируются в сегменте DATA_P/DATA20_P, который при линковке можно расположить где угодно.

Думаете, я это сам сочинил? Мне бы такое и в страшном сне не приснилось... Хотите, пришлю конкретный хедер. Все там есть: и изьятые дефайны (причем нвполовину, часть битов в одном и том-же регистре определена, часть нет), и несоответствующие даташиту имена. Причем в предыдущих версиях это как раз был нормальный рабочий файл (как обычно, struct+define, полностью соответсвующий даташиту), а изгадили его недавно. PS: Уже выпустили и 5.20 и 5.20.2, там все то-же.

Как то не додумался :cranky:

У них только один недостаток - если меняешь камень в проекте, приходится бегать по всем файлам и менять их вручную. С иаровсими хедерами проще - везде пишешь io430.h, а тип камня меняешь в настройках проекта. Хотя, наверное, стоит написать аналог io430.h для тексасовских хедеров. Только поддерживать его придется самому :(

Никто не знает, с какого бодуна ИАРовцы решили поменять структуру заголовочных файлов (io430***.h) в новой версии 5.10.6? Сегодня накатил sp6 и вдруг компилятор перестал понимать, что такое UCMST. Полез в io430x26x.h (текуший мой камень), а там выкинута куча #define, частично заменены на struct + enum, причем сделано все через ж... Тот же USMST в UCB0CTL0 переименовали в UCB0MST. а в UCB1CTL0 оставили как USMST, зачем-то ввели для UCB0CTL0 еще одно определение UCB0CTL0__SPI ... В общем, ляпов там выше крыши. Бегло сравнил размеры файлов в INC с предыдщей версией, изменений довольно много. Кто нибудь еще сталкивался с этим? Это у ИАРа идейное (типа, избавляемся от #define, переходим на enum) или просто ляп? Я бы просто откатился назад, но в этой версии появились удобные штучки типа __persistent, __ro_placement... Так что просто подставил старый .h из sp4, но оно не кошерно как-то... ЗЫ: Не знаю, куда было правильнее поместить тему - в ИАР или МСП, но все-таки ближе к МСП, по-моему.

Разработчики USART MSP430 2xx заложили в него 2 идеи, в общем-то спорные, но имеющие право на жизнь, без понимания которых вы не сможете понять все остальное: (речь о режиме Master Transmitter/Receiver) 1 адрес Slave не является частью пакета данных, а задается отдельно. Это сильно упрощает программирование, если у Вас на шине одно устройство (частая ситуация). Вы один раз задаете адрес и можете забыть о нем, USCI сам вставляет его в начале каждого приема/передачи. Бит R/W при этом определяется битом UCTR. 2 Штатным ответом Slave является ACK, NACK - признак нештатной ситуации. По ACKу не выставляется никаких специальных флагов, просто контроллер дает знать о готовности к приему/передаче следующего байта через UCxxRXIFG/UCxxTXIFG, в случае получения NACK контроллер выставит UCNACKIFG ( вызовет прерывание), сотрет данные из передающего буфера, если они там есть, и будет ждать вашей реакции. В общем, проще прислать код, наверное... Вот кусок кода, только он для UCB1, надо будет подправить. Прерывания для приема,передачи не используются, NACK обрабатывается в ISR Реализует как раз ваше: Start - Slave Address - R/W - ACK - Data - ACK - S Slave Address - R/W - ACK - Data - ACK - Stop void I2C_SetSlave(unsigned char slave_address, unsigned char baudrate) { UCB1CTL1 |= UCSWRST; // Clear SW reset, resume operation UCB1CTL1 = UCSSEL_2 + UCSWRST; // Use SMCLK, SW reset UCB1BR0 = baudrate; // set prescaler UCB1BR1 = 0; UCB1I2CSA = slave_address; // Set slave address UC1IFG &= ~(UCB1TXIFG+UCB1RXIFG); UCB1CTL1 &= ~UCSWRST; // Clear SW reset, resume operation if(UCB1STAT & UCBBUSY) I2C_BusReset(); } unsigned char I2C_ReadByteRs(unsigned char reg) { UCB1CTL1 |= (UCTR + UCTXSTT); // Master TX, start condition while (!(UC1IFG & UCB1TXIFG)); // Wait for address transmit UC1IFG &= ~UCB1TXIFG; UCB1TXBUF = reg; while (!(UC1IFG & UCB1TXIFG)); // Wait for register tx UC1IFG &= ~UCB1TXIFG; UCB1CTL1 &= ~UCTR; // Set master receiver mode UCB1CTL1 |= UCTXSTT; // Set start condition, Master rx while (UCB1CTL1 & UCTXSTT); // Start condition sent? UCB1CTL1 |= UCTXSTP; // Set stop immediately while (!(UC1IFG & UCB1RXIFG)); // Wait for receive UC1IFG &= ~UCB1RXIFG; return UCB1RXBUF; } #pragma vector = USCIAB1RX_VECTOR void USCIAB1RX_ISR(void) { if (UCB1STAT & UCNACKIFG){ // if slave sends NACK UCB1CTL1 |= UCTXSTP; // set STOP condition UCB1STAT &= ~UCNACKIFG; UC1IFG &= ~(UCB1TXIFG+UCB1RXIFG); // Здесь сообщить об ошибке } } И еще. Частая ошибка при работе с акселерометрами - забывают их инициализировать и сразу кидаются читать регистры осей. А многие акселерометры при включении уходят в сон и при чтении большинства регистров выдают нули. 2 rezident Согласитесть, "TFM", который надо читать, в части I2C довольно мутный, точнее, слишком много впихнуто в крайне сжатом виде, рисунки - это вообще песня, учитывая, что легенда к ним приводится один раз и за 3 страницы до первого рисунка. Кстати, давно хотел спросить у Вас: учитывая Ваш опыт работы с MSP430, не кажется ли Вам, что I2C в 2хх намного глючнее, чем в 1хх?