Перейти к содержанию
    

BratherLU

Свой
  • Постов

    103
  • Зарегистрирован

  • Посещение

Сообщения, опубликованные BratherLU


  1. Хотелось бы, как всегда, попроще, а лучше с готовыми формулами.

    http://www.dsplib.ru/content/allpasseq/allpasseq.html - про то-же самое, что и

    только на русском с готовыми формулами. Wave-filter это или не wave-filter мне пока не понятно... планировал разбираться как руки дойдут.

    +1 за matlab

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

    http://powerdsp.narod.ru/modem_v32.html

  3. Думаю Гилберт как раз подходит. Теперь вопрос, писать с нуля прогу или есть где посмотреть т.к. не верю что Гилберта никто не писал и нет примера в инете(Фурье допустим полно). Сам лично не смог найти. Или есть более простой способ нахождения смены фазы.

    Может уже смотрели в matlab функции:

    1) hilbert - реализует ПГ при помощи БПФ (можно посмотреть в исходниках hilbert.m где-то в недрах)

    2) angle - фаза комплексного числа

    3) unwrap - уберет разрывы фазы.

     

    Преобразование Гильберта можно реализовать при помощи КИХ-фильтра.

    В matlab есть инструмент FDATool - в пару кликов может дать коэффициенты соответствующего КИХ-фильтра.

    Это если не с чего начать.

  4. Оно так и сделано, только заведено на AHCLKX (выше схему выкладывал), но возникла проблемка с синхронизацией (описывается примерно с начала данной страницы), поэтому и ищу способ, как лучше отформатировать принимаемые данные.

    Прошу прощения схемы сразу не разглядел. Посмотрел на времянки Вашего ST-Bus - такой frame - тяжелый случай для - MCASP. С двойными клоками - еще одна засада - нужно попасть на нужный клок при старте автомата состояний - иначе имеем ошибку 1/2 бита - что вполне может приводить к срыву синхронизации и ошибкам при приеме данных. Возможный вариант - подождать нужного фронта фрейма и затем нужного франта клока и тогда запустить синхронизацию. Пока больше вариантов не вижу...

  5. Что-то читал про маску для определённых бит и padding, но пока не разобрался, подходит ли оно мне? Может быть есть возможность для McASP настроить приём бит через один?

    А может лучше завести битовую синхронизацию на АHCLKR потом поделить внутренним делителем MCASP и от этих клоков засинхронизировать прием. AHCLKR/H можно даже внутри проинвертировать - в MCASP есть все тоже самое что и в MCBSP (кроме g711)

  6. В Mcasp есть регистры RCLKCHK/XCLCHK - можно их использовать для диагнотики проблем с пропажей аппаратной синхронизации. Прием поднимется после восстановления синхронизации; передача скорее всего нет (не уверен на счет передачи) - может потребоваться перезапуск передатчика.

  7. О причинах не запуска передачи могу сказать что XDATA выставится сразу при отпускании автомата состояния сериалайзера - об этом в доке написано.

    Вероятно первый вариант не запустился т.к. не известно когда вы вызвали Send() может уже underrun возник.

    По прерыванию вы тут же влетели в обработчик все сработало штатным образом - я так думаю (с).

  8. С передатчиком проблема следующая

    - достаточно возникнуть Tx buffer Underrun событию и автомат состояний передатчика встает колом.

    Соответственно - лечение: не допускать underrun.

    Возможные варианты:

    1) Гарантированно успевать CPU писать данные в TX_BUFF(x) + включать AFIFO от mcasp

    2) Использовать - EDMA+AFIFO от mcasp

    3) Использовать PRUSS

     

    TX AFIFO - лучше использовать даже при работе через EDMA. т.к. при определенном уровне нагрузки на EDMA связка может зависнуть. При этом ни в одной периферии ошибок не видно. Под нагрузкой имею ввиду например работу с MMCSD на том же контроллере.

     

    На форуме TI есть пара тем по данному вопросу.

    Как запустить AFIFO написано документации на MCASP

     

  9. Ещё не понимаю, каким образом связаны регистры RSTAT, XSTAT и множество RBUF, XBUF? Если у меня несколько каналов используются, то что отражает RSTAT.RDATA? Для каждого канала - свой сериалайзер, для сериалайзера - свой SRCTL(x).RRDY, который отображает наличие приёма в данном канале, а каким образом к статусу приёма для данного канала относится RSTAT.RDATA?

    RSTAT.RDATA - говорит что данные готовы для ВСЕХ активных RX сериалайзеров, т.к. все они:

    1) - сидят на одной синхронизации и соответственно параллельно получают данные со входов RX входов;

    2) - имеют ОДИНАКОВЫЙ формат кадра.

    Для передающей половины все аналогично.

  10. Подход верный.

    запуск связки примерно такой:

     

    1) запретить EVENT18 в EER (на всякий случай)

    2) записать настройки в 64 paramset

    3) записать настройки в 65 paramset

    4) записать настройки в 18 paramset

    5) настроить прерывания от EVENT18 если используются ( выставить бит в IER (через IESR) - куда указывает TCC от 18 paramset )

    6) разрешить EVENT18 в EER (через EESR)

    7) теперь можно { запускать spi } или { для отладки писать в ESR 1 для EVENT18 - притворяясь spi } => { пересылки должны идти + прерывания должны возникать }

  11. При завершении задания для парамсета 18 - контроллер EDMA копирует содиржимое линка (64/65) в парамсет 18 и все продолжает работать без участия процессора.

    Таким образом связка ping-pong настраивается 1 раз и работает без участия CPU.

  12. Если правильно понял вопрос...

    spi переинициализироать не надо - он и не знает кто его будет писать/читатать.

    О прарамсетах:

    Настройки 18-го и 65-го должны быть идентичны

    Настройки 64-го отличаются от 18 только линком на 65 и src/dst адресом - в соответствии с Вашей задачей

    В общем случае правильность работы Вашего пинг понга можно проверить не запуская spi

    Инициализируете парамсеты как надо и потом руками (программно) пишите 1 в соответсвующий бит в EVENT SET register в EDMA контроллере - все должно пересылаться и с отключенным spi

  13. Если еще актуально...

    Возможные причины не возникновения прерываний от MCASP

    0) -не разрешены прерывания глобально и неразрешен вектор NMI

    1) -не разрешен соответствующий вектор в ядре (IER)

    2) -не смапированы прерывания от MCASP в соответтствующий вектор - (смотреть в настройках контроллера прерываний)

    3) -не разрешены источники прерываний MCASP (RINTCTL/XINTCTL)

    4) - все флаги в RSTAT/XSTAT должны быть сброшены при запуске MCASP записью единиц в соответствуюшие биты

    5) - в обработчике прерывания все флаги в RSTAT/XSTAT нужно сбрасывать руками записью единиц в соответствуюшие биты

  14. А я вот никак не могу понять как задаётся внешнее событие для запуска транзакции.

     

    Если правильно понял вопрос - нужно правильно проинициализировать 22-й ParamSet + разрешить события от 22-го ParamSet в EER + правильно наcтроить события в GPIO модуле.

     

    Дока на omap-l138

    6.9.1 EDMA3 Channel Synchronization Events

    event - 22

     

    ps кодом помочь не могу - не использовал GPIO для синхронизации EDMA-пересылок

  15. возможны-ли одновременные операции на одном физ. диске когда 1 или 2 файла читаются, а один пишется.

    ...

    ЗЫ. да, файловые операции происходят в одном потоке, без ртосин, прерываний и многозадачности.

    Делал одновременные обращения к разным файлам на запись и на чтение на одном диске - все работает (версия FatFs - R0.08b). _FS_LOCK не использовал. Все делал через очередь запросов к файловой системе (была многопоточность). Низкоуровневые дисковые операции (disk_write() disk_read() ничего не знают о файлах и FAT - они работают с секторами диска. Если все в одном потоке - проблем быть не должно и при прямом обращении к функциям fatfs, без очередей.

     

×
×
  • Создать...