IPB

Здравствуйте, гость ( Вход | Регистрация )

8 страниц V  < 1 2 3 4 5 > »   
Ответить в данную темуНачать новую тему
> RTOS: распространенные заблуждения, Обсудим?
_pasha
сообщение 9.1.2012, 4:41
Сообщение #41


тот самый
Иконка группы

Группа: Мод
Сообщений: 13629
Регистрация: 24.11.2009
Из: Харьковская обл., UA
Пользователь №: 25



Тут интересно со РТОС ведь другие проблемы возникают - реентерабельность сторонних подпрограмм, TLS и размеры стека задачи.
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 9.1.2012, 10:18
Сообщение #42


сундук
***

Группа: Пользователи
Сообщений: 4043
Регистрация: 21.11.2009
Из: Ростов-на Дону
Пользователь №: 15



Цитата(GuruKiller @ 9.1.2012, 3:27) *
Так нельзя. Иначе тема "ымбеддер и AVR" будет закрыта smile.gif
Как собственно ещё дозревающая тема "ымбеддер и ОСь".
Поражаюсь способности Прохожего ругать то, в чём не разбираешься (или с чем не работал) smile.gif

Ладно, насчет NVIC я слегка погорячился.
Контроллер, как контроллер, только очень много лишнего, впрочем, как и в самой архитектуре ARM.
При ознакомлении с этими потрохами возникает масса вопросов о назначении тех или иных технических изысков.
Основная претензия к ARM - отсутствие бесплатных полноценных средств разработки.
Что же касается темы "Ымбедер и AVR", то было бы неплохо услышать претензии по-существу.
Кто и когда там был незаслуженно упомянут.
А то, что Ымбедеры постсоветского пространства почему-то предпочитают именно AVR - действительно загадка.
Цитата(GuruKiller @ 9.1.2012, 3:27) *
Очень любопытно. Получается реальная РТОСь, написанная для этого МК - это ОСь в квадрате smile.gif

Ну да, вот им она и стучит...
Перейти в начало страницы
 
+Цитировать сообщение
_pasha
сообщение 9.1.2012, 10:55
Сообщение #43


тот самый
Иконка группы

Группа: Мод
Сообщений: 13629
Регистрация: 24.11.2009
Из: Харьковская обл., UA
Пользователь №: 25



Цитата(Прохожий @ 9.1.2012, 10:18) *
А то, что Ымбедеры постсоветского пространства почему-то предпочитают именно AVR - действительно загадка.

А что там загадочного? После пиков появились АВР с (о чудо!) гораздо более прямой архитектурой, народ ломанулся. Это подстегнуло к развитию средств разработки и отладки. Теперь достаточно иметь бесплатный ГЦЦ и пижженый протеус, чтобы, не отрывая жжж от стула, чувствовать себя гением. По себе знаю.
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 9.1.2012, 11:07
Сообщение #44


сундук
***

Группа: Пользователи
Сообщений: 4043
Регистрация: 21.11.2009
Из: Ростов-на Дону
Пользователь №: 15



Цитата(_pasha @ 9.1.2012, 12:55) *
А что там загадочного? После пиков появились АВР с (о чудо!) гораздо более прямой архитектурой, народ ломанулся. Это подстегнуло к развитию средств разработки и отладки. Теперь достаточно иметь бесплатный ГЦЦ и пижженый протеус, чтобы, не отрывая жжж от стула, чувствовать себя гением. По себе знаю.

Но все-равно, не до конца понятно.
"Протез" поддерживает не только AVR.
Можно чувствовать себя гением и с ARM от различных контор и с тем же PIC24/dsPIC.
Но почему-то именно AVR здесь в лидерах.
Хотя архитектура у ARM еще более кошерная (не гарвардская) и возраст у него приблизительно совпадает с AVR.
Перейти в начало страницы
 
+Цитировать сообщение
Гость_MrYuran_*
сообщение 9.1.2012, 11:52
Сообщение #45





Гости






Цитата(Прохожий @ 9.1.2012, 12:18) *
Основная претензия к ARM - отсутствие бесплатных полноценных средств разработки..

О5 25 smile.gif
между прочим, ARM в GCC отродясь поддерживается.
А ECLIPSE - вполне полноценная среда, не хуже мелкосиудии и уж точно не хуже бледно-серых IDE от IAR или кейла.
Отладка работает замечательно, я на STM32 гонял.
Симулятор- для симулянтов smile.gif
Честно говоря, я и отладку-то не люблю, привык как-то через терминал контрольные точки выводить.
Перейти в начало страницы
 
+Цитировать сообщение
dxp
сообщение 9.1.2012, 11:59
Сообщение #46


Adept
***

Группа: Пользователи
Сообщений: 522
Регистрация: 20.4.2011
Из: Novosibirsk
Пользователь №: 346



Цитата(Прохожий @ 8.1.2012, 21:30) *
У меня есть уважительная причина. Даже несколько.
1. Логика проста и тривиальна.

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

Цитата(Прохожий @ 8.1.2012, 21:30) *
2. Метод универсален. Попробуйте в своей методике моргнуть светодиодом раз, эдак, 200 после включения реле.

Любой метод может быть универсальным, а вот код непереносим, т.к. завязан на прерывания. А вот в моём примере код полностью переносим.

Мигнуть раз 200? Вы шутите? Извольте:
Код
    ...
    relay_on(true);
    for(int i = 0; i < 200; ++i)
    {
        led_on(true);  sleep(500);
        led_on(false); sleep(500);
    }

Код абсолютно прозрачен и тривиален. А ваш пример - это write-only code, извините. Т.е. код, который более-менее понятен автору (в течение пары месяцев с момента написания). smile.gif

Цитата(Прохожий @ 8.1.2012, 21:30) *
3. Скорость работы выше, чем у Вас.

Что вы понимаете под скоростью? Поясните?. Скорость реакции на событие - например, timer expiration, в моём варианте будет лучше - процесс сразу получит управление по выходу из таймерного прерывания, это время предсказуемое. А как у вас это осуществляется, я так и не понял, извините. Накладные расходы в случае вытесняющей RTOS будут больше, главным образом по расходу ОЗУ на стеки процессов. Но и только. На современных копеечных МК это вообще не проблема.

