Здравствуйте, BAC, Вы писали:
BAC>Дано ИСТОЧНИК(чип) с которого считываются параметры( П1, П2, П3, ... П32).
BAC>На длинну списка накладываю ограничение: число параметров никогда не будет 64.
BAC>Каждый из параметров я хотел бы считывать с определённой периодичностью (примерно). Хотелось бы получить список в котором параметры могут повторяться. С очередным тиком базового таймера рассматривать следующий элемент.
BAC>создать список, каждый из параметров можит входить в него один или более раз. Те что должны чаще считываться -- чаще встречаются в списке. создать такой список не так то просто, как я определил.
Создавать такой список не обязательно. Решение лучше базировать на более интуитивных вещах, а список пусть сам себе строится в процессе. Впрочем, я там ниже также приведу размышления по поводу списка.
Пусть у тебя tps тиков в секунду. i-й параметр должен считываться в среднем ki раз в секунду, т.е. его "потребность" в обновлении растет с каждым тиком на ni=ki/tps (за tps тиков она вырастает до ki). Изначальную потребность параметров в обновлении можно инициировать либо нулем, либо каким-нибудь случайным числом от 0 до 1, либо по возрастающей для всех параметров, либо как-то еще. С каждым тиком ты пробегаешь по массиву этих самых double nfu[32] и увеличиваешь i-й элемент на ni. Можно вместо double взять числа с фиксированной точкой. Тебе важно отловить момент, когда целая часть nfu перевалит к следующему значению. На ассемблере в игрушках часто делают так: используют банальный byte или int для хранения дробной части только, а отлавливают переполнение. Таким образом, если экран надо обновлять максимум 60 раз в секунду, интеллект должен работать для AI 10 раз в секунду, а ввод отлавливаться 20 раз в секунду, то очередь на все эти функции выстраивается сама собой.
Если же такое саморегулирующееся решение не подходит (оно может не подходить по очень многим причинам), и хочется просто (циклическую) очередь обновления параметров, то тебе надо следующее.
а) Выявить минимальное время L в тиках, за которое каждый параметр должен обновиться [i]целое число раз, т.е. wi=L*ki/tps целое для всех. Еще лучше, если время L будет степенью двойки, чтобы индекс, который будет бежать по времени, можно было просто увеличивать и and-ть по младшим битам.
б) Для i-го параметра, который должен встретиться в этой очереди wi раз с шагом si или si+1, где si=[tps/ki], надо расставить его так: первая позиция x0i должна быть от 0 до si-1, затем j-я позиция должна быть x0+j*si или x0+j*si+1. В этом случае достигается максимально равномерное считывание каждого параметра.
Далее, могут возникать коллизии, когда на какой-то тик вдруг надо считывать сразу несколько параметров. Более того, обработка одного входного параметра может длиться более одного тика. В этом случае в очереди, чтобы не было таких коллизий, надо размещать считывание очередного параметра с учетом возможной задержки в считывании или обработке предыдущего параметра. В первом варианте обычно либо считывают все, что набрало достаточное количество тиков к данному моменту, либо считывают один, а остальные откладывают на следующий цикл/тик, но продолжают для них обновлять их nfu, чтобы эта задержка не сказалась на последующем времени обработки.
Поиск расстановки параметров по второму варианту -- дело кропотливое и нудное. Допустим, что первый параметр k обновляется сразу, т.е. его x0k=0. Далее, ему соответствует цепочка тиков j*sk[+1], в которые он должен обновляться. Второй параметр l обновляется в моменты x0l+j*sl[+1]. Если возникает коллизия этих двух параметров, то она решается просто: за счет того, что j-я позиция обновления может быть в пределах двух возможных тиков. Коллизию трех параметров k,l,m нельзя разрешить, если x0k+jk*sk = x0l+jl*sl = x0m+jm*sm для каких-то чисел k,l,m. Разрешить такую коллизию можно только путем изменения x0 для одного из параметров. А вообще, какого порядка у тебя величины tps, ki и длина обработки одного входного сигнала? Насколько вообще такие коллизии вероятны?
