[ASN 0]

TigerSHARC

А зачем обрабатывать каждый отсчёт ? Набрал буфер (несколько сотен отсчётов), запустил обработку.

По условия задачи данные необходимы раз в секунду по запросу с SPI ПЛИС должна отдавать данные блоком, который накопился за 1 секунду.

Тут никого реального времени нет.

Maverick

1. Заказчик всегда прав.

2. Если тебе кажется, что заказчик неправ - смотри пункт 1.

Если продавец мне объяснит, что в моей деревне 100 бесплатных стереорадиостанций, а плеер проигрывает музыку только на бобинах , которые стоят много денег, то я скажу спасибо продавцу и куплю радио.

Уважаемый iosifk предложил решение и дал ссылку на методологию. Поскольку я разделяю его точку зрения, то и позволил высказать своё мнение. Только и всего. Есть у ТС есть желание изучать HDL - я только буду рад. С практической точки зрения ПЛИС в данной задаче избыточна.

[TigerSHARC 0]

TigerSHARC

А зачем обрабатывать каждый отсчёт ? Набрал буфер (несколько сотен отсчётов), запустил обработку.

набирать буфер придётся в ядре Linux(в буфере драйвера), если делать напрямую АЦП->ARM(Linux). Драйвер будет тоже работать по прерываниям, а на скорости 64кгц - это проблематично.

 

Придётся делать аппаратный буфер на МК или ПЛИС (воздержусь от коментариев).

 

Я всего лишь хотел опровергнуть мнение что 64кГц - это легко для линукс.

 

Хотя, может есть другие хитрые решения, я бы у удовольствием послушал.

 

 

Только сейчас подумал. Можноли сделать так: задать величину DMA буфера, по одному прерыванию буфер забивать(игнорируюя прерывания на каждом цикле преобразования во время заполнения буфера), как толкьо забьётся буфер через DMA, ловить следующее прерывание... получается вся суть в настройке DMA.

 

Хотя может это бред...

Изменено 20 декабря, 2012 пользователем TigerSHARC

[ASN 0]

TigerSHARC

Всё правильно - обрабатывать события быстрее, чем 50 мс в Linux сложно (это мнение нескольких незнакомых между собой прикладных программистов, с которыми мне приходилось работать).

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

Если в СнК нет развитой системы, то да - внешний Cortex накапливает буфер данных, формирует событие и передаёт в Linux по высокоскоростному интерфейсу.

 

[iosifk 3]

Только сейчас подумал. Можноли сделать так: задать величину DMA буфера, по одному прерыванию буфер забивать(игнорируюя прерывания на каждом цикле преобразования во время заполнения буфера), как толкьо забьётся буфер через DMA, ловить следующее прерывание... получается вся суть в настройке DMA.

 

Хотя может это бред...

 

Аналоговские микропроцессоры так и работают еще начиная с древних 2181... Они умеют принимать по ДМА в память весь ИКМ тракт, а это 30 разговорных каналов, и по окончании кадра об этом рапортуют прерыванием...

А уж сейчас есть процессоры и с более умными каналами ДМА...

И об этом я как раз писал, что надо просто выбрать именно такой микроконтроллер, который так умеет делать, а не городить "доработки"...

 

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