IPB

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

8 страниц V  < 1 2 3 4 > »   
Ответить в данную темуНачать новую тему
> Споры о подходах к программированию МК, ASM vs C, и не только
Student Pupkin
сообщение 25.7.2010, 19:29
Сообщение #21


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

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



Цитата(Прохожий @ 25.7.2010, 21:02) *
Если на то будет разрешение, могу открыть соответствующую тему.

Надо открыть! Причем интересно обсудить (вернее почитать чужие мысли - сам я хера-два чего путного сказать могу, молод ысчо) - кто больше ответственен за выбор подхода? Сам программер? Или его босс? Надо ли придерживаться в отделе (команде, секторе и т.п.) одного метода, или же варьировать от проекта к проекту? И опять таки кто должен решать? Лично против привычки начальства запускать проект с условиями "пусть программер пишет как умеет или как ему нравиться" (часто ему это нравиться, потому что только так он и умеет smile.gif )  у меня есть аргумент - а если программера завтра каток переедет или ему рожать приспичило? Как потом другому человеку в коде разбираться? Естественно с учетом прочих условий... 

Wise, если позволите, не в обиду - в разделе для начинающих/ARM некто vallav открыл тему про LPC17xx. В ходе нее в баню его отправляли толи 2, толи 3 раза, причем последний раз на месяц. Лично мне его подход к обсуждению не понравился с самого начала. Хотя там в конце я тож себя гавененько повел, каюсь. Но в целом его бан был закономерен. Сравнивая его и Вас с одной стороны примерно понятен ходел мыслей модера, когда он вам отпуск выписывал (если надо, то поясню). Но вот чего совсем не понятно - почему vallav-у zltigo позволял чуть ли не с говном себя смешивать где-то с неделю? А к Вам карательные меры были приведены незамедлительно в срочном порядке? Учитывая, что по сравнению с vallav-ом ваш стиль общения - практически светская беседа на французском, икскьюзимуа сель-ву-пле smile.gif


Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 25.7.2010, 19:59
Сообщение #22


сундук
***

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



Цитата(Wise @ 25.7.2010, 21:53) *
..От апологета слышу.. smile.gif

..Чем меньше принципов, тем лучше.

Согласен. Сам пользуюсь и тем и другим, или в сочетании.

Цитата(Wise @ 25.7.2010, 21:53) *
Но. согласен с тем, что, кое-что, в вышепредставленном обмене мнениями, вы уловили верно.

Поэтому и предлагаю обсудить.
Где, в каких случаях оптимально применять тот или иной подход, или разумное их сочетание.
Желательно с примерами.
Перейти в начало страницы
 
+Цитировать сообщение
orthodox
сообщение 25.7.2010, 20:46
Сообщение #23


ДИКТАТОР
Иконка группы

Группа: Мод
Сообщений: 23809
Регистрация: 20.11.2009
Из: Житомир
Пользователь №: 3



Цитата(Прохожий @ 25.7.2010, 20:59) *
Поэтому и предлагаю обсудить.
Где, в каких случаях оптимально применять тот или иной подход, или разумное их сочетание.
Желательно с примерами.

Да вроде ясно более менее...
Или кажется, что ясно..

Там, где разрабатывают массовые изделия, не сильно устаревающие,
типа какого-то сетевого стабилизатора (например, даже старые для телевизоров феррорезонансники выпуска 50-60 годов до сих пор могли бы иметь сбыт, баксов по 30-50, не устарели... Но надо знать, куда продавать) -
Там подход светлейшего единственно принят. Правильно - неправильно это - уже необсуждаемо.
Ибо нужна предельная оптимизация, раз такая массовость.

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

Хотя по сути все сходится в одном - создать для себя уютную среду и после пользоваться наработками.
В крайнем случае - пользоваться чужими наработками ...Или не в крайнем...
С чужими предельной оптимизации не будет, как правило, если не влезть в код по самое некуда..
\Но тогда уже лучше самому и писать с начала...



Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 25.7.2010, 21:00
Сообщение #24


сундук
***

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



Цитата(orthodox @ 25.7.2010, 22:46) *
...
Хотя по сути все сходится в одном - создать для себя уютную среду и после пользоваться наработками.
В крайнем случае - пользоваться чужими наработками ...Или не в крайнем...
С чужими предельной оптимизации не будет, как правило, если не влезть в код по самое некуда..
\Но тогда уже лучше самому и писать с начала...

