Ya_Mike

А опцию "early printk" и "kernel low level debugging functions" пробовали включать? Возможно, с этими опциями вы получите ответ, почему не загружается плата. Kernel hacking -> Early printk Kernel hacking -> Kernel debugging -> Kernel low-level debugging См. FAQ от TI.

Открытие-закрытие можно делать только один раз - расходы на них сокращаются в ноль по сравнению с временем работы. В приведенном по ссылке драйвере - имеется двойная буферизация с поочередным дма-заполнением каждого, а скорость считывания такова, что системный вызов будет "срабатывать" раз в несколько десятков мс. Накладные расходы - нивелируются. Ко всему - с mmap, наверное, будет не очень удобно реализовывать блокирующее чтение, которое есть в этом драйвере. К тому же - при больших частотах дискретизации возможны потери данных, если читать малыми порциями через опрос регистров. Выигрыш mmap кажется сомнительным. В добавок, в драйвер можно удобно вставить предобработку данных с АЦП без пересборки приложения (например, скользящее среднее, медиана). Может я не совсем уловил высказанную идею и её преимущества. Можно описать подробней, какая связка mmap-а, ring-buffer-a и readv имеется ввиду? В целом, конечно, приличней работать через какое-нибудь символьное устройство в devfs, но не уверен, что по скорости работа через него будет отличаться, например, от sysfs (те же copy_{to,from}_user(..)).

Как-то пользовался драйвером АЦП для at91-adc, для его 4-х каналов, для arm926-го (at91sam9m10g45ek). В этом драйвере есть и регистрация файлов в sysfs с чтением и записью для созданного misc-устройства, реализованы системные вызовы open/read/write/poll/close, используется dma. Выложил патч, добавляющий этот драйвер в ядро, на pastebin - может быть пригодится. Да, драйвер проверенный и рабочий. А так procfs - да, проще в реализации, можно работать с ней откуда угодно, не тянет за собой ничего (например). Именно поэтому procfs в любой рабочей системе уже стала похожа на винегрет "из всего, что только в системе есть". Драйверы для spi-ных АЦП тоже имеются (например, для AD7887). Может быть даже готовый есть для нужного АЦП.

Так ли уж нужна IDE Code Composer? Если нет жесткой привязки к ней, то можно воспользоваться EZSDK от Texas Instruments. Нужна только машина с линуксом или, лучше, образ виртуальной машины. В SDK есть codec engine с большим количеством примеров. Один из примеров - scale. В нём производится масштабирование вектора данных на DSP и передача результата обратно на АРМ. Работает всё практически "из коробки" - требуется лишь несколько шагов по прилагаемым инструкциям (настройка путей, кода вообще не придётся писать ни одной строки). Этот же SDK позволяет собрать образ всей ОС для платформы, загрузчики. Всё автоматизировано. Автоматизирована даже настройка nfs и tftp на хосте, после чего можно очень и очень удобно отлаживать ПО на платформе. В целом, при использовании этого SDK, старт работы на 814* и 816* становится быстрым и удобным. Даже больше: на 8168 - шесть ядер (1 ARM + 1 DSP + 3 Cortex M3 + 1 графика). :-)

Всем добрый день, С какой максимальной скоростью у вас получалось передавать данные по SPI на ARM\с ARM с данным ядром (имею ввиду arm926ej-s)? Интресна именно практическая скорость, при использвании Linux и передачи небольших порций данных от единиц до десятков КБ. Ну или просто укажите, какими порциями получалось передавать у вас. А интересно потому, что в даташите написано: • Very fast transfers supported – Transfers with baud rates up to MCK В то же время, в том же даташите чуть позже написано, что в нормальном режиме: • MDIV is ‘11’, MCK is 133 MHz Т.е. даже в нормальном режиме скорость может быть довольно высокой. Самому пока нет возможности попробовать. :crying:

Да, если строго, то это TRM. Так-то там вроде есть всё. Но, проблема в том, что есть ещё линукс на плате, который надо должным образом настроить или дополнить нужным функционалом, чтобы оптимизировать потребление. По оптимизации энергопотребления в линуксе ничего от производителя не нашёл пока. Да и опыта немного у меня в направлении энергосбережения. Вот, только свет умею выключать за собой. :laughing:

Да, 4460. Даташит-то(~23М) есть, ознакомляюсь. Чувствую только, что копаться в нём можно долго (5617 страниц). Поэтому и пост сделан, что может кто-то сможет направить туда, за что в первую очередь можно взяться при работе над энергосбережением.

