Ruslan1

Прежде чем 'требовать' подумайте а чем занимается контроллер, когда у него отобрали память? В памяти оно конечно 'само все пересылается' а процессор просто стоит, если у него конечно нет кэшей немеряно и продвинутой системы предсказаний для загрузки кэшей.... Ну а чем стоять - мог и пересылать... Короче, DMA в микроконтролерном мире во многих случаях это просто словечко для маркетинга..... Да пусть хоть совсем стоит и ждет, пока две железяки быстро обменяются с помощью его DMA-контроллера. Цикл шины на источник плюс на приемник и слово передано. Что должно быть не хуже, чем под управлением АЛУ- это очевидно. А насчет "DMA для маркетологов"- совсем не согласен. Скажу про себя- разгружает сильно. Для вссяких там UART/SPI/I2C- это просто спасение. Да и для USB/Ethernet думаю тоже.

Что-то уж слишком медленно получается. По-моему, где-то ошибка. Надеюсь, что так. Сам удивился. Пошуршу еще.

Едва ли: функция memcpy, как правило, очень хорошо оптимизирована. Ну ладно, я уже смирился и приспособился. :) Чтение страницы из NAND Flash в память (2112 байт, 8-битная шина) при тактовой шины MCK=25.3MHz, Fcore=101MHz на AT91RM9200 продолжается 2750 us. Из них собственно внутренние дела NAND Flash занимают 23 us, остальное- именно пересылка двух килобайт. Вот еще прочитал в одном документе, описывающем драйвер NAND Flash (одно из моих устройств тоже NAND-Flash). Пишут о наличии нужного DMA в платформах на базе ядра ARM7TDMI. Только непонятно, речь идет о случае "память-память" или "NANDflash-память". Да и что за камни это имеют, интересно. Написано следующее: Below is an example for a platform based on ARM7TDMI core: #ifdef DMA_ENABLE do i=*(volatile udword*) (GDMACON0); while ( (i&0x2) != 0); *((volatile unsigned int*) (GDMASRC0)) = Base_Address; *((volatile unsigned int*) (GDMADST0)) = (udword)Buffer; *((volatile unsigned int*) (GDMACNT0)) = udLength[0]; *(volatile unsigned int*) (GDMACON0) = 0x0081; udIndex+=udLength[0]; #endif А, вот, нашел, о ком это они: Samsung KS32C50100. Это конкретно NAND Flash можно на DMA повесить. Круто. Интересно, а все-таки существуют камни с ядром ARM7 или ARM9, имеющие просто DMA для передач "память-память"? Странно, если нету- ведь очень востребованная вещь.

Думаю, проблема популярная. Нужно как можно быстрее скопировать данные из одной части адресного пространства в другую. Можно придумать что-то, работающее быстрее, чем memcpy() ? Еще конкретнее: есть устройства с 8- и 16- битной организацией, расположенные в пространстве адресов контроллера StaticMemory. Хочется наиболее оптимально обменяться данными с массивом, расположенным в SDRAM.

Сначала мне прочиталось "..тот кто Плюнет на ето безумно заманчивое предложение..." :) Да одно согласование ТЗ может месяц занять. Далее по документации. Кое-где по умолчанию подразумевается ЕСКД. А это увеличивает стоимость простой работы на порядок (в 10 раз). Заказчик не упомянет, исполнитель не уточнит, потом секс надолго обеспечен. И таких "мелочей" можно толстую книжку навспоминать. И вообще. Сначала отдельно составляется договор на составление ТЗ, а вот после завершения работ по этому договору можно и о самой работе поговорить. (PS. Если конечно речь не идет о какой-нибудь конструкции выходного дня).

