sigmaN

Подскажите как правильнее оптимизировать его, чтобы не вдаваться в подробности алгоритмов и ассемблера... Ну или, если всё-же придётся - то на что в первую очередь обратить внимание? В мануале указаны функции, которые следовало-бы оптимизировать, но как-то не очень заманчиво выглядит перспектива изучения ещё и ассемблера для данного DSP...т.е. не то, чтобы лень - просто на это нет времени уже. Ещё вопрос: я когда ставлю полную оптимизацию всего что только можно, при компиляции получаю: "bits.asm", ERROR! at line 18182: [E0200] Block size out of range RPTB $C$L266,AR6 1 Assembly Error, No Assembly Warnings Я так понимаю, RPTB имеет ограничения по размеру и этот кусок кода не проходит эту проверку. Можно ли как-нибудь сказать компилятору, чтобы не пытался оптимизировать какой-то участок программы??

Ха ха ха! Вот горе-то какое ) Просто я удалил из проекта не ту таблицу exc_10_32_table.с там в коментах написано, что она не используется для 8Kbps, а на самом деле используется )) Вот и не сходилось у меня ничего. Сегодня уже утром докопался до истины. Вот что значит оптимизация ещё до того, как что-то заработает. Думал зачем нужны лишние таблицы - эти битрейты использовать не буду всё равно.... Мипсов не очень много. До реалтайма не дотягивает пока...Щас буду чё-нибудь инлайнить и переносить ответственные функции в оперативку DSP.

Не сколько) На радостях я недоглядел. В действительности и на FIXED тоже выходной буфер лажовый получается. Совпадают всегда только первые 4 charа всё остальное лажа! Пробывал это скормить декодеру - на выходе шум со слабыми признаками какой-то искаженной до неузнаваемости речи. Провел пошаговое сравнение в режиме FIXED с WIN реализацией. Всё идёт нормально до функции lsp_to_lpc Она какая-то странная! void lsp_to_lpc(spx_lsp_t *freq,spx_coef_t *ak,int lpcrdr, char *stack) int i,j; spx_word32_t xout1,xout2,xin; spx_word32_t mult, a; VARDECL(spx_word16_t *freqn); VARDECL(spx_word32_t **xp); VARDECL(spx_word32_t *xpmem); VARDECL(spx_word32_t **xq); VARDECL(spx_word32_t *xqmem); int m = lpcrdr>>1; /* Reconstruct P(z) and Q(z) by cascading second order polynomials in form 1 - 2cos(w)z(-1) + z(-2), where w is the LSP frequency. In the time domain this is: y(n) = x(n) - 2cos(w)x(n-1) + x(n-2) This is what the ALLOCS below are trying to do: int xp[m+1][lpcrdr+1+2]; // P matrix in QIMP int xq[m+1][lpcrdr+1+2]; // Q matrix in QIMP These matrices store the output of each stage on each row. The final (m-th) row has the output of the final (m-th) cascaded 2nd order filter. The first row is the impulse input to the system (not written as it is known). The version below takes advantage of the fact that a lot of the outputs are zero or known, for example if we put an inpulse into the first section the "clock" it 10 times only the first 3 outputs samples are non-zero (it's an FIR filter). */ ALLOC(xp, (m+1), spx_word32_t*); ALLOC(xpmem, (m+1)*(lpcrdr+1+2), spx_word32_t); ALLOC(xq, (m+1), spx_word32_t*); ALLOC(xqmem, (m+1)*(lpcrdr+1+2), spx_word32_t); for(i=0; i<=m; i++) { xp[i] = xpmem + i*(lpcrdr+1+2); xq[i] = xqmem + i*(lpcrdr+1+2); } //.....покусано.....\\ После этого цикла xp[] ухе не сходятся. MSVC: +28652 +163 +28704 +163 +28756 +163 +28808 CCS3.3: -31834 0 -31808 0 -31782 0 -31756 0 -31730 0 -31704 0 Я только-что дошел до этого. Очень странный вообще результат получается! Смотрел на них в HEX, хотел найти может какую-то закономерность или похожесть....ничего. xp = xpmem + i*(lpcrdr+1+2) - пока непонятен смысл этого! Только был вызван ALLOC(xpmem, (m+1)*(lpcrdr+1+2), spx_word32_t); и началось! Хоть убей не пойму! в моей конфигурации: #define ALIGN(stack, size) ((stack) += ((size) - (long)(stack)) & ((size) - 1)) #define PUSH(stack, size, type) (ALIGN((stack),sizeof(type)),(stack)+=((size)*sizeof(type)),(type*)((stack)-((size)*sizeof(type)))) #define VARDECL(var) var #define ALLOC(var, size, type) var = PUSH(stack, size, type) Намучено у них тут с этим стеком.... Идея, конечно, хорошая, но мне кажется подглючивает она изза того, что int у нас на TMS 16ти битный. А кое-где встречаются эти int'ы вместо, предназначенных для этого spx_int16_t. Тоже с char... Может что-то я не учёл? Помогите плиз. Целый день с ним провозился уже, а результат ==0 Так, дадно. С этими xp[] и xq[] разобрался. Это ведь указатель на указатель, поэтому ему и содержать адрес. А судя по написанному в коменте авторов - это хитрый способ объявления двумерного массива. Числа разные, потому, что адреса разные. И не более того. Едем дальше.... прогонка кода продолжается...... )