Цитата(Прохожий @ 8.1.2012, 21:30) *
4. Код короче, чем в Вашем случае поскольку я Вам предъявил заодно и реализацию, чего в Вашем случае не было.

Ваш код выглядит длиннее. И в целом будет длиннее, если в программе будет не один такой фрагмент. У меня же используются общие для всех частей программы механизмы RTOS. Футпринт RTOS, которую я использую составляет для MSP430 1.2K (из примера с тремя пользовательскими процессами) при 60К доступной флеши. При этом имеет полноценное приоритетное вытеснение и все плюшки в виде межпроцессного взаимодействия.

Цитата(Прохожий @ 8.1.2012, 21:30) *
Я думал, что у меня все очевидно.

Вы описали логику работы, а я спрашивал не про это, а про то, как осуществляется передача управления. Т.е. когда таймер досчитал до нужного значения - тут нужно немедленно передать управление в основную программу - именно в тот автомат, который ждёт события. Как это осуществляется у вас? Поллингом? Или карусель в суперлупе?

Цитата(Прохожий @ 8.1.2012, 21:30) *
Естественно, все переменные - глобальные.

Ещё один недостаток - замусоривание глобального пространства имён. Такой простой код уже добавляет прилично мусора, что же там будет твориться в действительно большой программе?

Цитата(Прохожий @ 8.1.2012, 21:30) *
а драйвера - это тоже совокупность процессов, то моя основная забота - это HAL.

Извините, вот это (выделенное) я никак принять не могу. Драйвер - это программный код, предназначенный для абстрагирования управления аппаратурой от конкретного устройства аппаратуры. К процессам, потокам выполнения программы это не имеет ни малейшего отношения. Драйвера прекрасно живут в окружении, где может быть вообще только один поток выполнения.

Цитата(Прохожий @ 8.1.2012, 21:30) *
С чего бы это? Расчет полиномов - это сплошная программа, оформленная в виде функции для повторного использования. Ее можно использовать и из автомата процесса.
Мне, честно говоря, не понятно - откуда у Вас такое заблуждение, про которое Вы говорите в цитируемом выше тексте?
С какой это радости мне нужно терпеть все мучения, описанные Вами?
Уверяю Вас. В реальности все гораздо проще.

Гуд. Изобразите ваш вариант насчёт этого полинома:
Код
float P3x(const float Coeffs[3], const float x)
{
    float x2 = x*x;
    return Coeffs[0]*x2*x + Coeffs[1]*x2 + Coeffs[2]*x + Coeffs[3];
}

Условия: в программе происходит обмен через UART на скорости 9600 бод (примерно 1 мс на символ), данный полином вычисляется за время порядка 5 мс (MSP430 @5MHz).

У меня в программе он именно так и реализован, я голову не грею себе, как его декомпозировать на части, чтобы удовлетворить времянки (в том числе и при переносе на другой МК - в частности на AVR это тоже успешно работает в том же виде, хотя там время выполнения побольше - что-то около 8 мс).

На самом деле код процесса состоит не только из этого полинома, там их пачка вычисляется - численное нахождение значения итеративным путём. Полиномы тоже разные. Был даже вариант с нахождением значения через полином двух переменных - там МК 22 мс пыхтел. smile.gif Но для программы это всё без прозрачно - пишешь код свободно, как хочешь, совершенно не напрягаясь насчёт времянок - главное, чтобы вычисления были завершены до определённого момента.

Цитата(Прохожий @ 8.1.2012, 21:30) *
А Вы уверены, что им всем нужны разные приоритеты?

Абсолютно. Это относительно большая программа, которая выполняет кучу задач от обслуживания обмена по сериальным протоколам, взаимодействие с ПЛИС, корректировка параметров видеотракта, управление исполнительными устройствами, сбор и обработка данных от датчиков (температура приёмника, углы наклона, клавиатура), GUI и ещё много всяких более мелких задач. Не вижу причин ограничивать себя в удобстве проектирования и создании читабельного и сопровождаемого кода.

Цитата(Прохожий @ 8.1.2012, 21:30) *
Микрочип на сегодняшний день - самая лояльная к потребителю контора с достаточно неплохой поддержкой.

Только это не характеризует уровень его достижений в МКстроении. Не вижу причин отдавать ему предпочтение на фоне TI, ADI и других фирм.

Цитата(Прохожий @ 8.1.2012, 21:30) *
Согласен со всеми тезисами. Добавлю еще, что у него очень приятная система команд, очень похожая на PDP11, но отсутствие бесплатной полновесной среды разработки перечеркивает для меня всю его привлекательность. Равно как и его улучшенному варианту.

А что вы понимаете под "полновесной" средой разработки?

Цитата(Прохожий @ 8.1.2012, 21:30) *
А если переписать Кернел?

Ну, это-то дело плёвое, не то, что осовить RTOS, общий объём сорцов которой составляет меньше сотни килобайт.

Цитата(Прохожий @ 8.1.2012, 21:30) *
Гы, винда - это первая ОС, где было введено понятие события. И осуществлено переползание с обыкновенного программирования к событийному.
А так, там все то же самое, что и в Ваших любимых RTOS. Обыкновенная вытесняющая ОС, с присущими ей достоинствами и недостатками.

Пардон. Вот у меня в текущем проекте время передачи управления (т.е. при возникновении события, через сколько времени ожидающий этого события код получит управление) составляет 1.5 мкс. Это на Blackfin @200MHz. И это время детерминировано. Детерминированность именно обеспечивается используемыми простыми механизмами. Какие времена даёт венда? Как они детерминированы? Да никак. Именно этим RTOS и отличается от просто OS.

Цитата(Прохожий @ 8.1.2012, 21:30) *
Я достаточно хорошо ознакомился с идеологией RTOS и понял, что мне на текущем этапе это не нужно.

Мои поздравления. smile.gif

Цитата(Прохожий @ 8.1.2012, 21:30) *
Еще раз повторю. Любой современный МК - сам себе RTOS.

Очень сильное заявление. smile.gif Наверное, чтобы разобраться в этом вопросе, нужно дать определение терминам - что такое "МК" и что такое "ОС". Тогда сразу станет ясно, на самом ли деле MK == OS.

Цитата(Прохожий @ 8.1.2012, 21:30) *
А сколько стоит нормальный софт разработчика с симулятором и приличной IDE? GNU не предлагать.