А вот еще есть такой небольшой редактор MED (http://www.med-editor.com/indexus.html). Я в нем пишу, мне нравится.

Есть еще среда передачи, а она бывает далека от идеала. Нередко драйверы на материнских платах заваливают фронты на больших скоростях. Да, действительно. Сейчас глянул на своей материнке- есть такая буква. Передний фронт (стоп->старт) имеет спад полторы микросекунды, задний- даже две микросекунды. На 115200 это уже должно быть чувствительно. Раньше с RS232 не применял таких скоростей, чтобы драйверы вносили заметные искажения, вот и не думал об этом. Спасибо, учту. Тут действительно все хитрее, и характеристику драйвера надо смотреть, да и емкость линии COM-порта контролировать, то есть уже и о RC надо думать.

По опыту разброс более 1.5% может вызвать проблемы. Тут все можно объяснить. Цель: синхронизировавшись по стартовому биту, не вылезти за границы бита при приеме последнего бита. Для 8N1 это выглядит так: длительность бита должна уплыть не более чем на полбита за время передачи 10 бит, иначе когда приемник будет ожидать середину последнего бита, передатчик еще будет передавать предыдущий бит или уже закончит передавать этот бит. Получается, что требуется точность 1/2 бита из 10 бит- это 5%. Учитывая, что отличаться от нормы может и приемник и передатчик, допустимую погрешность установки частоты нужно уменьшить еще в два раза. То есть 2.5%. Если отличие скорости приемника и передатчика от номинала не превышает 2.5%, то гарантированно должно работать. Или нужно говорить о разницы скоростей приемника и передатчика не более чем 5%. Есть методы, которые статистически могут улучшить результат (позволят работать с бОльшими отклонениями- но это отдельная песня. :)

Да я ж не против, я только за обеими четырьмя конечностями! Но это ж не так просто, задействовать MMU. (Все, вырубаюсь, спать охота. Завтра все, что тут рекомендовали, попробую начать воплощать.)

Нет. Лучше почитайте документацию. Вопрос в том, как в SDRAM появляется новый код, и включен ли при этом ICache. Вона как! Если кеш в это время включен- то потом возможна ошибка? Я как-то не думал об этом, так как до этого к SDRAM вообще не обращаюсь, откуда комады из той области попадут в кеш? Хотя однако туда контроллер ПДП обращается. Это объясняет то, почему я нашел почти нормально работающее сочетание, тогда у меня действительно кеш был выключен в то время, как по ПДП в SDRAM лилась новая прошивка. Но имеется один непонятный эффект, вероятно связанный с некорректным выключением кеша.

У меня не Линукс, у меня Юкос. Насчет выгрузить кеш при переключении контекста- я согласен это сделать, но не знаю как. Завтра попробую, как мне уже подсказали, инвалидизировать его. Насчет книг- спасибо за наводку, гляну. Еще вот увидел в документации на ядро 920T о кешах. А про MMU я со времен Блэкфина еще что-то помню. Потому что там его не было вообще, и это составляло проблему. Теперь же у меня есть MMU, и его наличие тоже является проблемой. :) Ну уж нет, оно того стОит- ускорение в четыре раза это не шуточки!

Это про первую строчку сообщения? Если я не включаю кеш в бутлодере, а включаю его в стартапе основного приложения, то все работает без ошибок. Был у меня и вариант, когда кеш включается только в бутлодере и все. Результат: при передаче управления основной программе программа успевает совершить некоторые действия (выдать в дебаггерский порт сообщение о своем старте) и виснет. Вероятно, происходит то же исключение, у меня там заглушка. Насчет инвалидировать- спасибо, я не знал. Сейчас(нет, все же завтра) прочитаю еще раз описание CP15. В случае этого действия что произойдет? довыполнятся операции, уже сохраненные в кеше, и кеш выключится? Мне кажется, что у меня такая хитрость: во время работы кеша происходит, можно сказать, переключение контекста (в адресах SDRAM появляется новый код). Может быть, в этом и дело?

Сразу оговорюсь, что если я не включаю кеш в бутлодере, то все работает отлично. В своем первичном бутлодере включаю кеш команд: __MCR(15,0,__MRC(15,0,1,0,0) | 0x00001000,1,0,0) ; Кеш данных не включаю, так как MMU не использую (не умею), а без MMU он не работает. Все отлично и шикарно, ускорение ого-го (в 4 раза при тестировании SDRAM). Но вот когда загружаю в SDRAM основную прошивку и перехожу на нее, то в какой-то момент возникает исключение по вектору 0x10 (Data Abort). При попытке пошагово просмотреть то место, с которого происходит исключение, ничего крамольного не вижу. Более того- если я даже просто ставлю точку останова в основной программе до возникновения исключения, то дальше исключения уже не происходит. То есть достаточно поставить отладчиком точку останова, а при остановке запустить дальше- и никаких усключений, все работает отлично. Такое ощущение, что пока оно стоит, что-то там в кеше успевает дозреть и далее работает нормально. Ну ладно. Выключаю кеш в конце бутлодера и потом включаю его по новой в основном коде- тоже возникает исключение. Передаю управление основной программе из бутлодера в состоянии, как можно более близком к ресету (в основной программе происходит полный стартап, кроме уже проинициализированной бутлодером периферии): и ARM-мода, и прерывания выключены, и в супервизоре. Чего ему еще не хватает, не понимаю. С помощью метода тыка добился почти работоспособного варианта: выключаю кеш где-то посередине бутлодера, и включаю его уже потом в основной программе. В-общем шаманство какое-то. Может кто-то сталкивался с подобным? И от чего вообще может возникает этот Data Abort, если я не включаю кеш данных (кстати, пробовал включать, ничего не изменилось), и не использую MMU ? И вдогонку: а как MMU включить? Хочу кеш данных использовать.