Всем доброго времени суток! Есть задача о максимально возможном уменьшении энергопотребления устройства... Очень нужны подсказки и толчки в нужных направлениях! Про мат часть: имеется модуль с симметричным двухядерным ARM Cortex-A9 в окружении переферии: wifi, большой набор i2c+spi устройств +аудио +графика и с Ubuntu 3.1 на борту. Есть два сигнала, заведенные на GPIO ноги, по наличию выского уровня хотя бы на одном их них устройство должно перейти в активный режим. При этом переход должен быть достаточно быстрым: загрузка устройства происходит в течение 3-5 секунд, это много. Желательно уложиться в гораздо меньший интервал - до 1 с. Если после перехода в активный режим в течение времени t (минуты) пользователь не проявляет к устройству интереса, и нет ни одного из этих двух сигналов, то устройство должно максимально уменьшить свой энерго-аппетит. Как при таком раскладе уменьшать потребление? Есть ли какие-то общепринятые подходы? Можно ли как-то перевести в энергосберегающий режим всё, кроме графического ядра PowerVR? Буду рад любым высказанным идеям, рассуждениям по теме, подсказкам, ссылкам и т.п.

Попробуйте i2ctools - очень полезный инструментарий при отладке и работе с i2c, да и в качестве примера юзер-спейсного кода для работы с i2c подойдёт.

faa, доброго времени суток вам, В драйвере, что на фтп, обнаружил одну маленькую проблемку на 150 строке: while (fpga_done_read == 0) {..} - этот цикл не выполнится ни разу, а пользователь может не узнать, что возникла проблема. Вообще большое спасибо за ваш пост, очень помог!

faa, спасибо за отлик! Т.е. я правильно понимаю, что работа через EBI - это, по сути, обмен через определенный участок памяти? Наверное, лучше будет через драйвер все делать, так как прерывания будут нужны наверняка. А ног gpio заведено с запасом, поэтому хватит на всё. Нашёл на kernel.org пример драйвера carma-fpga. Пока что его изучаю, но если есть на примете более удачные (покороче) примеры - буду рад. В arm926ej-s есть поддержка только второй версии AMBA (AHB), а AXI появился в третьей версии. Не могли бы вы сказать, в чем преимущества использования AXI по сравнению с использованием EBI?

Всем доброго времени суток, Возник вопрос в выборе интерфеса для передачи данных от ПЛИС(Spartan6) к АРМу(arm926ej-s). На арме - линукс с ядром 3.х.х. Плис будет постоянно обмениваться данными с армом небольшими порциями (пока не определился, какого размера их сделать), поток - оринтировочно 128 кБит/с туда и столько же обратно (*3). При этом АРМ должен будет при старте загрузить прошивку в неё(*2), а при работе - считывать некоторые статистические данные помимо этого основного потока (*1). Итого, получается три "потока" данных. Есть идея выделить под: *3 - по EBI интерфейсу, *2 + *1 - по SPI, (либо всё-таки по отдельным интерфейсам передавать?) В наличии ещё gpio есть, но думал их использовать для сигналлинга в случае SPI (когда slave что-то хочет сказать master-у). Так как такая задача возникла впервые, то есть сомнения в правильности выбора интерфейсов. Ко всему, хочется как можно меньше нагружать систему. Буду благодарен, если кто-нибудь сможет посоветовать, где при таком выборе интерфейсов разложены грабли и какие проблемы могут возникнуть.

Нет кросс-компилятора для arm системе или в переменной среды PATH. Если его нет в системе - самый простой путь - поставить через package manager. Например, в убунту есть synaptic package manager, в котором можно набрать там в строке поиска arm-linux-gnueabi и поставить версию 4.6 плюс - базовый набор библиотек. Должно получиться. И использовать команду arm-linux-gnueabi-gcc-4.6 Посложнее, и, если нужен именно arm-linux-gcc, можно его скачать arm-linux-gcc с http://www.friendlyarm.net/dl.php?file=arm...x-gcc-4.4.3.tgz. Распаковать. Содержимое /opt/FriendlyARM/toolschain/4.4.3/ - положить в каталог /usr/local/arm (если нет - создать). Для того, чтобы прописать в переменную окружения - в конец .bashrc добавить export PATH=/usr/local/arm/bin:$PATH После этого в новой открытой консоли всё должно быть просто чудесно. Тулчейн в полном распоряжении. Добро пожаловать в мир embedded. :yeah: Да, скорей всего, при "более сложном пути" потребуется познакомиться с командами sudo, mkdir, cp, tar. Справка по ним - ya, google, команда man.

Скидывать нужно бинарный файл, имя которого можно узнать в Makefile'e проекта или в где-то в настройках eclipse'a. Может обозначаться именем TARGET или как-то так, или можно посмотреть где-то рядом со словом all - по-разному бывает. Если проекты в эклипсе - то вам будет проще в настройках проекта найти имя конечного бинарного файла. Может быть и *.hex. При отсутствии зависимостей от каких-либо библиотек - только один файл и нужен будет. Обычно на SD карте должен быть раздел с корневой файловой системой, в ней должна быть папка вида /home/SOME_USER. Пользователь может быть root или другой. Можно прямо туда или, если нравится порядок, организовать где-то там спец. папку. Если отладочная плата настроена, то для запуска потребуется только консольный доступ. После загрузки окажатесь в домашнем каталоге SOME_USER, куда скинули программу. Там и запускаете.

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