zeleny (09.12.2013 23:33, просмотров: 285) ответил mazur на Только сильно не бейте. Все еще не могу определиться, как мне быть. Вот смотрите, программа в виде карусельки. Многие процессы я вынес из прерываний в основной цикл. Чтобы прерывания максимально быстро обрабатывались.-
- Нет. Большинство т.н. RTOS "любительского уровня" позволяют ожидать _одно_ событие одновременно. Не надо объяснять, что это годится только для "линейных" автоматов (с переходами строго 1->2->3->4...) ? Попытка закодировать сколько-нибудь сложный fk0(104 знак., 10.12.2013 01:27)
- не касаемо прототреадс, а ртос вообще... вот сколько раз вижу этот твой конец света без вэйтформногоевентс и просто понять не могу, что мешает использовать очередь (приоритетную, если нужно)? тем более, как ты сам отмечал, пока событие aoreh(103 знак., 10.12.2013 03:07 - 03:25)
- Если б у бабушки был... А где в protothreads очередь? Нет eё. Такой подход применён в quantim leaps (теперь state-machine.com), когда события записываются в очередь, а после извлекаются и дальше... а дальше имеем ситуацию как в автомате: в fk0(1841 знак., 10.12.2013 09:56 - 09:58)
- Я ж написал "не касаемо прототреадс, а ртос вообще". У тебя это необходимая фишка номер один в любом упоминании и обсуждении любой ртос - aoreh(10.12.2013 10:34)
- Так и есть. Допустим, у нас 4 состояния и есть переходы не только 1->2->3->4, а между любыми состояниями, в зависимости от внешних событий и состояния. Как без "фишки" спрашивается это записать? Вот Зелёный даёт пример: while (1) { if (event)... fk0(171 знак., 10.12.2013 10:50)
- (зевая) От переноса кода этой проверки в супервизор, издержки не уменьшаться - Скрипач(10.12.2013 13:43)
- Нет. Супервизор может быть устроен таким образом, что проверка будет не в цикле, а выполняться вовсе один раз. Вообще-то все нормальные RTOS так устроены, для того вообще-то ОС и нужна. Для этого внутри обычно очереди есть. Не событий, а ожидающих fk0(35 знак., 10.12.2013 13:52)
- Дайте пример. Пусть, для опроса нескольких контактов с гашением дребезга. - Скрипач(10.12.2013 13:57 - 14:02)
- Речь о работе планировщика. Причём здесь контакты? Подробности можно подсмотреть в uCOS, автор книгу написал, там всё есть. - fk0(10.12.2013 14:21)
- Вы рассписываете некий ПРИНЦИП. Покажите его на простом примере. Не почтите за труд, уважьте старика. - Скрипач(10.12.2013 14:27)
- Какой-либо поток ожидает, например события (поступление данных в fifo, семафора, да не важно чего). Есть очередь связанная с событием (внутри ОС). И при вызове функции ожидания ОС помещает поток в эту очередь. Дальше ОС никак не затрагивает поток fk0(972 знак., 10.12.2013 14:40 - 14:42)
- Я, извините, просил показать НА ПРОСТОМ ПРИМЕРЕ. (два входа с дребезгом) В чем экономия переноса опроса входов в ОС? - Скрипач(10.12.2013 14:46)
- Экономия не в переносе входов в ОС, а в другом механизме взаимодействия драйвера клавиатуры и использующих её модулей. - fk0(10.12.2013 14:59)
- :) - Скрипач(10.12.2013 15:03)
- Экономия не в переносе входов в ОС, а в другом механизме взаимодействия драйвера клавиатуры и использующих её модулей. - fk0(10.12.2013 14:59)
- Я, извините, просил показать НА ПРОСТОМ ПРИМЕРЕ. (два входа с дребезгом) В чем экономия переноса опроса входов в ОС? - Скрипач(10.12.2013 14:46)
- Какой-либо поток ожидает, например события (поступление данных в fifo, семафора, да не важно чего). Есть очередь связанная с событием (внутри ОС). И при вызове функции ожидания ОС помещает поток в эту очередь. Дальше ОС никак не затрагивает поток fk0(972 знак., 10.12.2013 14:40 - 14:42)
- Вы рассписываете некий ПРИНЦИП. Покажите его на простом примере. Не почтите за труд, уважьте старика. - Скрипач(10.12.2013 14:27)
- Речь о работе планировщика. Причём здесь контакты? Подробности можно подсмотреть в uCOS, автор книгу написал, там всё есть. - fk0(10.12.2013 14:21)
- Дайте пример. Пусть, для опроса нескольких контактов с гашением дребезга. - Скрипач(10.12.2013 13:57 - 14:02)
- Нет. Супервизор может быть устроен таким образом, что проверка будет не в цикле, а выполняться вовсе один раз. Вообще-то все нормальные RTOS так устроены, для того вообще-то ОС и нужна. Для этого внутри обычно очереди есть. Не событий, а ожидающих fk0(35 знак., 10.12.2013 13:52)
- чем ид евента (или некая дополнительная инфа из него) будет хуже номера сработавшего евента из массива евентов переданного в вэйтфоревентс? - aoreh(10.12.2013 11:04)
- Ничем. Но причём это. Нет возможности одновременно ожидать все нужные события. А есть возможность, например, ожидать только _одно_ событие вообще (хотя обычно два -- часто есть таймаут). Да и не нужна она, возможность эта, наверное. Если fk0(133 знак., 10.12.2013 11:09)
- Притом, что ты в каждой, абсолютно в каждой теме про ртос пишешь, что без этого никуда, я же пытаюсь тебе сказать, что без этого ни чем не хуже, может, иногда, менее удобно, но не хуже. aoreh(184 знак., 10.12.2013 11:14)
- Без механизма ожидания более чем одного события одновременно в принципе невозможно строить некоторые алгоритмы управления, в 10-й раз повторяю. На практическом примере: когда, например, стиральная машина должна остановиться когда сработал датчик fk0(720 знак., 10.12.2013 11:26)
- ...без этого невзможно. При этом речь идет о некоем абстрактном принципе, которым никто (даже заявивший) не пользуется. - Скрипач(10.12.2013 13:46)
- А-ха-ха! А где в стиральной машине батарейка? Да проверяй условия хоть 100500 раз в секунду! Это же стиральная машинка, а не космический корабль! - SciFi(10.12.2013 12:05)
- Вот это -- серьёзный аргумент. - fk0(10.12.2013 13:54)
- Именно так. Я просто напоминаю, что совсем не плохо, когда инструмент адекватен задаче. Кроме того, "преждевременная оптимизация..." - ну, вы помните. Далеко не во всех задачах требуется микропотребление. - SciFi(10.12.2013 14:03)
- даешь по VxWorks-у в каждую стиралку! иначе - никак - aoreh(10.12.2013 14:06)
- LG давно делает компьютеры со встроенным холодильником... - fk0(10.12.2013 14:13)
- no comments... - aoreh(10.12.2013 14:18)
- LG давно делает компьютеры со встроенным холодильником... - fk0(10.12.2013 14:13)
- даешь по VxWorks-у в каждую стиралку! иначе - никак - aoreh(10.12.2013 14:06)
- Именно так. Я просто напоминаю, что совсем не плохо, когда инструмент адекватен задаче. Кроме того, "преждевременная оптимизация..." - ну, вы помните. Далеко не во всех задачах требуется микропотребление. - SciFi(10.12.2013 14:03)
- Вот это -- серьёзный аргумент. - fk0(10.12.2013 13:54)
- О майн гад... Ты вообще разработчик или преподаватель информатики??? Я просто в шоке от этого бреда... - aoreh(10.12.2013 11:32)
- По существу ответить нечего, вопрос исчерпан? Приведи пример для libpthreads (без асинхронных сигналов) или windows (с ожиданием одиночного события), как быть в такой ситуации. Если и приведёшь, то там будет грязный трюк с проверкой "флагов" fk0(246 знак., 10.12.2013 11:47)
- Товарищ наверно под Windows не писал оконную процедуру. - LightElf(10.12.2013 12:39)
- Товарищ различает т.н. Event Object и Message Queue. - fk0(10.12.2013 13:50)
- Замечательно! Может все же укажете алгоритм, который невозможно реализовать в RTOS без WaitForMultipleObjects? - LightElf(10.12.2013 15:27)
- Я не прав. Реализовать можно всё что угодно. Но средства и методы... дописать отсутствующий функционал к оси -- лучший вариант. Остальное выливается в тормозное bloatware. - fk0(10.12.2013 15:44)
- Вопрос об Multiple Events регулярно всплывает в конфе FreeRTOS и регулярно Барри обламывает страждущих. Это просто невозможно реализовать хорошо. Получается связь "многие к многим", что выльется в хождение по спискам внутри критической секции LightElf(96 знак., 10.12.2013 18:42)
- Уже который человек который раз просит тебя привести конкретный алгоритм! Хватит словоблудия. Хотя чем больше ты пишешь, тем больше убеждаюсь, что ты к практике вообще не причастен, давай, признавайся, где и что ты преподаешь? - aoreh(10.12.2013 15:58)
- так он уже дважды приводил, он не умеет обрабатывать клавиатуру, кроме как WaitForMultipleObjects, причем обязательно в нескольких потоках. :))))) - aoreh(10.12.2013 15:42)
- Я не прав. Реализовать можно всё что угодно. Но средства и методы... дописать отсутствующий функционал к оси -- лучший вариант. Остальное выливается в тормозное bloatware. - fk0(10.12.2013 15:44)
- судя по всему, товарищ знает много теории, но не умеет использовать ее на практике... - aoreh(10.12.2013 13:58)
- Замечательно! Может все же укажете алгоритм, который невозможно реализовать в RTOS без WaitForMultipleObjects? - LightElf(10.12.2013 15:27)
- Товарищ различает т.н. Event Object и Message Queue. - fk0(10.12.2013 13:50)
- Еще раз... Ожидание события из очереди, пока там нет событий - спим, появилось - поток просыпается - обрабатывает. В очеред можно поставить событие как по кнопке, так и по датчику, какой еще грязный трюк? - aoreh(10.12.2013 12:00)
- Трюк, опять трюк. В данном случае трюк в том, что нет как такового события специфичного для источника события. Источник событий _должен_ _знать_ _о_ _получателе_ и класть сообщение в его message-box, fifo, очередь, как ни назови. Такой подход fk0(300 знак., 10.12.2013 13:36)
- вариантов решения - масса, никакого трюкачества. Или так - любое программирование - набор трюков - aoreh(10.12.2013 13:52)
- А что мешает оповещать каждый ожидающий поток о событии? Религия? - SciFi(10.12.2013 13:41)
- та можно реализовать события со списками подписчиков, можно ожидать все в одном потоке, в нем отдавать на обработку в нужный, можно вообще, как рекомендуют часто иметь минимум потоков, один - получающий события, и отдающий их на обработку любому aoreh(129 знак., 10.12.2013 13:54)
- Всё это сложные искусственные механизмы призванные исправить очевидный недостаток: невозможность ожидания множества событий в одном потоке. Иными словами говоря -- костыли и подпорки. Ожидать в одном потоке -- та же проблема. Этот волшебный поток fk0(28 знак., 10.12.2013 14:17)
- какая разница на чьей стороне этот костыль? Почему волшебный? что в мэпах и списках волшебного? - aoreh(10.12.2013 14:19)
- Если подразумевается publisher-subscriber pattern, то ничего волшебного кроме того, что излишне избыточно на пустом месте (т.е. вместо легковесного события, просто разблокирующего поток в нормальной ОС, у нас на каждый чих будут сообщения через fk0(121 знак., 10.12.2013 14:26)
- Вдогонку. В более приличных RTOS, вроде TNKernel и других *TRON подобных, в eCOS, в RTEMS... есть event flags, например, для того. В любимой FreeRTOS -- нет. В выросших из unix -- нет (и родные IPC там тем же страдают), но там есть асинхронные fk0(17 знак., 10.12.2013 14:35)
- У FreeRTOS своя специфика. Она очень детерминированная. Хождение по спискам автор обходит любой ценой. EventFlag требует обхода списка переменной длины. - LightElf(10.12.2013 15:36)
- Ооо... уже дошли до того, что никсовые оси то же недооси, с костылями вокруг сигналов? бугагага... - aoreh(10.12.2013 14:38)
- И в догонку, причем тут freeRTOS и кто сказал что она любимая? хотя, думаю, ее можно оочень неплохо использовать в своих нуждах, каждому свое. - aoreh(10.12.2013 14:40)
- uCOS первой версии не имела event flags, потом ввели. Что ещё? В сколько-нибудь "большой" ОС есть какой-либо механизм ожидания множества событий, хоть и примитивный (vs WaitForMultipleEvents из windows). В игрушечных ОС его нет просто потому, что fk0(61 знак., 10.12.2013 14:48)
- бред, а не тезис, нет, что бы не перегружать ос для цпу с минимальными ресурсами не столь сверхнеобходимой вещью, но с другой стороны таже фриртос - в исходниках, добавь туда это, если сильно надо, много времени не займет ни добавление, ни отладка - aoreh(10.12.2013 14:54)
- Вещь принципиально необходимая если алгоритмы управления подразумевают ветвление, а не линейное исполнение 1->2->3->4... Если мы пытаемся попросту имеющийся "не линейный" конечный автомат переписать в рамках такой ОС. Альтернативу мы уже видели fk0(226 знак., 10.12.2013 15:03)
- т.е. ты так считаешь, что реализация внутри ос без оверхида? :)))) - aoreh(10.12.2013 15:26)
- Он может быть существенно меньший, чем подписка на сообщения через fifo или опрос. - fk0(10.12.2013 15:47)
- т.е. ты так считаешь, что реализация внутри ос без оверхида? :)))) - aoreh(10.12.2013 15:26)
- Вещь принципиально необходимая если алгоритмы управления подразумевают ветвление, а не линейное исполнение 1->2->3->4... Если мы пытаемся попросту имеющийся "не линейный" конечный автомат переписать в рамках такой ОС. Альтернативу мы уже видели fk0(226 знак., 10.12.2013 15:03)
- бред, а не тезис, нет, что бы не перегружать ос для цпу с минимальными ресурсами не столь сверхнеобходимой вещью, но с другой стороны таже фриртос - в исходниках, добавь туда это, если сильно надо, много времени не займет ни добавление, ни отладка - aoreh(10.12.2013 14:54)
- uCOS первой версии не имела event flags, потом ввели. Что ещё? В сколько-нибудь "большой" ОС есть какой-либо механизм ожидания множества событий, хоть и примитивный (vs WaitForMultipleEvents из windows). В игрушечных ОС его нет просто потому, что fk0(61 знак., 10.12.2013 14:48)
- И в догонку, причем тут freeRTOS и кто сказал что она любимая? хотя, думаю, ее можно оочень неплохо использовать в своих нуждах, каждому свое. - aoreh(10.12.2013 14:40)
- Вдогонку. В более приличных RTOS, вроде TNKernel и других *TRON подобных, в eCOS, в RTEMS... есть event flags, например, для того. В любимой FreeRTOS -- нет. В выросших из unix -- нет (и родные IPC там тем же страдают), но там есть асинхронные fk0(17 знак., 10.12.2013 14:35)
- Если подразумевается publisher-subscriber pattern, то ничего волшебного кроме того, что излишне избыточно на пустом месте (т.е. вместо легковесного события, просто разблокирующего поток в нормальной ОС, у нас на каждый чих будут сообщения через fk0(121 знак., 10.12.2013 14:26)
- какая разница на чьей стороне этот костыль? Почему волшебный? что в мэпах и списках волшебного? - aoreh(10.12.2013 14:19)
- Всё это сложные искусственные механизмы призванные исправить очевидный недостаток: невозможность ожидания множества событий в одном потоке. Иными словами говоря -- костыли и подпорки. Ожидать в одном потоке -- та же проблема. Этот волшебный поток fk0(28 знак., 10.12.2013 14:17)
- То, что нужно знать о их существовании вообще-то. Т.е. следуя такой логике драйвер клавиатуры должен знать о всех программах, которым захочется получать коды клавиш. - fk0(10.12.2013 13:54)
- не нужно ничего знать в драйвере, не нужно фантазировать - aoreh(10.12.2013 13:57)
- А как быть? Откуда драйвер узнает кому посылать сообщение? Пусть не клавиатура. Пусть датчик воды в стиральной машине. Которым может интересоваться несколько параллельных потоков. Причём в некоторых моделях машины их только 5, а в некоторых все fk0(67 знак., 10.12.2013 14:17)
- а зачем ему знать об этом? - aoreh(10.12.2013 14:18)
- Действительно, какой-то откровенный неадекват попёр. - SciFi(10.12.2013 14:05)
- А как быть? Откуда драйвер узнает кому посылать сообщение? Пусть не клавиатура. Пусть датчик воды в стиральной машине. Которым может интересоваться несколько параллельных потоков. Причём в некоторых моделях машины их только 5, а в некоторых все fk0(67 знак., 10.12.2013 14:17)
- не нужно ничего знать в драйвере, не нужно фантазировать - aoreh(10.12.2013 13:57)
- та можно реализовать события со списками подписчиков, можно ожидать все в одном потоке, в нем отдавать на обработку в нужный, можно вообще, как рекомендуют часто иметь минимум потоков, один - получающий события, и отдающий их на обработку любому aoreh(129 знак., 10.12.2013 13:54)
- Трюк, опять трюк. В данном случае трюк в том, что нет как такового события специфичного для источника события. Источник событий _должен_ _знать_ _о_ _получателе_ и класть сообщение в его message-box, fifo, очередь, как ни назови. Такой подход fk0(300 знак., 10.12.2013 13:36)
- Товарищ наверно под Windows не писал оконную процедуру. - LightElf(10.12.2013 12:39)
- По существу ответить нечего, вопрос исчерпан? Приведи пример для libpthreads (без асинхронных сигналов) или windows (с ожиданием одиночного события), как быть в такой ситуации. Если и приведёшь, то там будет грязный трюк с проверкой "флагов" fk0(246 знак., 10.12.2013 11:47)
- Без механизма ожидания более чем одного события одновременно в принципе невозможно строить некоторые алгоритмы управления, в 10-й раз повторяю. На практическом примере: когда, например, стиральная машина должна остановиться когда сработал датчик fk0(720 знак., 10.12.2013 11:26)
- Притом, что ты в каждой, абсолютно в каждой теме про ртос пишешь, что без этого никуда, я же пытаюсь тебе сказать, что без этого ни чем не хуже, может, иногда, менее удобно, но не хуже. aoreh(184 знак., 10.12.2013 11:14)
- Ничем. Но причём это. Нет возможности одновременно ожидать все нужные события. А есть возможность, например, ожидать только _одно_ событие вообще (хотя обычно два -- часто есть таймаут). Да и не нужна она, возможность эта, наверное. Если fk0(133 знак., 10.12.2013 11:09)
- (зевая) От переноса кода этой проверки в супервизор, издержки не уменьшаться - Скрипач(10.12.2013 13:43)
- Так и есть. Допустим, у нас 4 состояния и есть переходы не только 1->2->3->4, а между любыми состояниями, в зависимости от внешних событий и состояния. Как без "фишки" спрашивается это записать? Вот Зелёный даёт пример: while (1) { if (event)... fk0(171 знак., 10.12.2013 10:50)
- Я ж написал "не касаемо прототреадс, а ртос вообще". У тебя это необходимая фишка номер один в любом упоминании и обсуждении любой ртос - aoreh(10.12.2013 10:34)
- Если б у бабушки был... А где в protothreads очередь? Нет eё. Такой подход применён в quantim leaps (теперь state-machine.com), когда события записываются в очередь, а после извлекаются и дальше... а дальше имеем ситуацию как в автомате: в fk0(1841 знак., 10.12.2013 09:56 - 09:58)
- объясните почему в том же PT нельзя ожидать несколько событий одновременно ? На счет переходов тоже непонятно - в задачах доступны все условные операторы и циклы, то есть реализуются не только линейные переходы 1>2>3>4, а алгоритмы любой zeleny(104 знак., 10.12.2013 01:49 - 01:52)
- Пойдём от противного. Напишите код, как ожидать два события одновременно. Если WAIT позволяет что-то одно. Написать цикл с проверкой всех событий и таймером, чтоб не сожрать 146% CPU? А линейность возникает автоматически в силу невозможности fk0(155 знак., 10.12.2013 01:53)
- не вижу препятствий почему нельзя написать PT_WAIT_UNTIL(pt, ((val1==1)||(val2==2))). - zeleny(10.12.2013 02:04)
- Можно. Только потом придётся ещё раз написать эти условия поодиночке: if (....), if (...) и не забыть записать то же самое в PT_WAIT... -- пришли к тому же автоматному программированию, но любая мелкая ошибка теперь доставляет массу часов отладки. - fk0(10.12.2013 02:34)
- и что ? на большинстве контроллеров проверка - меньше микросекунды. - zeleny(10.12.2013 02:47)
- И то, что сверху можно написать одно, а ниже другое. И получить замечательный глюкодром. Классика жанра: не храни одну вещь в двух переменных (не записывай одно условие два раза подряд). - fk0(10.12.2013 02:48)
- И главный вопрос тут: и зачем? Если в switch-технологии те же самые условия точно также записываются, но один раз (PT_WAIT... просто не записывается, т.к. не нужен). - fk0(10.12.2013 02:49)
- напр.можно так: zeleny(177 знак., 10.12.2013 03:12)
- пример волшебного switch-кода можно ? как подождать и обработать 2 условия. - zeleny(10.12.2013 02:58)
- "Подождать" -- это третье условие: fk0(383 знак., 10.12.2013 10:07)
- И главный вопрос тут: и зачем? Если в switch-технологии те же самые условия точно также записываются, но один раз (PT_WAIT... просто не записывается, т.к. не нужен). - fk0(10.12.2013 02:49)
- И то, что сверху можно написать одно, а ниже другое. И получить замечательный глюкодром. Классика жанра: не храни одну вещь в двух переменных (не записывай одно условие два раза подряд). - fk0(10.12.2013 02:48)
- и что ? на большинстве контроллеров проверка - меньше микросекунды. - zeleny(10.12.2013 02:47)
- Можно. Только потом придётся ещё раз написать эти условия поодиночке: if (....), if (...) и не забыть записать то же самое в PT_WAIT... -- пришли к тому же автоматному программированию, но любая мелкая ошибка теперь доставляет массу часов отладки. - fk0(10.12.2013 02:34)
- не вижу препятствий почему нельзя написать PT_WAIT_UNTIL(pt, ((val1==1)||(val2==2))). - zeleny(10.12.2013 02:04)
- Пойдём от противного. Напишите код, как ожидать два события одновременно. Если WAIT позволяет что-то одно. Написать цикл с проверкой всех событий и таймером, чтоб не сожрать 146% CPU? А линейность возникает автоматически в силу невозможности fk0(155 знак., 10.12.2013 01:53)
- не касаемо прототреадс, а ртос вообще... вот сколько раз вижу этот твой конец света без вэйтформногоевентс и просто понять не могу, что мешает использовать очередь (приоритетную, если нужно)? тем более, как ты сам отмечал, пока событие aoreh(103 знак., 10.12.2013 03:07 - 03:25)
- Покажите мне свои примеры с prototreads. - Mazur(09.12.2013 23:41)
- Prototreads те же автоматы. Смысл их использовать? - Mazur(09.12.2013 23:36)
- в PT задачи могут включать любые вложенные циклы и условия. На автоматах без сложного жонглирования состояниями и разворота циклов такое сделать можно, но выглядеть будет нечитаемо. zeleny(261 знак., 16.12.2013 16:56)
- У Шалыто есть понятие "вложенного автомата" (в состояние). А у тебя ключевое слово -- static. - fk0(16.12.2013 18:10)
- смысл в том что код чище, исходник не зас"рается бесконечными проверками текущего состояния, код получается короче - zeleny(09.12.2013 23:38)
- В switch-технологии только _один_ switch всего. Какие бесконечные проверки? Я даже больше скажу. В protothreads используется тот же switch и та же переменная состояния, только это спрятано в макросах. Только код состояния -- это __LINE__. - fk0(10.12.2013 01:30)
- -> - Mazur(09.12.2013 23:41, ссылка)
- Линейный код: он интуитивно понятный. Наш товарищ в будёновке его поносит как может, но это его личные тараканы. - SciFi(09.12.2013 23:38)
- Не всегда код может быть линейный. Если он изначально не линейный -- что делать, спрашивается? Если есть, например, 4 состояния и переходы из любого в любое с разными условиями. Как это в protothreads запрограммировать? Программируем маленький fk0(79 знак., 10.12.2013 01:32)
- Мы тут не космический корабль делаем, а осваиваем азы программирования. Не надо нас путать, мы и сами запутаемся :-) - SciFi(10.12.2013 09:01)
- А я то не про космический корабль, а про контроллер стиральной машины, например. Чтоб луж на полу потом не оставлял. Как программировать -- дело десятое. Нужно вначале понять, что до программирования нужна какая-то стадия проектирования алгоритмов fk0(761 знак., 10.12.2013 10:13)
- Ладно, отвечу иначе. "Не всегда код может быть линейный" - нет, не всегда, но очень-очень часто. Так что не надо катить бочку на годный инструмент (это protothreads, есличо). - SciFi(10.12.2013 10:28)
- Protothreads -- специнструмент ограниченно-годный для одного очень узкого случая. Просто у некоторых мышление такое же линейно-императивное. За слова о том, что программа -- _последовательность_ инструкций -- точно сжигать нужно. За fk0(1211 знак., 10.12.2013 10:46)
- Да-да. Персену :-) - SciFi(10.12.2013 10:51)
- Protothreads -- специнструмент ограниченно-годный для одного очень узкого случая. Просто у некоторых мышление такое же линейно-императивное. За слова о том, что программа -- _последовательность_ инструкций -- точно сжигать нужно. За fk0(1211 знак., 10.12.2013 10:46)
- Ладно, отвечу иначе. "Не всегда код может быть линейный" - нет, не всегда, но очень-очень часто. Так что не надо катить бочку на годный инструмент (это protothreads, есличо). - SciFi(10.12.2013 10:28)
- А я то не про космический корабль, а про контроллер стиральной машины, например. Чтоб луж на полу потом не оставлял. Как программировать -- дело десятое. Нужно вначале понять, что до программирования нужна какая-то стадия проектирования алгоритмов fk0(761 знак., 10.12.2013 10:13)
- Мы тут не космический корабль делаем, а осваиваем азы программирования. Не надо нас путать, мы и сами запутаемся :-) - SciFi(10.12.2013 09:01)
- -> - Mazur(09.12.2013 23:42, ссылка)
- Не всегда код может быть линейный. Если он изначально не линейный -- что делать, спрашивается? Если есть, например, 4 состояния и переходы из любого в любое с разными условиями. Как это в protothreads запрограммировать? Программируем маленький fk0(79 знак., 10.12.2013 01:32)
- в PT задачи могут включать любые вложенные циклы и условия. На автоматах без сложного жонглирования состояниями и разворота циклов такое сделать можно, но выглядеть будет нечитаемо. zeleny(261 знак., 16.12.2013 16:56)
- Нет. Большинство т.н. RTOS "любительского уровня" позволяют ожидать _одно_ событие одновременно. Не надо объяснять, что это годится только для "линейных" автоматов (с переходами строго 1->2->3->4...) ? Попытка закодировать сколько-нибудь сложный fk0(104 знак., 10.12.2013 01:27)