jcxz

Во-первых: очереди возможно и не нужны. Если доступ к службе делать с блокировкой (задачи), до достаточно для каждой задачи иметь флаг и задаче ждать на этом флаге снятия его ISR-ом. ISR знает все флаги. Во-вторых: очереди легко строятся без всяких критических секций, если писатель (в очередь) только один (задача или ISR) и читатель - только один. Так даже можно очереди синхронизации между ядрами CPU строить, где невозможно сделать критическую секцию другому ядру. Да, у ТС естественно детский, АВР-ский подход. Думаю он ещё не скоро вырастет из детских штанишек ;)

Возможно у меня были какие-то проблемы с этим, возможно теневые наборы не грузились из физических PaRAM. Не помню уж. Да и зачем их использовать если целый вагон теневых?

Ну да, насколько помню - инфа о след. блоках может грузиться только из памяти (теневых каналов), а из физических - не может.

Если учесть, что как пишет ТС, период запрета много короче периода прерываний, и думать что и как делаешь, то не будут теряться. Но правильней конечно пересмотреть структуру программы, чтобы обмен по SPI не вызывался изнутри обработчика прерывания и снаружи. Сделать нормальный менеджер службы SPI и API доступа к нему.

У меня и так два .icf. Но как сказать, что секцию ".text" из одного файла компоновать в одну область памяти, а ".text" из другого - в другую? Вы знаете как? В CCS это сделать можно. В IAR не знаю как. Это было-бы идеальным решением - вообще не трогать исходник.

Её станет меньше, но она останется ;) Очень неудобно перед каждой функцией и после каждой переменной писать имя секции. Особенно когда их в файле - десятки. И постоянно забываешь это сделать. О! Это хороший совет! спасибо! У меня кстати как раз и определено несколько вариантов сборки (FLASH_DEBUG, RAM_DEBUG, FLASH_RELEASE, RAM_RELEASE), и нужный мне дефайн (определяющий в какие секции памяти какие выходные секции компоновать) он и указывается в Extra options. При выборе вариантов с RAM_.., он как раз компоновал readonly-секции в ОЗУ (для скорости отладки). Но про --section OldName=NewName не знал. Значит впишу его туда.

Не совсем точно. Первые 32 - это физические каналы. Т.е. - собственно сами каналы. И насколько я помню (хотя может ошибаюсь?) Вы не можете их использовать для хранения данных о следующих блоках пересылки. Следующие блоки всегда хранятся в теневых каналах. Теневые каналы - это собственно просто регион памяти (массив ParamSET), который может использовать EDMA3 для подгрузки данных о новых блоках передачи. Когда в физ. канале исчерпывается блок и в нём есть ссылка на один их теневых каналов, то данные о блоке загружаются из этого теневого канала в физический и начинают там выполняться. И так далее по цепочке блоков. В физическом канале счётчики декрементируются, адреса изменяются, а в теневом - нет.

См. SysTick Control and Status Register [0xE000E010] бит 1.

Правильно сообщили :)

Ну мне изначально и нужно было чтобы, если некий define определён, то устанавливались нестандартные секции для CODE/DATA, если не определён - дефолтные секции. Сейчас это решено через использование по всему файлу #pragma location = TEXT_SECTION перед каждой функцией (и соответствующей своей строки для переменных). Ну а значение TEXT_SECTION задаётся в зависимости от определения или неопределения некоего define (".text" или ".textN"). Но хотелось бы без этой грязи по всему тексту, а в одном месте - в начале файла. В CCS такая возможность имеется: #pragma SET_CODE_SECTION ("section name") #pragma SET_DATA_SECTION ("section name") Может в IAR тоже есть?

Как я понимаю - наличие NOP не гарантирует, что последующая запись в периферийное адресное пространство не выполниться ранее чем та запись, которая перед NOP. Это касается тех случаев, когда периферия сидит на разных периферийных шинах да ещё с разным частотами тактирования. Могу предположить, что RCC сидит на одной APB, а DMA - на другой (хотя в даташит мне заглядывать лень :). Так что DSB - нужно, имхо.

Мне хватило обычных DMA-каналов на все нужды и зачем нужны QDMA я так и не понял (и не особо разбирался ;) Первые 32 - физические каналы. Остальные - теневые каналы. Т.е. - если вам нужна транзакция связным списком (или пинг-понг и т.п.), то физический канал программируете на передачу первой порции данных, делаете в нём ссылку на первый теневой канал, в котором прописаны параметры для след. порции данных. Далее - в первом теневом можете сделать ссылку на второй теневой, в котором параметры для 3-го блока. И так далее. Или в одном из теневых каналов можно зациклить передачу на первый теневой канал. Теневой канал - это набор значений регистров конфигурации DMA канала, которые грузятся в ссылающийся на него физический канал, когда в физическом заканчивается очередной блок передачи. Примерно так. PS: Да, если что - моя информация из опыта с OMAP L137. Но думаю подходит.

