IPB

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

8 страниц V  « < 3 4 5 6 7 > »   
Ответить в данную темуНачать новую тему
> RTOS: распространенные заблуждения, Обсудим?
Прохожий
сообщение 15.1.2012, 14:44
Сообщение #81


сундук
***

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



Цитата(_pasha @ 15.1.2012, 14:50) *
Шоза игрушки? Я не барышня, вопервых.

Потомушо собираюсь советовать.
А на грабли второй раз - ни малейшего желания.
Тем не менее.
ПМСМ, 1-Wire вообще не ложится в канву линейного кодирования в связи с большим количеством временных слотов.
И в связи с этим советы:
1. Отказаться при организации таймингов от использования спецфункций.
2. Все сделать на программных таймерах, тикающих в прерывании, а запускаемых и останавливаемых там, где нужно.
3. Выход программного таймера - булева переменная, используемая в логическом выражении в месте применения.
4. Вход тоже.
5. Таймеры могут быть разными - с задержкой включения, выключения, одновибраторы и т. д.
Можно даже создать некие программные сущности в виде структур и функций. Как Вы любите.
Собсна все.
Звиняйте, ежели сказал банальность и Вам она без надобности.
Перейти в начало страницы
 
+Цитировать сообщение
Гость_MrYuran_*
сообщение 15.1.2012, 16:33
Сообщение #82





Гости






Цитата(Прохожий @ 15.1.2012, 16:44) *
ПМСМ, 1-Wire вообще не ложится в канву линейного кодирования в связи с большим количеством временных слотов.

Критично только начало тайм-слота, это порядка 10-15 мкс.
Можно оформить в критическую секцию.
Кстати, РТОС ни разу не мешает обычным прерываниям, т.к. диспетчер задач вешается на самое низкоприоритетное прерывание из всех возможных.
То есть все обычные прерывания будут выполняться как ни в чем не бывало.
А ещё лучше повесить это дело на аппаратный выход одной из защелок таймера - тогда вообще по барабану на все софтверные примочки.
Ну а самая халява - пожертвовать уартом.
Перейти в начало страницы
 
+Цитировать сообщение
Secter
сообщение 15.1.2012, 19:00
Сообщение #83


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

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



Цитата(Idle @ 13.1.2012, 13:12) *
не согласен, для работников есть тк и нечего тут юлить, вот с партнёрами договаривайся как хочешь

pardon.gif ...а несогласных трутникофф сразу в очередь на биржу...))) ...лишний рот, артели горе... biggrin.gif
Перейти в начало страницы
 
+Цитировать сообщение
Idle
сообщение 15.1.2012, 19:22
Сообщение #84


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

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



так а я о чём? есть установленная законом процедура увольнения, вот и пользуйся
они все любят ныть про отсутствие материальной ответственности, барыги чёртовы, продажи видишь ли у него
Перейти в начало страницы
 
+Цитировать сообщение
Secter
сообщение 15.1.2012, 19:24
Сообщение #85


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

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



Цитата(Idle @ 15.1.2012, 20:22) *
так а я о чём? есть установленная законом процедура увольнения, вот и пользуйся

))) ...да ну на... biggrin.gif ...сам уволится.
Перейти в начало страницы
 
+Цитировать сообщение
Гость_MrYuran_*
сообщение 17.1.2012, 6:53
Сообщение #86





Гости






Цитата(GuruKiller @ 16.1.2012, 22:24) *
Ввинде потоками являются не только потоки с хэндлами, но и обработчикивсяких кнопок, событий и прочее. Они так же выполняютсяпсевдопаралельно в виде отдельного от всего остального кода.

Разница в том, что процессы в винде создаются и управляются средствами ОС, а потоки (нити) - уже непосредственно внутри процесса и напрямую на ось не завязаны.
РТОС в большинстве своем - это как раз вот этот низовой уровень, соответстующий потокам во "взрослых" ОС.
Причем, создание потоков может быть как динамическим (FreeRTOS), так и статическим, заданным раз и навсегда при компиляции.
Если уж совсем минимизировать оверхед (хотя в нынешних условиях "гонки вычислительных вооружений" об этом приходится задумываться все меньше), то можно применить невытесняющие (кооперативные) оси. Они практически соответствуют (и не мешают) "безосевому" подходу, но имеют встроенные сервисы, упрощающие жизнь.
Вырожденный случай - protothreads.
Переключалка, реализованная на макросах прекомпилятора и операторе switch. Авто-автомат.
Перейти в начало страницы
 
+Цитировать сообщение
_pasha
сообщение 17.1.2012, 13:49
Сообщение #87


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

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



Цитата(GuruKiller @ 16.1.2012, 20:24) *
В винде потоками являются не только потоки с хэндлами, но и обработчики всяких кнопок, событий и прочее. Они так же выполняются псевдопаралельно в виде отдельного от всего остального кода.