Проблема была в том модели памяти. Стояла Unified Memory Model. Не знаю, как её использовать(или может она вообще для этих процов не пригодна), но при её использовании творится чёрти-что! Я когда прошагал асм код, сгенерированный компилятором и увидел, как он прыгает к разным инструкциям, причём даже вверх(!) без всяких видимых причин! Ужас! Переставил на Large и всё сразу встало на свои места! А я купился на: Use this switch if your memory map is configured as a single unified space. This will allow the compiler to generate RPT PREAD instructions for most memcpy calls and structure assignments. This will also allow MAC instructions to be generated. This switch will also allow more efficient data memory instructions to be used to access switch tables. И потратил 3 с половиной часа на разборки кто виноват и что делать ) [/i] А всё-таки на FLOATING_POINT выход не сходится...первые 4 байта ok а потом расхождения. FIXED_POINT всё Ok. Это изза погрешностей плавающей точки?? Как можно подобное объяснить?

Наконец-то всё запустилось и вроде даже заработало, но как всегда не всё так гладко. Отредактировал config.h и arch.h, так, что они совпадают для WIN и TMS версий. Пробный frame объявлен так(на самом деле он больше, но для примера сгодится и так) const int input_table[160]={ 0x0000,0x0001,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000, 0x0000,0x0000,0x0000,0x0000,0x0000,0x0001,0x0000,0x0000, 0x0000,0x0000,0x0001,0x0000,0x0000,0x0000,0x0000,0x0000, 0x0000,0x0000,0x0001,0x0000,0x0000,0x0000,0x0000,0x0000, 0x0001,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000, 0x0000,0x0000,0xFFFF,0x0001,0x0000,0x0000,0x0001,0x0000, 0x0000,0x0000,0x0000,0xFFFF,0x0000,0x0000,0xFFFF,0x0000, 0x0001,0x0000,0x0000,0x0000,0xFFFF,0x0000,0x0000,0x0001, 0x0000,0x0000,0x0000,0x0000,0xFFFF,0x0000,0x0000,0x0000, 0x0000,0x0000,0x0000,0x0000,0x0000,0x0001,0xFFFF,0x0000, 0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0xFFFF, 0x0000,0x0000,0xFFFF,0x0000,0x0000,0x0000,0x0000,0x0000, 0x0000,0xFFFF,0xFFFF,0x0000,0x0000,0x0001,0x0000,0x0000, 0x0000,0x0000,0xFFFF,0x0000,0x0000,0x0000,0x0000,0x0000, 0x0000,0x0000,0xFFFF,0xFFFF,0xFFFE,0xFFFE,0xFFFE,0xFFFE, 0xFFFE,0x0001,0x0001,0x0001,0xFFFF,0xFFFC,0xFFF3,0xFFEB, 0xFFE4,0xFFE5,0xFFEE,0xFFF7,0x0005,0x001E,0x001D,0x0006, 0xFFE7,0xFFB7,0xFF89,0xFF72,0xFF6C,0xFFA1,0x000E,0x0048, 0x0089,0x00BB,0x0021,0xFF4F,0xFEAC,0xFD77,0xFCA3,0xFC80, 0xFCB4,0xFDC4,0xFFEA,0x0332,0x05CC,0x069B,0x0802,0x0728}; Далее, поскольку speex "портит" входной буфер, я объявил input_buf[160] extern const signed int input_table[]; signed int input_buf[160]; Перед вызовом я заполняю input_buf и speex_encode_int(enc_state, &input_buf, &encBits); Аналогично поступаю на WIN реализаци. После вызова, я сначала сравнивал выход. Но потом я посмотрел на вход(он ведь портачит входной буфер) и там тоже оказываются разные значения. Т.е. внутри, получается, он поразному обрабатывает буфер! Почему?? К примеру WIN изменяет только значения с input_buf[150] до input_buf[159], на TI меняются со 115 до 159 плюс ещё вразнобой, значений 6-7... Выходы, естественно тоже не соответствуют. Что делать? Как такое может быть? Пробывал как FIXED_POINT, так и FLOAT - результаты одинаковы. Перед вызовом буферы одинаковы. С памятью вроде всё ok - нигде не переполняется. Оптимизации компилятора выкл.

