Мое мнение:
1. обязательно разное ранжирование на разное настроение. Не обязательно называть это настроением. Например я при работе не перевариваю песни с русскими или английскими словами — периодически ловлю себя на том, что слушаю слова. Но от этого песя не становится нелюбимой
2. в качестве способа выбора трека вполне устроит случайный выбор с учетом веса(рейтинга) песни. На пальцах — сложили все рейтинги, получили, например 1500. Выбрали случайное число от 1 до 1500, посмотрели по порядку, в какую песню попали. Каждая песня получит шанс, более ретинговые — больше шанса.
3. Возможно я ищу какую-то конкретную песню и пролистываю много треков подряд. Надо в этой серии рейтинг пролистываемых снижать незначительно, а рейтинг найденной — повышать
Задача обработчика прерывания — или положить событие в очередь или уменьшить максимум 64 таймера. Все легко уложится в 200 мкс, то есть до прихода следующего прерывания.
Проверял на работу как часы реального времени — визуально за час не разбежалось на секунду. Плюс к этому у меня есть отдельно аппаратные часы реального времени — синхронизироваться раз в час не проблема совсем.
Конечно. А за счет чего? Только за счет того, что в некоторых участках кода могут быть заблокированы прерывания на время, большее чем 200 мксек. И то ошибка не составит больше, чем единицы процентов. Тик таймера — 41 прерывание.
Да, сработал таймер и событие ждет обработки в очереди. Но до следующего тика таймера оно будет гарантировано обработано. Задачи некритичны к задержкам менее тика таймера.
По поводу аппаратных таймеров — разработчики набора задействовали все таймеры на такую фигню:
— управление яркостью и контрастностью экранчика (аппаратный ШИМ. Или правильно писать «аппаратная ШИМ»?)
— бипер (опять ШИМ)
Ходит как утка и крякает как утка — значит это утка :)
Я реализовал диспетчер задач и таймеры, но не реализовал приоритетное принудительное вытеснение процессов. Где граница, после которой «просто прошивка» становится rtos?
в stdint.h, то понял, что фатальным нарушением использовать unsigned char не будет. Тем более, просмотрел листинг, структуры все ровно того размера как и планировалось. Где надо — 1 байт, где надо — два байта.
В любом случае, спасибо за науку, в следующем цикле рефакторинга обязательно исправлюсь.
Точно, указатель на первую свободную ячейку.
В оправдание могу сказать, что текущие структуры эволюционировали (и сейчас эволюционируют), поэтому какие-то огрехи вполне могут иметь место.
А можно на пальцах, как будет выглядеть автомат для такой задачи:
Опрос датчика 1 каждые 750 мсек
Опрос датчика 2 каждые 200 мсек
Обновление экрана каждые 500 мсек (выводятся данные датчиков)
Реакция на клавиатуру (хотя бы старт-стоп).
Как я не прикидывал, от конечного автомата остается еще меньше, чем в моей системе от классической rtos ;)
Вопрос классификации всегда спорный. Этот диспетчер гарантирует мне время отклика 1 мсек при всех возможных комбинациях входящих взаимодействий. Этого для решения моих практических задач хватает. Да, это достигнуто не только особенностью системы, но и оптимизацией функций-обработчиков, которые не занимают процессор дольше 10-100 мксек.
Элементы двигаю неспроста — мне надо, чтобы вновь вставляемые всегда шли после существующих. Некая система приоритетов обработчиков. Сначала событие обрабатывает самый последний зарегистрированный обработчик.
Компилятор avr-gcc, есть inttypes.h, но внятного объяснения, почему надо использовать uint8_t вместо unsigned char я не уловил, кроме идеи тотальной портабельности. Не спорю, что мог нарушить какие-то рекомендации, но хотелось бы узнать, какие именно.
И по поводу динамики — да, можно сделать конечный автомат. Но когда нужно выполнять несколько действий с разной периодичностью (опрашивать датчики, перерисовывать экран, опрашивать клавиатуру, выдавать управляющие команды, и не забывать, что может прилететь из UART), то либо автомат становится монстрообразным и его уже на бумажке не отладишь, либо вырождается до трех состояний «инициализация-работа-ошибка», а все остальное впихивается в прерывания с непредсказуемыми задержками.
А что есть список условий запуска, как не организованная очередь сообщений?
Мне такого обзора не хватало. Или готовый монстр типа FreeRTOS, или голая теория. Понаступал на грабли, выкристаллизовал свое виденье. Если кому-то пригодится еще — значит свою миссию этот пост выполнил.
По опыту знаю, что операторов очень раздражает нелинейность форм. Даже если какое-то поле автоматом пропускается, они автоматом жмут Enter-Enter (или Tab-Tab, у кого как) и очень удивляются, что получилось совсем не то. Не говоря про какие-то вопросы, которые появились в начале формы, а оператор смотрит на бумажный документ и набирает вслепую.
Схема образования «как в институте» подразумевает, что студент в свободное время не бухает, а таки углубляет то, что ему интересно и полезно. Но вчерашние школьники только почувствовав немного свободы, срываются в загул.
В противовес — мастер-подмастерье. Но не как свободное посещение (это уже получается мини институт), а жесткое вдавливание своего образа мысли в голову неофитов. Минусы — сложно найти подходящих учеников. Плюсы — ученик всегда превзойдет мастера.
1. обязательно разное ранжирование на разное настроение. Не обязательно называть это настроением. Например я при работе не перевариваю песни с русскими или английскими словами — периодически ловлю себя на том, что слушаю слова. Но от этого песя не становится нелюбимой
2. в качестве способа выбора трека вполне устроит случайный выбор с учетом веса(рейтинга) песни. На пальцах — сложили все рейтинги, получили, например 1500. Выбрали случайное число от 1 до 1500, посмотрели по порядку, в какую песню попали. Каждая песня получит шанс, более ретинговые — больше шанса.
3. Возможно я ищу какую-то конкретную песню и пролистываю много треков подряд. Надо в этой серии рейтинг пролистываемых снижать незначительно, а рейтинг найденной — повышать
Проверял на работу как часы реального времени — визуально за час не разбежалось на секунду. Плюс к этому у меня есть отдельно аппаратные часы реального времени — синхронизироваться раз в час не проблема совсем.
Да, сработал таймер и событие ждет обработки в очереди. Но до следующего тика таймера оно будет гарантировано обработано. Задачи некритичны к задержкам менее тика таймера.
По поводу аппаратных таймеров — разработчики набора задействовали все таймеры на такую фигню:
— управление яркостью и контрастностью экранчика (аппаратный ШИМ. Или правильно писать «аппаратная ШИМ»?)
— бипер (опять ШИМ)
—
Я реализовал диспетчер задач и таймеры, но не реализовал приоритетное принудительное вытеснение процессов. Где граница, после которой «просто прошивка» становится rtos?
typedef unsigned char uint8_t;
в stdint.h, то понял, что фатальным нарушением использовать unsigned char не будет. Тем более, просмотрел листинг, структуры все ровно того размера как и планировалось. Где надо — 1 байт, где надо — два байта.
В любом случае, спасибо за науку, в следующем цикле рефакторинга обязательно исправлюсь.
В оправдание могу сказать, что текущие структуры эволюционировали (и сейчас эволюционируют), поэтому какие-то огрехи вполне могут иметь место.
А можно на пальцах, как будет выглядеть автомат для такой задачи:
Опрос датчика 1 каждые 750 мсек
Опрос датчика 2 каждые 200 мсек
Обновление экрана каждые 500 мсек (выводятся данные датчиков)
Реакция на клавиатуру (хотя бы старт-стоп).
Как я не прикидывал, от конечного автомата остается еще меньше, чем в моей системе от классической rtos ;)
Вот и получилась «недоОСРВ».
Элементы двигаю неспроста — мне надо, чтобы вновь вставляемые всегда шли после существующих. Некая система приоритетов обработчиков. Сначала событие обрабатывает самый последний зарегистрированный обработчик.
Компилятор avr-gcc, есть inttypes.h, но внятного объяснения, почему надо использовать uint8_t вместо unsigned char я не уловил, кроме идеи тотальной портабельности. Не спорю, что мог нарушить какие-то рекомендации, но хотелось бы узнать, какие именно.
И по поводу динамики — да, можно сделать конечный автомат. Но когда нужно выполнять несколько действий с разной периодичностью (опрашивать датчики, перерисовывать экран, опрашивать клавиатуру, выдавать управляющие команды, и не забывать, что может прилететь из UART), то либо автомат становится монстрообразным и его уже на бумажке не отладишь, либо вырождается до трех состояний «инициализация-работа-ошибка», а все остальное впихивается в прерывания с непредсказуемыми задержками.
А что есть список условий запуска, как не организованная очередь сообщений?
Вот при валидации формы — это самое то.
Схема образования «как в институте» подразумевает, что студент в свободное время не бухает, а таки углубляет то, что ему интересно и полезно. Но вчерашние школьники только почувствовав немного свободы, срываются в загул.
В противовес — мастер-подмастерье. Но не как свободное посещение (это уже получается мини институт), а жесткое вдавливание своего образа мысли в голову неофитов. Минусы — сложно найти подходящих учеников. Плюсы — ученик всегда превзойдет мастера.