Становится интересно, с чего Вы так решили? smile.gif Коллбэк может запускать какие-то нити, а может и нет. Хелловорлд может написать и сдохнуть. smile.gif

Цитата(MrYuran @ 17.1.2012, 6:53) *
можно применить невытесняющие (кооперативные) оси.
Вырожденный случай - [censored]

Со временем на первый план выходит гибрид указанного "случая" с написанными в таком же стиле ISR. Красиво получаиццо, кстати.
Перейти в начало страницы
 
+Цитировать сообщение
_pasha
сообщение 17.1.2012, 14:40
Сообщение #88


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

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



Значит, где-то умолчания "подправлены".
Перейти в начало страницы
 
+Цитировать сообщение
_pasha
сообщение 17.1.2012, 15:04
Сообщение #89


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

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



Не, я енаблед отключал на длинных операциях, но не докапывался до того, что оно мильтредед, не было смысла. В коллбэке не задерживался, запускался соответствующий Tthread.execute, а там, конечно, могли быть и свои проверки, типа через исключения EThreadInUse. Такшта, до сих пор сомневаюсь в чистоте эксперимента. С дельфей ушел, лазарус форева. Аж интересно проверить, шоза.
Перейти в начало страницы
 
+Цитировать сообщение
Гость_AlexKlm_*
сообщение 21.1.2012, 22:49
Сообщение #90





Гости






Цитата(Прохожий @ 5.1.2012, 20:48) *
Это я к тому, что текст одинаковый, а читаем мы с Вами, что-то разное.
Я бы хотел узнать, в чем по мнению окружающих, с автором статьи можно согласиться, а с чем можно поспорить в области применения RTOS.

Если в микроконтроллер будут в процессе эксплуатации загружаться разные программы, то безусловно RTOS это плюс. Плюс может быть также в том что может быть в меньшем количестве требуемого кода для писанины программистом, может и меньше ошибок. Но минус в том что поедает ресурсы, память, особенно там где она на на исходе. По поводу ДОСа ведь таких вопросов не возникало. Кстати, тот же бутлодер - это тоже в определённой мере RTOS.
Чёткой границы между началом RTOS и её отсутствием нет.



Перейти в начало страницы
 
+Цитировать сообщение
_pasha
сообщение 26.1.2012, 15:33
Сообщение #91


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

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



Постоянно мозолит глаза догадка, что если забить на разделение ртос и биоса, то получается намного более удачная штуковина.
Т.е. например контекстопереключатель, планировщик и примитивы синхронизации объявляем архитектурно зависимыми - и вуаля - оно плавно кочует в наполнение HAL, а понятия "ртось" вроде как и не было никогда smile.gif
Собсна, с чего и начинался разговор.
Перейти в начало страницы
 
+Цитировать сообщение
dxp
сообщение 26.1.2012, 17:15
Сообщение #92


Adept
***

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



Цитата(_pasha @ 26.1.2012, 19:33) *
Т.е. например контекстопереключатель, планировщик и примитивы синхронизации объявляем архитектурно зависимыми - и вуаля - оно плавно кочует в наполнение HAL, а понятия "ртось" вроде как и не было никогда smile.gif
Собсна, с чего и начинался разговор.

Не, не канает. Планировщик и сервисы по своей сути являются платформеннонезависимыми и в платформеннозависимом коде им не место ни с какой стороны. Сам по себе HAL, как правило, значительно проще и меньше по объёму того, что вы предлагаете добавлять в него.
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 18.2.2012, 14:27
Сообщение #93


сундук
***

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



Цитата(dxp @ 26.1.2012, 18:15) *
Не, не канает. Планировщик и сервисы по своей сути являются платформеннонезависимыми и в платформеннозависимом коде им не место ни с какой стороны. Сам по себе HAL, как правило, значительно проще и меньше по объёму того, что вы предлагаете добавлять в него.

Тоже соглашусь.
Даже при моем подходе предпочитаю HAL делать отдельно.
Там совершенно другие задачи.
Требующие иных подходов и другой базы знаний.
Интересно было бы узнать, что каждый из нас подразумевает под HAL, чтобы разговор получился конструктивным.
Перейти в начало страницы
 
+Цитировать сообщение
dxp
сообщение 18.2.2012, 20:08
Сообщение #94


Adept
***

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



Цитата(Прохожий @ 18.2.2012, 18:27) *
Интересно было бы узнать, что каждый из нас подразумевает под HAL, чтобы разговор получился конструктивным.

HAL - аббревиатура говорит сама за себя: Hardware Abstraction Level. Совокупность кода (набор функций, библиотека и т.п.), предоставляющая некий аппаратно- и платформенно-независимый интерфейс (типа API). Некая прослойка между аппаратурой процессора и прикладной программой. С одной стороны этой прослойки плотная завязка на регистры, биты управления аппаратными частями процессора (таймеры, порты и т.д.), с другой - формализованный интерфейс доступа.

