caxapa.ru :: Ну я уже и не знаю как еще. Молотит АЦП несколько каналов и через DMA кидает в память. После каждого цикла опроса, в обработчике прерывания DMA делаются некие действия над этими данными. Разные действия для разных групп каналов, но общие для

Codavr (13.10.2014 11:23 - 11:34, просмотров: 243) ответил SciFi на Да ладно, не кипятись. Ты же ТЗ так и не выкатил. Привёл несколько странных цифр, которые ничего не прояснили.

Ну я уже и не знаю как еще. Молотит АЦП несколько каналов и через DMA кидает в память. После каждого цикла опроса, в обработчике прерывания DMA делаются некие действия над этими данными. Разные действия для разных групп каналов, но общие для потребителей. Потребители получают результаты обработки асинхронно и отбалдово. То что я сейчас накропал с семафорами, фигня получается, если потребитель захватил семафор, то обработчик DMA в пролете, а это в моем случае недопустимо. Воткнуть очередь думаю над этой темой. Нужно организовать ее так чтобы непотребленные данные из нее удалялись чтобы обработка DMA не блокировалось. Тут у меня неясность как это правильно сделать. Может есть еще какие механизмы, я нефкурсах. Если что FreeRTOS уже имеется.

Долой империалистический интернационал!

Ответить

- Семафоры могут быть не только бинарными, но и счетными. Ничего там не должно пропускаться - Petrovich(13.10.2014 11:42, )
  - А как сделать так чтобы потребитель знал, что в момент потребления туда не произошла запись новых значений. А то ведь пока я буду первый int вычитывать у меня третий тынц и изменился, а мне это низзя. - Codavr(13.10.2014 11:45)
    - Для этого есть критические секции и копирование. - =AlexD=(13.10.2014 11:46)
      - Потребитель запускает критическую секцию, а у DMA пришло время новые данные обработать. Вот мне и хочется, чтобы потребитель не лез своим рылом в драгоценный процесс обработки, а просто знал что данные повреждены и следует униженно попросить дать Codavr(17 знак., 13.10.2014 11:50)
        
        Потребитель в критической секции копирует 4 байта результата в в свою локальную копию. Ну, задержится прерывание DMA на 100нс. Не будет же overrun'а АЦП. - Petrovich(13.10.2014 11:58, )
        
        Вроде да. А других граблей тут не может быть? - Codavr(13.10.2014 12:01 - 12:04)
        
        Ка говаривал М.Горький или старуха Извергиль, в жизни всегда есть место подвигу и граблям. если потребители должны быть синхронными - то подлая DAC может вклиниться и нарушить. - Petrovich(13.10.2014 12:07, )
        
        Потребители хавают что дали и не выеживаются. - Codavr(13.10.2014 12:18)
