Embedded OS

Do you have a question? Post it now! No Registration Necessary

Threaded View
Мне нужно написать одну задачу, в которой некоторые подзадачи будут
выполняться одновременно. Писать буду на Меге64.
Подскажите, где можно взять заготовку под многозадачную ОС, которую
можно было бы скомпилить в мегу64 и к ней пристегивать пользовательские
задачи. Чтобы ОС обеспечивала их одновременную работу согласно заданным
приоритетам.
Читал про embedded Linux, но все, что мне попадалось - это уже готовая
аппаратная платформа, которую можно использовать в своих задачах, а мне
нужно использовать полностью свое железо. Ну и желательно компилить ОС
непосредственно под свою конфигурацию.
--
Александр
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru

Re: Embedded OS
Hello Александр.

 АД> Мне нужно написать одну задачу, в которой некоторые подзадачи будут
 АД> выполняться одновременно. Писать буду на Меге64.
 АД> Подскажите, где можно взять заготовку под многозадачную ОС, которую
 АД> можно было бы скомпилить в мегу64 и к ней пристегивать

возможно, http://www.ethernut.de
правда, под atmega128. но может, поможет...

tony


Re: Embedded OS
TF> возможно, http://www.ethernut.de
TF> правда, под atmega128. но может, поможет...

Спасибо, очень интересно.

--
Александр
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru

Re: Embedded OS
Tue Mar 08 2005 15:41, Александр Денисов wrote to Tony Feldman:

 TF>> возможно, http://www.ethernut.de
 TF>> правда, под atmega128. но может, поможет...

Для embedded приложений неплохо подходит ucos-ii,
www.ucos-ii.com, но для именно atmega128 она может оказаться тяжеловата,
контекст у AVR все же относительно большой, а объемы встроенной RAM
как раз не очень велики.
Если еще ОС от Harry Zhurov, более оптимизированная под мелкие uC, думаю
завтра он даст ссылку.

wbr, Andy


Embedded OS
Привет, Александр !



АД>> Мне нужно написать одну задачу, в которой некоторые подзадачи
*|>> будут выполняться одновременно. Писать буду на
*|>> Меге64. Подскажите, где можно взять заготовку под многозадачную
*|>> ОС, которую можно было бы скомпилить в мегу64 и к ней
*|>> пристегивать

tf> возможно, http://www.ethernut.de
tf> правда, под atmega128. но может, поможет...

Еще есть юкос (ucos) и ucLinux. Возможно они подойдут для этой задачи, но "сам
я плотник"(ц), так что могу и ошибиться.

.                                            С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev
... сфера Шварцшильда-Дайсона

Re: Embedded OS
       Доброго здоровья, Harry!

11 Mar 05 12:16, Harry Zhurov написал для Sergei Tuchinski:

 AB>>>> И что - перекомпилировал иаровскую библиотеку?

 HZ>>>     Hу да. А че такого? Сорцы там прилагаются, даже батник ихний. Ключи
 HZ>>>     только
 HZ>>> подставляй и все.

 ST>>   сорцы, кстати, к eval-версии не прилагаются :)

 HZ>     В курсе. До недавнего времени мне это не мешало. :) При желании,
 HZ>     думается,
 HZ> все можно найти.

  угу. хотя приходится поиметь приличное желание :) кстати, от 4.10 я все
больше не в восторге... тут совсем никто им не пользуется? у меня чего-то и
линковка не идет, проблемы с битовыми определениями регистров в iomacro.h... не
говоря о том, что компилер нашел 46 байт для NEAR_C, которого у меня нет и не
было, и который 3.20-му был не нужен...

    WBR, Сергей.                                     ICQ: 101347299


Re: Embedded OS
Hello Denis.

11 Mar 05 16:54, you wrote to me:

 AB>> У нее с доступностью проблемы. Где ее берут? У меня есть какая-то
 AB>> V2.00 от 1998 года.
 DB> Можно купить одноименную книгу, в ней на диске есть.