Ну вот, уже некая путаница.
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 26.7.2010, 21:49
Сообщение #25


сундук
***

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



Цитата(Designer56 @ 26.7.2010, 21:06) *
Я вообще не понимаю, из- за чего в программистких ветках сыр- бор разгорается.
...

Дело в том, что само по себе программирование - вещь достаточно простая.
В принципе, этим делом может заниматься любой - даже пионер.

Проблемы начинаются при увеличении объема проекта.
Отдельные личности, привыкшие к определенным правилам, тут же начинают притаскивать за уши всякие посторонние предметы, в виде дополнительных сущностей.
Пример - ООП.
Дабы обеспечить привычную среду обитания своему программному продукту.
При этом утверждаются абсолютно не очевидные вещи - типа так проще сохранять нетленку или разбираться с чужим кодом.
Или - при таком подходе возрастает надежность программного продукта.
Так же, якобы, упрощается проблема переноса проекта с одной платформы на другую (портирование).
Хотя у такого подхода есть и совершенно очевидные преимущества.
1. Можно спокойно использовать чужой код, если он достаточно надежен и проверен, абсолютно не вникая в его суть. Пример тому C++Builder.
2. Легко кодить в команде. Когда один делает индикацию, а другой, скажем, считает ряд Фурье в реал-тайме.
3. Модификация одного участка кода не приводит к фатальным последствиям для всего проекта в целом.
4. Замена игрока в команде или даже капитана команды не разрушает самого процесса создания продукта, а лишь слегка приостанавливает его.
5. Возрастает скорость создания программного продукта.
Вопрос в том, сколько Вы готовы заплатить за эти удобства и нужны ли они Вам?

Другие личности, уважаемый Огурцов, например, наоборот, стремятся к минимализму.
В этом случае код будет специфичным для конкретной задачи, хотя и более емким и оптимальным по быстродействию.
Кроме этого, он будет очень жестко привязан к конкретному "железу".
Очевидно так же, что код будет авторским и без правильных комментариев постороннему лицу непонятным.
Вопрос. Стоит ли при нынешнем раскладе рисковать проектом в целом и зависеть от автора?
Или может проще пойти купить кристалл "пожирнее" и не зависеть ни от чего?

В большинстве современных приложений на МК возлагается решение нескольких задач одновременно.
Иногда их число доходит до нескольких десятков или даже сотен.
Причем, задачи эти разноплановые по времени.
К примеру, HMI (ЖКИ+кнопки), опрос входов с подавлением дребезга и шороха, получение сигналов с инкрементального энкодера, обработка информации от входов и энкодера с учетом параметров, выдача результатов на выходы, связь с внешним миром по последовательному каналу, запись/чтение параметров в/из EEPROM.
Задачи, перечисленные мною выше, постоянно и одновременно крутятся в простейшем, в общем-то, девайсе промышленной автоматики.
Здесь любителям правил приходит на помощь РТОС, организующая псевдопараллельную работу задач.
Базовое преимущество очевидно.
Платформенная независимость. Смена МК влечет за собой лишь переписывание малой доли софта в порте выбранной ОС для будущего МК.
Для любителей бритвы Оккама существуют разные подходы в организации псевдопараллельности, но суть остается одна.
Железо МК принимается за готовую систему. Собственно, оно и есть РТОС. Об этом я уже распинался выше.
Здесь мы уже попадаем в зависимость от производителя "железа", который может выкинуть любой фортель.
Опять же остаются вопросы стоимости "удобств".

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

Различия в подходах к решению перечисленных проблем и приводят к спорам в среде программистов.
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 26.7.2010, 22:02
Сообщение #26


сундук
***

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



Цитата(Огурцов @ 26.7.2010, 23:53) *
Не поминай Огурцова в суе (с) ;

Но я же в приличном контексте...
Как образец для подражания.
Перейти в начало страницы
 
+Цитировать сообщение
orthodox
сообщение 26.7.2010, 22:04
Сообщение #27


ДИКТАТОР
Иконка группы

Группа: Мод
Сообщений: 23809
Регистрация: 20.11.2009
Из: Житомир
Пользователь №: 3



