Тем, что теперь последовательность действий отделена от самого алгоритма, для него теперь это просто входные данные, которые вы можете получить каким угодно способом: можете задать жестко, генерировать на лету, вычитывать из конфига, преобразовывать другие данные. Записав алгоритм как последовательность вызовов методов вы не сможете получить такую гибкость.
Да не имел в виду я никакой DSL, просто не хотел привязываться к конкретному языку программирования.
В си я бы использовал массив указателей на функции, в C++/Java накидал бы коллекцию различных реализаций интерфейса Move и т.д.
Да, можно вынести во внешние конфиги или описать действия на внешнем DSL, чтобы не пересобирать программу при изменении состава действий, в любом случае, это будет лучше чем метод с большим количеством строк.
Я бы предложил вам каждый шаг алгоритма выделить в данные, тогда реализация самого алгоритма будет занимать 3-5 строк цикла обработки данных, размер же самих данных в +100500 элементов, никого не смущает.
magicDance(moves) {
for (move: moves) {
move.do();
}
}
И такая реализация, гораздо лучше метода в +100500 строк, теперь входные данные могут быть произвольными, генериться на лету, например во время танца под музыку.
Возможно, это сделано для одностороннего вызова из пользовательского кода в код ядра: например, вы записываете аргументы в системный стек и вызываете программное прерывание — таким образом происходит системный вызов. Обратный же вызов должен быть запрещен — переход от ядра к пользовательскому коду должен быть только по команде reti — возврат из прерывания. Причина тому — возврат из пользовательской функции, который, в таком случае, должен был бы вернуться в ядро, а это плохая идея, поскольку, установка адреса возврата стала бы доступна пользовательскому коду.
Как уже написали выше, присмотритесь к протопотокам о них уже писали тут.
Я могу предложить свою библиотеку для AVR: например, вот модуль i2c, примеры как с ним работать есть тут и тут, а вот очередь.
Мьютекс в статье я не увидел, присмотритесь к конструкции ATOMIC_BLOCK.
Был на премьере. Очень понравилось, действительно круто, особенно для Калуги. Вход был бесплатный, поддержали с друзьями на пожертвованиях ну и плакатики с дисками приобрели :)
Кстати, на премьеру приехали зрители из Москвы, Омска, Мурманска, был приятно удивлен.
Что за странная нелюбовь к динамической индикации? :-)
Прям напрашивается выход ШИМ контроллера завести на вход «Output disable» драйвера и яркость в ваших руках.
Скажите, как качество приема на пассивную антенну в помещении? Сколько времени проходит до корректного приема времени?
Не понял, зачем вам посылки $GNGSA?
В си я бы использовал массив указателей на функции, в C++/Java накидал бы коллекцию различных реализаций интерфейса Move и т.д.
Да, можно вынести во внешние конфиги или описать действия на внешнем DSL, чтобы не пересобирать программу при изменении состава действий, в любом случае, это будет лучше чем метод с большим количеством строк.
Что-то типа:
moves = {'присесть': aMove, 'покудахтать': bMove, 'порычать': mooMove, 'помахать руками': cMove, 'привстать': dMove, 'попрыгать': eMove,…};
magicDance(moves) {
for (move: moves) {
move.do();
}
}
И такая реализация, гораздо лучше метода в +100500 строк, теперь входные данные могут быть произвольными, генериться на лету, например во время танца под музыку.
Я могу предложить свою библиотеку для AVR: например, вот модуль i2c, примеры как с ним работать есть тут и тут, а вот очередь.
Мьютекс в статье я не увидел, присмотритесь к конструкции ATOMIC_BLOCK.
www.ozon.ru/context/detail/id/2851811/
Физика в комиксах! С удовольствием и сейчас бы почитал.
Да, но разве освобождение захваченного спинлока не требует переключения на процесс его захвативший?
Кстати, на премьеру приехали зрители из Москвы, Омска, Мурманска, был приятно удивлен.
Прям напрашивается выход ШИМ контроллера завести на вход «Output disable» драйвера и яркость в ваших руках.
Не понял, зачем вам посылки $GNGSA?