Сергей Борщ

Ну так напишите обертку и вручную используйте. Компилятор-то тут при чем? Именно так. Внутри обработчика (предворительно исключив собственную рекурсию если она могла быть) разрешается прерывание. Чего тут непонятного :blink: ? Опс. Еще и вложенные прерывания организовать там, где можно просто тупо взять данные из копии в ОЗУ. Тогда не удивительно, что "грабли" :-)

Вот очень подробно описано: http://www.telesys.ru/projects/proj022/index.shtml

Огласите хотя бы один способ. PUSH/POP-нуть глобальные временные регистры EEAR, EEDR... Он это должен сделать тогда и только тогда когда вызов идет из прерывания. Во всех остальных случаях это будут ненужные накладные расходы. Как компилятор определит, что вызов делается из прерывания? Даже при разрешенных прерываниях? Даже если ожидаемое событие все равно глобально должно поменять весь алгоритм работы? :blink: ?? Ожидается готовность eeprom. Что значит при разрешенных прерываниях? Мы уже внутри обработчика. Нет, компилятор тут не при чем. Он физически не может тут ничем помочь. Если уж если вам так хочется поизвращаться - напишите обертку для функции чтения из прерывания.

Огласите хотя бы один способ. Ну, не знал, что чтение в прерывании флагов сохраняемых в EEPROM в каком-то другом месте это глюк :cranky: ... Теперь знаете - вы сами на него напоролись. Для обхода приходится запрещать прерывания в основном цикле, хотя без этого можно было обойтись. Обращение к eeprom требует ожидания готовности eeprom, а ожидание чего-либо находясь в прерывании - ошибка алгоритма. TomaT абсолютно прав. Копии данных, которые могут потребоваться в прерывании надо держать в ОЗУ. И грабли сразу исчезнут. А главное, компилятор сразу станет не виноват.

Это не у этого контроллера надо было отлавливать момент обратного хода развертки и в это время менять содержимое? Да, он. Вот например: http://www.telesys.ru/wwwboards/mcontrol/9...ges/75094.shtml Тема часто поднимается, вот еще: http://www.google.com/search?client=opera&...-8&oe=utf-8

Пришел на работу, прочитал вчерашние сообщения и только рука потянулась написать предупреждение, как похоже вы уже "наступили" :-) Я недавно по дурости первыми же командами инициализации периферии перевел ноги JTAG в состояние обычных ног. А поскольку залил сразу во флешку то получил мигающий светодиод и мертвый JTAG. Пришлось подключить COM-порт, ногой P0.14 принудительно стартануть загрузчик, стереть через загрузчик флешку и только после этого JTAG ожил. Может вас тоже спасет стирание через загрузчик? А про инструмент соглашусь с zltigo - ИАР гораздо дружелюбнее. Там все работает и отладка начинается без всяких заглушек.

Грабли не в компиляторе. Вопрос первый: Зачем запрещать прерывания если программа уже находится в прерывании? Из него плавно вытекает второй: как компилятор определит что в одном случае функция вызвана из прерывания и запрещать не нужно а в другом случае из фона и запрещать нужно? В том виде в каком оно есть все прекрасно работает из фона _без_ лишних накладных расходов - запретов/разрешений прерываний и сохранения/восстановления регистров. Если уж вы решили извратиться и работать с eeprom в прерывании (что само по себе уже глюк, только алгоритма) то уж будьте добры возьмите на себя труд сделать все эти лишние действия вручную и там где по-вашему они необходимы. P.S. А еще он за пивом не бегает, вот это меня бесит больше всего.

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

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

Ой... ассемблер :-( Ну симптомы явно указывают на неправильную инициализацию. Глянул инициализацию: ldr r0,=ioset ldr r2,=D45 // установка D4, D5 str r2,[r0] stmfd sp!,{r14} mov r2,#0x200 // 43,4 мкс bl pause ldmfd sp!,{r14} ldr r0,=ioclr ldr r2,=LCD_IOALL str r2,[r0] Вижу выставление D4, D5, задержку и сброс всех ножек. Не вижу где здесь выставляется E. Вы пробоваали на симуляторе или в железе пошагово проходить и смотреть что ноги выставляются именно так как надо? После команд =D45 задержки есть, после остальных команд инициализации задержек нет. Индикатор не будет успевать. Задержки 43 мкс при инициализации маловаты. Я делаю (взял в даташите, с тех пор кочуют из проекта в проект): перед началом инициализации 200мс, после первой и второй команд (0x03) по 50мс и после 0x02 200мс. Далее все задержки около 40 мкс.

А если попробовать в .ddf исправить для нужного участка памяти access type с R на RW - это не поможет? Или добавить еще одну область с RW?

Да. Но кроме локальных переменных на стеке хранятся адреса возвратов из подпрограмм и временные переменные (если они нужны компилятору в процессе выполнения кода). Можно с примерами? Если глобальная переменная инициализирована при объявлении, то необходим код для инициализации и для хранения инициализирующего значения. А если просто int a, b, c; int main (int) { return 1; } и int a, b, c, d, e, f; int main (int) { return 1; } То размер кода должен остаться неизменным.

Это шутка такая? А программа while(ind--){PORTD=ind;}; располагается где же? переменная объявлена внутри функции (локальная), поэтому размещается в стеке (скорее всего в тех 64 bytes of DATA memory). (+ 1 absolute ) - это PORTD

Спроси у автора (=Shura=) на http://www.telesys.ru/wwwboards/mcontrol/index.shtml

А если такой вариант: Кто первый захотел занять модем, тот его и получил в прозрачном режиме. Для всех остальных устройство прикидывается модемом но на попытку звонка отвечает Busy или какой эквивалент "SMS не прошла". Устройство будет пытаться повторить посылку. После освобождения канала первым устройством прозрачный канал переключается на второе и очередная попытка успешно пройдет уже через модем.

Я бы даже сказал static void Regeneration(void) { ... } Красиво! Даже и в голову не приходило такое :-)

