Передача данных, fifo, кольцевой буфер и т.д. Опции

[Atlantis-]

Добрый день!
Мне нужен некий буфер для обмена данными между прерываниями (в одном пишу в буфер, в другом читаю, передаю дальше) с условием, что при чтении данные должны лежать в памяти линейно.
Суть в том, что сейчас я пишу в кольцевой буфер данные в прерывании I2S, потом в прерывании USB SOF смотрю есть ли данные, если есть - отправляю. Проблема в том, что библиотечная функция передачи данных по USB требует в качестве параметров адрес начала массива данных и количество данных. А буфер то у меня кольцевой! Подскажите, какие есть еще способы передачи данных? Я всегда кольцевым буфером пользовался, а тут надо чтобы данные лежали линейно в памяти.

[zltigo]

Мне нужен некий буфер для обмена данными между прерываниями (в одном пишу в буфер, в другом читаю, передаю дальше) с условием, что при чтении данные должны лежать в памяти линейно.

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

[Atlantis-]

Элементарно. Организовать кольцевой буфер не из байтов, а из блоков данных типового размера.

Эмм...и что будет? У меня сейчас кольцевой буфер 64 байта, а блоки данных 8 байт. Это не мешает одному блоку данных находиться в конце буфера, а второму - в начале.

Простите, а что мешает при переходе через конец буфера первой посылкой отправлять данные от текущего положения до конца буфера, а по следующему запросу отдавать уже от начала буфера? Я так в УАСПП через ПДП отправляю и VCP у меня так же работает.

Я сначала отмел этот вариант потому что скорость передачи данных по Interrupt каналу и так всего 64 байта за 1 мс. Потом прикинул, вроде должно хватать, получается это более выгодный вариант, чем копировать в линейный буфер.
Но меня сейчас больше волнует, как писать в кольцевой буфер из основного потока и из прерывания одновременно.

то есть как?
функция, которая пишет в буфер, все используют только ее

в начале ждем мютекс, в конце отпускаем

если функция вызывается и мютекс занят (кто-то уже вызвал функцию), ОС будет держать вызывающую функцию в ожидании, пока мютекс не освободится (ранее вызвавший функцию записи в буфер закончил работу)

Это подразумевает, что пишущий поток должен отложить свою работу на потом. У меня предполагается, что в кольцевой буфер будут писаться сообщения из прерывания I2S о начале/конце выдаваемого блока данных и сообщения из основного потока о нажатии кнопок.
То есть очень вероятен вариант, что я буду писать сообщение в буфер из основного потока, в этот момент вылетит прерывание и данные смешаются. Тут я вроде бы должен заблокировать запись в буфер из прерывания, но когда прерывание снова сработает снова - мне надо будет посылать еще одно сообщение (первое - о конце одного блока данных, второе - о начале другого блока). То есть получается надо внутри прерывания I2S буферизировать сообщения...

Сообщение отредактировал Atlantis- - Dec 15 2016, 07:57

[Valentine Logino...]

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

Запрещать прерывание во время работы с буфером из основного приложения. Но это некрасиво.

То есть получается надо внутри прерывания I2S буферизировать сообщения...

Разделите свой драйвер I2S на две части: обработчик прерывания и фоновый обработчик на уровне приложения. Фоновый обработчик драйвера I2S будет через небольшой буфер получать данные из обработчика прерывания, а затем формировать и передавать сообщения в вашу общую очередь, доступ к которой вы осуществляете мьютексом. Это позволит вам не блокировать прерывания (не терять данные) и разграничить доступ. Однако следует корректно рассчитать размеры буферов и очередей, а также времена блокировки обработчиков во время обращения за доступом к мьютексу.

[Atlantis-]

Запрещать прерывание во время работы с буфером из основного приложения. Но это некрасиво.

Джиттер будет если надолго запрещать

Разделите свой драйвер I2S на две части: обработчик прерывания и фоновый обработчик на уровне приложения. Фоновый обработчик драйвера I2S будет через небольшой буфер получать данные из обработчика прерывания, а затем формировать и передавать сообщения в вашу общую очередь, доступ к которой вы осуществляете мьютексом. Это позволит вам не блокировать прерывания (не терять данные) и разграничить доступ. Однако следует корректно рассчитать размеры буферов и очередей, а также времена блокировки обработчиков во время обращения за доступом к мьютексу.

Я хотел так сначала разделить - чтобы прерывание I2S только отправляло данные и обрабатывало флаги, а расчет следующих данных для отправки и всего остального вести в специальной задаче, которую вызывать из прерывания I2S. Но I2S у меня работает на частоте 48 кГц, то есть период 21 мкс, прерывание I2S обрабатывается у меня за 3 мкс, а вызов задачи FreeRTOS занимает 4 мкс! Поэтому я решил все эти дела делать в прерывании, даже для сообщений кольцевой буфер сделал, хотя мог просто очередь создать и писать в нее хоть из прерываний, хоть из основного потока одновременно. Но писать в очередь в прерывании I2S это плюс 4 мкс к времени его обработки, то есть в сумме 7 мкс, а это уже треть от 21...в общем показалось мне многовато, поэтому и пытаюсь что то изобрести.

[AlexandrY]

Но I2S у меня работает на частоте 48 кГц, то есть период 21 мкс, прерывание I2S обрабатывается у меня за 3 мкс, а вызов задачи FreeRTOS занимает 4 мкс!

Выглядит не очень разумно каждый сэмпл на I2S делать прерывание.
Но даже так, 3 мкс на прерывание в котором только пересылка это подозрительно много. Может прерывание RTOS используете?