Это я протупил
9911/6 = 1651
9911%6 = 5
P.S. Малые числа(в пределах байта) легко в уме делал, а с большим не справился))
0%5 = 0 +1 =1
1%5 = 1 +1 =2
2%5 = 2 +1 =3
3%5 = 3 +1 =4
4%5 = 4 +1 =5
5%5 = 0 +1 =1
PS Февраль жеж однако
Да блин! Хорошо, остаток от 6 надо взять,@ua6em, от 6!)))
Теперь осталось уточнить зачем +1.
А вообще ещё micros() есть. Хотел узнать, они с миллис от одного “физического источника” работают или нет? Если нет, то возможно ли расхождение в их показаниях?
От одного. На ATtiny13 вообще один таймер.
Чтобы было 1 … 6, а не 0 … 5 ))
Кстати, необязательно делить все байты, полученные у millis, может хватить и одного-двух младших.
1 лайк
Спасибо, подучиться никогда не мешает
Если делить только младший, то при условии, что millis считает по 1 последовательно, то 5 и 6 будут выпадать (примерно) на 2 % реже.
В Attiny13 алгоритм millis наверное может быть разным в разных версиях, в той что у меня MicroCore 2.3.0, считает с шагом 19. Но если бы например считало с шагом 16, то данный метод бы не работал.
Нельзя использовать просто остаток от деления.
Шанс выпадения меняется.
А вот в прерывании
count==6?count=0:count++;
Вполне себе равные шансы
- Это слишком сильное условие. По крайней мере, для AVR оно не выполняется.
- Я не утверждал, что хватит, я утверждал, что может хватить. При этом оговорил, что не обязательно следует брать один байт, возможно - два. Вопрос исключительно в том, насколько нам нужна равномерность распределения (которая, кстати, на AVR все равно не достигается). И именно из этого вопроса уже вытекает: может хватить или не может, и, если может, сколько байт именно брать.
Можно!
Если не предъявлять завышенных требований к равномерности распределения.
Особенно, если установить прерывание на 100 мс, а случайные числа запрашивать 5000 раз в секунду.
Абсолютно универсальных решений не существует.
Любое решение нужно проектировать под конкретную задачу.
Собственно, зачем брать millis, когда можно читать регистр TCNT напрямую? Неравномерность практически незаметна будет.
От 0 до 251 целое ччисло раз пробегает остаток от деления на 6. Добавляем условие игнорировать значения счётчика от 251 до 255.
Вот!
Не важно, равномерно или неравномерно, главное - незаметно!
1 лайк
Я больше скажу! Реальный игральный кубик(обнаковенный, копеешный,китайский) имеет бОльшую погрешность, т.к. кол-во углублений, обозначающих число, разное, посему и центр тяжести смещён. Так что нечего изобретать)
Вопрос в “универсальности” метода.
Во первых в начале обсуждалась Attiny13 - и там для millis может использоваться WDT
Если же это не Attiny13 и используется таймер 0, то
Алгоритм может (и скорее всего будет) перед вызовом использовать delay или ожидание millis() и тогда TCNT может быть заметно не случайным.
Дополнение: Про delay - скорее всего не прав, т.к. он срабатывает не по переполнению счетчика.
Ох уж эти ваши “переносимости”. ДеДиван’а на всех вас нет!
Задача. Найдите такое расположение граней достоинством в 1,2,3… чтобы центр тяжести (или всё таки центр масс?) имел минимальное смещение от “геометрического” центра.
Хм. Думаю числа на противоположных гранях должны быть соседними: 1 и 2, 3 и 4, 5 и 6. Есть у кого кубик под рукой сфотать?) А не, ща найду сам.
Не угадал… Но тут 1 имеет большую лунку.
На самодельных кубиках так и размечаем на уроках
Я думал это задача с подвохом)
Интуиция подсказывает что есть другое решение, но пока не могу в голове его сформулировать.