Очень похожую задачу (тоже по приходу импульса надо было считать пачку байт с ПЛИС) я решал. Только на LPC176x. И решил как раз так как описал в первом сообщении. Всё прекрасно работало и это при том, что проц в это время занимался другими (более тяжёлыми) делами. Я уже прекратил. Кнопка - "поместить в игнор" очень полезна :) Как я писал - дело не в том насколько это загрузит CPU, а в том что требование реакции на прерывание в 1-2 мкс, сильно ужесточит требования ко всему остальному коду (где могут быть критические секции с запретом прерывания или другие высокоприоритетные прерывания. Я для себя всегда беру за правило: стараться строить работу системы прерываний так, чтобы она была устойчива к запретам прерывания до неск. десятков мкс (по возможности конечно). К тому-же ТС у нас - из мира DSP, тогда он тем более должен понимать чем вредны высокочастотные прерывания (на DSP с несколькими десятками регистров и конвееризацией вычислений).

хм... И куда это вставить? В .icf? Если компилить из батника то ясно, но в проекте IAR? Надо же между компилёром и линкером. Да - и нужно всё-таки в исходниках, так как переопределять или нет секцию должно управляться в зависимости от значения некоторого #define (#ifdef..).

Подскажите пожалуйста: можно-ли в IAR переопределить дефолтные секции кода/данных для конкретного файла? Типа #pragma location = ".some_section", но только не для конкретной функции/переменной, а для всего файла. А то что-то в мануале к компилятору не найду.... :(

Да, наверное так и придётся сделать если припрёт. Не хочется возиться с этим, думал есть готовое решение... Да и производство вроде не массовое, а мелкое будет. Овчинка выделки не стоит. Главное чтобы без конфига не уходило случайно. А то при таком изготовлении мелкими партиями от случая к случаю, когда нет отработанногоо техпроцесса, это как раз очень вероятно. Да знаю я его. Штатный загрузчик (по рабочему протоколу) писал тоже я. Он разбирает .ais и грузит его через рабочее ПО. А зачем к обоим коннектиться? Можно ведь только к DSP. Ведь ПО рассчитано что первоначально стартует только DSP. А весь ARM-код расположен в памяти, видимой DSP-ядру. Можно загрузить в ОЗУ и далее снять reset с DSP-ядра. PS: Изначально, когда проект только начинался, я планировал что начальная загрузка ПО будет производиться по UART (и на плате есть джампер включающий загрузку с UART). Но потом мне так и не удалось добиться загрузки ПО UART. Хотя вроде формировал .ais по всем правилам (знаю что для загрузки через UART он должен быть другим чем через SPI (штатный режим)). Не грузились даже готовые примеры. Т.е. - насколько я помню, загрузка начиналась, доходила до какого-то блока и там всё застревало. Причину мне найти не удалось, поэтому забил.

И что? USB тоже использует внутреннюю шину (да и прочая периферия), это тоже CPU? Функционирование DMA (после инициализации) и выполнение команд CPU - совершенно разные и асинхронные вещи. То что они разделяют общий ресурс к делу не относится. Откройте reference manual или user manual или как там и найдите что такое Core Cortex-M3/M4 и что такое DMA/GPDMA/uDMA или как там в конкретном МК. Везде одинаково. В задаче ТС этот этап делается один раз - при старте ПО (если делать как хочет ТС). Так что - тоже к делу не относится. Пересылка малыми блоками в любом случае неэффективна. Дёрганье в ISR и такая пересылка CPU - ещё менее эффективны чем заранее настроенный DMA в режимах flip-flop, связные списки и т.п. Как ни странно - вход в ISR тоже выполняется с задержкой + ещё и шину грузит. Это можно сказать о любом методе пересылки любым bus master-ом. Это общее свойство. Вы сейчас говорите о себе? Где это я обижался? У Вас ни в одном сообщении ни капли полезной информации. Вам по делу нечего сказать. И не пытался я Вас оскорбить, просто написал, что несёте полную чушь.

Это хорошо, но это мне известно, есть у меня такой скрипт и шил я им прекрасно. Нужно не это. Нужна именно загрузка в ОЗУ CPU и старт там ПО. А не зашивка его в SPI-флешку. После такого старта ПО, оператор должен далее штатным образом обновить ПО через рабочий интерфейс (ПО примет себя самого и запишет в SPI-флешь). Так нужно, потому что, при штатном обновлении, встроенное ПО принимает от внешнего прошивающего ПО кроме прошивки ещё и некоторую конфигурационную инфу, которую добавляет к записываемому образу. Можно конечно записать этим скриптом встроенное ПО, потом запустить его и обновить штатно. Но боюсь, что на производстве могут забывать вторую стадию (раз ПО уже заработало) и изделие будет уходить без конфигурационной инфы. А это надо исключить.

Вот это открытие так открытие! Кто-ж знал-то??? Я-то по скудости ума всегда думал, что DMA - это такой периферийный узел, главное назначение которого - разгрузить CPU от тупого перетаскивания байтов по шине. А значит - это совершенно разные узлы. Ан нет, он оказывается тоже какая-то часть CPU... левая задняя нога наверное.. Маленькая процедурка с сохранением контекста на входе и выходе в ISR, десятком команд, с выборкой их из памяти (заполнение как минимум 2-3 prefetch-буферов по 128/256бит каждый), +несколько обращений по шине для чтения/записи данных, и опять заполнение prefetch-буферов командами после возврата из ISR. И Вы утверждаете, что это быстрее чем заранее настроенному каналу DMA активироваться и сделать 2-3 пересылки по шине для записи управляющих регистров таймера или другого канала DMA для запуска пакета из 16 операций обмена с SPI??? Ню-ню.... Это уже разработчику решать - что ему важнее: потратить несколько DMA-каналов или по всему коду программы вводить жёсткие ограничения на длительность запретов прерываний, понижать приоритеты других ISR (в которых тоже время реакции может оказаться критичным). Если речь идёт о периоде событий порядка 10 мкс (и это только период стартовых импульсов, а время реакции на них значит ещё в разы меньше), то требования к времени реакции на прерывание (если делать по прерыванию) весьма жёсткие. При таких требованиях имхо надо всё делать максимально без-процессорно, всё свалив на DMA. Для того он и нужен. А более медленную периферию можно и программно обслужить, если каналов DMA не хватит. PS: Кстати - ТС указал период стартовых событий (10мкс), но забыл указать более важное - максимальное время реакции на стартовый импульс. Оно будет зависеть ещё от частоты SPI и необходимого запаса времени между последней SPI-пересылкой и новым импульсом.

Так как в STM32 в каналах SPI нет буферизации, то одним DMA здесь не обойтись. Можно сделать примерно так: Таймер1 получает внешний сигнал, пинает DMA-канал1, который конфигурит другой таймер2, который в свою очередь начинает выдавать события (16 штук) на пересылки DMA-канал2->SPI, последним блоком (в STM32 есть DMA-передачи свЯзным списком типа L137/L138 или NXP LPC17xx?) DMA-канал2 конфигурит таймер2 (выключает его). Всю эту кухню можно сделать работающей в пинг-понг (без перепрограммирования CPU на каждый цикл). Если в DMA STM32 нет возможности передач связным списком, то функцию выключения таймера2 можно также возложить на таймер1+DMA-канал1 (в таймере1 делаем два события по совпадению: одно - сразу после старта, второе - через определённый промежуток времени, достаточный для генерации таймером2 16 событий). Если-бы в SPI STM32 было FIFO на 16*8бит, то можно было-бы обойтись одним DMA и таймером - сразу загонять в FIFO 16*8бит, а уже он, с установленной частотой выдавал бы их наружу. Опять-же - на LPC17xx такое возможно (там есть требуемый объём FIFO) и на L137/L138 думаю тоже.

Имеется-ли возможность загрузки и запуска .out-файлов в ОЗУ CPU посредством эмулятора класса SAU510 без использования CCS? Желательно с минимальным кол-вом нажатий или вообще из командной строки. И чтобы грузить и стартовать разные .out-файлы в разные устройства в JTAG-цепочке (каждый файл для своего устройства). Нужно для первоначальной прошивки устройств на двухядерных CPU (OMAP L137) в условиях производства через SAU510 ISO PLUS (или SAU510 просто).

Да-да... молодёжь уже не та......

Если даже источник и приёмник намертво закреплены на каких-то конструкциях, то есть ещё температурный дрейф из-за температурной деформации несущих конструкций. Так что это тоже надо учитывать.

Думаю, что в подавляющем большинстве хостов не заморачиваются с установкой каких-то дополнительных ключей, а питают с одного ключа.

Солнце с посторонними засветками убирается расположением приёмника на дне приёмной трубы (чёрной трубы). И через 1.5км даже у лазерного луча будет уже не точка, а некоторое пятно на приёмной плоскости (рассеяние даже у лазера не нулевое). И при анализе надо будет определять границы и центр данного пятна.