Hет возможности.

 DB> Я брал кажется "в будке".

ru_embedded00 ?

Чёй-то она фигово работает. То "Zero sized repry", то вообще без ответа.
Это так и должно быть?

Alexey


Re: Embedded OS
Привет, Harry !


 11 Mar 05 , 17:36  Harry Zhurov писал к Yuriy K:

HZ>     Как ты будешь организовывать прерывание, например, вычислительного
HZ> процесса, чтобы передать управление коду, выгребающему байт из
HZ> приемника UART'а?

Прерывания по таймеру и/или по приходу байта в уарт.

.                                            С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev

Embedded OS
Fri Mar 11 2005 23:50, Nickita A Startcev wrote to Harry Zhurov:

 HZ>>     Как ты будешь организовывать прерывание, например, вычислительного
 HZ>> процесса, чтобы передать управление коду, выгребающему байт из
 HZ>> приемника UART'а?

 NAS> Прерывания по таймеру и/или по приходу байта в уарт.

Hу, а дальше?
В прерывании байт получил, что с ним дальше делать то?
Его же как то обработать надо, возможно сформировать ответ и
передать его назад, причем сразу, с минимальной задержкой.
Какая-то более или менее долгая обработка делается уже вне прерываний,
а там у тебя вычислительны процесс работает в данный момент.
Как его прервать, чтобы сформировать ответ для передачи по UART?

wbr, Andy


Embedded OS
Hi Andy, hope you are having a nice day!


12 Мар 05, Andy Mozzhevilov wrote to Nickita A Startcev:

 NAS>> Прерывания по таймеру и/или по приходу байта в уарт.
 AM> Hу, а дальше?
 AM> В прерывании байт получил, что с ним дальше делать то?
 AM> Его же как то обработать надо, возможно сформировать ответ и
 AM> передать его назад, причем сразу, с минимальной задержкой.
 AM> Какая-то более или менее долгая обработка делается уже вне прерываний,
 AM> а там у тебя вычислительны процесс работает в данный момент.
 AM> Как его прервать, чтобы сформировать ответ для передачи по UART?

Для пакетных протоколов (которых все-таки большинство) все очень даже
прозрачно. По прерыванию выгребаем байт,
проверяем его на валидность кладем в буфер... вобщем выполняем все задачи до
момента разбора принятого пакета. Это
легко т.к. простейший конечный автомат с малым и детерминированным временем
выполнения (иногда даже сопоставимым со
временем переключения контекста). Делать из этого задачу не выгодно хотя бы
из-за бОльших накладных расходов на
щелканье контекстами (это превращается в проблему при высоких битрейтах на
контроллерах без FIFO).

Когда пакет принят и лежит в буфере, тут уже семафорим задаче (Application
Layer) о том, что пора разбирать пакет.
Разбирать пакет обычно можно сравнительно неспеша и отвлекаясь на
выкоприоритетные события, т.е. для этого отдельная
задача обычно оправдана. Задача выполняет нужные действия, формирует ответный
пакет и кладет его в буффер. Далее
разрешает прерывания от передатчика уарта и так же в прерываниях весь пакет
сливается в сеть.

Hу и какой смысл дергать задачу по каждому принятому/отправленному байту?

WBR,
    AVB


Embedded OS
Sat Mar 12 2005 16:16, Alexey V Bugrov wrote to Andy Mozzhevilov:

 AM>> В прерывании байт получил, что с ним дальше делать то?
 AM>> Его же как то обработать надо, возможно сформировать ответ и
 AM>> передать его назад, причем сразу, с минимальной задержкой.
 AM>> Какая-то более или менее долгая обработка делается уже вне прерываний,
 AM>> а там у тебя вычислительны процесс работает в данный момент.
 AM>> Как его прервать, чтобы сформировать ответ для передачи по UART?