Не хватает мне оперативки как ни крути! То, о чём вы писали, я проделывал раньше, но после сборки speex, секция .text уже никуда не вмещалась. Пришлось мудрить с XINTF....

В общем всё работает. Редактируем linker .cmd файл, .gel файлик, очень кстати, инициализирует XINTF перед загрузкой проги. Поначалу, когда наблюдал за GPIO регистрами, закомментировал эту функцию, а вот сейчас пришлось вернуть )) Для интересующихся, выкладываю свою версию XINTF_lnk.cmd MEMORY { PAGE 0 : /* BEGIN is used for the "boot to SARAM" bootloader mode */ /* BOOT_RSVD is used by the boot ROM for stack. */ /* This section is only reserved to keep the BOOT ROM from */ /* corrupting this area during the debug process */ BEGIN : origin = 0x200000, length = 0x000002 /* Boot to XINTF zone7A */ BOOT_RSVD : origin = 0x200002, length = 0x00004E /* Part of M0, BOOT rom will use this for stack changed for XINTF*/ RAML0123 : origin = 0x008000, length = 0x004000 /*Together*/ /* RAML1 : origin = 0x009000, length = 0x001000 */ /* RAML2 : origin = 0x00A000, length = 0x001000 */ /* RAML3 : origin = 0x00B000, length = 0x001000 */ ZONE7A : origin = 0x200050, length = 0x03F7B0 /* XINTF zone 7 - program space */ CSM_RSVD : origin = 0x33FF80, length = 0x000076 /* Part of FLASHA. Program with all 0x0000 when CSM is in use. */ CSM_PWL : origin = 0x33FFF8, length = 0x000008 /* Part of FLASHA. CSM password locations in FLASHA */ ADC_CAL : origin = 0x380080, length = 0x000009 RESET : origin = 0x3FFFC0, length = 0x000002 IQTABLES : origin = 0x3FE000, length = 0x000b50 IQTABLES2 : origin = 0x3FEB50, length = 0x00008c FPUTABLES : origin = 0x3FEBDC, length = 0x0006A0 BOOTROM : origin = 0x3FF27C, length = 0x000D44 PAGE 1 : RAMM01 : origin = 0x000050, length = 0x0007B0 /* RAMM1 : origin = 0x000400, length = 0x000400 */ RAML4567 : origin = 0x00C000, length = 0x004000 /*together*/ /* RAML5 : origin = 0x00D000, length = 0x001000 RAML6 : origin = 0x00E000, length = 0x001000 RAML7 : origin = 0x00F000, length = 0x001000 */ ZONE7B : origin = 0x23F800, length = 0x000800 /* XINTF zone 7 - data space */ } SECTIONS { /* Setup for "boot to SARAM" mode: The codestart section (found in DSP28_CodeStartBranch.asm) re-directs execution to the start of user code. */ codestart : > BEGIN, PAGE = 0 ramfuncs : > RAML0123, PAGE = 0 .text : > ZONE7A, PAGE = 0 /*all code in external RAM*/ .cinit : > ZONE7A, PAGE = 0 .pinit : > ZONE7A, PAGE = 0 .switch : > RAML0123, PAGE = 0 .stack : > RAMM01, PAGE = 1 .ebss : > RAML4567, PAGE = 1 /*here, we use internal RAM*/ .econst : > RAML4567, PAGE = 1 .esysmem : > RAML4567, PAGE = 1 IQmath : > RAML0123, PAGE = 0 IQmathTables : > IQTABLES, PAGE = 0, TYPE = NOLOAD IQmathTables2 : > IQTABLES2, PAGE = 0, TYPE = NOLOAD FPUmathTables : > FPUTABLES, PAGE = 0, TYPE = NOLOAD /* DMARAML4 : > RAML4, PAGE = 1 DMARAML5 : > RAML5, PAGE = 1 DMARAML6 : > RAML6, PAGE = 1 DMARAML7 : > RAML7, PAGE = 1*/ ZONE7DATA : > ZONE7B, PAGE = 1 .reset : > RESET, PAGE = 0, TYPE = DSECT /* not used */ csm_rsvd : > CSM_RSVD PAGE = 0, TYPE = DSECT /* not used for SARAM examples */ csmpasswds : > CSM_PWL PAGE = 0, TYPE = DSECT /* not used for SARAM examples */ /* Allocate ADC_cal function (pre-programmed by factory into TI reserved memory) */ .adc_cal : load = ADC_CAL, PAGE = 0, TYPE = NOLOAD } Много лишнего мусора, также, кажется не вся внутренняя оперативка используется, но чистить окончательно было лень. Главное сам смысл - циферки каждый сам подставит :)