Цитата(Прохожий @ 26.7.2010, 23:02) *
Но я же в приличном контексте...
Как образец для подражания.

Мне нравится.
Я думаю, что должна быть граница , как в железе - что на развесе, что на БИС...
смотря по задаче, а иногда смотря по понтам(это я к тому, что часто одни задачи по разному делаются).
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 26.7.2010, 22:14
Сообщение #28


сундук
***

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



Цитата(orthodox @ 27.7.2010, 0:04) *
Мне нравится.
Я думаю, что должна быть граница , как в железе - что на развесе, что на БИС...
смотря по задаче, а иногда смотря по понтам(это я к тому, что часто одни задачи по разному делаются).

Но учтите, если Вы становитесь на минимализме, то становятся неизбежными споры о преимуществах и недостатках конкретных МК.
Перейти в начало страницы
 
+Цитировать сообщение
orthodox
сообщение 26.7.2010, 22:23
Сообщение #29


ДИКТАТОР
Иконка группы

Группа: Мод
Сообщений: 23809
Регистрация: 20.11.2009
Из: Житомир
Пользователь №: 3



Цитата(Прохожий @ 26.7.2010, 23:14) *
Но учтите, если Вы становитесь на минимализме, то становятся неизбежными споры о преимуществах и недостатках конкретных МК.

Да ладно, играть будем теми картами что сданы.
Идиотская система разделения памяти на страницы не только МК свойственна, в конце концов...
А всякие глюки с неуместной установкой или сбросом всяческих флагов можно обходить , близко или далеко...
Перейти в начало страницы
 
+Цитировать сообщение
Student Pupkin
сообщение 26.7.2010, 22:32
Сообщение #30


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

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



Цитата(Прохожий @ 26.7.2010, 23:49) *
Еще одной проблемой является человеческий фактор. А именно, характер, опыт, склонности человека, создающего программный продукт. Кто-то перед решением задачи тщательно продумывает структуры данных, просматривает способы решения каждой из задач, рисует алгоритмы на бумаге и т.д. Другой сразу в бой - решение тех или иных задач появляется уже в процессе работы, равно, как и взаимодействие между задачами. Невозможно отдать предпочтение тому или иному способу. В данном случае все зависит от программиста.
Насколько я знаю в больших программных проектах для команды программмистов назначается менеджер (руководитель - раздача заданий, контроль за исполнением, премирование поощрительными пиздюлинами и т.д.). Потом внутри команды есть некая иерархия - team leader, т.е. старший программист,которого все слушаются... Вообще ничего конкретного не скажу, но вопрос у меня такой - допустим проект для 4-х программистов. Предположим 2 программиста сидят на одном процессоре, у остальных двух - у каждого свой МК. По сути задача - одна большая сложная программа и две поменьше и попроще, плюс разработка протокола взаимодействия между ними.  Как тут быть? Пусть каждый программист выбирает для себя наиболее приемлемый (с его точки зрения способ)? Или же должен быть некий начальник-программист (возможно из состава команды, возможно просто как пятое лицо в задаче), который сам исходя из своих знаний/опыта выберет "правильный" способ? А "шаг влево, шаг вправо" будет караться анально. Как на ваш взгляд? Это касается выбора методики разработки ПО. Параллельно встает задача опротоколе взаимодействия... Как тут должно? Пусть четыре программиста "добазарятся на месте"? Или же опять пятое лицо (начальник, тимлид и т.д.) все определяет и устаканивает?

 

Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 26.7.2010, 23:23
Сообщение #31


сундук
***

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



Цитата(Огурцов @ 27.7.2010, 0:26) *
Чтобы почти даун мог сесть за код и понять, что же тут такого этим хотел сказать автор.

Я Вам скажу так.
Мои подчиненные слесари КИПиА лучше всего понимают такой язык программирования.
И не только они.

Цитата(Student Pupkin @ 27.7.2010, 0:32) *
Насколько я знаю в больших программных проектах для команды программмистов назначается менеджер (руководитель - раздача заданий, контроль за исполнением, премирование поощрительными пиздюлинами и т.д.). Потом внутри команды есть некая иерархия - team leader, т.е. старший программист,которого все слушаются...