Вот нашел недоработку в загрузчике, связанную с ограничениями ПДП. В связи с тем, что контроллеру ПДП нельзя указывать длину пакетов более 65535 байт, при более длинных прошивках нужно грузить частями. Вот измененный кусочек : [/code] { unsigned int tmpLoadAddr = hOSImage.LoadAddr; unsigned int tmpLoadBytes = hOSImage.LoadBytes; unsigned int tmpFlashAdr = 0x4020; //Это мой адрес начала расположения прошивки в DataFlash do { if (tmpLoadBytes > 0xffff){ AT91F_DataFlashArrayRead(&DataFlash,tmpFlashAdr,(unsigned char *)tmpLoadAddr, 0xffff ); tmpFlashAdr = tmpFlashAdr + 0xffff; tmpLoadAddr = tmpLoadAddr + 0xffff; tmpLoadBytes = tmpLoadBytes - 0xffff; } else{ AT91F_DataFlashArrayRead(&DataFlash,tmpFlashAdr,(unsigned char *)tmpLoadAddr, tmpLoadBytes ); tmpLoadBytes = 0; } AT91F_DataFlashWaitReady(DataFlash.pDataFlashDesc,AT91C_DATAFLASH_TIMEOUT); }while (tmpLoadBytes != 0); } Как понимаете, вылазит только в случае загрузки длинных программ. Актуально для таких как я, которые грузят напрямую код, а не вторичный загрузчик. Вот сегодня подключил пару bmp-шек к микроГуе и сразу ощутил эту границу :)

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

Не могу сообразить, как мне делать бинарник, который будет загружаться с помощью первичного загрузчика. Неужели ручками? Пока что я вижу, что мне придется сделать: 1. Сказать линкеру сделать сырой бинарник. В результате получаю файл размером порядка полгигабайта, так как сам проект находится в SDRAM (с адреса 0x20000000). 2. Отрезать от этого файла все, что ниже 0x20000000. 3. Дописать размер этого файла, ну и еще можно адрес расположения и контрольную сумму(которую еще нужно посчитать), в начало файла. В результате получаю искомый бинарник, который уже можно записывать в DataFlash. И что, эти все действия нужно выполнять самописной утилиткой (которая, правда, несложна)? Может, это уже где-нибудь в IAR уже встроено? Или где лежит уже такая утилитка, готовая?

О! Я как раз вчера вернулся к этому вопросу. Сегодня таки хочу добить. Или допинать. :) Спасибочки! :) Кстати, что-то на фоне юкоса не хотят встроенные сервисы работать как нужно (наверное проблема в прерываниях, не успел еще разобраться). Да и не понравилась еррата про снятие CS, если не успею данные подсунуть. Хотя как это ПДП может не успеть- отдельный вопрос, это очень тормозную память наверное нужно (Меня интересует доступ не только для загрузки, но и потом тоже). Опечатки возможны у всех. Вот можно ли подкорректировать название темы, я не уверен. Понятно, что Администрация все может. :)

Спасибо! Ясно. Я думал, что есть какой-то один, уже описанный в куче аппнотов путь, а получается, что каждый своей дорогой идет к результату. Так и сделаю.