Анегдот классный. Про то, что с нулевого по третий reserved - я как-то не подумал. Значит на данный момент ситуация такая: если всё делать в самом начале, в main() - всё работает. Если в функции timerInit - не работает. В регистрах(через один) одинаковое значение, которое не выбить ничем. Конечно, я буду проверять, но какие могут быть ошибки? Сами регистры задефайнены в одном хидере и просто используются в разных местах... При этом timer0 работает нормально, а timer1 и 2 не хотят.

Конечно в железе! Причем я же говорю - это проявляется только на этом проекте. Я уже build options все перепроверил, codeStartBranch.asm стандартный, далее main() и на тебе! Нужно как-то разобраться со всем этим. Могу выложить доп. скрины, .map, исходники - всё, что нужно.

Разобрался сам: в основном проекте стоял Floating point support: fpu32, а в либе none. Поставил в fpu32 - всё заработало! :-)

Я ничего не понимаю :05: ПОСМОТРИТЕ НА ЭТО БЕЗОБРАЗИЕ! Когда создаю новый проект(или открываю пример) - всё работает! Как только всё то-же самое проделываю в существующем проекте, то вообще ничего не фурычит )) Даже уже первым оператором в main() поставил присвоение - и всё равно результат потрясает! В других регистрах устойчиво наблюдаются значения, которые с ходом программы как-то магически меняются(но не часто). Результат воспроизводится - т.е. в одном и том-же месте в программе, значения регистров не меняются во время разных прогонов. HEEEELP!!!!!

А мне уже не хватает! Люди, а может быть прямо с CCS во внешнюю память можно записать прогу?! Слинковать всё красиво, чтоб .text лежал в XINTF ZONE7 и load program! В GEL есть инициализация XINTF. прям через JTAG пропишет все регистры, а дальше простая запись в адрес такой-то и вперед! Что скажете? По-моему вполне реально!