...

 AVB> Hу и какой смысл дергать задачу по каждому принятому/отправленному
 AVB> байту?

Ты полез в детали. Реально в большинстве случаев так и
делается, как ты описал, и я так делаю.
Hо не суть важно, байт ты получил или пакет, все равно когда-то потребуется
его относительно длительная обработка, которая делается вне прерываний.
В то же время, обычно есть требования на время ответа, а у тебя в это время
в i2c память пишется пара килобайт в фоне.
Впрочем, ты же понимаешь, что эти вопросы не к тебе :)

wbr, Andy


Re: Embedded OS

   Yuriy, ты ещё здесь сидишь?


Понедельник Март 14 2005 19:01, Yuriy K wrote to Andy Mozzhevilov:
 AM>> Пpедположим y меня _yже_ есть "любимая" вытесняющая RTOS,
 AM>> ...
 AM>> Имхо, выбоp того или иного стиля выбиpается сyбъективно, исходя
 AM>> из пpошлых наpаботок и опыта.
 YK> Полностью согласен.
 YK> Личные предпочтения и субъективное удобство - решающие факторы. :-))

 Покуда удаётся достичь требуемого результата.

 Если (когда) не удаётся - приходится искать альтернативные решения...


                                                   Георгий


Re: Embedded OS

   Olga, ты ещё здесь сидишь?


Понедельник Март 14 2005 21:13, Olga Nonova wrote to Michael Belousoff:

 ON> Hеправильным я вижу то, что мы начинаем спорить не договорившись о
 ON> терминах- что называть "драйвером"?

 Шофёр ;)


                                                   Георгий


Embedded OS
Sat, 12 Mar 2005 16:16:19 +0300 Alexey V Bugrov wrote to Andy Mozzhevilov:

AV> Для пакетных протоколов (которых все-таки большинство) все очень даже
AV> прозрачно. По прерыванию выгребаем байт,
AV> проверяем его на валидность кладем в буфер... вобщем выполняем все задачи
AV> до момента разбора принятого пакета. Это
AV> легко т.к. простейший конечный автомат с малым и детерминированным временем
AV> выполнения (иногда даже сопоставимым со
AV> временем переключения контекста). Делать из этого задачу не выгодно хотя бы
AV> из-за бОльших накладных расходов на
AV> щелканье контекстами (это превращается в проблему при высоких битрейтах на
AV> контроллерах без FIFO).

AV> Когда пакет принят и лежит в буфере, тут уже семафорим задаче (Application
AV> Layer) о том, что пора разбирать пакет.
AV> Разбирать пакет обычно можно сравнительно неспеша и отвлекаясь на
AV> выкоприоритетные события, т.е. для этого отдельная
AV> задача обычно оправдана. Задача выполняет нужные действия, формирует
AV> ответный пакет и кладет его в буффер. Далее
AV> разрешает прерывания от передатчика уарта и так же в прерываниях весь пакет
AV> сливается в сеть.

AV> Hу и какой смысл дергать задачу по каждому принятому/отправленному байту?

    Все абсолютно правильно сказал! Так все и есть, когда скорость высокая. Но
когда у меня 9600 бод, т.е. между символами почти миллисекунда, и проц успевает
с энкратным запасом, задача минимизации потребления не стоит, почему бы не
совместить оба куска? Просто код так получается короче и проще. Только и всего.

    На более высоких скоростях делаю именно так, как ты и описал.

    Была еще идея рулить векторами прерываний - т.е. иметь два обработчика:
один для приема всех символов, кроме последнего, другой - для приема
последнего. Первый ISR выполняется обычным образом, без манипуляций
контекстами, при приеме предпоследнего символа, производится подмена адреса
вектора, вследствие чего следующее прерывание будет обрабатываться другим
обработчиком - там уже на входе сохранение контекста, на выходе
перепланирование (и возврат адреса вектора к первому ISR). Тут можно совместить
приятное с полезным - прием на высокой скорости без оверхеда на щелканье
контекстами и передача управления обработчику пакета без поллинга готовности.
Но руки так и не дошли. :)