Это почему это? ГНУтые компиляторы очень приличны и по кодогенерации, и по поддерживаемым фичам языка. Отладчики тоже есть. Даже среда есть могучая - эклипс, которую не брезгуют брать за основу ведущие производители софта - IAR, Altera, Xilinx, NXP и многие другие. Уж не убожище ли MPLab вы хотите противопоставить? smile.gif

Цитата(Прохожий @ 8.1.2012, 21:30) *
Да, действительно есть. Но с NVIC от ARM я знаком давно. Просто не ассоциировал его и CORTEX-ы.
Но это бред, а не контроллер прерываний.
Это источник неисчислимых багов и загадок для программиста.
Как, впрочем, и весь ARM.
Как был студенческой поделкой, так ею и остается по сей день.
Кстати, у NVIC тоже всего 8 уровней приоритетов.
Вот беда...

Cortex-M - очень продуманная серия процессоров. При изучении документации постоянно ловлю себя на мысли, что люди, которые его спроектировали, прошли определённый путь, тут чувствуется школа. Вы как-то погорячились насчёт него, не разобрались. К сведению, сам по себе NVIC поддерживает до 250 уровней прерываний. Просто не во всех МК это количество реализовано, т.к. там просто не надо.
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 9.1.2012, 16:34
Сообщение #47


сундук
***

Группа: Пользователи
Сообщений: 4043
Регистрация: 21.11.2009
Из: Ростов-на Дону
Пользователь №: 15



Во-первых, приношу свои извинения за те места, где был излишне эмоционален.
Перечитал нашу переписку и понял, что выгляжу не очень хорошо.
Еще раз извините...
Цитата(dxp @ 9.1.2012, 12:59) *
Отнюдь не так проста как кажется - особенно по сравнению с альтернативным вариантом, где три строчки линейного кода и больше ничео - ни таймеров, ни счётчиков, ни автоматов (во, сколько лишних сущностей на пустом месте). И это в таком простейшем примере.

Это базовые сущности. Они будут всегда.
Вне зависимости от примера.
Причем, с увеличением технической сложности примера, структура и сущности остаются.
Цитата(dxp @ 9.1.2012, 12:59) *
Что вы понимаете под скоростью? Поясните?. Скорость реакции на событие - например, timer expiration, в моём варианте будет лучше - процесс сразу получит управление по выходу из таймерного прерывания, это время предсказуемое. А как у вас это осуществляется, я так и не понял, извините. Накладные расходы в случае вытесняющей RTOS будут больше, главным образом по расходу ОЗУ на стеки процессов. Но и только. На современных копеечных МК это вообще не проблема.

В моем случае время реакции на простое событие - конец отсчета таймера - это время, необходимое МК для входа в обработчик прерывания (прерывание пипелайна и аппаратное сохранение контекста). В случае сложного события - когда этот таймер увязан еще на что-то - к этому времени добавляются простые логические операции. Все считается с точностью до такта.
Цитата(dxp @ 9.1.2012, 12:59) *
Ваш код выглядит длиннее. И в целом будет длиннее, если в программе будет не один такой фрагмент. У меня же используются общие для всех частей программы механизмы RTOS. Футпринт RTOS, которую я использую составляет для MSP430 1.2K (из примера с тремя пользовательскими процессами) при 60К доступной флеши. При этом имеет полноценное приоритетное вытеснение и все плюшки в виде межпроцессного взаимодействия.

Еще раз извините, но Вы пока еще не поняли сути подхода, о котором я рассказываю. Попытаюсь объяснить.
Заодно, отвечу и на эти вопросы:
Цитата(dxp @ 9.1.2012, 12:59) *
Вы описали логику работы, а я спрашивал не про это, а про то, как осуществляется передача управления. Т.е. когда таймер досчитал до нужного значения - тут нужно немедленно передать управление в основную программу - именно в тот автомат, который ждёт события. Как это осуществляется у вас? Поллингом? Или карусель в суперлупе?

Извините, если буду банален и будет много букофф.
Любую программу, выполняемую на МК, в простейшем виде можно представить как последовательность неких операторов.
В примитивной модели - это суперлуп, когда анализируя входные переменные мы выполняем или пропускаем те или иные последовательности этих самых операторов.
Попутно застревая в продолжительных участках долгоиграющего кода, в тот момент, когда надо бы выполнить что-то более существенное и важное.
Желая разорвать этот порочный круг мы можем сделать вставки в долгоиграющий код с проверками, типа, а не пришло ли время проверить такие-то и такие-то условия?
И тут возникает вопрос - как это сделать, тем более асинхронно? И желательно быстро, чтобы реакция на события была как можно более короткой.
Все решения, которые приходят в голову, кроме RTOS, которая инкапсулирует так или иначе это безобразие, выглядят кургузо и коряво.

Но на самом деле все очень просто. Если отойти в сторону от парадигмы непременной линейности кода, за которую Вы ратуете.
Каждый процесс представляется в виде автомата, иногда вырожденного, как в моем примере. И переход этого автомата из состояния в состояние осуществляется в прерываниях с действиями на переходах. Программа в этом случае может вообще не иметь суперлупа, а МК может переходить в спячку до следующего события.
Т. е. каждое событие, приписанное к данному процессу, вызывает условно мгновенную реакцию (за вычетом аппаратных издержек самого МК) этого процесса на это событие.
Вы можете законно возразить - действия на переходах могут быть очень долгими и обслуживание прерывания может затянуться.
В этом случае действие на переходе осуществляется в суперлупе. Т. е. в самом низкоприоритетном месте программы.
Которое всегда может быть прервано другими процессами, чьи события наступили в текущий момент времени.
Таким образом, процесс сам меняет приоритеты в зависимости от того, в каком состоянии он находится.
Вот более сложный пример, чтобы было понятно, о чем идет речь.
Прикрепленный файл  Процесс_обслуживания_USART.pdf ( 150,44 килобайт ) Кол-во скачиваний: 39

Если пользоваться всеми возможностями современных контроллеров прерываний, то можно изменять приоритеты динамически.
Но лично я этого пока не делал. Но непременно буду - есть для чего.
При таком подходе скорость обслуживания событий максимальная и определяется в случае совпадения событий с прерыванием только аппаратными издержками МК.
Нет необходимости изучать дополнительную документацию по RTOS.
Документирование ведется на этапе проектирования.
А сами недостатки имеются и это:
Цитата(dxp @ 9.1.2012, 12:59) *
Ещё один недостаток - замусоривание глобального пространства имён. Такой простой код уже добавляет прилично мусора, что же там будет твориться в действительно большой программе?

