Jump to content

    

Ya_Mike

Участник
  • Content Count

    21
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Ya_Mike

  • Rank
    Участник
  • Birthday 01/26/1986

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    Ярославль
  1. Правка файла борды

    Цитата(TigerSHARC @ Mar 27 2014, 08:05) раз выводится "done, booting the kernel." - значит decompress_kernel() честно отрабатывает... а дальше вот дело не идёт... А опцию "early printk" и "kernel low level debugging functions" пробовали включать? Возможно, с этими опциями вы получите ответ, почему не загружается плата. Kernel hacking -> Early printk Kernel hacking -> Kernel debugging -> Kernel low-level debugging См. FAQ от TI.
  2. свой драйвер АЦП

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

    Как-то пользовался драйвером АЦП для at91-adc, для его 4-х каналов, для arm926-го (at91sam9m10g45ek). В этом драйвере есть и регистрация файлов в sysfs с чтением и записью для созданного misc-устройства, реализованы системные вызовы open/read/write/poll/close, используется dma. Выложил патч, добавляющий этот драйвер в ядро, на pastebin - может быть пригодится. Да, драйвер проверенный и рабочий. А так procfs - да, проще в реализации, можно работать с ней откуда угодно, не тянет за собой ничего (например). Именно поэтому procfs в любой рабочей системе уже стала похожа на винегрет "из всего, что только в системе есть". Драйверы для spi-ных АЦП тоже имеются (например, для AD7887). Может быть даже готовый есть для нужного АЦП.
  4. Цитата(milky1 @ Sep 14 2012, 10:28) Здравствуйте Стала необходимость обмениваться данными между ARM и DSP ядром. Хочу обработать в ARM ядре данные и отправлять в DSP ядро для дальнейшей обработки. Установил CCS 5.2 и пытаюсь что то сделать. Можно ли в CCS 5.2 работать одновременно с ARM и DSP ядром???Литературы на ti.com не нашел, либо "проскочил". Так ли уж нужна IDE Code Composer? Если нет жесткой привязки к ней, то можно воспользоваться EZSDK от Texas Instruments. Нужна только машина с линуксом или, лучше, образ виртуальной машины. В SDK есть codec engine с большим количеством примеров. Один из примеров - scale. В нём производится масштабирование вектора данных на DSP и передача результата обратно на АРМ. Работает всё практически "из коробки" - требуется лишь несколько шагов по прилагаемым инструкциям (настройка путей, кода вообще не придётся писать ни одной строки). Этот же SDK позволяет собрать образ всей ОС для платформы, загрузчики. Всё автоматизировано. Автоматизирована даже настройка nfs и tftp на хосте, после чего можно очень и очень удобно отлаживать ПО на платформе. В целом, при использовании этого SDK, старт работы на 814* и 816* становится быстрым и удобным. Цитата(jcxz @ Sep 14 2012, 13:30) Как же не надо? Любой OMAP - это два ядра, между которыми надо осуществлять обмен данными. Даже больше: на 8168 - шесть ядер (1 ARM + 1 DSP + 3 Cortex M3 + 1 графика). :-)
  5. Всем добрый день, С какой максимальной скоростью у вас получалось передавать данные по SPI на ARM\с ARM с данным ядром (имею ввиду arm926ej-s)? Интресна именно практическая скорость, при использвании Linux и передачи небольших порций данных от единиц до десятков КБ. Ну или просто укажите, какими порциями получалось передавать у вас. А интересно потому, что в даташите написано: • Very fast transfers supported – Transfers with baud rates up to MCK В то же время, в том же даташите чуть позже написано, что в нормальном режиме: • MDIV is ‘11’, MCK is 133 MHz Т.е. даже в нормальном режиме скорость может быть довольно высокой. Самому пока нет возможности попробовать.
  6. Энергосбережение ARM Cortex-A9 (dual core)

    Цитата(vitan @ Apr 20 2012, 13:09) Это не даташит. Я сам подробно не читал это, но, по-идее, в даташитах всегда самые точные электрические параметры. Ну и плюс, думал, может, поделитесь, если что... А что за модуль? Самодельный? Если покупной, то там же обычно подробные мануалы и жрайвера в комплекте... Да, если строго, то это TRM. Так-то там вроде есть всё. Но, проблема в том, что есть ещё линукс на плате, который надо должным образом настроить или дополнить нужным функционалом, чтобы оптимизировать потребление. По оптимизации энергопотребления в линуксе ничего от производителя не нашёл пока. Да и опыта немного у меня в направлении энергосбережения. Вот, только свет умею выключать за собой.
  7. Энергосбережение ARM Cortex-A9 (dual core)

    Цитата(vitan @ Apr 20 2012, 00:25) Процессор - OMAP4? У Вас есть даташит? Да, 4460. Даташит-то(~23М) есть, ознакомляюсь. Чувствую только, что копаться в нём можно долго (5617 страниц). Поэтому и пост сделан, что может кто-то сможет направить туда, за что в первую очередь можно взяться при работе над энергосбережением.
  8. Всем доброго времени суток! Есть задача о максимально возможном уменьшении энергопотребления устройства... Очень нужны подсказки и толчки в нужных направлениях! Про мат часть: имеется модуль с симметричным двухядерным ARM Cortex-A9 в окружении переферии: wifi, большой набор i2c+spi устройств +аудио +графика и с Ubuntu 3.1 на борту. Есть два сигнала, заведенные на GPIO ноги, по наличию выского уровня хотя бы на одном их них устройство должно перейти в активный режим. При этом переход должен быть достаточно быстрым: загрузка устройства происходит в течение 3-5 секунд, это много. Желательно уложиться в гораздо меньший интервал - до 1 с. Если после перехода в активный режим в течение времени t (минуты) пользователь не проявляет к устройству интереса, и нет ни одного из этих двух сигналов, то устройство должно максимально уменьшить свой энерго-аппетит. Как при таком раскладе уменьшать потребление? Есть ли какие-то общепринятые подходы? Можно ли как-то перевести в энергосберегающий режим всё, кроме графического ядра PowerVR? Буду рад любым высказанным идеям, рассуждениям по теме, подсказкам, ссылкам и т.п.
  9. Цитата(kovigor @ Apr 10 2012, 16:48) Дополнение от 10.04.2012. Попробовал прочитать байт из Serial EEPROM, запаянной на плате (ее адрес: 0x50). Вот этот вызов завершается с ошибкой: (ioctl(file, I2C_SLAVE, addr). И при этом осциллограф показывает полное отсутствие на шине всякой активности. Если взять любой другой адрес, например, 0x10, то при выполнении указанного выше "ioctl(file, I2C_SLAVE, addr)" этот адрес действительно наблюдается на шине, но на обращение по нему, конечно же, никто не отвечает. Такое впечатление, что ядро блокирует доступ по адресу 0x50. Завтра в отладочных целях попробую припаять на плату еще одну ИС памяти, но уже с другим адресом, и обратиться к ней ... Дополнение от 11.04.2012. Подпаял на плату еще одну ИС Serial EEPROM, о которой Linux не знал (ее адрес: 0x51), и попробовал прочитать из нее байты. На этот раз все отлично читается. Теперь нужно выяснить, как обратиться к штатной ИС, запаянной на плате, если это вообще возможно. Кстати, на плате есть и другие ИС, например, кодек TLV320 c интерфейсом I2C. К ней Linux тоже не дает обратиться, картина в точности соответствует наблюдаемой для Serial EEPROM ... Попробуйте i2ctools - очень полезный инструментарий при отладке и работе с i2c, да и в качестве примера юзер-спейсного кода для работы с i2c подойдёт.
  10. Интерфейс между ARM и FPGA

    faa, доброго времени суток вам, Цитата(faa @ Apr 1 2012, 14:20) Драйвер для программирования есть - лежит на ftp. В драйвере, что на фтп, обнаружил одну маленькую проблемку на 150 строке: while (fpga_done_read == 0) {..} - этот цикл не выполнится ни разу, а пользователь может не узнать, что возникла проблема. Вообще большое спасибо за ваш пост, очень помог!
  11. Интерфейс между ARM и FPGA

    faa, спасибо за отлик! Цитата(faa @ Mar 30 2012, 17:18) ИМХО, вешать FPGA на EBI и все делать через этот интерфейс. Для программирования написать драйверочек - там нужны будут еще -две-три (или четыре) ноги gpio с ARM (для PROG, INIT, DONE и т.п.). После программирования можно через /dev/mem обмениваться (или через драйвер). Ну и при желании можно прерывания попользовать. Т.е. я правильно понимаю, что работа через EBI - это, по сути, обмен через определенный участок памяти? Наверное, лучше будет через драйвер все делать, так как прерывания будут нужны наверняка. А ног gpio заведено с запасом, поэтому хватит на всё. Цитата(faa @ Mar 30 2012, 17:18) Примеры есть в инете. Если не найдете - помогу ссылками. Нашёл на kernel.org пример драйвера carma-fpga. Пока что его изучаю, но если есть на примете более удачные (покороче) примеры - буду рад. Цитата(litv @ Mar 30 2012, 17:23) А как же AXI - плис в арм ? ( http://www.xilinx.com/support/documentatio...rence_guide.pdf ) В arm926ej-s есть поддержка только второй версии AMBA (AHB), а AXI появился в третьей версии. Не могли бы вы сказать, в чем преимущества использования AXI по сравнению с использованием EBI?
  12. Всем доброго времени суток, Возник вопрос в выборе интерфеса для передачи данных от ПЛИС(Spartan6) к АРМу(arm926ej-s). На арме - линукс с ядром 3.х.х. Плис будет постоянно обмениваться данными с армом небольшими порциями (пока не определился, какого размера их сделать), поток - оринтировочно 128 кБит/с туда и столько же обратно (*3). При этом АРМ должен будет при старте загрузить прошивку в неё(*2), а при работе - считывать некоторые статистические данные помимо этого основного потока (*1). Итого, получается три "потока" данных. Есть идея выделить под: *3 - по EBI интерфейсу, *2 + *1 - по SPI, (либо всё-таки по отдельным интерфейсам передавать?) В наличии ещё gpio есть, но думал их использовать для сигналлинга в случае SPI (когда slave что-то хочет сказать master-у). Так как такая задача возникла впервые, то есть сомнения в правильности выбора интерфейсов. Ко всему, хочется как можно меньше нагружать систему. Буду благодарен, если кто-нибудь сможет посоветовать, где при таком выборе интерфейсов разложены грабли и какие проблемы могут возникнуть.
  13. компиляция программы для ARM

    Цитата(Алексей Е @ Nov 17 2011, 14:40) Всем доброго дня! Купил плату SK-AT91SAM9260-SIM508 с установленным встроенным линуксом, теперь задача запустить на нем свою программу "hello world". В линуксе новичок, поэтому застопорился уже на этапе компиляции. Набираю команду (как написано тут): $ arm-linux-gcc -o hello hello.c и получаю ошибку: bash: arm-linux-gcc: command not found как это исправить? чья это команда arm-linux-gcc? может какой пакет нужно установить? (повторюсь, в линуксе я новичок) Нет кросс-компилятора для 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. Да, скорей всего, при "более сложном пути" потребуется познакомиться с командами sudo, mkdir, cp, tar. Справка по ним - ya, google, команда man.
  14. Свое приложение для Linux SoC

    Цитата(elusive @ Nov 17 2011, 15:23) Есть отладочная плата с процессором на ARM9 (проц от Texas Instruments, TMS320DM36x). В плату вставляется SD-карта с линуксом и лоадером и на плате запускаются demo-программы. Вопрос: в какую линуксовую папку на SD-карте записывать какой файл из скомпилированного проекта, чтобы запустить свое приложение на плате? Я предполагаю, что *.hex, но не уверен совершенно. Для компиляции исп. GCC, eclipse. Скидывать нужно бинарный файл, имя которого можно узнать в Makefile'e проекта или в где-то в настройках eclipse'a. Может обозначаться именем TARGET или как-то так, или можно посмотреть где-то рядом со словом all - по-разному бывает. Если проекты в эклипсе - то вам будет проще в настройках проекта найти имя конечного бинарного файла. Может быть и *.hex. При отсутствии зависимостей от каких-либо библиотек - только один файл и нужен будет. Обычно на SD карте должен быть раздел с корневой файловой системой, в ней должна быть папка вида /home/SOME_USER. Пользователь может быть root или другой. Можно прямо туда или, если нравится порядок, организовать где-то там спец. папку. Если отладочная плата настроена, то для запуска потребуется только консольный доступ. После загрузки окажатесь в домашнем каталоге SOME_USER, куда скинули программу. Там и запускаете.
  15. Цитата(dmkr00 @ Feb 5 2010, 14:08) ... Если кого то интересует, что из этого вышло, пишите мне через два месяца. ... Цитата(darlok @ Nov 13 2011, 23:34) Таки меня очень даже интерисует что из этого вышло. Расскажите, а Присоединяюсь. Если возможно, озвучьте детали - какой подход-таки выбрали, на каком расстоянии работает, достоверность определения, на чём было реализовано. Я не китаец, копировать не собираюсь, просто интересен сам подход и результат.