Добрый день. Работаю в CCS3.3 DSP TI320F28335 Наткнулся на проблему. Захотел в своём проекте использовать .lib (скомпилил Speex как lib) т.е. она вроде собралась без ошибок - всё нормал. При создании проекта выбрал C28X, как положено! Как только я начинаю использовать её функции в своём основном проекте(который будет .out) я натыкаюсь на пробему(проект тоже для C28X) <Linking> >> error: linking files for incompatible targets (library '!mySpeex/Debug/libspeex.lib', member 'speex.obj') >> warning: creating output section .const without SECTIONS specification >> warning: creating output section .cio without SECTIONS specification >> warning: entry point other than _c_int00 specified пробывал также разные модели памяти использовать(Large и unified memory) также ставил их вместе. В общем, даже когда и в либе и в проекте стоит Unified Memory Model - я получаю: >> error: linking files with incompatible memory models (library '!mySpeex/Debug/libspeex.lib', member 'speex.obj') Ткните, пожалуйста, меня в подробное описание Unified memory model. И подскажите как правильно слинковать либу с проектом. Что за секция .cio? Пересобираю оба проекта, сравниваю настройки - всё одинаково, а он всё равно не хочет линковать их!!!! :05:

Speex.... При создании проекта, выбрал .lib чтоб лежал себе он в либе, а я его использовал. Минут за 20 - 30 я наконец собрал его и на выходе получилась libspeex.lib В основной проект пишу#include "speex.h", линкеру Include libraries: libspeex.lib Rebuild.... <Linking> >> error: linking files for incompatible targets (library '!mySpeex/Debug/libspeex.lib', member 'speex.obj') Там и там, естественно, я выбирал С28х проц.... что ему может не нравится???

Всё дело в том, что timer0 работает отлично! И именно с таким-же подходом к нему! timers.c void _InitCpuTimer(int tmr) //Инициализирует соответствующий таймер { // CPU Timer 0 if(tmr==0){ // Период на максимум TIMER0PRD32 =0xFFFFFFFF; //Частоту SYSCLKOUT пока далить не на что не будем TIMER0TPR=0; TIMER0TPRH=0; //Таймер пока должен стоять! TIMER0TCR|=BIT4; //TSS в еденицу! //Перезагрузить регистры таймера(применить вышепроведенные настройки) TIMER0TCR|=BIT5; //TRB = 1 #ifdef DEBUGMD TIMER0TCR&=BIT10+BIT11 ^ 0xFFFF; //Поставим в HARD STOP режим #endif } if(tmr==1){ // Период на максимум TIMER1PRD32 =0xFFFFFFFF; //Частоту SYSCLKOUT пока далить не на что не будем TIMER1TPR=0; TIMER1TPRH=0; //Таймер пока должен стоять! TIMER1TCR|=BIT4; //TSS в еденицу! //Перезагрузить регистры таймера(применить вышепроведенные настройки) TIMER1TCR|=BIT5; //TRB = 1 #ifdef DEBUGMD TIMER1TCR&=BIT10+BIT11 ^ 0xFFFF; //HARD STOP #endif } if(tmr==2){ // Период на максимум TIMER2PRD32 =0xFFFFFFFF; // TIMER2PRDH=0xFFFF; //Частоту SYSCLKOUT пока далить не на что не будем TIMER2TPR=0; TIMER2TPRH=0; //Таймер пока должен стоять! TIMER2TCR|=BIT4; //TSS в еденицу! //Перезагрузить регистры таймера(применить вышепроведенные настройки) TIMER2TCR|=BIT5; //TRB = 1 TIMER2TPR=0; // [b]а это для проверки[/b] но он всё равно не хочет быть 0 #ifdef DEBUGMD TIMER2TCR&=BIT10+BIT11 ^ 0xFFFF; //HARD STOP #endif } } Битовые поля не использую, можно сказать, из религиозных соображений :) Ваш пример у меня работает. watch показывает, что всё хорошо. Странно всё это. Буду копать дальше...в чём может быть дело..... Просто я в #define делаю разименование указателя, а у вас по тексту * ставится. Разницы быть не должно никакой, но я попробую и так... Вроде асм код ведь нормальный генерится! Почему-же не работает-то?!?! Вот что напрягает! Да нет же. Я PRD наоборот объявил как unsigned long и обозвал его TIMER2PRD32, чтоб не маяться с половинками. TIMER2TPR(TIMER2TPRH) мне не нужны - я их оставил int'ами....