Мне трудно что-либо Вам советовать в данном случае.
У меня нет практического опыта работы в программистском коллективе.
Да и работа в команде не по мне. Не нравится.
Над программно-аппаратными проектами всегда работал в одиночку.
Начиная со схемотехники и заканчивая программами для МК и CPLD.
Ну и PCB тоже...
ПМСМ, здесь таких большинство.
Может быть MrYuran Вам поможет...
Перейти в начало страницы
 
+Цитировать сообщение
Гость_MrYuran_*
сообщение 27.7.2010, 6:44
Сообщение #32





Гости






Цитата(Огурцов @ 26.7.2010, 23:26) *
Просто я хотел сказать. Что я сторонник жесткого ООП (с перечисленными (и м.б. не перечисленными) вами плюсами), максимального сведения задачи к набору иерархических, независимых кубиков, в ущерб быстродействию и необходимым ресурсам.

ООП - это тоже уже пройденный этап.
Компонентная модель - вот что круто.
Набор независимых компонентов с определёнными интерфейсами.
То есть не просто кубики, а калиброванные и со стандартными "зацепами", что твои кубики ЛЕГО.
Почитал немного про TinyOS - очень понравилось.
Там программным компонентам верхнего уровня глубоко пофиг, общаются они внутри одного кристалла или через сеть - интерфейс один и тот же. Язык, правда, расширен - nesC.
Система заточена под самоорганизующуюся распределённую сеть (концепция "умной пыли") и курируется интелом и DARPA.
Ну это так, лирическое отступление.

Насчёт ущерба быстродействию и (или) ресурсам - готов поспорить.
Если я вместо явной записи явного байта в регистр подсуну функцию-обёртку, нормальный компилятор развернёт её и сделает именно то, что нужно. Зато в тексте не будет явно указан ни регистр, ни значение.
Кроме улучшения читабельности, получаем отвязку общего алгоритма от конкретной реализации.

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




Цитата(Огурцов @ 27.7.2010, 7:17) *
Если сделать иначе, то однозначно будет зоопарк.

Это точно.
У нас примерно так.
В настоящее время вплотную столкнулись с необходимостью определения корпоративных стандартов кодирования.
Причём, не на уровне форматирования, где сколько отступов (хотя некоторые конторы и это фиксируют), а в плане структуры проекта и вообще исходников. Нас в принципе всего трое (пока), каждый занимается своей областью, пересекаемся только на уровне протокола обмена, ну и логики взаимодействия (ты мне это, я тебе то, если не то, то вот это ну и т.д.)
И получается, что быстрее и проще написать заново, чем колупаться с чужими исходниками.
А заново нельзя, как по времени (на дежурную правку даётся намного меньше, чем на разработку), так и из соображений надёжности.
В серийном изделии за годы эксплуатации постепенно вылизаны все (ну или большинство) глюки, а новая писанина может внести новые, причём в непредсказуемом месте.
Вот беру чужой исходник (товарищ уволился год назад) и вижу:
ttt = tt - t;
Без комментариев.
И вообще, вся программа в стиле бейсика.
Руки надо отрывать за такое.
Перейти в начало страницы
 
+Цитировать сообщение
Гость_MrYuran_*
сообщение 27.7.2010, 9:13
Сообщение #33





Гости






Цитата(Огурцов @ 27.7.2010, 9:18) *
Трое - это еще очень мало. А структурой должен заниматься системный архитектор.

У нас даже ведущего нет, каждый сам себе ведущий.
Начальник в программировании вообще никак, он больше по науке и аналогу.
Это плохо, должен быть хоть какой-то контроль.
Чтобы однажды выявленные грабли не повторялись.
В идеале - написать общую библиотеку стандартных и верифицированных компонентов и по максимуму их использовать, не залезая внутрь и не колупая ничего ручками, только через документированные API
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 27.7.2010, 21:58
Сообщение #34


сундук
***

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



Цитата(Огурцов @ 27.7.2010, 23:19) *
Писали мы такую хреновину. Потом я писал такую штуку один, потом...некрософт написал такую штуку и мы крупно отсосали. Ибо платить за то, что можно взять на халяву дураков не очень много. Workflow назывется. Или бизнес-процессы. Суть в том, что набор кубиков-функций или подпроцессов собирается на диаграмме в единое целое, стрелочками, ветвлениями, событиями, исключениями и т.д. Рисуется...и тут же компилится в нативный код и исполняется. Слесарям было бы гораздо понятнее и приятнее. Для продвинутых - дот-нет языки, отмороженным - обычные dll или com.

