RTOS во встроенных системах., Критерии применения. |
Здравствуйте, гость ( Вход | Регистрация )
RTOS во встроенных системах., Критерии применения. |
5.8.2010, 21:14
Сообщение
#41
|
|
посіпака Хунти Группа: Мод Сообщений: 20016 Регистрация: 21.11.2009 Из: Vinnitsa Пользователь №: 11 |
Та же кухня... 249 вроде приручили, но призрак кортекса бродит...
Памяти у этих MSP катастрофически мало оказалось. В свете последних веяний. |
|
|
5.8.2010, 21:18
Сообщение
#42
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Динамика сейчас очень сильная. Например, приходит снабженец и говорит: у мсп-шек f149 срок поставки внезапно стал 3 месяца. Так что готовьтесь в случае чего пересесть на f249. Их обещают за три недели. А мы их потребляем несколько сотен в месяц. Мы давай метаться, инфу качать, но потом успокоились. Там различия минимальны, а корпус вообще пин-то-пин. Но в любой момент может что угодно произойти, и надо быть к этому готовым. То экранчики не достать, то это, то другое... Ну и опять же, если переходить, то оптом, сразу везде. Чтобы закупаться большими ящиками по нормальной цене, а не у барыг втридорога. Тут как то отмечалось, что дело не в моторе ARM, MIPS, PIC, AVR, а в периферии. Под нее все равно все по-новой. А если нет, то получается привязка к производителю. Что тоже, в общем-то, нехорошо. Я для себя выбрал второй вариант. А что касается негативных тенденций с железом, то эту тему тоже надо раскрыть, ПМСМ. Мы тоже столкнулись с этим при покупке IGBT. У нас еще и контрафакт был... OFF. Хорошо было, если бы Вы нашли немного времени и просветили нас всех по поводу GNU программирования. В техническом смысле. Что, где и зачем. Я думаю, что можно было бы отдельный подфорум в рамках МК сделать... |
|
|
Гость_MrYuran_* |
5.8.2010, 21:32
Сообщение
#43
|
Гости |
Та же кухня... 249 вроде приручили, но призрак кортекса бродит... Памяти у этих MSP катастрофически мало оказалось. В свете последних веяний. После атмелов с ихними 128 (или 256?) байтами 2 кила не знали куда деть. Все вычисления - во float-ах, все флаги - как минимум char И всё равно половина остаётся... А вот флеши в индикаторном блоке с графическим экраном и поддержкой 2-х языков уже почти не осталось... |
|
|
5.8.2010, 21:58
Сообщение
#44
|
|
Админ с Элха Группа: Пользователи Сообщений: 735 Регистрация: 28.7.2010 Из: Москва Пользователь №: 188 |
Цитата Тут как то отмечалось, что дело не в моторе ARM, MIPS, PIC, AVR, а в периферии. Под нее все равно все по-новой. А если нет, то получается привязка к производителю. Именно по этой причине перешел на Линукс. В тех приложениях, где требуется реальное время, использую на низком уровне МК послабее |
|
|
5.8.2010, 22:44
Сообщение
#45
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Именно по этой причине перешел на Линукс. В тех приложениях, где требуется реальное время, использую на низком уровне МК послабее МК послабее на низком уровне - это не транзистор BC847 и не UC3842, которые делают все и по рупь ведро. Это тоже привязка к производителю, поскольку - нет компонента - нет системы. Вот и получается ходьба по замкнутому кругу. А под Линукс драйвера нужны, однако. И писать их - гемор еще тот... |
|
|
5.8.2010, 22:52
Сообщение
#46
|
|
Админ с Элха Группа: Пользователи Сообщений: 735 Регистрация: 28.7.2010 Из: Москва Пользователь №: 188 |
МК на нижнем уровне - это МК, на котром обычно уже сделана масса проектов, чтобы его выбор не вызывал вопросов.
Цитата А под Линукс драйвера нужны, однако. И писать их - гемор еще тот... Используйте стандартные интерфейсы по-максимому, для которых драйверы есть, или заведите программиста, который умеет оперативно подкрутить драйвера. Такого спеца можно использовать и на расстоянии, а не в штате держать |
|
|
6.8.2010, 19:11
Сообщение
#47
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
МК на нижнем уровне - это МК, на котром обычно уже сделана масса проектов, чтобы его выбор не вызывал вопросов. Но этот МК не из воздуха берется. Его тоже надо купить. И здесь могут быть разные косяки. Используйте стандартные интерфейсы по-максимому, для которых драйверы есть, или заведите программиста, который умеет оперативно подкрутить драйвера. Такого спеца можно использовать и на расстоянии, а не в штате держать Уж лучше зависеть от производителя МК, чем от такого снобливого и амбициозного существа, коим является системный программист. |
|
|
6.8.2010, 19:37
Сообщение
#48
|
|
посіпака Хунти Группа: Мод Сообщений: 20016 Регистрация: 21.11.2009 Из: Vinnitsa Пользователь №: 11 |
МК послабее на низком уровне - это не транзистор BC847 и не UC3842, которые делают все и по рупь ведро. Это тоже привязка к производителю, поскольку - нет компонента - нет системы. В своё время наблюдалась некая унификация распиновки MCS-51 у различных производителей и, пмсм, это было хорошо весьма. С нынешними прогрессивными архитектурами, пардон, каждый дрочит, как хочет (или же я не всё знаю?)... последнее, на что сподвигся, некий "мегадевайс", в который можно ставить 51 от нескольких производителей, или mega162 от одного-единственного, перепаяв пару-тройку "нулёвок" да блокировочных конденсаторов... |
|
|
6.8.2010, 19:58
Сообщение
#49
|
|
Активный участник Группа: Пользователи Сообщений: 1075 Регистрация: 22.11.2009 Пользователь №: 20 |
>>Уж лучше зависеть от производителя МК, чем от такого снобливого и амбициозного существа, коим является системный программист.
насквозь видят, но я не весь такой |
|
|
6.8.2010, 20:07
Сообщение
#50
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
|
|
|
6.8.2010, 20:27
Сообщение
#51
|
|
Админ с Элха Группа: Пользователи Сообщений: 735 Регистрация: 28.7.2010 Из: Москва Пользователь №: 188 |
Цитата Уж лучше зависеть от производителя МК, чем от такого снобливого и амбициозного существа, коим является системный программист. Руководитель проекта, нанимающий программиста, сам должен быть хорошим программистом, тогда зависимость минимальна, так как он же определяет, как будет строиться проект. Значит он может разделить задачи так, чтобы зависимость была минимальна |
|
|
6.8.2010, 20:57
Сообщение
#52
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Руководитель проекта, нанимающий программиста, сам должен быть хорошим программистом, тогда зависимость минимальна, так как он же определяет, как будет строиться проект. Значит он может разделить задачи так, чтобы зависимость была минимальна Приехали к известной идиоме. Если хочешь что-то сделать - сделай это сам. |
|
|
6.8.2010, 21:00
Сообщение
#53
|
|
Админ с Элха Группа: Пользователи Сообщений: 735 Регистрация: 28.7.2010 Из: Москва Пользователь №: 188 |
В конечном счете за проект отвечает его руководитель. Поэтому, как не крутись, сам все должен решать и отвечать потом
|
|
|
Гость_MrYuran_* |
6.8.2010, 21:11
Сообщение
#54
|
Гости |
|
|
|
6.8.2010, 21:18
Сообщение
#55
|
|
Админ с Элха Группа: Пользователи Сообщений: 735 Регистрация: 28.7.2010 Из: Москва Пользователь №: 188 |
Я не говорил все сам. Он за все отвечает. Если он нанимает программиста, о чем мы говорим, то уже никак не получается, что РП все делает сам )))
|
|
|
Гость_MrYuran_* |
6.8.2010, 21:26
Сообщение
#56
|
Гости |
Я не говорил все сам. Да и я не говорил, что Вы говорили. Просто есть такие руководители, которые всё время лезут в каждую щель, контролируют каждый шаг, в общем, "держат руку на пульсе". Разработчик всё время под прессом. Попробуй что не согласовать - сразу огребёшь. Вот такие, мсм, не на своём месте. Хотя бывают и диаметрально противоположные примеры. Подходит ко мне начальник и спрашивает: а ты, мол, вообще чем сейчас занимаешься? А то дело одно есть... "Ребят, может потренируемся, а?"© |
|
|
6.8.2010, 21:58
Сообщение
#57
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
В конечном счете за проект отвечает его руководитель. Поэтому, как не крутись, сам все должен решать и отвечать потом Замыкаю все на начало темы. Все согласились с тем, что РТОС нужна для кооперативного творчества. Теперь получается, что руководитель должен быть программистом. И отдать в руки бойца лишь малую часть процесса создания продукта. Которую, в принципе, может сделать и сам, потратив на это не очень много времени. Тогда возникает вопрос. А зачем нужен боец? И зачем нужна РТОС? Иными словами. В исходной позиции мы сражались с "железом". Теперь к этому "железу" добавляется дополнительная сущность в виде РТОС с документацией и багами. И дополнительный гемороой в виде коллектива программистов. Так за что боролись? |
|
|
7.8.2010, 5:25
Сообщение
#58
|
|
посіпака Хунти Группа: Мод Сообщений: 20016 Регистрация: 21.11.2009 Из: Vinnitsa Пользователь №: 11 |
Подходит ко мне начальник и спрашивает: а ты, мол, вообще чем сейчас занимаешься? А то дело одно есть... Было, пару раз. Но вот незадачка, предлагаемое дело тянуло (абсолютно без дураков) на нобелевку, а гонорар за него предлагался почему-то на два порядка меньший... |
|
|
7.8.2010, 8:19
Сообщение
#59
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
В исходной позиции мы сражались с "железом". Теперь к этому "железу" добавляется дополнительная сущность в виде РТОС с документацией и багами. В исходной позиции мы хотели построить программу для проца так, чтобы ее внутренняя организация была максимально простой, а затраты на редактирование текста, переписывание и адаптации были минимальными. Больше ни для чего эта вся ботва не нужна. Если кому-то кажется, что устройство той или иной оси слишком сложное, то это означает, что решаемые задачи не подразумевают какие-либо сложности в реализации программного алгоритма, т.е. "ВАМ НЕ НУЖНА ОСЬ". А вот по поводу хорошего API для борьбы с разношерстным железом - вот это всегда нужно. И я не верю в известные высказывания типа "вы никогда не напишите совершенный API". |
|
|
7.8.2010, 10:23
Сообщение
#60
|
|
Админ с Элха Группа: Пользователи Сообщений: 735 Регистрация: 28.7.2010 Из: Москва Пользователь №: 188 |
Если говорить о ситуации, когда с нуля вдруг пришлось взяться за решение задачи с применением ОС РВ, то здесь и спорить не очем. Если мы емеем опытного программиста, который реализовал не один проект, тогда применение ОС РВ не представляется осложняющим фактором.
Юра, я тоже не люблю людей, которые суют нос во все дела, особенно, если это руководитель. Идеальный случай, когда между коллегами есть понимание и осознание того, что в результате каждый все-таки отвечает за свою часть. Перед Заказчиком отвечает РП, но внутри коллектива каждый отвечает за свой участок. Это возможно, если программист не нанятый на один раз, когда он в деле и в доле в каком-то смысле. Тогда он на своей шкуре понимает все прелести недополучения прибыли или еще того хуже, отказа от продолжения проекта со всеми вытекающими возвратами уже потраченных средств. |
|
|
Текстовая версия | Сейчас: 29.3.2024, 13:58 |