Это позволяет значительно облегчить переносимость кода - при портировании достаточно только переработать эту самую прослойку. При условии, конечно, что там всё правильно и грамотно спроектировано и на прикладной уровень не проникло никаких target specific features. smile.gif
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 19.2.2012, 9:47
Сообщение #95


сундук
***

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



Цитата(dxp @ 18.2.2012, 21:08) *
HAL - аббревиатура говорит сама за себя: Hardware Abstraction Level. Совокупность кода (набор функций, библиотека и т.п.), предоставляющая некий аппаратно- и платформенно-независимый интерфейс (типа API). Некая прослойка между аппаратурой процессора и прикладной программой. С одной стороны этой прослойки плотная завязка на регистры, биты управления аппаратными частями процессора (таймеры, порты и т.д.), с другой - формализованный интерфейс доступа.

Это правильное определение. Практически один в один совпадает с учебниками.
Но чаще говорят о Hardware Abstraction Layer, т. е. не уровень, а слой.
А это меняет дело. Т.е речь идет о программной прослойке между железом и софтом верхнего уровня.
Лично я его воспринимал с другой стороны. Но это, когда речь об уровне.
Иными словами ты работаешь на уровне, когда тебе не надо задумываться об особенностях архитектуры выбранного вычислителя.
Цитата(dxp @ 18.2.2012, 21:08) *
Это позволяет значительно облегчить переносимость кода - при портировании достаточно только переработать эту самую прослойку. При условии, конечно, что там всё правильно и грамотно спроектировано и на прикладной уровень не проникло никаких target specific features. smile.gif

А я иногда провожу испытания кода, который над HAL, в Builder-е.
Так значительно удобнее - можно построить всяких графиков, да и результаты проще выводить на экран.
К примеру, правильность расчетов полиномов для термопар проверялась по таблицам, приведенным в ГОСТ-е вместе с полиномами.
Т.е. подход с разделением софта на HAL и не HAL используется не для кросс платформенности, а для моделирования.

В связи с этим имеется некий спорный тезис.
Некоторые программисты считают, что в МК порты ввода-вывода, например, должны быть доступны с высокого уровня практически напрямую.
Противоречит ли это требованию о запрете target specific features на уровне/слое выше HAL?
Перейти в начало страницы
 
+Цитировать сообщение
_pasha
сообщение 19.2.2012, 9:54
Сообщение #96


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

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



Цитата
считают, что в МК порты ввода-вывода, например, должны быть доступны с высокого уровня практически напрямую.

Наверное не конкретно порты, а отдельные ноги и на уровне "вкл/выкл такое-то реле" или выдать такое-то значение в порт жки, причем "порт" может в реале собираться из битов в разных физ. портах МК, а иногда еще и через ж.. железную логику на плате smile.gif
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 19.2.2012, 10:14
Сообщение #97


сундук
***

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



Цитата(_pasha @ 19.2.2012, 10:54) *
Наверное не конкретно порты, а отдельные ноги и на уровне "вкл/выкл такое-то реле" или выдать такое-то значение в порт жки, причем "порт" может в реале собираться из битов в разных физ. портах МК, а иногда еще и через ж.. железную логику на плате smile.gif

Вот иманно.
Но здесь и кроется базовое противоречие кросс платформенности.
Мы уходим от "железа" МК, но приходим к железу натуральному - всяким толкателям, мальтийским колесам, карманам, конвейерам и прочей механической фигне.
И самое прикольное в том, что натуральное железо еще более уникально, чем "железо" МК, даже если оно от Microchip-а.

Цитата(GuruKiller @ 19.2.2012, 11:04) *
Но выделенное мной никак не обясняет, а даже наоборот подтверждает причину того, почему в ПО задачи нижний уровень не нужен. Ну и сответственно какая-то "прокладка".

А развернуть сию мысль?
С учетом того, что тут не все люди соображают быстро...
Перейти в начало страницы
 
+Цитировать сообщение
_pasha
сообщение 19.2.2012, 10:17
Сообщение #98


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

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



Цитата(Прохожий @ 19.2.2012, 10:12) *
Вот иманно.
Но здесь и кроется базовое противоречие кросс платформенности.

Гы. Некоторые считают, что очень хорошо забить на тело функции main() и более не возвращаться к нему smile.gif
Такая позиция понятна на писишном программировании, но совершенно не понятна в ымбеде. Там же, в главном файле, и должны собираться все уровни.
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 19.2.2012, 10:33
Сообщение #99


сундук
***

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