Во первых, на скриншоте виден асм код. Адреса там именно те, которые нужно. Во вторых, unsigned int 16ти битный. А вот char обычно 8ми, это в CCS он 16ти битный, что тоже вписывается в стандарт. Дока TMS320x2833x, 2823x System Control and Interrupts see page 132 Для объединения некоторых с их половинками, я и использовал unsigned long, который уже 32х битный. Проблема в том, что я пишу в TIMER2TCR с адресом 0x0C14(чётный!!!!)! Но почему-то значение TIMER2TPR с адресом 0x0C16(тоже чётный) получается равным тому-же TIMER2TCR! При присвоении TIMER2TPR=0 - ничего не происходит. А мне нужно, чтобы в нём был именно 0! Иначе ниего не работает. В этом и состоит суть проблемы. Пожалуйста внимательнее почитайте мой пост и посмотрите скриншот. По нему видно, что компилятор использует именно те адреса, которые нужно - но всё равно ничего не происходит и регистры дублируются!!!! Я считаю, что это либо ошибка документации, либо самого чипа..Хотя верить в это не хочется! Нужен взгляд со стороны. Может я действительно что-то упустил!?!?!

Ну если с защитными паузами - тогда всё ясно и понятно. Спасибо за разъяснения )

Странно как-то. А если я передаю данные, в которых встретилось +++<lf><cr>? Модем перескочит в AT режим и начнётся веселуха.... Всё равно толком не могу понять сам механизм!

А я пришел к выводу, что виснет студия ИСКЛЮЧИТЕЛЬНО изза того, что кагда Target connected, и после очередного прогона программы, делается stop - студия, при наведении мышью на переменную(и вообще, на символ) пытается выдать popup с её значением. Я не знаю почему, но это у неё не всегда получается. Если Target disconnected - всё отлично работает.

Выдержка из даташита: Name Address Size (x16) Description Bit Description TIMER0TIM 0x0C00 1 CPU-Timer 0, Counter Register. Figure 3-21 TIMER0TIMH 0x0C01 1 CPU-Timer 0, Counter Register High. Figure 3-22 TIMER0PRD 0x0C02 1 CPU-Timer 0, Period Register. Figure 3-23 TIMER0PRDH 0x0C03 1 CPU-Timer 0, Period Register High Figure 3-24 TIMER0TCR 0x0C04 1 CPU-Timer 0, Control Register Figure 3-25 Reserved 0x0C05 1 TIMER0TPR 0x0C06 1 CPU-Timer 0, Prescale Register Figure 3-26 TIMER0TPRH 0x0C07 1 CPU-Timer 0, Prescale Register High Figure 3-27 TIMER1TIM 0x0C08 1 CPU-Timer 1, Counter Register. Figure 3-21 TIMER1TIMH 0x0C09 1 CPU-Timer 1, Counter Register High. Figure 3-22 TIMER1PRD 0x0C0A 1 CPU-Timer 1, Period Register. Figure 3-23 TIMER1PRDH 0x0C0B 1 CPU-Timer 1, Period Register High Figure 3-24 TIMER1TCR 0x0C0C 1 CPU-Timer 1, Control Register Figure 3-25 Reserved 0x0C0D 1 TIMER1TPR 0x0C0E 1 CPU-Timer 1, Prescale Register Figure 3-26 TIMER1TPRH 0x0C0F 1 CPU-Timer 1, Prescale Register High Figure 3-27 TIMER2TIM 0x0C10 1 CPU-Timer 2, Counter Register. Figure 3-21 TIMER2TIMH 0x0C11 1 CPU-Timer 2, Counter Register High. Figure 3-22 TIMER2PRD 0x0C12 1 CPU-Timer 2, Period Register. Figure 3-23 TIMER2PRDH 0x0C13 1 CPU-Timer 2, Period Register High Figure 3-24 TIMER2TCR 0x0C14 1 CPU-Timer 2, Control Register Figure 3-25 Reserved 0x0C15 1 TIMER2TPR 0x0C16 1 CPU-Timer 2, Prescale Register Figure 3-26 TIMER2TPRH 0x0C17 1 CPU-Timer 2, Prescale Register High Figure 3-27 Так, что проблема не в том. В этом DSP вся память адресована 16ти битными блоками. Было-бы как-то странно, если бы по нечетным адресам нельзя было расположить переменную int

