Здравствуйте!
Абстрагируясь, моя задача состоит в том, чтобы принять несколько разных блоков данных по USB, массивы определяющие в какой последовательности, по сколько раз и с какой паузой между ними выдавать эти блоки по I2S.
Я разбил все эти данные на три глобальные структуры:
1) структура содержащая адреса блоков данных и их длины
2) структура содержащая массивы определяющие в какой последовательности, по сколько раз и с какой паузой между ними выдавать эти блоки
3) структуру содержащую счетчики, которые изменяются в процессе выдачи данных для расчета окончания блока данных, количества его повторений, паузы между блоками и т.д. Переменные этой структуры будут меняться в теле прерывания.

Вопрос у меня такой: правильно ли я вообще мыслю, не будет ли путаницы с глобальными переменными, чего следует остерегаться и может быть есть какие то другие варианты, без глобальных переменных?

Забыл сказать - использую FreeRTOS и меня немного смущает использование в задачах глобальных переменных.

Зачем три? В чем страхи пред одной?
Заодно в чем конкретно страхи перед глобальными переменными? Хотя, конечно, те переменные, которые используются в одной задаче, красивее положить в стек этой задачи.
Вообще-то абстрактно надо стремится передавать информацию между задачами через очереди сообщений, а не через кучи глобальных переменных - это насколько я понимаю, явно отностися к помянутому Вами в 1)

Получится 18 переменных в одной структуре, я могу запутаться и забыть какая чего означает. Придется названиями разделять на три вида. А в чем преимущество одной большой структуры перед тремя маленькими? Ну теоретически первые две структуры можно объединить, а третью уже не хочется.


Да не знаю, перестраховываюсь. По идее у меня возможен одновременная запись и чтение 2-й структуры


У меня конкретно сейчас сделано так: приходит блок данных по USB, отправляется сообщение содержащее адрес, размер блока и адрес структуры куда это надо переписать. В задаче данные переписываются. Но сегодня меня "осенило", что зачем адреса структур передавать, они у меня все равно глобальные...

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

Вообще-то, могу только повторить, что, насколько я смог понять, что Вы наворотили, первой структуры вообще быть не должно.

Незнание это страшная беда - ведет прямиком к стучанию в бубен и прочим камланиям

Совершенено очевидно, что если дела получателя этого сообщения только в копировании куска памяти, то такой получатель нинафиг не нужен вообще. Подумайте, как делать прием и обработку фреймов в стиле zero-copy.

В первой структуре у меня содержится массив указателей на блоки данных, массив длин этих блоков, массив служебной информации о каждом блоке, номер (индекс в массиве) записываемого блока и текущий указатель записи (блоки большие и по USB передаются не за один раз).


Почему? Ну я мог бы прямо в прерывании от USB копировать данные в нужные структуры. Сейчас у меня сообщение вызывает задачу и в ней данные пишутся в структуры, просто я использую RTOS для своих задач. Я же данные не копирую в сообщение, а отсылаю только адрес начала и кол-во данных.

Зачем все эти "массивы" нужны??? Есть приемный буффер. По приему в него кладется (если нужно) Ваш заголовок и принятая информация. Указатель, единственный! параметр!, кладется в очередь сообщений к задачам, котрые сие все обрабатывают. Все.

Зачем, ну зачем! Вообще что-то куда-то копировать!

Вы уж тогда определитесь, что такое у Вас "пишутся" для меня и любого другого читателя, это то-же самое, что копируются, ибо Вы что-то уже принятое и записанное в RAM берете и
пишите в другую память выделеную под структуру. Либо Вы назывете словом "пишутся" что-то ведомое только Вам, либо у Вас таки есть копирование данных.

И что, это объясняет изобилие и копирование данных???

Не совсем понял. Вот у меня приходят данные от хоста, они содержаться в каком то массиве, их туда библиотечные функции складывают. Я эти данные перекопирую в память (в SDRAM). Чтобы их переписать мне нужен указатель и количество данных. Чтобы принять новую порцию - мне нужно знать последний записанный адрес в памяти.


Мне как минимум надо копировать в SDRAM, но даже если бы и не так - все равно не понятно. Допустим от хоста надо передать блок данных 256 байт. В первой посылке по USB придет 64 байта, они будут хранится в RAM. Что значит не копировать? Следующая посылка будет записана по тому же адресу. Или Вы имеете ввиду сразу из USB писать по нужному адресу? Это надо переписывать библиотеку, HAL от STM.

Отлично. Они УЖЕ в памяти вот С ЭТОЙ памятью и работайте БЕЗ лишнего копирования куда либо.

Не верю, что не смотря на всю "библиотечность" и соответственно почти гарантированную уродливость творений индийских недоученных студентов , "библиотека" НЕ умеет принимать НЕСКОЛЬКО фреймов подряд.
Почему? Потому сие начисто ломает саму идею буферизации и не позволяет в общем случае ни на что, кроме обработки приемы фреймов отвлекаться - чуть овлекся, не успел забрать фрейм и все . Так-то либо Ваши "библиотеки" неземной кривизны, либо Вы не понимаете, как их реально использовать. А вообще дерьмо-софт от производителей железа, он и есть дерьмо. Можно изучать ТОЛЬКО, как образец того, как делать НЕ надо. Исключений не встречал . Так-что припасть к первоисточникам и переписать очень даже ПОЛЕЗНО.

а кто не тупые, кроме вас?

Я понял Вашу мысль.


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


Это катастрофически увеличит время разработки.

Больше чего? Больше имеющейся у Вас в распоряжении памяти ? Если нет , то пусть все и продолжает сваливаться в память. Ну разве только наступит какое-нибудь органичение, типа размера блока памяти доступного каналу DMA который обслуживает USB. Ну, тогда, простите, думайте над протоколом, ибо негоже многие килобайты сначала кидать, а потом уже только разбитаться.

Если это НЕ последняя разработка в Вашей жизни, то не важно. Принцип - "Если ты сделаешь быстро и плохо, то скоро забудут, что ты сделал быстро,
и долго будут помнить, что ты сделал плохо. А если ты сделаешь медленно и хорошо, то скоро забудут, что ты сделал медленно, и долго будут помнить, что ты сделал хорошо" - таки работает.