Пока хватает 256 байт ОЗУ можно и Tiny, но тогда и .xcl надо брать для модели Tiny, т.е. с "t" на конце.

Видимо в настройках проекта стоит настройка memory model: Tiny а файл .xcl взят с "s" на конце, т.е. для модели памяти Small. Измените настройку на Small и все должно заработать. Кстати, интересно как "В дебагере все легло ровно", ведь файл для дебаггера тоже генерит линкер и с теми же самыми параметрами... Или это после переключения target с debug на release? Тогда понятно - надо сравнить модель памяти и выбранный .xcl в обоих targets.

Да, это работает, спасибо. Но хотелось бы, чтобы конец сегмента, или начало требуемого массива в тексте модуля *.с, а не в *.xcl , и адрес вычислялся на этапе компиляции Стоп. Вычислялся адрес или размещались данные? Для вычисления адреса вполне работает intrinsic-функция __segment_end("INTVEC"). А рулить размещением из .C можно только в одном случае: размещение констант по абсолютному адресу. Во всех остальных случаях это невозможно, ибо С с адресами не работает. Он знает только смещения в пределах перемещаемого сегмента (участка сегмента), а абсолютные адреса взамен этих смещений проставляет линкер после размещения сегмента. Возможно имеет место неправильный подход к проблеме. Если программа не использует прерываний то INTVEC состоит из одного вектора (RESET). Далее возможны два варианта в зависимости от содержания .xcl: следующий за этим сегментом адрес будет равен двум(байтам) либо будет "дырка" на неиспользуемые вектора. Но опять же предугадать какой вариант будет в конкретном случае не смотря в .xcl невозможно. Может вы изложите задачу более подробно, с каким-нибудь примитивным примером?

а... Я-то думал вы сначала даташит про bootloader прочитали... Setting the Boot Loader Lock Bits by SPM To set the Boot Loader Lock Bits, write the desired data to R0, write “X0001001” to SPMCR and execute SPM within four clock cycles after writing SPMCR. Интересно, что же может делать функция с загадочным названием __DataToR0ByteToSPMCR_SPM? Не пользовался, но могу предположить что для процессоров с более 64К памяти, т.е. с адресом в 24 бита? Ну нет в функциях команды SPM очистки буфера The temporary buffer will auto-erase after a page write operation or by writing the RWWSRE bit in SPMCR. А макрос может выглядеть так: while(SPMCR & (1<<SPMEN)); Согласно правилам языка высокого уровня С если имя файла в директиве #include указано в двойных кавычках то компилятор ищет его в текущей директории, т.е. в папке проекта. Если же в угловых - то в папках указанных компилятору в опциях как include path. Поэтому flash.h искать в папках IAR не имело смысла - он должен быть в исходниках от "аплекухи 910".

Если узнать и разместить надо на этапе компиляции - то в .xcl определить свой сегмент сразу после определения INTVEC и до остальных кодовых сегментов. В этот сегмент и поместить нужное. Если на этапе выполнения - __segment_end("INTVEC") в С и SFB(INTVEC) в асм.

ой мама... "На колу мочало...". В intrinsics.h есть макросы >Очистить буфер, занести слово в буфер, _SPM_FILLTEMP(Addr,Data) > записать буфер, _SPM_PAGEWRITE(Addr) >биты защиты выстывить _SPM_LOCKBITS(Data) Там же полезные _SPM_ERASE(Addr) _SPM_GET_LOCKBITS() _SPM_GET_FUSEBITS() Они вызывают "в IAR функции для самопрограмирования": __DataToR0ByteToSPMCR_SPM() __AddrToZByteToSPMCR_SPM() __AddrToZWordToR1R0ByteToSPMCR_SPM() Или я опять вопроса не понял?

Постараюсь по мере возможностей. Сначала сделаю отступление: эти функции я в своей работе пока не использую, поскольку в части проектов у меня загрузчик написан на асме а в части я использую AES Loader из аппликашки Атмела. С этими функциями я баловался еще в версии 2.28 (сейчас нашел тот исходник, там судя по исходнику их прототипы были описаны в pgmspace.h. Вот тот исходник: #include <iom8.h> #include <inavr.h> #include <pgmspace.h> void ErasePage (unsigned char page); const __root __flash unsigned char TestFill[64] @ (0x10 << 6) = {1,2,3,4,5}; void main (void) { DDRC = (1<<2)|(1<<3); PORTC = 0; ErasePage(0x10); for(;;) PORTC ^= (1<<2); } void ErasePage(unsigned char page) @ "BLS" { _SPM_ERASE((unsigned int)page << 6); while(SPMCR & (1<<SPMEN)) PORTC |= (1<<3); __DataToR0ByteToSPMCR_SPM(0, (1<<RWWSRE)|(1<<SPMEN)); }

Все правильно, только препроцессор здесь ни при чем. Препроцессор тупо заменяет один текст другим, а все остальное делает компилятор. Да, правильно. А меня чего-то заклинило что это делает препроцессор. И очень меня это смущало. Спасибо, теперь "отпустило" :-) Действительно, при таком раскладе все становится гармоничным. Возможно я где-то более подробно читал какая из частей компилятора занимается вычислением констант и в голове ошибочно отложился препроцессор.

Тем что в некоторых компиляторах long long состоит из вдвое большего количества бит чем long?