Цитата(_pasha @ 19.2.2012, 11:17) *
Гы. Некоторые считают, что очень хорошо забить на тело функции main() и более не возвращаться к нему smile.gif
Такая позиция понятна на писишном программировании, но совершенно не понятна в ымбеде. Там же, в главном файле, и должны собираться все уровни.

Так и сделано, к примеру, в PLC-шном подходе у SIEMENS-а.
Да и у остальных тоже, только слегка изменен профиль...
Есть основной блок OB1, в котором сосредоточены вызовы всех остальных исполняемых блоков.
А блоки, отвечающие за немедленную реакцию, имеют отдельные системные номера.
К примеру OB35 - прерывание от системного таймера.
OB100 - стартовый блок, выполняемый при холодном и горячем рестарте.
И т. д. Конкретные номера можно выяснить из документации на конкретный контроллер.
Но там ты имеешь дело со своеобразным HAL, который является данностью.
Вместо архитектуры МК тебе подставляют более простую архитектуру.

А что касается эмбеда (не путать с Ымбедом), то здесь все зависит от подхода.
Если он событийный, то функция main() не является необходимостью.
МК может находиться в спячке, а просыпаться только в ответ на те или иные события.
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 19.2.2012, 11:21
Сообщение #100


сундук
***

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



Цитата(GuruKiller @ 19.2.2012, 11:41) *
Если не нужно задумываться об уровне аппаратуры проца, то зачем ПО задачи иметь какие-то самые низкоуровневые вещи. Это как конус - выбери точку опоры, обрежь. Снизу HAL, сверху верхний уровень, или как он там называется. Зачем этот конус резать колбасой и в середине будет кусок HAL. А ниже что? И кому это что принадлежит - ПО задачи?

Сейчас поясню.
К примеру. Панель оператора и PLC.
Там есть такое понятие, как тэг.
Это такая штука, которая связывает данные из PLC с изображением на панели.
Причем, это может быть что угодно, начиная от отдельного бита и заканчивая структурой.
Важно, чтобы обе стороны понимали о чем речь.
При этом разработчик системы панель оператора <-> PLC совершенно ничего не знает о механизмах связи между ее компонентами.
Его низкий уровень - это картинки, окошечки, кнопочки, перделки и свистелки.
В результате пользователь с панели оператора может включить/выключить свет в сортире на пятом этаже подконтрольного здания.
Т. е. имеете возможность управлять низким уровнем с помощью ПО верхнего уровня.

Цитата(GuruKiller @ 19.2.2012, 11:04) *
ИМХО зависит от сложности задачи.

Давайте не будем говорить о мелких задачах, где даже функция main() вырожденная.
О них можно будет отдельно потом...
Цитата(GuruKiller @ 19.2.2012, 11:04) *
И от необходимости в мультиплатформенности. В простых проектах, в которых изменения вносятся за малое, как вариант можно выносить LowLevelFunctions (управления портами и прочее) в хидеры, в которых либо инлайном, но я предпочитаю дефайны управляющие этими делами. При переносе на другую платформу (и даже просто на слегка другой проц => NXP ARM7 -> NXP CM3) можно менять хидер, а не основной код. Это разумеется выжимает максимум эффективности кода. Это всё касаемо эмбеддед-ПО.

Я так делал даже на АСМ-е. Потому как, вдруг ноги поменять надо?
И дабы не рыть весь текст, то, конечно, дефайн в хидере - оптимум.
Цитата(GuruKiller @ 19.2.2012, 11:04) *
Типа мы тут тактически всех победили не понеся ни одного поражения. Но в более сложном ПО, типа венды, такого низкоуровнего перфекционизма нет. Там программеры мыслят типа стратегически, вынося на первый план приоритеты верхнего уровня. Поэтому zltigo с VslavX на элхе как-то раз пытались убедить кого-то, что все программы надо писать именно так, а не иначе, и оценивать "правильность" нужно только по этой стороне вопроса. Всё остальное (особенно такое мнение у zltigo) - не важно.

Я могу лишь о своем...
Когда делал проект преобразователя на 100 кВт, то столкнулся со следующей проблемой.
С одной стороны, надо погружаться в железо МК, дабы все работало правильно.
С другой стороны, надо привязываться к самому преобразователю с его совершенно иной базой понятий и знаний.
И с третьей стороны, надо обеспечить связь с клиентом, который о первых двух сторонах ничего не знает и знать не хочет.
Но он тоже видит мир по-своему.
И каждый раз, переходя от решения одной задачи к другой, пришлось переключать мозг.
А для меня это напряжно.
Поэтому и завел речь об уровнях абстрагирования.
Нельзя ли свести всю математику к х@ям? biggrin.gif
С целью упрощения жизни...
Перейти в начало страницы
 
+Цитировать сообщение

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

 



Текстовая версия Сейчас: 28.3.2024, 10:57