а что за способы? Опрашивать его реже? Тоже не очень хорошо...
Тут много зависит от возможности библиотеки. Варианты.
1. Настроить ds18b20 на менее "кровожадный" режим. 750мс это для выдачи 12бит точности, т.е. 0.0625°C при том что сам датчик брешет 0,5°C. Загрубив выдачу до 0,25°C ничего не теряете а 750мс превращаются в 200мс. а загрубив до 0,5°C - 100мс. Этого должно хватит. Даже если эта либа не умеет настроить датчик, сделайте любой другой, настройка энергонезависима.
2. В совсем кривых либах получение температуры одной командой, здесь их две, это дает надежду, что если не делать эти вызовы подряд, а с паузой более 750мс то они отработают быстро. Тогда надо перестроить луп с учетом этих знаний.
3. Поменять либу на соответствующую требованиям п.2
4. Почитать описание датчика и реализовать работу с ним в скетче в два этапа- старт преобразования и получение результата спустя 750мс. А между ними - обычная работа в лупе или минимум- опрос кнопки.
Краткие сигналы, типа однократного нажатия кнопок всегда надо обрабатывать из прерывания. Даже при очень быстром выполнении всего остального по закону Мэрфи кнопка нажмётся именно в тот момент, когда процессор занят чем-то другим.
Процесор - не толчек, чем-то занят не может быть. Он чем-то другим кроме выполнения команд програмы не занимается. Организовать эти команды правильно и требуется. Краткий сигнал - это пролет релятивистского электрона вблизи атома. Нажатие кнопки - очени быстрое, т.е. специально постаратся - порядка 100мс. Для МК - целая вечность, порядка 100000команд. Мэрфи - к черту! Он плохой алгоритмист.
ЕвгенийП пишет:
.. прерывании не делаются никакие принтмэйны. Там надо просто взвести флажок, что было нажатие, а в loop этот флажок проверять. Разница в том, что он никуда не денется в отличие от кнопки, которая к моменту проверки может быть уже отжата. Флажок спокойно дождётся обработки.
Ваши ходы прощитаны. Читайте внимательней. Цитирую "то между нажатием кнопки и появлением меню пройдет неприятная пауза,"
ЕвгенийП пишет:
Это и есть причина - кнопка может быть нажата в момент, когда процессор занят, неважно насколько быстро от там всё делает.
Причина - это пауза 750мс в глубине либы. В её время процессор не делает то, что должен. Он тратит свою производительность, за которую ТС заплатил между прочим деньги, в пустую. Из-за того что автор либы дол.еб. Возможно. Если не предусмотрел такое.
ЕвгенийП пишет:
С краткосрочными сигналами - только прерывание.
Да. Только краткие сигналы не меряют в секундах и милисекундах. Краткие для МК и для Вас - две большие разницы. Вы ориентируетесь на свои пальцевые реакции, а не на скорость обработки МК. Хотя возможно Вы просто предпочитаете длинные лупы по 10сек на проход, делеи по 100мс, кривые либы ожидающие в блокирующих вызовах с моря погоды и теплое пиво. Я - нет.
Хотя возможно Вы просто предпочитаете длинные лупы по 10сек на проход, делеи по 100мс, кривые либы ожидающие в блокирующих вызовах с моря погоды и теплое пиво. Я - нет.
Даже если в процессоре 198 ядер - он будет выполнять то что ему задано программой.
Язык Си не есть среда ОСРВ. На языке Си - который используется для программирования ардуино - не имеет функций распаралеливания процессов по несколким ядрам.
Соответсвтвенно вопрос теряет смысл - т.к. организовать реальную мультизадачность на искомом железе с искомым софтом просто НЕВОЗМОЖНО. Для этого нужно использовать многоядерные процы в комплекте со средой разработки обеспечивающей эти функции. Т.к. это будут совсем другие деньги - далее не продолжаю.
Максимум что можно получить - режим псевдо-многозадачности по аналогии с ДОС - резидентные программы/функции на прерывании, которые будут работать даже в делае и цикле. Собственно для наших основных задач этого должно хватить выше крыши. Нужно только разобраться с прерываниями и и х использованием. Я пока не занимался т.к. нет необходимости...
Даже если в процессоре 198 ядер - он будет выполнять то что ему задано программой.
Ну дак это основная аксиома ИТ!!
at0mix пишет:
Язык Си не есть среда ОСРВ. На языке Си - который используется для программирования ардуино - не имеет функций распаралеливания процессов по несколким ядрам.
Язык - он и есть язык, средство обеспечивающее написания исполняемой программ на понятном челу языке. Не ОСРВ, даже не ОС вообще. Были языки обеспечивающие распаралеливание сами - вечная им память. В С пробовали делали расширения - не прижилось. Слишком платформенозависимая штука.
at0mix пишет:
Соответсвтвенно вопрос теряет смысл - т.к. организовать реальную мультизадачность на искомом железе с искомым софтом просто НЕВОЗМОЖНО. Для этого нужно использовать многоядерные процы в комплекте со средой разработки обеспечивающей эти функции. Т.к. это будут совсем другие деньги - далее не продолжаю.
Та ладно, многоядерные процессоры появились намного позже многозадачных ОС. Обходились как-то. Если хотите - считайте псевдо. От этого суть не меняется. И не путайте потоки (процессы) и задачи. Хоть мультипотоки (Вы их наверно "псевдо" считаете, т.к. ядро одно - так пожалуйста, на i386 они тоже тогда "псевдо" т.к. ядро одно, но обшепринятое название без "псевдо", это как бы подразумевается) для ардуино есть, выше ссылка на rtos. От них мало толка, интересна именно мультизадачность, в утилитарном смысле, т.е. задача1 - робот крутит колеса задача2-робот измеряет расстояния,... Еще пока задачи независимые, то не интересно, а вот когда начинают пересекатся, обе выводят на экран каждая - свое. Тогда и прерывания и потоки нервно курят, нужна синхронизация. А вот конечныйавтомат - тут проще.
at0mix пишет:
Максимум что можно получить - режим псевдо-многозадачности по аналогии с ДОС - резидентные программы/функции на прерывании, которые будут работать даже в делае и цикле.
Вы в курсе, что из прерываний ДОС очень многие функции недоступны. А ардуино нечто похожее. Если бы хвататло.
at0mix пишет:
Собственно для наших основных задач этого должно хватить выше крыши. Нужно только разобраться с прерываниями и и х использованием. Я пока не занимался т.к. нет необходимости...
Годятся для простых и быстрых действий. В этом их назначение.
Logic вы спорте ради спора. В том, что программу надо организовывать с умом, сомнений нет, но в том, обработка кнопок должна делаться именно в прерывании - тоже общеинжнерная аксиома. Так что вы оба правы, просто говорите о разных аспектах проблемы, а срётесь как дети. Нафига?
обработка кнопок должна делаться именно в прерывании - тоже общеинжнерная аксиома.
Ну? А дальше? Типа там.... " потому что..." или "вот здесь написано..." или "вот здесь Вы неправы". Хоть какая аргументация у Вас должна быть. А так прийти кучку отложить дело не хитрое. Вы еще сюда - http://arduino.ru/forum/programmirovanie/klass-titanovyi-velosiped-dlya-taktovoi-knopki зайдите, они там Вашу аксиому на 5 страницах в хвост и гриву. Изложите её там, порадуйте Клапауций-я )))
Ворота пишет:
Так что вы оба правы, просто говорите о разных аспектах проблемы, а срётесь как дети. Нафига?
Нет, тут не про аспекты, а про подходы к решению проблемы. Устранять причины (тормозню при работе с датчиком) или боротся с последствиями, что в свою очередь создаст новые проблемы (нажатие кнопки не теряются, но на дисплей отрисует с паузой до 750мс) . У себя в коде каждый может может делать как захочет - его проблемы. Но прежде чем чего советовать в теме полезно её прочитать и подумать о том негативе, который несет то или иное предлагаемое решение. Это к вопросу про "Нафига". Я дальнейшего смысла обсуждать чего, здесь не вижу. По крайней мере до получения от Вас подтверждения "аксиомности" и разяснения как поступать если нажатие кнопки в прерывании зафиксировано в флаге, а луп как раз влез в работу с датчиком и вылезет через 750мс. А то знаете ... не мешки ворочать.
обработка кнопок должна делаться именно в прерывании - тоже общеинжнерная аксиома.
Ну? А дальше? Типа там.... " потому что..." или "вот здесь написано..." или "вот здесь Вы неправы". Хоть какая аргументация у Вас должна быть. А так прийти кучку отложить дело не хитрое. Вы еще сюда - http://arduino.ru/forum/programmirovanie/klass-titanovyi-velosiped-dlya-taktovoi-knopki зайдите, они там Вашу аксиому на 5 страницах в хвост и гриву. Изложите её там, порадуйте Клапауций-я )))
нет уж - пусть здесь обоснует свою аксиому, зачем в интерфейсе человек-машина требуется пользовать прерывания.
Logik, мне кажется, что вы излишне эмоционально воспринимаете посты людей с заниженным ЧСВ .. такие всегда есть, стоит ли?
В целом поддержу. Тоже не вижу причин делать обработку кнопок на прерываниях .. хотя-бы в силу "дребезга контактов" .. чисто из инженерных побуждений. Ну и верно то, что это никак не "быстрый" процесс даже для атмеловских МК.
Конкретно данный скетч (и тут я с вами тоже согласен), имхо явно нуждается в правильной библиотеке работы с датчиком и соотественно иной организации основного цикла loop(). Всё, больше тут ничего не требуется.
По самому вопросу многозадачности:
1. в Ардуино, есть кооперативная многозадачность, реализуемая макросом everyMillis() .. его более чем достаточно.
2. Достаточно несложно, слегка доработав обработчик таймера времени, организовать запуск процессов в заданное время из под обработчика таймера, и даже не выключая оный. В arhat.h именно так и доработан таймер времени.
3. Многопоточная работа с вытесняющей многозадачностью - отсутствует в силу наличия только одного ядра, да и нафиг никому не нужна тут. МК "Ардуино", да и Атмелы в целом под это НЕ ПРЕДНАЗНАЧЕНЫ. Насколько стоит ли собирать космический спутник из говна и палок? :)
Logik, мне кажется, что вы излишне эмоционально воспринимаете посты людей с заниженным ЧСВ .. такие всегда есть, стоит ли?
В целом поддержу. Тоже не вижу причин делать обработку кнопок на прерываниях .. хотя-бы в силу "дребезга контактов" .. чисто из инженерных побуждений. Ну и верно то, что это никак не "быстрый" процесс даже для атмеловских МК.
Конкретно данный скетч (и тут я с вами тоже согласен), имхо явно нуждается в правильной библиотеке работы с датчиком и соотественно иной организации основного цикла loop(). Всё, больше тут ничего не требуется.
По самому вопросу многозадачности:
1. в Ардуино, есть кооперативная многозадачность, реализуемая макросом everyMillis() .. его более чем достаточно.
2. Достаточно несложно, слегка доработав обработчик таймера времени, организовать запуск процессов в заданное время из под обработчика таймера, и даже не выключая оный. В arhat.h именно так и доработан таймер времени.
3. Многопоточная работа с вытесняющей многозадачностью - отсутствует в силу наличия только одного ядра, да и нафиг никому не нужна тут. МК "Ардуино", да и Атмелы в целом под это НЕ ПРЕДНАЗНАЧЕНЫ. Насколько стоит ли собирать космический спутник из говна и палок? :)
Только по прерыванию необходимо HID устройства обрабатывать. Пользователь может раз в год кнопку нажимать - зачем её постоянно опрашивать тратить на неё ресурсы? шуметь в эфире гармониками? Ведь опрашивание, это чаще всего не просто чтение состояния ноги, эта нога может быть на расширительном регистре защёлке, например, в который надо слазить для чтения.
В аврках не приянто использовать шину, потому все хотят читать сигналы прямиком, а это ограничивает возможности очень сильно.
Обработка прерываний может быть двух типов:
1. Выполнить чтение состояния в самом обработчики и, возможно, какие-то ответные действия. Например, кнопка аварии может тут же выходы сбросить.
2. Установить флаг доступности данных для чтения, который проверяется в основном цикле и обрабатывается там же. Возможно, тут же чтение в локальный буфер.
Теперь о многозадачности. В АВР нет и не может быть многозадачности. Многозадачность, это когда выполнимые процессы работают линейно непрерывно, не подозревая о работе параллельных. Когда в любом процессе запросто можно длинный цикл шуранить и никого из соседей это не затормозит. В АВР же каждый процесс должен сам заботится о шаговом своём выполнении. Можно сделать карусель, можно даже прервывать в этой карусели процессы, давая им таймслоты, но это не многозадачность. Нету у АВР инструкций переключения между процессами. Поточно-шаговое оно. Т.ч. эммуляция, впрочем, для задачь АВР, вполне достаточная, ибо оно не не для HID предназначено. :)
Эй, хохол! Ты чё седня злой такой, опять печеньку не завели? Лучше бы подсказал что с ошибкой линкера делать .. как раз вопрос по RTOS хотел порешать.. :)
Эй, хохол! Ты чё седня злой такой, опять печеньку не завели? Лучше бы подсказал что с ошибкой линкера делать .. как раз вопрос по RTOS хотел порешать.. :)
а что за способы? Опрашивать его реже? Тоже не очень хорошо...
Тут много зависит от возможности библиотеки. Варианты.
1. Настроить ds18b20 на менее "кровожадный" режим. 750мс это для выдачи 12бит точности, т.е. 0.0625°C при том что сам датчик брешет 0,5°C. Загрубив выдачу до 0,25°C ничего не теряете а 750мс превращаются в 200мс. а загрубив до 0,5°C - 100мс. Этого должно хватит. Даже если эта либа не умеет настроить датчик, сделайте любой другой, настройка энергонезависима.
2. В совсем кривых либах получение температуры одной командой, здесь их две, это дает надежду, что если не делать эти вызовы подряд, а с паузой более 750мс то они отработают быстро. Тогда надо перестроить луп с учетом этих знаний.
3. Поменять либу на соответствующую требованиям п.2
4. Почитать описание датчика и реализовать работу с ним в скетче в два этапа- старт преобразования и получение результата спустя 750мс. А между ними - обычная работа в лупе или минимум- опрос кнопки.
Краткие сигналы, типа однократного нажатия кнопок всегда надо обрабатывать из прерывания. Даже при очень быстром выполнении всего остального по закону Мэрфи кнопка нажмётся именно в тот момент, когда процессор занят чем-то другим.
Процесор - не толчек, чем-то занят не может быть. Он чем-то другим кроме выполнения команд програмы не занимается. Организовать эти команды правильно и требуется. Краткий сигнал - это пролет релятивистского электрона вблизи атома. Нажатие кнопки - очени быстрое, т.е. специально постаратся - порядка 100мс. Для МК - целая вечность, порядка 100000команд. Мэрфи - к черту! Он плохой алгоритмист.
.. прерывании не делаются никакие принтмэйны. Там надо просто взвести флажок, что было нажатие, а в loop этот флажок проверять. Разница в том, что он никуда не денется в отличие от кнопки, которая к моменту проверки может быть уже отжата. Флажок спокойно дождётся обработки.
Ваши ходы прощитаны. Читайте внимательней. Цитирую "то между нажатием кнопки и появлением меню пройдет неприятная пауза,"
Это и есть причина - кнопка может быть нажата в момент, когда процессор занят, неважно насколько быстро от там всё делает.
Причина - это пауза 750мс в глубине либы. В её время процессор не делает то, что должен. Он тратит свою производительность, за которую ТС заплатил между прочим деньги, в пустую. Из-за того что автор либы дол.еб. Возможно. Если не предусмотрел такое.
С краткосрочными сигналами - только прерывание.
Да. Только краткие сигналы не меряют в секундах и милисекундах. Краткие для МК и для Вас - две большие разницы. Вы ориентируетесь на свои пальцевые реакции, а не на скорость обработки МК. Хотя возможно Вы просто предпочитаете длинные лупы по 10сек на проход, делеи по 100мс, кривые либы ожидающие в блокирующих вызовах с моря погоды и теплое пиво. Я - нет.
Тема вывода на экран из многозадачного приложения не раскрыта!
// значение t сам напечатаешь в индикатор.#12
Процесор - не толчек, ....
Хотя возможно Вы просто предпочитаете длинные лупы по 10сек на проход, делеи по 100мс, кривые либы ожидающие в блокирующих вызовах с моря погоды и теплое пиво. Я - нет.
А, ну тогда ладно, я понял :)
Мэрфи - к черту! Он плохой алгоритмист.
Да, конечно, Вы - хороший :)
Это чудесно, что мы пришли к единому выводу по сути вопроса!
Даже если в процессоре 198 ядер - он будет выполнять то что ему задано программой.
Язык Си не есть среда ОСРВ. На языке Си - который используется для программирования ардуино - не имеет функций распаралеливания процессов по несколким ядрам.
Соответсвтвенно вопрос теряет смысл - т.к. организовать реальную мультизадачность на искомом железе с искомым софтом просто НЕВОЗМОЖНО. Для этого нужно использовать многоядерные процы в комплекте со средой разработки обеспечивающей эти функции. Т.к. это будут совсем другие деньги - далее не продолжаю.
Максимум что можно получить - режим псевдо-многозадачности по аналогии с ДОС - резидентные программы/функции на прерывании, которые будут работать даже в делае и цикле. Собственно для наших основных задач этого должно хватить выше крыши. Нужно только разобраться с прерываниями и и х использованием. Я пока не занимался т.к. нет необходимости...
Даже если в процессоре 198 ядер - он будет выполнять то что ему задано программой.
Ну дак это основная аксиома ИТ!!
Язык Си не есть среда ОСРВ. На языке Си - который используется для программирования ардуино - не имеет функций распаралеливания процессов по несколким ядрам.
Язык - он и есть язык, средство обеспечивающее написания исполняемой программ на понятном челу языке. Не ОСРВ, даже не ОС вообще. Были языки обеспечивающие распаралеливание сами - вечная им память. В С пробовали делали расширения - не прижилось. Слишком платформенозависимая штука.
Та ладно, многоядерные процессоры появились намного позже многозадачных ОС. Обходились как-то. Если хотите - считайте псевдо. От этого суть не меняется. И не путайте потоки (процессы) и задачи. Хоть мультипотоки (Вы их наверно "псевдо" считаете, т.к. ядро одно - так пожалуйста, на i386 они тоже тогда "псевдо" т.к. ядро одно, но обшепринятое название без "псевдо", это как бы подразумевается) для ардуино есть, выше ссылка на rtos. От них мало толка, интересна именно мультизадачность, в утилитарном смысле, т.е. задача1 - робот крутит колеса задача2-робот измеряет расстояния,... Еще пока задачи независимые, то не интересно, а вот когда начинают пересекатся, обе выводят на экран каждая - свое. Тогда и прерывания и потоки нервно курят, нужна синхронизация. А вот конечныйавтомат - тут проще.
Максимум что можно получить - режим псевдо-многозадачности по аналогии с ДОС - резидентные программы/функции на прерывании, которые будут работать даже в делае и цикле.
Вы в курсе, что из прерываний ДОС очень многие функции недоступны. А ардуино нечто похожее. Если бы хвататло.
Собственно для наших основных задач этого должно хватить выше крыши. Нужно только разобраться с прерываниями и и х использованием. Я пока не занимался т.к. нет необходимости...
Годятся для простых и быстрых действий. В этом их назначение.
Logic вы спорте ради спора. В том, что программу надо организовывать с умом, сомнений нет, но в том, обработка кнопок должна делаться именно в прерывании - тоже общеинжнерная аксиома. Так что вы оба правы, просто говорите о разных аспектах проблемы, а срётесь как дети. Нафига?
нет уж - пусть здесь обоснует свою аксиому, зачем в интерфейсе человек-машина требуется пользовать прерывания.
Ну пожалуй да. Дабы не смущать там умы неофитов, сюда они не так захаживают. Токо недождемся мы ни тут, ни там...
Logik, мне кажется, что вы излишне эмоционально воспринимаете посты людей с заниженным ЧСВ .. такие всегда есть, стоит ли?
В целом поддержу. Тоже не вижу причин делать обработку кнопок на прерываниях .. хотя-бы в силу "дребезга контактов" .. чисто из инженерных побуждений. Ну и верно то, что это никак не "быстрый" процесс даже для атмеловских МК.
Конкретно данный скетч (и тут я с вами тоже согласен), имхо явно нуждается в правильной библиотеке работы с датчиком и соотественно иной организации основного цикла loop(). Всё, больше тут ничего не требуется.
По самому вопросу многозадачности:
1. в Ардуино, есть кооперативная многозадачность, реализуемая макросом everyMillis() .. его более чем достаточно.
2. Достаточно несложно, слегка доработав обработчик таймера времени, организовать запуск процессов в заданное время из под обработчика таймера, и даже не выключая оный. В arhat.h именно так и доработан таймер времени.
3. Многопоточная работа с вытесняющей многозадачностью - отсутствует в силу наличия только одного ядра, да и нафиг никому не нужна тут. МК "Ардуино", да и Атмелы в целом под это НЕ ПРЕДНАЗНАЧЕНЫ. Насколько стоит ли собирать космический спутник из говна и палок? :)
Logik, мне кажется, что вы излишне эмоционально воспринимаете посты людей с заниженным ЧСВ .. такие всегда есть, стоит ли?
В целом поддержу. Тоже не вижу причин делать обработку кнопок на прерываниях .. хотя-бы в силу "дребезга контактов" .. чисто из инженерных побуждений. Ну и верно то, что это никак не "быстрый" процесс даже для атмеловских МК.
Конкретно данный скетч (и тут я с вами тоже согласен), имхо явно нуждается в правильной библиотеке работы с датчиком и соотественно иной организации основного цикла loop(). Всё, больше тут ничего не требуется.
По самому вопросу многозадачности:
1. в Ардуино, есть кооперативная многозадачность, реализуемая макросом everyMillis() .. его более чем достаточно.
2. Достаточно несложно, слегка доработав обработчик таймера времени, организовать запуск процессов в заданное время из под обработчика таймера, и даже не выключая оный. В arhat.h именно так и доработан таймер времени.
3. Многопоточная работа с вытесняющей многозадачностью - отсутствует в силу наличия только одного ядра, да и нафиг никому не нужна тут. МК "Ардуино", да и Атмелы в целом под это НЕ ПРЕДНАЗНАЧЕНЫ. Насколько стоит ли собирать космический спутник из говна и палок? :)
Только по прерыванию необходимо HID устройства обрабатывать. Пользователь может раз в год кнопку нажимать - зачем её постоянно опрашивать тратить на неё ресурсы? шуметь в эфире гармониками? Ведь опрашивание, это чаще всего не просто чтение состояния ноги, эта нога может быть на расширительном регистре защёлке, например, в который надо слазить для чтения.
В аврках не приянто использовать шину, потому все хотят читать сигналы прямиком, а это ограничивает возможности очень сильно.
Обработка прерываний может быть двух типов:
1. Выполнить чтение состояния в самом обработчики и, возможно, какие-то ответные действия. Например, кнопка аварии может тут же выходы сбросить.
2. Установить флаг доступности данных для чтения, который проверяется в основном цикле и обрабатывается там же. Возможно, тут же чтение в локальный буфер.
Теперь о многозадачности. В АВР нет и не может быть многозадачности. Многозадачность, это когда выполнимые процессы работают линейно непрерывно, не подозревая о работе параллельных. Когда в любом процессе запросто можно длинный цикл шуранить и никого из соседей это не затормозит. В АВР же каждый процесс должен сам заботится о шаговом своём выполнении. Можно сделать карусель, можно даже прервывать в этой карусели процессы, давая им таймслоты, но это не многозадачность. Нету у АВР инструкций переключения между процессами. Поточно-шаговое оно. Т.ч. эммуляция, впрочем, для задачь АВР, вполне достаточная, ибо оно не не для HID предназначено. :)
Извини, друг, я ошибся.
А на топик полу ... скорее четвертьграмотного бандерлога сам ходи. Там как раз самое место квалификацию повышать
Ворота, переведи с бурятского на русский, что ты имел ввиду??
Зачем? Один хрен не поймёшь. Ты лучше это, не отвлекайся, изобретай велосипеды, да по майдану скачи.
Как разблокировать эту кнопку?
Больше одного раза не нажимается.
Как разблокировать эту кнопку?
Больше одного раза не нажимается.
приглашаешь своих друзей - русофобов, фашистов, массонов, пиндосов, жыдов, пр. врагов балалаек, берёзок и снигирей и просишь их нажать на кнопку.
*один раз я сам себя заплюсовал - Слава ватным атминам!
Молодец!
Можешь бежать к Хозяину за печенькой. Заработал. Я подтвержу, если что. Тока хвостом повилять не забудь, а то не даст.
Эй, хохол! Ты чё седня злой такой, опять печеньку не завели? Лучше бы подсказал что с ошибкой линкера делать .. как раз вопрос по RTOS хотел порешать.. :)
Эй, хохол! Ты чё седня злой такой, опять печеньку не завели? Лучше бы подсказал что с ошибкой линкера делать .. как раз вопрос по RTOS хотел порешать.. :)
муслим, тут православный базар. ходи мимо.
некогда мне за печеньками бегать - русскоязычных мальчиков нераспятый край.
То есть не знаешь нифига .. ладно, понял - отстал.