Вот я и дополз до следующей стадии. Сначала о том, как я понимаю процесс загрузки из внешней флешки (код исполняется из внешней SDRAM), то есть как себя ведет камень после reset: 1. Находит в DataFlash по CS0 микросхему, определяет, что в ней валидная прошивка (валидный вектор 0x14). 2. Грузит эту прошивку во внутреннее SRAM. То есть данные с нулевого адреса DataFlash попадают в нулевой адрес intRAM, и так далее, столько байт, сколько указано в векторе 0x14. Это еще не основная программа, а только загрузчик (длиной до 12 килобайт) 3. Производится remap, в результате которого intSRAM отображается на адреса с 0x00000000. 4. начинается исполнение кода загрузчика (с адреса 0x00000000) До этого момента мне все понятно. А вот дальше собственно суть. Действия загрузчика: 1. Проинициализировать периферию (для работы SDRAM) 2. Загрузить прошивку из DataFlash в SDRAM 3. передать управление основной программе, загруженной в SDRAM. Вот по шагам 2 и 3 у меня и вопросы. 1.В каком формате сохранять код в DataFlash, чтобы потом его легко можно было оттуда достать и распределить загрузчиком по указанным адресам? Ведь изначально все, что известно загрузчику- это то, что код расположен в DataFlash с адреса, скажем, 0x010000 ? Или достаточно иметь сырой бинарник? 2. Как вообще все это сделать (загрузку), чтобы потом сам бутлодер не занимал место в дефицитной intSRAM ? 3. Как это все отлаживать? У меня должен быть отдельный проект загрузчика, и отдельный проект загружаемого им приложения? Или можно как-то слинковать вместе? 4. Может, кто-нибудь поделится проектиком, где используется подобная загрузка? 5. И вообще, не изобретаю ли я велосипед? u-boot может мне помочь? Только избыточен он, все что мне нужно- это при включении загрузить прогу и передать ей управление. Что бы почитать еще на эту тему ? Вообще-то конечная цель- загрузить мой тестовый проектик юкоса из флешины. Сейчас работает в SDRAM, гружусь через J-Link.

Я начинающий АРМовод, поэтому просто боюсь давать непроверенные временем советы, вдруг у меня только случайно все работает. :) Да и почту часто смотреть не получается, поэтому торможу иногда на сутки. При отладке настраиваете железо макросом, в нем же делается ремап. После ремапа SRAM находится с адреса 0x000000. Тут уже Ken@t написал, что делать. Еще можете посмотреть http://electronix.ru/forum/index.php?showtopic=20153

Стандартный стартап - я тут ни при чём. Если бы это были мои инициализации - тогда я сразу бы догадался в чём дело. Среда MULTI на самом деле содержит очень серьёзный компилятор, со множеством расширений, включая проверку ошибок времени выполнения, RTTI (C++) и прочее - всё то, что уже давно поддерживают компиляторы на х86. Видимо этим и вызвано такое раздувание. Странно что он не выбрасывает всё это из кода - в опциях я отказывался от всевозможных наворотов. В общем тут надо ещё будет разбираться. Я это к чему удивился: Существуют варианты, когда просто необходимо, чтобы программа помещалась в внутренний SRAM. Например, если грузишься из SPI DataFlash, твоя программка сначала должна загрузиться в SRAM, проиницииализировать хотя бы контроллер SDRAM, и только после этого можно что-то заливать в SDRAM. Если же у тебя даже этот бутлодер из-за стартапа не помещается в внутреннюю RAM, то получается, что загрузится невозможно. Но думаю, что этот стартап какими-нибудь прагмами все-таки должен усекаться при желании. Иначе ну ее к монахам из ембидеда, эту серьезную среду!

Нифига себе! И как с этим работать? Это стандартный стартап или уже твои инициализации?

Я, честно говоря, только про IAR могу что-то сказать, да и то только про работу в SRAM и SDRAM. У меня J-Link 5. Куда ты грузишь? Как-то странно, программа работает, а код не видно. Если посмотреть сеггеровской утилиткой (J-Mem), что видно?

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

Спасибо, вроде стало проясняться. Во всех виденных мной стартапах написано что-то вроде: org 0x00 __program_start ldr pc,[pc,#24] ; Absolute jump can reach 4 GByte ; b ?cstartup ; Relative branch allows remap, limited to 32 MByte ; Vectors can be enabled by removing the comments below or by ; using #pragma vector from C code. org 0x04 ; ldr pc,[pc,#24] ; Branch to undef_handler org 0x08 ; ldr pc,[pc,#24] ; Branch to swi_handler org 0x0c ; ldr pc,[pc,#24] ; Branch to prefetch_handler org 0x10 ; ldr pc,[pc,#24] ; Branch to data_handler org 0x18 ; ldr pc,[pc,#24] ; Branch to irq_handler org 0x1c ; ldr pc,[pc,#24] ; Branch to fiq_handler Я вставил нужный код по 0x14, но эффекта не дало. Может быть, у вас есть пример такого стартапа, предназначенного для загрузки из флеша? Я еще подумал, что может быть а просто-напросто неправильно произвожу загрузку в мою AT45D642. Завтра попробую Flashloader пошагово посмотреть, может и не там я ищу. А скорее всего, у меня несколько ошибок в разных местах. Прочешу все сначала.