не самый главный.
Я вообще не заморачиваюсь насчет глобальных переменных.
Памяти в современных МК более, чем достаточно.
И документирование при таком подходе - вещь отработанная.
Цитата(dxp @ 9.1.2012, 12:59) *
Извините, вот это (выделенное) я никак принять не могу. Драйвер - это программный код, предназначенный для абстрагирования управления аппаратурой от конкретного устройства аппаратуры. К процессам, потокам выполнения программы это не имеет ни малейшего отношения. Драйвера прекрасно живут в окружении, где может быть вообще только один поток выполнения.

Правильно. Но при работе даже одного потока пользователя, драйвера обязаны работать во всей свое совокупности. Т. е. реально имеем выполнение нескольких задач одновременно. Просто драйвера лежат ниже уровня HAL и Вы эти задачи не видите.
А когда между человеком и железом МК никого нет, то достигать нужного уровня приходится самостоятельно.
Поверьте, мне тоже неудобно смешивать низ и верх. Поэтому я и стремлюсь к их разделению.
Цитата(dxp @ 9.1.2012, 12:59) *
Гуд. Изобразите ваш вариант насчёт этого полинома:
Код
float P3x(const float Coeffs[3], const float x)
{
    float x2 = x*x;
    return Coeffs[0]*x2*x + Coeffs[1]*x2 + Coeffs[2]*x + Coeffs[3];
}

Условия: в программе происходит обмен через UART на скорости 9600 бод (примерно 1 мс на символ), данный полином вычисляется за время порядка 5 мс (MSP430 @5MHz).