--
H.Z.

h.z<antispam::at>ngs<antispam::period>ru

We've slightly trimmed the long signature. Click to see the full one.
Re: Embedded OS
12-Mar-05 16:16 Alexey V Bugrov wrote to Andy Mozzhevilov:


AB> Для пакетных протоколов (которых все-таки большинство) все очень даже
AB> прозрачно. По прерыванию выгребаем байт,
AB> проверяем его на валидность кладем в буфер... вобщем выполняем все
AB> задачи до момента разбора принятого пакета. Это
AB> легко т.к. простейший конечный автомат с малым и детерминированным
AB> временем выполнения (иногда даже сопоставимым со
AB> временем переключения контекста).
 А иногда - так совсем несопоставимо :-)
 Вот специально полез глянул.
Дано - приходят пакеты, разделённые флагами. Байт-стаффинг (по SLIP,
у меня так "исторически сложилось"). Разбор "а чего это там
флагом отмахнулось - там хоть CRC совпала?" - это делается "выше",
в прерывании только разбор подстановки байтов, сохранение уже
восстановленных данных в буфере, подсчёт числа байтов в пакете, короче,
минимум, необходимый для выделения пакета без его анализа.
 По осциллографу - продолжительнсть тела обработчика прерывания -
болтается в окрестности 2.2-2.3мкс, по листингу - вход и выход в прерывания
(включая неявный "call" и явный reti) - ещё в сумме окло 2.5мкс.
Итого меньше 5мкс, около 70 тактов процессора (AVR @ 14.7458MHz).
На AVR переключение контекста таким маленьким не будет даже если
зафиксировать и исключить из контеста половину регистров.

wbr,
p.s. а таки многовато регистров у AVR, многовато...
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua     */


Embedded OS
    Hello, Andy!

Суб Маp 12 2005, Andy Mozzhevilov писал к Nickita A Startcev по   поводу
"Embedded OS."
 AM> В прерывании байт получил, что с ним дальше делать то?
 AM> Его же как то обработать надо, возможно сформировать ответ и
 AM> передать его назад, причем сразу, с минимальной задержкой.
 AM> Какая-то более или менее долгая обработка делается уже вне прерываний,
 AM>  а там у тебя вычислительны процесс работает в данный момент.
 AM> Как его прервать, чтобы сформировать ответ для передачи по UART?
Почитай мое предыдущее письмо - там есть ответ на этот вопрос ;)
 AM> wbr, Andy
  WBR!  Maxim Polyanskiy.


Embedded OS
Sun Mar 13 2005 03:19, Maxim Polyanskiy wrote to Andy Mozzhevilov:

 AM>> передать его назад, причем сразу, с минимальной задержкой.
 AM>> Какая-то более или менее долгая обработка делается уже вне прерываний,
 AM>>  а там у тебя вычислительны процесс работает в данный момент.
 AM>> Как его прервать, чтобы сформировать ответ для передачи по UART?

 MP> Почитай мое предыдущее письмо - там есть ответ на этот вопрос ;)

А чего его читать? Там в все то же самое, что и в предыдущих твоих
письмах.
1) Ты сначала попробуй хоть что-нибудь написать на Си - потом спорь.
2) Ты сначала хотя бы пойми насчет того, "что там и как переключается",
потом спорь.

Тебе привели гипотетический пример, общий подход без деталей,
а ты принял его за конечную реальную задачу.

Если ты не разбираешься в Си, RTOS - так чего лезть и жужжать постоянно?
Пишешь на асме, так никто ж не против. А рассуждать о вкусе устриц, если
их не ел, дурной тон.

wbr, Andy


Embedded OS
    Hello, Andy!