Снова я чего-то не понимаю, хотя, может это фича, а не баг.... В общем есть в TMS320А28335 аж 3 таймера. Везде в мануалах пишут, что timer1 и timer2 for TI/RTOS use. Ну думаю, чтоб не занимали таймеры в своих проектах. Меня ведь этими предупреждениями не напугать :) Пишу функции под все таймеры. Все адреса регистров в описалове имеются. Таймерок один, думаю, заделаю под что-то типа GetTickCount. Пригодится. Но не тут-то было! Оказывается, присвоение значения регистру TIMER2TCR(адрес 0x0С14) тут-же, магическим образом, оказывается записанным и в TIMER2TPR(адрес 0x0C16). Таймер, естественно, работать не хочет, т.к. TIMER2TPR - это делитель SYSCLKOUT и получается, мы делим его на "космическое" число 62609! Плюс ко всему, оказывается запись в TIMER2TPR(0x0C16) не приводит не к каким результатам! Объявил регистры, следующим образом: #define TIMER2TIM32 (*(volatile unsigned long *)(0x0C10)) //#define TIMER2TIMH (*(volatile unsigned int *)(0x0C11)) #define TIMER2PRD32 (*(volatile unsigned long *)(0x0C12)) //#define TIMER2PRDH (*(volatile unsigned int *)(0x0C13)) #define TIMER2TCR (*(volatile unsigned int *)(0x0C14)) #define TIMER2TPR (*(volatile unsigned int *)(0x0C16)) #define TIMER2TPRH (*(volatile unsigned int *)(0x0C17)) С таймером 1 - та-же ситуация!!!! Что-же это выходит, только один таймер могут юзать простые смертные? А если я эту самою RTOS разрабатываю сейчас, то как-же быть??? В общем что-то ОЧЕНЬ всё это странно. Привожу скриншот с иллюстрацией происходящего. Какие будут соображения?

Добрый день. Планирую использовать телефон SonyEricsson W810i в качестве GSM модема. Достал AT command set на него, всё вроде так радужно )) Но меня интересует вот такой вопрос: сконнектился я с другим модемом, после CONNECT, ведь, всё, что приходит и уходит с порта - это данные, которые идут на другой модем. Тогда как-же мне, допустим, отключиться? Или модем фильтрует AT команды и выполняет их? Тогда как-же я передам, допустим, текстовик с описанием всех AT команд? Модем что их будет пытаться воспринимать как команды? Думаю как-то иначе всё. Порсто я не знаю как :05:

Хорошо хоть сбойного кода не делает, а то вообще туго пришлось-бы. CSS v3.3, я считаю, не содержит(к счастью) подобного глюка, иначе бы уже давно наткнулся на проблему с "я". Всё равно спасибо за информацию! Если бы проблема возникла - изрядно я помучался, мне кажется, не будь предупрежден. ))

Ха ха. А вот я тоже сейчас задумался, а как с нулями? Присвоение регистру 0 наверное не воспринимается как запись и соответственно, ничего не происходит....Надо проверить щас. С другой стороны, ведь передаются же файлы как-то по кабелю? А в них нули ведь встречаются пачками!

Понято. Спасибо. Ну раз до сих пор вроде компилится, может этот CCS к глюкавым не относится... А как обычно глючит-то? Не компилится? Или сбоит код на выходе?