Да нет проблем.
Кусок из пресловутого терморегулятора:
Код
float t;
char i;
...
switch (ThermoType)
{
case 'R':
    if(e>=-0.226&&e<1.923)
    {
        t=R0[10]*e;
        for(i=9;i>0;i--) t=(t+R0[i])*e;
        t=t+R0[0];
    }
    else if(e>=1.923&&e<11.361)
    {
        t=R1[9]*e;
        for(i=8;i>0;i--) t=(t+R1[i])*e;
        t=t+R1[0];
    }
    else if(e>=11.361&&e<19.739)
    {
        t=R2[5]*e;
        for(i=4;i>0;i--) t=(t+R2[i])*e;
        t=t+R2[0];
    }
    else if(e>=19.739&&e<=21.103)
    {
        t=R3[4]*e;
        for(i=3;i>0;i--) t=(t+R3[i])*e;
        t=t+R3[0];
    }
    break;
............
Ну и так далее для остальных типов термопар.

Здесь е - нормализованное значение термо ЭДС, ThermoType - номер типа термопары.
t - температура.
R0, R1, R2, R3 - массивы коэффициентов полиномов для каждого из диапазонов термо ЭДС для термопары типа R.
Цитата(dxp @ 9.1.2012, 12:59) *
У меня в программе он именно так и реализован, я голову не грею себе...

Дык, и я тоже.
Цитата(dxp @ 9.1.2012, 12:59) *
Абсолютно. Это относительно большая программа, которая выполняет кучу задач от обслуживания обмена по сериальным протоколам, взаимодействие с ПЛИС, корректировка параметров видеотракта, управление исполнительными устройствами, сбор и обработка данных от датчиков (температура приёмника, углы наклона, клавиатура), GUI и ещё много всяких более мелких задач. Не вижу причин ограничивать себя в удобстве проектирования и создании читабельного и сопровождаемого кода.

Без всяких шуток. А Вы на людях эксперименты проводили? Давали посмотреть свой код кому-нибудь еще?
Ведь читаемость и сопровождаемость - понятия относительные и очень субъективные.
Поверьте человеку, который вынужден сопровождать кучу разных девайсов, в том числе и программных.
Разница есть и существенная.
Цитата(dxp @ 9.1.2012, 12:59) *
Только это не характеризует уровень его достижений в МКстроении. Не вижу причин отдавать ему предпочтение на фоне TI, ADI и других фирм.

ADI - это кто? Гугель на вскидку дает это.
Я с Вами соглашусь, когда среды разработки будут бесплатными.
Цитата(dxp @ 9.1.2012, 12:59) *
А что вы понимаете под "полновесной" средой разработки?

1. Наличие адекватного симулятора.
2. Наличие удобной IDE. Никаких make файлов (только по запросу, если сильно кому надо).
3. Наличие удобных дебуггеров.
Цитата(dxp @ 9.1.2012, 12:59) *
Ну, это-то дело плёвое, не то, что осовить RTOS, общий объём сорцов которой составляет меньше сотни килобайт.

Вы меня не поняли. Среда CoDeSys в варианте TwinCat, с которой я имею дело, как простой юзер, перегружает Кернел, как в Винде, так и в Линуксе.
При этом софт-PLC на основе любого либо x-86, либо ARM работает в реал тайме.
Его жесткость можете оценить самостоятельно, если хотите - дам ссылку на первоисточник.
В моем варианте это PC от Beckhoff и их же удаленка на ProfiBus-е.
Для линии, упаковывающей по 300 пачек сигарет в минуту вполне хватает.
Цитата(dxp @ 9.1.2012, 12:59) *
Пардон. Вот у меня в текущем проекте время передачи управления (т.е. при возникновении события, через сколько времени ожидающий этого события код получит управление) составляет 1.5 мкс. Это на Blackfin @200MHz. И это время детерминировано. Детерминированность именно обеспечивается используемыми простыми механизмами. Какие времена даёт венда? Как они детерминированы? Да никак. Именно этим RTOS и отличается от просто OS.

Ого! Целых 300 команд. Расточительно, однако.
Цитата(dxp @ 9.1.2012, 12:59) *
Очень сильное заявление. smile.gif Наверное, чтобы разобраться в этом вопросе, нужно дать определение терминам - что такое "МК" и что такое "ОС". Тогда сразу станет ясно, на самом ли деле MK == OS.

Скажу как художник художнику. Я так вижу! biggrin.gif
Цитата(dxp @ 9.1.2012, 12:59) *
Уж не убожище ли MPLab вы хотите противопоставить? smile.gif

Не такое оно и убожище. Всегда можно сделать лучше - это понятно.
С Эклипсом дело имел очень мало в варианте от ARM-KEIL.
Честно скажу, не увидел в нем ничего особо выдающегося.
Может быть я его готовить не умею?
Цитата(dxp @ 9.1.2012, 12:59) *
Cortex-M - очень продуманная серия процессоров. При изучении документации постоянно ловлю себя на мысли, что люди, которые его спроектировали, прошли определённый путь, тут чувствуется школа. Вы как-то погорячились насчёт него, не разобрались. К сведению, сам по себе NVIC поддерживает до 250 уровней прерываний. Просто не во всех МК это количество реализовано, т.к. там просто не надо.

Я очень давно приглядываюсь к ARM. Может быть там все так и есть, как Вы говорите. Но у меня есть рад вопросов к архитектуре ядра и к NVIC, на которые вразумительных ответов в документации я не нашел. Качество самой документации от ARM - очень низкое. По крайней мере на Thumb2.
В отличие от...
Но это выходит за рамки применения RTOS. Если хотите, можно сделать отдельную тему - "Изучаем/Применяем ARM Cortex М".
Перейти в начало страницы
 
+Цитировать сообщение
Idle
сообщение 9.1.2012, 17:21
Сообщение #48


Активный участник
***

Группа: Пользователи
Сообщений: 1075
Регистрация: 22.11.2009
Пользователь №: 20



Цитата(Прохожий @ 9.1.2012, 18:34) *
ADI - это кто?

скорее всего Analog Devices, Inc. (NYSE: ADI)

Перейти в начало страницы
 
+Цитировать сообщение
dxp
сообщение 10.1.2012, 8:18
Сообщение #49


Adept
***

Группа: Пользователи
Сообщений: 522
Регистрация: 20.4.2011
Из: Novosibirsk
Пользователь №: 346



Цитата(Прохожий @ 9.1.2012, 20:34) *
В моем случае время реакции на простое событие - конец отсчета таймера - это время, необходимое МК для входа в обработчик прерывания (прерывание пипелайна и аппаратное сохранение контекста). В случае сложного события - когда этот таймер увязан еще на что-то - к этому времени добавляются простые логические операции. Все считается с точностью до такта.

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

Цитата(Прохожий @ 9.1.2012, 20:34) *
Еще раз извините, но Вы пока еще не поняли сути подхода, о котором я рассказываю. Попытаюсь объяснить.
Заодно, отвечу и на эти вопросы:

Извините, если буду банален и будет много букофф.
Любую программу, выполняемую на МК, в простейшем виде можно представить как последовательность неких операторов.

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

Цитата(Прохожий @ 9.1.2012, 20:34) *
Но на самом деле все очень просто. Если отойти в сторону от парадигмы непременной линейности кода, за которую Вы ратуете.

А зачем от неё отходить? Это и была цель - сделать написание кода простым и прозрачным, без видимых ветвлений и явных "завязок" на конкретные прерывания.

Цитата(Прохожий @ 9.1.2012, 20:34) *
Каждый процесс представляется в виде автомата, иногда вырожденного, как в моем примере. И переход этого автомата из состояния в состояние осуществляется в прерываниях с действиями на переходах. Программа в этом случае может вообще не иметь суперлупа, а МК может переходить в спячку до следующего события.

Я всё-таки не вижу ответа на свой простой вопрос: как осуществляется передача управления при возникновении события. Т.е. вот работает какой-то код - например, длительные вычисления в низком приоритете, а ваш автомат ждёт события от таймера. Происходит прерывание, в котором состояние автомата обновляется - теперь нужно передать управление этому автомату, чтобы он отработал новое состояние, но при выходе из прерывания поток выполнения попадёт в прерванный код (так устроена аппаратура процессора), а не в автомат. Так вот, вопрос в том, как при возникновении события передать управление сразу автомату? В RTOS'ах это реализуется путём специальных механизмов, которые переключают контексты процессов, и из прерывания поток выполнения сразу попадает в нужное место, а не в прерванный код. Вот и интересно, как вы добиваетесь такого же поведения (по вашим словам) без RTOS'овых механизмов.

Цитата(Прохожий @ 9.1.2012, 20:34) *
Да нет проблем.
Кусок из пресловутого терморегулятора:
Код
float t;
char i;
...
switch (ThermoType)
{
<...>    }
    break;
............
Ну и так далее для остальных типов термопар.

Здесь е - нормализованное значение термо ЭДС, ThermoType - номер типа термопары.
t - температура.
R0, R1, R2, R3 - массивы коэффициентов полиномов для каждого из диапазонов термо ЭДС для термопары типа R.

Что-то у нас с вами как-то не ладится взаимопонимание. Я вам про Фому, вы мне про Ерёму. Я вас просил показать реализацию вычисления полинома - так, чтобы оно не мешало работе с периферией, которая не будет ждать. Вы мне какой-то левый код обработки термодачтиков. Покажите реализацию предъявленного полинома, чтобы его вычисление не мешало приёму и отправке пакетов байтов через UART на скорости 9600 бод.

Цитата(Прохожий @ 9.1.2012, 20:34) *
Без всяких шуток. А Вы на людях эксперименты проводили? Давали посмотреть свой код кому-нибудь еще?
Ведь читаемость и сопровождаемость - понятия относительные и очень субъективные.

Конечно. У нас целое семейство проектов, где большая часть кода просто заимствована. Работают разные люди. Нареканий нет. То, что RTOS позволяет формализовать подход в организации потока выполнения программы, оказывается очень кстати при работе в команде.

Цитата(Прохожий @ 9.1.2012, 20:34) *
ADI - это кто? Гугель на вскидку дает это.

Нет, это Analog Devices Inc.

Цитата(Прохожий @ 9.1.2012, 20:34) *
Я с Вами соглашусь, когда среды разработки будут бесплатными.

Их есть.

Цитата(Прохожий @ 9.1.2012, 20:34) *
1. Наличие адекватного симулятора.

А это-то зачем, когда щас в любом проце эмулятор имеется?

Цитата(Прохожий @ 9.1.2012, 20:34) *
2. Наличие удобной IDE. Никаких make файлов (только по запросу, если сильно кому надо).

Как всё запущено. smile.gif Я так скажу - такие IDE фтопку! Кроме шуток. Они хороши для тотальных бегиннеров или только для того, чтобы быстро попробовать. Для серьёзной работы рулит хороший программерский редактор + система сборки (make или что-то иное (у меня SCons)).

Цитата(Прохожий @ 9.1.2012, 20:34) *
Ого! Целых 300 команд. Расточительно, однако.

Не команд, а тактов. У этого процессора контекст большой - 180 байт. Но полторы микросекунды не напрягают совершенно. Проц, кстати, без проблем может работать на 500 МГц, просто мне это не надо, электроэнергию экономлю, а успевает он со свистом и на 200 МГц.

Цитата(Прохожий @ 9.1.2012, 20:34) *
Честно скажу, не увидел в нем ничего особо выдающегося.
Может быть я его готовить не умею?

Очень гибкая среда, всё позволяет настроить. Правда, надо с системами сборки дружить, хотя бы на уровне базовых принципов. Минус для меня был - тормознутая она весьма, во всяком случае была года полтора назад, когда я её щупал. Поэтому до сих пор сижу на слике.
Перейти в начало страницы
 
+Цитировать сообщение
Гость_MrYuran_*
сообщение 10.1.2012, 8:36
Сообщение #50





Гости






Цитата(dxp @ 10.1.2012, 10:18) *
Покажите реализацию предъявленного полинома, чтобы его вычисление не мешало приёму и отправке пакетов байтов через UART на скорости 9600 бод.

Попробую угадать: автомат, расположенный в прерывании UARTа.
Я с этого начинал 6 лет назад, и постепенно отказался в пользу карусельного поллинга в суперлупе.
При всех сопутствующих издержках, получается структурнее, более предсказуемо и переносимо (даже из проекта в проект).
Ну и естественно, (RT)OS - следующий логический шаг на пути к всеобщей гармонии и стандартизации.
Это правильно подмечено, что общая платформа в виде RTOS дисциплинирует и приводит к общему знаменателю разношерстный мелкопрограммерский коллектив.
Кстати, тоже сейчас на МСП сидим, но уже в глубоких раздумьях по поводу STM32.
Перейти в начало страницы
 
+Цитировать сообщение
_pasha
сообщение 10.1.2012, 10:01
Сообщение #51


тот самый
Иконка группы

Группа: Мод
Сообщений: 13629
Регистрация: 24.11.2009
Из: Харьковская обл., UA
Пользователь №: 25



Цитата(dxp @ 10.1.2012, 8:18) *
Очень гибкая среда, всё позволяет настроить. Правда, надо с системами сборки дружить, хотя бы на уровне базовых принципов. Минус для меня был - тормознутая она весьма, во всяком случае была года полтора назад, когда я её щупал. Поэтому до сих пор сижу на слике.

Да, если бы там таггер был не на жабе... Не будет клипса шустрой никогда.
Перейти в начало страницы
 
+Цитировать сообщение
Гость_MrYuran_*
сообщение 10.1.2012, 10:33
Сообщение #52





Гости






Цитата(_pasha @ 10.1.2012, 12:01) *
Да, если бы там таггер был не на жабе... Не будет клипса шустрой никогда.

Излишества типа парсинга на лету можно и отключить, если уж прижмет.
А поскольку сейчас даже самые дешёвые нетбуки на 2-ядерных процессорах делают, то вообще проблем никаких.
Зато никаких вопросов типа "как запустить под линуксом".

А для меня лично главное преимущество всех свободных систем - возможность работать с любой флешки, не заморачиваясь с установкой и уж тем более (боже упаси) с кряками/патчами етц. Если ранняя клипса требовала какой-то минимальной установки, то нынешняя вообще идет в виде рабочей копии.
Перейти в начало страницы
 
+Цитировать сообщение
_pasha
сообщение 10.1.2012, 10:54
Сообщение #53


тот самый
Иконка группы

Группа: Мод
Сообщений: 13629
Регистрация: 24.11.2009
Из: Харьковская обл., UA
Пользователь №: 25



Парсинг на лету - это как воздух. Особенно там, где чувствительность к регистру.
Когда постоянно сидел в паскале, ассемблере - потребности никакой в этом не ощущал.
Перейти в начало страницы
 
+Цитировать сообщение
dxp
сообщение 10.1.2012, 14:16
Сообщение #54


Adept
***

Группа: Пользователи
Сообщений: 522
Регистрация: 20.4.2011
Из: Novosibirsk
Пользователь №: 346



Цитата(MrYuran @ 10.1.2012, 12:36) *
Попробую угадать: автомат, расположенный в прерывании UARTа.

Ну, это не спортивно. smile.gif На прерываниях, конечно, можно приоритетный код выполнять, только это не очень способствует реализации более-менее больших кусков кода, а иначе тормоза остальной программы.

Цитата(_pasha @ 10.1.2012, 14:01) *
Да, если бы там таггер был не на жабе... Не будет клипса шустрой никогда.

Да, именно оно и тормозило больше всего. Поэтому и остался на слике - этот шустрый и умеет всё это с незапамятных времён.

Цитата(MrYuran @ 10.1.2012, 14:33) *
Излишества типа парсинга на лету можно и отключить, если уж прижмет.

Ну уж нет. smile.gif Эта штука оченно полезная и сильно экономит силы и нервы, особенно когда проект немалый - быстренько сходили, посмотрели, что за объект такой, вернулись и "продолжаем разговор" - на всю операцию пара-тройка секунд. Ну, и автодополнение и контроль области видимости тоже в тему - пресекает ошибки кодирования непосредственно на этапе кодирования.
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 10.1.2012, 18:26
Сообщение #55


сундук
***

Группа: Пользователи
Сообщений: 4043
Регистрация: 21.11.2009
Из: Ростов-на Дону
Пользователь №: 15



Цитата(dxp @ 10.1.2012, 10:18) *
Так при выходе из прерывания таймера, когда счётчик досчитал до нужного значения и состояние автомата обновилось, поток выполнения куда попадает?

Какой такой поток выполнения? Вы можете хоть на шаг отойти в сторону от своей парадигмы?
У меня этого понятия нет.
Цитата(dxp @ 10.1.2012, 10:18) *
Спасибо за экскурс, с удовольствием бы послушал лет 15 назад, а сегодня уже не актуально. Хочется на конкретные вопросы получить конкретные ответы, а не пространные рассуждения, уж простите.

Извините, но при отсутствии желания разобраться, Вы ничего не поймете.
Цитата(dxp @ 10.1.2012, 10:18) *
А зачем от неё отходить? Это и была цель - сделать написание кода простым и прозрачным, без видимых ветвлений и явных "завязок" на конкретные прерывания.

Хотя бы затем, чтобы осознать, что в природе существуют и другие подходы, отличные от линейного кодинга.
Простой и прозрачный код опять же только в Вашем понимании. Еще раз повторю, что в этом мире существуют и иные системы программирования.
Что касается "конкретных" прерываний. Они у большинства МК практически одинаковы в логическом аспекте.
Цитата(dxp @ 10.1.2012, 10:18) *
Я всё-таки не вижу ответа на свой простой вопрос: ...

Уверяю Вас, я практически Вам уже все рассказал. Не скрыл практически ничего.
Цитата(dxp @ 10.1.2012, 10:18) *
Что-то у нас с вами как-то не ладится взаимопонимание. Я вам про Фому, вы мне про Ерёму. Я вас просил показать реализацию вычисления полинома - так, чтобы оно не мешало работе с периферией, которая не будет ждать. Вы мне какой-то левый код обработки термодачтиков. Покажите реализацию предъявленного полинома, чтобы его вычисление не мешало приёму и отправке пакетов байтов через UART на скорости 9600 бод.

Я Вам показал. Все именно так и выглядит.
Я Вам практически все рассказал для того, чтобы можно было понять, каким образом это все проистекает.
Но попробую еще раз.
Предположим, расчет находится в суперлупе и выполняется. В этот момент очередной байт был отправлен по USART и наступает прерывание от этого периферийного устройства. В обработчике прерывания мы загружаем в регистр передатчика USART очередной байт и возвращаемся к расчетам, если в системе ничего не произошло.
Пусть, параллельно с окончанием выдачи байта, приходит передний фронт синхронизации с сетью для фазы А, заведенный на одно из внешних прерываний.
Тогда мы не вернемся к расчетам, а выполним следующие действия:
1. Изменим состояние автомата управления симистором фазы А со СТОП на ОТСЧЕТ_УГЛА;
2. Загрузим таймер, отвечающий за фазу А неким наперед рассчитанным значением.
3. Запустим этот таймер.
После этого, таки, вернемся к расчетам.
Цитата(dxp @ 10.1.2012, 10:18) *
Конечно. У нас целое семейство проектов, где большая часть кода просто заимствована. Работают разные люди. Нареканий нет. То, что RTOS позволяет формализовать подход в организации потока выполнения программы, оказывается очень кстати при работе в команде.

Ненавижу этот термин - "работать в команде". Тем не менее, в той же Италии существуют достаточно большие коллективы, которые сопровождают огромные проекты для PLC. Они - эти PLC работают исключительно на прерываниях, где нет потока выполнения в Вашем понимании. Ну и RTOS соответственно.

Цитата(dxp @ 10.1.2012, 16:16) *
Ну, это не спортивно. smile.gif На прерываниях, конечно, можно приоритетный код выполнять, только это не очень способствует реализации более-менее больших кусков кода, а иначе тормоза остальной программы.

Если Вы не умеете этого делать, то это не означает того, что этого не умеют делать остальные...
Симуляторы как раз и предназначены для того, чтобы обеспечить именно это.


Цитата(MrYuran @ 10.1.2012, 10:36) *
Попробую угадать: автомат, расположенный в прерывании UARTа.

Не угадали. Фикус в том, что автомат распределен по прерываниям. Что гораздо более естественно:
Цитата(MrYuran @ 10.1.2012, 10:36) *
... карусельного поллинга в суперлупе.

...хотя и это используется тоже. И не только...
Цитата(MrYuran @ 10.1.2012, 10:36) *
Ну и естественно, (RT)OS - следующий логический шаг на пути к всеобщей гармонии и стандартизации.
Это правильно подмечено, что общая платформа в виде RTOS дисциплинирует и приводит к общему знаменателю разношерстный мелкопрограммерский коллектив.

Опять же. Это только для Вас. Нельзя отображать свои комплексы на остальных.
Если Вы не в состоянии структурировать алгоритм, кроме как линейным кодом, то это Ваша проблема, а не достоинство.
Простите за резкость.
Огромное количество специалистов не нуждаются в линейном коде.
И нет ничего удивительного в том, что не все Ваши коллеги воспринимают Ваши подходы.
Может быть они наделены тем, чего нет у Вас?
Перейти в начало страницы
 
+Цитировать сообщение
dxp
сообщение 10.1.2012, 20:45
Сообщение #56


Adept
***

Группа: Пользователи
Сообщений: 522
Регистрация: 20.4.2011
Из: Novosibirsk
Пользователь №: 346



Цитата(Прохожий @ 10.1.2012, 22:26) *
Какой такой поток выполнения? Вы можете хоть на шаг отойти в сторону от своей парадигмы?
У меня этого понятия нет.

Поток выполнения программы - устоявшийся термин (program control flow). Если вступаете в такие дискуссии, то азы бы надо знать.

* * *
При всём уважении, замечу, что вы переходите рамки, переходите на личности, не замечая собственных недостатков (коих в избытке) в знаниях.

Цитата(Прохожий @ 10.1.2012, 22:26) *
...
Извините, но при отсутствии желания разобраться, Вы ничего не поймете.
...
Простой и прозрачный код опять же только в Вашем понимании. Еще раз повторю, что в этом мире существуют и иные системы программирования.
...
Если Вы не умеете этого делать, то это не означает того, что этого не умеют делать остальные...

Опять же. Это только для Вас. Нельзя отображать свои комплексы на остальных.

Если Вы не в состоянии структурировать алгоритм, кроме как линейным кодом, то это Ваша проблема, а не достоинство.
...
И нет ничего удивительного в том, что не все Ваши коллеги воспринимают Ваши подходы.
Может быть они наделены тем, чего нет у Вас?


Я был предельно корректен и вежлив и достаточно терпел необоснованные заявления по поводу подходов в разработке софта, инструментария и процессоров. Но толку нет, дошло до того, что посыпались обвинения в невежестве, неумении и прочем. Отвечу теперь без обиняков, не обессудьте.

Вы демонстрируете удивительную зашоренность в знаниях по очень широкому спектру вопросов embedded программирования. Вы понятия не имеете, как устроена и функционирует приоритетная вытесняющая RTOS, предлагая в качестве альтернативы примитивный подход, когда код, рассован по прерываниям - такие программы я успешно писал 10 лет назад, пока не вышел на новый уровень понимания в организации потоков управления (да, да, именно потоков управления - есть такое технический термин). Уровень вашего кода на два порядка ниже по сложности уровня кода любой простейшей RTOS. И вы при этом не стесняетесь обвинять в невежестве тех, кто разобрался досконально в этом и успешно применяет, зряче и эффективно.

Вы понятия не имеете о том, как организуется эффективная среда разработки, основанная на редакторах с поддержкой context tagging, обработкой вывода с анализом на основе регулярных выражений, мощными средствами навигации по проекту, системах сборки проектов, основанных на скриптах, позволяющих делать что угодно, а не только то, что предоставляет IDE в виде чекбоксов. Но это не мешает вам критиковать этот подход.

Про С++ говорить не буду, тут мы его не обсуждали, зато обсуждали на элхе. Симптомы ровно те же.

На этом я, пожалуй, с вами дискуссию на эту тему закончу. Прошу просить, если был излишне резок. Всего доброго.
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 10.1.2012, 21:02
Сообщение #57


сундук
***

Группа: Пользователи
Сообщений: 4043
Регистрация: 21.11.2009
Из: Ростов-на Дону
Пользователь №: 15



Цитата(dxp @ 10.1.2012, 22:45) *
На этом я, пожалуй, с вами дискуссию на эту тему закончу. Прошу просить, если был излишне резок. Всего доброго.

Я тоже несколько устал от разговора в позиции младшего брата.
Опять же, приношу извинения, если чем-то Вас обидел.
Обвинений Вас в невежестве не было.
Было предположение, что некоторые вещи Вам даются тяжело, и Вы нашли иные пути для решения этих проблем.
Которые недоступны мне в силу моих собственных невежестве и лени.
И, если можно, хотелось бы глянуть Ваш код 10-летнй давности.
P. S. Я сожалею, что так вышло...
Перейти в начало страницы
 
+Цитировать сообщение
_pasha
сообщение 11.1.2012, 2:42
Сообщение #58


тот самый
Иконка группы

Группа: Мод
Сообщений: 13629
Регистрация: 24.11.2009
Из: Харьковская обл., UA
Пользователь №: 25



Мне вот другой вопрос интересен.
Где конечный автомат может выиграть, если ресурсы не напрягают применять ось? Если не вспоминать про размеры контекста итд итп и не затрагивать GUI, там везде мрачные автоматы, чёрт голову сломит smile.gif
Перейти в начало страницы
 
+Цитировать сообщение
_pasha
сообщение 11.1.2012, 5:58
Сообщение #59


тот самый
Иконка группы

Группа: Мод
Сообщений: 13629
Регистрация: 24.11.2009
Из: Харьковская обл., UA
Пользователь №: 25



Я еще когда на асме для авров сидел, это начиная года с 1999 по 2007, когда Winavr соответствующий стал устраивать, созрел к середине этого периода до самописных реалтаймовых приемов, благодаря ассемблеру меня не смущал размер контекста, ибо ручками его ограничивал до нужного набора регистров, обычно это были X,Y,Z и пара для знакового умножения, остальные служили для прерываний, системных вызовов, упрощали синхронизацию итд итп
С бесповоротным переходом на Си стала рулить кооперативка на прото..не буду больше всуе smile.gif
Ессно, раз и навсегда распрощавшись с грязной любовью к авркам, никаких сомнений не будет по поводу перехода на ось, извиняюсь за лесть в сторону dxp, мне scmRTOS как-то больше приглянулась, или на крайняк по-Клёновски фриртос оберну в классы. Но это должен Везувий проснуться, чтоб я куда-то спрыгнул. Кстати, были у меня проёбы на sam7s***, по-старинке ось по-боку, натрахался наверняка больше, чем мог бы с фриртосом. Но тогда zltigo чуть ли не каждый день обновления отписывал, испугало.
Ну, PICи двигательные, - тут я тоже консерватор, хоть и ресурсов на dsPIC - выше крыши будет. И все еще 18F2431 ставлю - скоро выжму из них 100% возможностей, с очередными совершенствованиями, но блин, они дубовые, значит - крепкие smile.gif
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 11.1.2012, 19:00
Сообщение #60


сундук
***

Группа: Пользователи
Сообщений: 4043
Регистрация: 21.11.2009
Из: Ростов-на Дону
Пользователь №: 15



Цитата(GuruKiller @ 11.1.2012, 6:56) *
К сожалению, уважаемый Прохожий не может сравнить варианты объективно.

Безусловно.
Хотя бы потому, что с ОС дела не имел в практическом смысле.
Но просматривал несколько.
ПМСМ, беда такого раздела человеческой деятельности, как программирование, в том, что нормального результата можно достичь разными способами.
В отличие от силовой электроники, скажем. Поскольку там все просто - некорректные действия караются немедленно.
Отсюда - разница во взглядах на это дело.
Уважаемый dxp, безусловно, имеет в нем больший опыт, нежели я.
Точно так же, как и MrYuran, хотя бы потому что это их основной способ существования.
Но и мои проекты проверены временем и жесткими условиями эксплуатации.
Один из проектов, правда, не очень большой, сопровождается уже порядка 7 лет и совсем без меня.
Ряд проектов средней сложности работают от года до 4-х лет без выключения оборудования.
Опять же сопровождаются с моим достаточно редким участием.
Следовательно, подходы, мною озвученные, имеют право на жизнь.
С другой стороны, RTOS и ООП на сегодня - это, де факто, мэйнстрим.
Этим по долгу службы занимается достаточно большое количество народу.
А поскольку я свободный художник, то могу себе позволить несколько выпасть из "потока управления".
И исследовать альтернативные подходы.
Их суть я и пытался изложить...
Вышло не очень. В чем признаю только свою вину.
Перейти в начало страницы
 
+Цитировать сообщение

8 страниц V  < 1 2 3 4 5 > » 
Ответить в данную темуНачать новую тему
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 



Текстовая версия Сейчас: 29.3.2024, 1:01