Нет, это совсем другое.
Это - языки стандарта МЭК 61131-3, предназначенные для программирования всякой пром. автоматики.
Более подробно можно посмотреть здесь.
Этими же языками пользуются вот эти товарищи.
А так же эти и эти и многие другие...
Это несколько иная сторона того же программирования, про которую многие и не знают даже.
Перейти в начало страницы
 
+Цитировать сообщение
Гость_MrYuran_*
сообщение 30.7.2010, 10:12
Сообщение #35





Гости






Цитата(Прохожий @ 25.7.2010, 21:02) *
Суть ООП в двух словах можно охарактеризовать как максимальное абстрагирование от "железа" и максимальное использование наработанной ранее "нетленки".

Это можно сравнить со схемотехникой.
Аналогия - рассыпная схемотехника (пусть даже логика) против интегральной.
То есть, когда тебе нужно сделать триггер, можно взять ТМ2, а можно несколько транзисторов и горсть дискретных элементов.
Если этих триггеров десятки, то в зависимости от конечной цели, можно взять либо м/с счётчиков, либо регистров.
Когда их сотни и тысячи, удобнее бывает взять ещё более интегрированные изделия, например статическую память или специализированные устройства (1002ХЛ1, к примеру - контроллер UART)

C одной небольшой разницей:
Если мы используем БИС не полностью, оставшаяся часть занимает место и потребляет энергию.
А если мы не используем часть унифицированного программного модуля, компилятор её просто выкинет и место зря не пропадёт.
Точно так же он может "размотать" кучу обёрток до конечной и лаконичной команды, например, записи в порт (или несколько портов).


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

Я вот приглядываюсь, что, например, АНТОХА на С++ вытворяет, тоже становится интересно.
Хотя лет 5 назад я бы долго смеялся над тем, кто предложил бы писать для контроллеров на плюсах.
В принципе, то же самое можно реализовать и на чистом си, но это будет нагромождение структур, указателей и массивов в самых причудливых комбинациях. В то время как на С++ будет выглядеть как наглядное описание классов, методов и объектов.
Давно бы попробовал, да по уши в текущих проектах, некогда...

А вот пример HAL для msp430 от TI.
Сижу, читаю. Хотел было свой написать, а тут вроде готовый велосипед подходит.
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 1.8.2010, 14:14
Сообщение #36


сундук
***

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



Цитата(MrYuran @ 30.7.2010, 12:12) *
Основная идея ООП - максимальная абстракция.
Отделение интерфейса от реализации.
Так уж устроен человеческий моск, что ему трудно охватить множество мелких конкретных деталей. А вот абстрактными понятиями он оперирует легко. Ну и прочие бонусы, типа переносимости.
Когда приходит старый прибор в ремонт или поверку, иногда бывает нужно перенести крайнюю версию прошивки на старое железо.
При правильно организованных исходниках это дело получаса-часа. Плюс, ещё столько же на тестирование и доработку при необходимости.
В противном случае можно провозиться неделю и всё равно оставить где-нибудь грабли, которые всплывут у пользователя через год-два и приведут к рекламациям и скандалам.

Я Вас удивлю, но при остальных подходах, а так же их сочетаниях все то же самое. Структурный подход сплошь и рядом применяется при программировании PLC.
И именно он считается более надежным. Исправление софта производится вообще "на лету", т. е. на реально работающей машине.
В случае ООП, при максимальной инкапсуляции, особенно, когда используется "дядины" объекты, раскидать грабли по софту гораздо проще.
Причем и не по своей вине тоже. За всем "чужим " софтом не уследишь...
Насчет устройства моска Вы не совсем правы. Так он устроен у Вас и, допускаю, у некоторых окружающих Вас людей.
А мне для понимания процессов вполне достаточно частностей. Я лично не вижу иерархии там, где ее видят большинство апологетов ООП.
А без этого "таланта" ООП без надобности.
И еще одно возражение.
Большинство задач разнородны. Это становится понятно, когда глубже вникаешь в структуру объектов.
Скажем, класс электромоторы.
Попробуйте построить здесь любую из иерархий...
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 1.8.2010, 15:29
Сообщение #37