Вcк Маp 13 2005, Andy Mozzhevilov писал к Maxim Polyanskiy по  поводу "Embedded
OS."
 AM>>> Какая-то более или менее долгая обработка делается уже вне
 AM>>> прерываний, а там у тебя вычислительны процесс работает в данный
 AM>>> момент. Как его прервать, чтобы сформировать ответ для передачи
 AM>>> по UART?
 MP>> Почитай мое предыдущее письмо - там есть ответ на этот вопрос ;)
 AM> А чего его читать? Там в все то же самое, что и в предыдущих твоих
 AM> письмах.
И тем не менее там есть ответ. Да и вообще причем тут языки - я предлагаю
альтернативный механизм! Чтоб его понять ничего не нужно знать кроме устройства
периферии процессора. Ты опять увидел за механизмом АСМ. Я чего-то не понял - у
тебя проблемы с прерываниями? С битами? Это же не пресловутый "cдвиг в С флаг".
Где там хоть слово про асм?
 AM> 1) Ты сначала попробуй хоть что-нибудь написать на Си - потом спорь.
Я честно пробовал. Поскольку даже у меня в спорах закрадывались разные смутные
мысли. Было необходимо поддерживать устройство на 89с52. Я честно пытался
добивать новую функциональность на С, через 3 дня у меня кончилось iram, я
посмотрел листинг, плюнул, и написал все то-же самое на асме pic16f877
переделав схему и выкинув дочерта лишней аналоговой фигни.

И еще у меня на полке стоит 5 книжек в стиле "c для полных мудаков". И я их
даже читал. И я чесно пишу на С математику с плавающей точкой на PC загоняю ее
в либы и потом использую в прогах. Причем делаю я это по причине банальной
лени, иначе бы просто разобрался с программированием сопроцессора. Hу и не
зря-же я в конце концов читал эти книжки. :)
 AM> 2) Ты сначала хотя бы пойми насчет того, "что там и как
 AM> переключается", потом спорь.
Чего понимать то? Вон Редчук понимает и написал, что вроде как оно конкретно
только и будет, что переключатся. ;-) Проблема в том, что любая хорошая идея в
реализациях как правило доводится до маразма.
 AM> Тебе привели гипотетический пример, общий подход без деталей,
 AM> а ты принял его за конечную реальную задачу.
Упаси боже - я привел гепотетическое решение так-же без деталей. А вообще я
против гипотетических примеров. Вот ты скажи - частенько ты байты из usarta
задачей ждешь и через задачу перекидываешь? или все-таки у тебя прерывания и
fifo буфер который ты там гдето на досуге пулишь?
 AM> Если ты не разбираешься в Си, RTOS - так чего лезть и жужжать
 AM> постоянно? Пишешь на асме, так никто ж не против. А рассуждать о вкусе
 AM> устриц, если их не ел, дурной тон.
Hикто не жужжит. Предлагаются альтернативные варианты менеджмента. В нормальном
стиле программирования, а не в попсовых новомодных веяниях.
 AM> wbr, Andy
  WBR!  Maxim Polyanskiy.


Embedded OS
Sun Mar 13 2005 09:11, Maxim Polyanskiy wrote to Andy Mozzhevilov:

 MP>>> Почитай мое предыдущее письмо - там есть ответ на этот вопрос ;)
 AM>> А чего его читать? Там в все то же самое, что и в предыдущих твоих
 AM>> письмах.

 MP> И тем не менее там есть ответ. Да и вообще причем тут языки - я предлагаю
 MP> альтернативный механизм! Чтоб его понять ничего не нужно знать кроме
 MP> устройства периферии процессора.

Этот механизм, который ты предложил, я пользовал еще лет 6-7 назад,
только в варианте, который описал OR. В этом случае этот механизм реализуем
только на асме, и он не решает всех проблем.

 MP> чего-то не понял - у тебя проблемы с прерываниями? С битами? Это же не
 MP> пресловутый "cдвиг в С флаг".
 MP> Где там хоть слово про асм?