- При чём здесь вообще DMA? Тебе ж судя по всему нужно буферизировать не сырые данные, а результаты обработки. - =AlexD=(13.10.2014 11:36)
  - Результаты работы АЦП (6 каналов) посредством DMA кладется в память (участок 12 байт). После того как все каналы опрошены происходит прерывание DMA и обработчик выполняет некоторые операции над этими (12 байт) данными и результат обработки Codavr(82 знак., 13.10.2014 11:40 - 11:43)
    - Ну и? В чём проблема? Обработчик DMA копирует себе 12 байт, обрабатывает их, раскладывает результаты по корзинкам и сигналит потребителям что их можно забирать. В каком месте проблема? - =AlexD=(13.10.2014 11:44)
      - Потребитель начинает их забирать, но все забрать не успел (причин тыща), а DMA в это время в корзиночку новые данные тынц. - Codavr(13.10.2014 11:47)
        
        Блокировка прерывания до копирования данных и разрешение после - гарантирует целостность данных полностью, не думаю что гипотетическое откладывание обработчика DMA на пару-тройку команд cpu отразятся на чём-либо негативно. - =AlexD=(13.10.2014 12:58)
        
        Прерывание можно даже не блокировать, а положить рядом с данными счетчик, который изменяется в прерывании вместе с данными. Если и до и после чтения данных этот счетчик неизменен, то данные годные, иначе перечитать. Хотя проще заблокировать. - mr-x(13.10.2014 14:48)
        
        Это уже перетерли. - Codavr(13.10.2014 14:55)
        
        Про критическую секцию уже перетерли. Это как вариант, возможно даже и лучший в этом случае. Просто хочется чтобы "огласили весь список". - Codavr(13.10.2014 13:46)
        
        Ну если хочется альтернативы... то банальный FIFO достаточной глубины позволяет неспешно работать с данными без пропусков, а если хочется иметь всегда оперативные данные, то потребитель просто вычёрпывает его и использует последнее значение. =AlexD=(105 знак., 13.10.2014 14:30)
        
        Кольцевой буфер имеется ввиду, где данные не двигаются, а только указатель начала и конца? - Codavr(13.10.2014 14:49)
        
        Да, кольцевой. - =AlexD=(13.10.2014 14:50)
        
        Это тема. Спасибо. - Codavr(13.10.2014 14:54)
        
        ping-pong buffer + некольцевой DMA уже перетирали? - Vit(13.10.2014 14:01)
        
        Вроде еще нет. Излагай шо за зверь. - Codavr(13.10.2014 14:01)
        
        2+ буфера. в обработчике DMA первым делом перезаряжаешь указатель на свободный буфер и запускаешь, из теперь уже "предыдущего" буфера можешь грести медленно и печально и даже в том же обработчике - Vit(13.10.2014 14:07)
        
        А если такая ситуевина Codavr(172 знак., 13.10.2014 14:12)
        
        в любом случае - один длинный буфер или 2+ коротких - общая длина должна быть с каким-то запасом. значение указателя для DMA актуально для DMA, та же фигня со свободными буферами и их "потребителями". сильно неспеша это медленнее, чем достаточно, Vit(171 знак., 13.10.2014 14:45)
        
        То есть мы читаем из дальнего конца буфра до которого кровавая рука обработчика DMA гарантировано не дотянется? Тогда по мне эстетичнее один кольцевой использовать. - Codavr(13.10.2014 14:53)
        
        сами буферы при 2+ могут быть расположены в памяти совсем не подряд. - Vit(13.10.2014 15:01)
        
        Я подумал, что 2+ это 2 буфера и больше. Я не ошибся, а то может я просто не понял? - Codavr(13.10.2014 15:04)
        
        не ошибся. - Vit(13.10.2014 16:07)
        
        случаи бывают разные. например, вывод в ЦАП в MP3-плеере - там с парой буферов на канал достаточно удобно получается. - Vit(13.10.2014 14:58)
        
        Ну да, по ситуации это наверное может быть удобнее. - Codavr(13.10.2014 15:06)
        
        Так проблема в том, что потребитель не может забрать данные атомарно? Для этого есть простое решение: SciFi(391 знак., 13.10.2014 12:07 - 12:11)
        
        Хватит одного счётчика, который обработчик прерывания инкрементирует после обновления данных. Потребитель читает счётчик, потом данные, потом снова счётчик. Если значения совпали, - данные верны(13.10.2014 12:58, )
        
        А, ну да. - SciFi(13.10.2014 13:02)
        
        Счетный семафор это типа реверсивного счетчика, который подсчитывает сколько раз прощелкали клювом :) - Codavr(13.10.2014 12:22)
        
        А чем это отличается от инвертирования бита (обычного семафора)? Скрипач(84 знак., 13.10.2014 12:21)
        
        Если потребитель захватил семафор, то производитель сосет банан. А тут производитель всегда свободен, а потребитель имеет инфу о том что принятые данные корректны. - Codavr(13.10.2014 12:24)
        
        Значит потребитель не должен захватывать семафор. Только читать его. - Скрипач(13.10.2014 12:29)
        
        Ну вот я прочитал что семафор свободен. Взял словечко. В это время DMA хвать семафор, новые данные тынц, и тут же отдал семафор. Я как ни в чем не бывало читаю семафор, он свободен, беру второй байтик и писец Чернобыль-2. - Codavr(13.10.2014 12:31)
        
        *О механизмах блокировки рекомендую "Алгоритмические языки реального времени. Конструирование и разработка" С.Янг., 1982г. Скрипач(214 знак., 13.10.2014 12:34 - 12:42)
        
        Книга в PDF бомж(13.10.2014 17:56)
        
        Почитаю на досуге. Блин! Она у меня была, какая сука не вернула!? - Codavr(13.10.2014 12:40 - 12:54)
        
        Возможно, среди общепринятых примитивов синхронизации нет примочки с двумя счётчиками, потому что эта примочка ничего не гарантирует: в худшем (общем) случае можно ждать бесконечно. SciFi(97 знак., 13.10.2014 12:40)
        
        Ну когда ждем бесконечно потому что пожелал больше собственного веса - сам дурак. Эта ситуация тривиальная и ее не рассматриваем. - Codavr(13.10.2014 12:44)
        
        Она является "велосипедом с квадратными колесами", поскольку функционал идентичен обычному семафору :) - Скрипач(13.10.2014 12:43)
        
        Лукавить изволишь, боярин. С семафорами нужно ещё и FIFO городить, а тут этого нет. Такшта извени, не считается. - SciFi(13.10.2014 12:50)
        
        ~~бред~~ Логической связи семафора и FIFO не уловил. - Скрипач(13.10.2014 12:55)
        
        Ну тогда объясни на пальцах как правильно семафором это реализовать. У меня фигня получилась. Я согласен, что чего то не знаю наверное, вот потому и решил спросить у старших товарищей. Отсылка к книге дело полезная - она сила и источник знаний, и Codavr(257 знак., 13.10.2014 12:46 - 12:49)
        
        Если "в лоб", то вот так: Скрипач(568 знак., 13.10.2014 12:53 - 13:25)
        
        Чота нефкурил. Семафор здесь кто, lock? - Codavr(13.10.2014 13:00)
        
        Исправил. Семафор - lock. Но не простой, а счетный. Корректно обрабатывается "параллельное чтение" несколькими юзерами. - Скрипач(13.10.2014 13:10)
        
        То есть семафором рулит потребитель, а обработчик его только смотрит. Пока все потребитель не схавал, данные не обновляем. Понял. Спасибо. - Codavr(13.10.2014 13:23)
        
        Пожалуйста. Но почитайте книжку, не пожалеете :) Семафором ВСЕГДА рулит одна сторона, а другая только анализирует. В отличии от сигнала, который один выставляет, а другой принимает. - Скрипач(13.10.2014 13:29)
        
        Всенепременно. Книга замечательная. Я ее купил еще в институте. Всю не осилил, но нашел очень много интересного для себя на ту пору. Но похоже кто-то ее у меня заиграл. Еще в институте собирался завести амбарную книгу чтобы записывать кто какую Codavr(419 знак., 13.10.2014 13:33 - 14:06)
        
        Ну да именно в этом. Интересный способ. Спасибо. - Codavr(13.10.2014 12:18)

ARM, RISC-V контроллеры