VladislavS

О какой среде разработки идет речь?

А меня вот заинтересовал вопрос перемещаемости кода. Могу я из разных мест запускать то что IAR накомпилил? Что-то мне говорит что нет.

Да ладно вам на пустом месте ругаться... Чтобы никому не было обидно я оставил вызов кода из флэшь по первому варианту (изменить её адрес всё равно не получится), а загруженный в SDRAM код по второму варианту. Работают оба варианта, а практика критерий истины.

Если делать на классическом С, то что-то типа того получается: typedef void (*MyFunc)(void); MyFunc MyCode; int main() { MyCode = (MyFunc)0x10000000; MyCode(); } Только вызов по всем книжкам (*MyCode)() должен быть, а работает правильно и просто MyCode().

А есть у кого __iar_data_init() в исходниках? А то привык в проекте cstartup.s79 , low_level_init.c и segment_init.c иметь. Пока только щупаю 5.10 - рабочие проекты на него еще не перевожу, но уже подумываю.

Так оно и есть. Запуск кода из параллельной flash был только первым шагом. Теперь буду загружать разные приложения из DataFlash в SDRAM. Да мне вообще стыдно за такой вопрос. Просто заклинило. Сидел побеждал размещение сегментов в памяти, копирование векторов прерываний, стартовые инициализации, флэшлоадер. Когда все вроде заработало и осталась такая мелочь как передать управление на код и пришлось воспользоваться подзатыльником. Теперь после просветления никакого труда не составит сделать указатель на функцию и по нему запускать код в любом нужном месте памяти.

Спасибо. Сработало. Как все просто когда знаешь...

Что-то совсем заработался... :( Ваяю начальный загрузчик. Основная программа лежит по адресу 0x10000000 в параллельном flash. По окончании всех действий надо просто передать на неё управление. Как? EWARM 4.40. Процессор AT91RM9200.

Если совсем на пальцах, то http://slycontrol.ru/scr/kb/ir.htm

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

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

Что-то я не пойму смысла DS1307 без батарейки. Весь его смак как раз в том, что часы тикают от батарейки пока устройство выключено или обесточено форсмажором.

Берем doc1768.pdf на офсайте Атмела. И читаем, читаем, читаем до полного прояснения.

Срочно надо мультикасты принимать. В даташите сказано: "The CRC algorithm reduce the destination address to a 6-bit index into a 64-bit hash register." Идея понятна, но алгоритма вычисления никак найти не могу.

Таймеры, прерывания... Все вроде правильно, но мне кажется надежнее будет работать так: for(;;) { if(PINA&(1<<PA0)) //Проверим уровень с фотоприемника PORTA&=~(1<<PA1); //Гасим светодиод else if(PINA&(1<<PA1)) PORTA&=~(1<<PA1); else PORTA|=(1<<PA1); //Колбасим светодиод __delay_cycles(подобрать); }

IgorKossak Согласен. Только откуда она там взялась?

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

Так 0400000300000000F9 это скорее всего сегмент EEPROM туда приписался и при прошивке завалил вектора прерываний - вот и не работает. Когда по молодости пользовался методом подавления e133, то регулярно забывал вычищать хвост hex-а и получал схожие грабли.

Я уже давно делаю так: __no_init __eeprom unsigned char ee_flag; __no_init __eeprom unsigned char a; __no_init __eeprom unsigned int b; int main() { if(ee_flag==0xFF) { ee_flag=0; a=0; b=1000; } // Остальной код } В качестве флага можно использовать одну из полезных из переменных, если у неё FF недопустимое значение. Это дает много плюсов. Во-первых, компилятор не генерит сегмент ee_prom и не надо думать как его вынести в другой файл. Во-вторых, не надо отдельно прошивать EEPROM и каждый раз ловить регулировщиков на том что они его не прошили. В-третьих, все равно контроль корректности данных в EEPROM надо делать, почему бы не совместить это с инициализацией.

Сколько ни возникало желание сделать цепочку на плате, но задница всегда шептала "НЕ НАДА". На разъеме (6 контактов) много не выиграешь. А если лень перетыкать разъемы - сооруди цепочку на переходнике.

Обычно если все правильно и не работает, то забыл клоки на устройство подать. :) Проверь.

Хм .... так и объявил, но массив хранится максимум секунд 7! А потом опять случайные числа там оказываются ... Может что то еще надо прописать? Интересно, а как давно RAM при выключеном питании стал сохраняться?

В IAR что-то типа вот этого надо использовать: __flash unsigned char codepage[256]= {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47, 48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63, 64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79, 80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95, 96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111, 112,113,114,115,116,117,118,119,120,121,122,123,124,125,0xE9,127, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0xCA,0xCB,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0xA2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0xB5,0,0,0,0,0,0,0, 0x41,0xA0,0x42,0xA1,0xE0,0x45,0xA3,0xA4, 0xA5,0xA6,0x4B,0xA7,0x4D,0x48,0x4F,0xA8, 0x50,0x43,0x54,0xA9,0xAA,0x58,0xE1,0xAB, 0xAC,0xE2,0xAD,0xAE,0x62,0xAF,0xB0,0xB1, 0x61,0xB2,0xB3,0xB4,0xE3,0x65,0xB6,0xB7, 0xB8,0xB9,0xBA,0xBB,0xBC,0xBD,0x6F,0xBE, 0x70,0x63,0xBF,0x79,0xE4,0x78,0xE5,0xC0, 0xC1,0xE6,0xC2,0xC3,0xC4,0xC5,0xC6,0xC7 };

Про запуск и конфигурирование PMC у этого чипа большая ERRATA. Если использовать много разных режимов отладки, прошивки и штатной работы, то PMC шизеет. Долгие опыты в начале освоения чипа дали более менее устойчивый к смене режимов код: //Включить главный генератор и задать время запуска 6/32768= 0,18 мс PMC_MOR = 1 | (6<<8); // MOSCEN | OSCOUNT while(!PMC_SR_bit.MOSCS); //Ждем пока генератор стабилизируется //Переводим процессор на главный генератор PMC_MCKR = 1 | (0<<2) | (0<<8); // MCK = MAIN PRES=0 MDIV=0 //Настроим PLLA на 196,608 МГц //Действуем согласно ERRATA PMC_PLLAR = (1<<29) | (32<<16) | (2<<14) | (28<<8) | 4; // MULA | OUTA | PLLACOUNT | DIVA while(!PMC_SR_bit.LOCKA); //Ждем пока PLLA захватится PMC_PLLAR = (1<<29) | (31<<16) | (2<<14) | (28<<8) | 3; // MULA | OUTA | PLLACOUNT | DIVA while(!PMC_SR_bit.LOCKA); //Ждем пока PLLA захватится //Настроим PLLB на 95,8464 МГц //Действуем согласно ERRATA PMC_PLLBR = (1<<28) | (24<<16) | (28<<8) | 5; while(!PMC_SR_bit.LOCKB); //Ждем пока PLLB захватится PMC_PLLBR = (1<<28) | (25<<16) | (28<<8) | 5; // USB96M | MULB | PLLBCOUNT | DIVB while(!PMC_SR_bit.LOCKB); //Ждем пока PLLB захватится //Переключим процессор на PLLA и MCK на PLLA/2 //Действуем согласно ERRATA PMC_MCKR_bit.MDIV=1; //MCK = PCK/2 PMC_MCKR_bit.PRES=0; PMC_MCKR_bit.CSS=2; //PCK = PLLA Каким бы код ни казался странным - каждая строчка буквально вымучена опытами на железе.

А чем лечили? Если юникряком, то запросто такое может быть.