Подмена прерывания другим, при помощи взведения флага этого прерывания руками,

метод, который работает не везде, потому что в х51 это можно делать (типа
софтверного прерывания), в других же uC эти флаги могут устанавливаться
только аппартано. Хотя мне лично не помешала бы иногда возможность генерации
софтверных прерываний при помощи флагов, но которые бы подчинялись логике
обычных периферийных прерываний, включая приоритезацию, разрешение их в
контроллере и т.п.

 AM>> 1) Ты сначала попробуй хоть что-нибудь написать на Си - потом спорь.

 MP> Я честно пробовал. Поскольку даже у меня в спорах закрадывались разные
 MP> смутные мысли. Было необходимо поддерживать устройство на 89с52. Я честно
 MP> пытался добивать новую функциональность на С, через 3 дня у меня
 MP> кончилось iram, я посмотрел листинг, плюнул,

Так надо было писать в нормальном стиле, а не заводить все переменные
глобально.

 MP> и написал все то-же самое на
 MP> асме pic16f877 переделав схему и выкинув дочерта лишней аналоговой фигни.

молодец.

 MP> И еще у меня на полке стоит 5 книжек в стиле "c для полных мудаков".

Достадочно K&R

 MP> их даже читал.

Значит плохо читал

 MP> И я чесно пишу на С математику с плавающей точкой на PC
 MP> загоняю ее в либы и потом использую в прогах. Причем делаю я это по
 MP> причине банальной лени, иначе бы просто разобрался с программированием
 MP> сопроцессора. Hу и не зря-же я в конце концов читал эти книжки. :)

 AM>> 2) Ты сначала хотя бы пойми насчет того, "что там и как
 AM>> переключается", потом спорь.

 MP> Чего понимать то? Вон Редчук понимает и написал, что вроде как оно
 MP> конкретно только и будет, что переключатся. ;-) Проблема в том, что любая
 MP> хорошая идея в реализациях как правило доводится до маразма.

Маразм - это писать все на асме, ровно как и игнорировать определенные
методики, даже не разобравшись, как оно там и зачем устроено.

 AM>> Если ты не разбираешься в Си, RTOS - так чего лезть и жужжать
 AM>> постоянно? Пишешь на асме, так никто ж не против. А рассуждать о вкусе
 AM>> устриц, если их не ел, дурной тон.

 MP> Hикто не жужжит. Предлагаются альтернативные варианты менеджмента. В
 MP> нормальном стиле программирования, а не в попсовых новомодных веяниях.

Этот стиль не решает всех проблем, однако на мелких uC типа х51
вполне имеет право на жизнь.

wbr, Andy


Embedded OS
    Hello, Andy!

Пон Маp 14 2005, Andy Mozzhevilov писал к Maxim Polyanskiy по  поводу "Embedded
OS."
 AM> Этот механизм, который ты предложил, я пользовал еще лет 6-7 назад,
 AM> только в варианте, который описал OR. В этом случае этот механизм
 AM> реализуем только на асме, и он не решает всех проблем.
Да такие "все проблемы" возникают дай бог в одном проекте из 10-ти. Опять-же не
ясно куда тебе больше 3-х приоритетов для исполняемого системой кода?

Кстати никто не задумывался почему MCS51 так долго живет и не думает умирать?
Где например будет ядро AVR через 15лет? Или PIC16 через 10?
 AM>>> 1) Ты сначала попробуй хоть что-нибудь написать на Си - потом
 AM>>> спорь.
 MP>> Я честно пробовал. Поскольку даже у меня в спорах закрадывались
 MP>> разные смутные мысли. Было необходимо поддерживать устройство на
 MP>> 89с52. Я честно пытался добивать новую функциональность на С,
 MP>> через 3 дня у меня кончилось iram, я посмотрел листинг, плюнул,
 AM> Так надо было писать в нормальном стиле, а не заводить все переменные
 AM> глобально.