сундук
***

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



Цитата(Огурцов @ 1.8.2010, 16:44) *
А все потому, что это самый нижний уровень "ООП". Т.е. именно то, к чему необходимо прикрутить некую ручку строго определенной формы, чтобы оно легко встраивалось в систему. На саму же реализацию натягивать ООП может и нет необходимости. Потому как большинство задач реализаций именно разнородны.

Правильно.
Беда в том, что большинство выходцев именно из программистской среды начинают отнюдь не с изучения обобщенной модели электрической машины и ее частного приложения.
Работа начинается с создания классов и прочей ООП-шной дребедени, простите за резкость.
Не многие понимают, что на самом деле подход ООП ограничен иерархическими задачами, когда одно плавно вытекает из другого.
А большинство реальных, практических задач уникальны по-сути. И занимаются ими люди - специалисты именно в своей области знаний.
Есть еще одна сторона медали - использование РТОС в МК.
Но для этого должна быть отдельная тема.
Перейти в начало страницы
 
+Цитировать сообщение
_pasha
сообщение 12.1.2011, 8:23
Сообщение #38


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

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



Сегодня прикрыл недельный траходром с 18-м пиком.
Суть: во всех мыслимых эмуляторах все работает, в железе - нет. Причем, уже почти( на 30% ) доверяю Протеусу. Сцуко, надоел С+асм - МСС18 другой возможности не оставляет кроме рулить самому. Какая же все-таки это гадость!
Проблема была в одном операторе - долго писАл для АВР, вот он и заштамповал голову - sublw k это ведь совсем не то, что subi r,k. Дальше шла запись по PLUSWx, в прерывании - и данные портились, но почему оно работало в протеусе, который на быстрой машине уже не говорит, что симуляция не в реалтайме, - не пойму.
Вывод: за асм убил бы.
Перейти в начало страницы
 
+Цитировать сообщение
orthodox
сообщение 13.1.2011, 17:44
Сообщение #39


ДИКТАТОР
Иконка группы

Группа: Мод
Сообщений: 23809
Регистрация: 20.11.2009
Из: Житомир
Пользователь №: 3



Цитата(_pasha @ 12.1.2011, 9:23) *
Вывод: за асм убил бы.

А что с теми, у кого асм? Их не любит Аллах?
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 13.1.2011, 19:46
Сообщение #40


сундук
***

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



Цитата(_pasha @ 12.1.2011, 9:23) *
Сегодня прикрыл недельный траходром с 18-м пиком.
Суть: во всех мыслимых эмуляторах все работает, в железе - нет. Причем, уже почти( на 30% ) доверяю Протеусу. Сцуко, надоел С+асм - МСС18 другой возможности не оставляет кроме рулить самому. Какая же все-таки это гадость!

Самая гадость - это AVR во всех его проявлениях.
Гибель 1 МВт-ного чиллера на нашем предприятии - целиком на совести датчиков, собранных именно на этом МК.
За два года эксплуатации там передохло практически все поголовье этих самых AVR.
Причем, дохли не просто так, а тащили за собой всякие механические повреждения, обусловленные выходом датчиков из строя.
Изделие уважаемой американской фирмы, стоящее немалых денех...
Хвала всевышнему за медленную и мучительную смерть этого уродца (в смысле AVR).
Цитата(_pasha @ 12.1.2011, 9:23) *
Проблема была в одном операторе - долго писАл для АВР, вот он и заштамповал голову - sublw k это ведь совсем не то, что subi r,k. Дальше шла запись по PLUSWx, в прерывании - и данные портились, но почему оно работало в протеусе, который на быстрой машине уже не говорит, что симуляция не в реалтайме, - не пойму.
Вывод: за асм убил бы.

АСМ там вполне пристойный, полностью соответствующий архитектуре.
А если кто готовить не умеет, то...
А с прерываниями осторожнее надо.
У меня достаточно много программ на чистом МСС18.
Все чудным образом работает в многочисленных прерываниях.
Сочетание С и ACM не есть необходимость.
Перейти в начало страницы
 
+Цитировать сообщение

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

 



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