Как раз наоборот. Поганый компилятор почти все локальные переменные разложил
в свои ячейки, хотя как правило мне для ручной оптимизации хватает 3-5 таких
ячеек на всю прогу, и то на pic, на x51 все чисто на регистрах делается. Эта-же
дрянь через регистры естественно передавала параметры, хотя после просмотра
листнга стало понятно, что передавать там особо нечего. Кроме того в части кода
несколько переменных ДО МЕHЯ были ошибочно определены как int, хотя и unsigned
char там бы за глаза хватило, данный кусок кода производил впечатления безумно
спертого откуда-то алгоритма. А я тогда не очень разбрался в преобразовании
типов не имел желания искать более нормальный компилятор, да и глобально бы это
не решило проблемы, и вобщем самым лучшим вариантом оказалось все накатать на
асм pic.
 MP>> И еще у меня на полке стоит 5 книжек в стиле "c для полных
 MP>> мудаков".
 AM> Достадочно K&R
Это тоже есть. Да все книги о ЯВУ в общем и целом одинаковые:
10% - собственно описание языка.
10% - описание языка "еще 1 раз" перемешанное с 1-м. (для идиотов данный раздел
может быть увеличен втрое).
10% - раздел про то, чем описываемый тут язык круче, чем все остальные языки
вместе взятые изобретенные до или после этого языка.
10% - cписок людей и организаций конкретно крутых в этом мире (как правло тех
кто круче автора - т.е. у которых автор натырил все свои идеи, за что им
спасибо, но денег не дам).
60% - смесь воды с прописными истиннами знакомыми любому человеку который
занимается программированием более 3 лет.

Как видишь - достаточно прочитать и 1/10 части.
 MP>> их даже читал.
 AM> Значит плохо читал
Ты кстати библию читал? Я нет. Hо говорят там все круто написано - некоторые
чтают и верят.

Так какое доселе закрытое откровение мно должно было открытся после почтения
K&R ?
 AM> Маразм - это писать все на асме, ровно как и игнорировать определенные
 AM>  методики, даже не разобравшись, как оно там и зачем устроено.
Это не маразм а банальный спор о вкусах. Яблок с грушами.

Hапример - в виндах есть механизм многопоточности. Механизм который как и API
дан с выше, который реализуется вот просто так, без чтения 100-страничных
талмудов по rtos. Cколько реально ты видел прикладных задач требующих
многопоточности? Я за всю жизнь могу припомнить дай бог если 10.
Hет конечно есть люди у которых вся жизнь в изобретении каких-то ethernet
устройств и протоколов, tcp/ip стеков, и качалок не хуже REGET, но причем тут
реальные вычислительные задачи, работа с файлами, поиск, cортировки, тайминг, и
ногодерганье?
 MP>> Hикто не жужжит. Предлагаются альтернативные варианты
 MP>> менеджмента. В нормальном стиле программирования, а не в попсовых
 MP>> новомодных веяниях.
 AM> Этот стиль не решает всех проблем,
Как раз ровно наоборот, этот стиль решает все проблемы которые могут возникнуть
в рамках возможностей данного кристала, поскольку он ограничен его физическми
возможностями. rtos по сути является чуждым в embedded механизмом,
предназначеным по своей сути для портиования чужих многопоточных решений
(например тех-же ворованных tcp/ip стеков от больших компов без особого
разбирательства как оно там работает итп). Его ноги растут из решений, которые
написаны cпециально под винды. Т.е. это фактически попытка запустить виндовое
ПО на контроллере.
 AM> однако на мелких uC типа х51 вполне имеет право на жизнь.
Этот стиль живет и на крупных uC типа ARM когда их ставят в нормальные
промышленные устройства, и вместо того, чтоб пользоватся халявным кодом уровня
sourceforge пишут все cами с нуля.
 AM> wbr, Andy
  WBR!  Maxim Polyanskiy.


Site Timeline