Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Споры о подходах к программированию МК
Шарага > Soft - НЕ железо > Программирование МК
Страницы: 1, 2, 3, 4
Прохожий
По просьбам трудящихся отделил кусок от темы.
Обсуждение технических аспектов предлагаю продолжить здесь.
С уважением, MrYuran


Цитата(Wise @ 24.7.2010, 12:34) *
Привет!
...

А почему Вы вдруг за AVR взялись?
Совершенно "левый" МК...
Все, с чем приходилось сталкиваться из выполненного на нем, глючит не по детски.
Давеча вот, чиллер (это такой кондиционер на 300 кВт) на куче мелких AVR сказал, что у него связь потеряна...
И это он делает периодически... С момента его покупки родным предприятием.
Ну, и трудности с доставанием тех же AVR...
Лучше уж PIC24 или dsPIC33.
По крайней мере там все проще и Вам привычней - тот же MPLAB, да и ассемблер поприличнее.
Впрочем, воля Ваша...
Что же касается существа дела, то совет про С, ПМСМ, верный.
Другое дело - форма высказывания в виде наставлений от "старшего брата"...
В догонку.
Вот еще тема с электроникса.
Кто что скажет?
Wise
Цитата
А почему Вы вдруг за AVR взялись?
Совершенно "левый" МК...
Все, с чем приходилось сталкиваться из выполненного на нем, глючит не по детски.


..Так я бы и не брался..
Не нравятся они, и то, что успел узнать, не внушает..

..Попросил заказчик один, старый знакомый и деньги хорошие платит..
Я ему раньше делал на PIC-ах, а кто-то ему насоветовал, что AVR дешевле и пинов (выходов) у них больше..
Отговорить не получилось.
..Думаю, ну, хрен с ним, заодно, свою базу знаний расширю.. russian_ru.gif
Прохожий
Цитата(Wise @ 24.7.2010, 17:15) *
..Так я бы и не брался..
Не нравятся они, и то, что успел знать, не внушает..

Так, от то ж...
Цитата(Wise @ 24.7.2010, 17:15) *
..Попросил заказчик один, старый знакомый и деньги хрошие платит..
Я ему раньше делал на PIC-ах, а кто-то ему насоветовал, что AVR дешевле и пинов (выходов) у них больше..
Отговорить не получилось.
Думаю, ну, хрен с ним, заодно, свою базу знаний расширю.. russian_ru.gif

Дык, предупредите товарища.
А то попадет в беду с этим ATMEL-ом.
Там трудности нешуточные с поставками.
И цены уже не низкие.
Вот, почитайте.
А PIC24 - это сочетание систем команд PIC16, PIC18 с PDP11.
Не Ассемблер, а песня.
Ширина данных - 16 бит.
Векторная система прерываний с приоритетами.
И цена низкая.
Harbinger
Если бы не надо было сейчас в техсупермаркет за соковыжималкой, начал бы всякие деривативы 51 пиарить, их есть, которых подешевле пиков и AVR при сопоставимых возможностях. wink.gif
Wise
Цитата
Вот, почитайте.

..Так я видел..
Почему и написал, что бан на месяц..
А вы как это нашли, вы же не заблокированы.. wacko.gif

..Мне в PIC-ах симпатична логичность.
Тридцать команд (примерно) - это как тридцать букв в алфавите.
А когда букв 130.. ..и большая часть из них, собственно, одно и то же..
Хочется спросить авторов: ну, на хрена вот это..

..Одна часть команд работает только с одними регистрами, другая - только с другими.
Карту придется рисовать (что ли) на листе ватмана, где будет указана память и что с чем может работать..
Прохожий
Цитата(Огурцов @ 24.7.2010, 19:10) *
Связь - это руки, а не МК. Хотя, если шнурок на прямую к МК подключен, то уже не руки, а голова, скорее.

Что, у всех пользователей AVR? И во всех странах сразу? Чиллер - американский.
Цитата(Огурцов @ 24.7.2010, 19:10) *
Значит пользуется огромным спросом на оптовых продажах, и на розницу уже не хватает.

Вы не внимательно прочли флуд по ссылке. Там речь шла как раз об оптовых закупках.
Достать несколько штук - не вопрос.
А вот количество, да по приемлемой цене...

Цитата(Wise @ 24.7.2010, 18:28) *
..Мне в PIC-ах симпатична логичность.
Тридцать команд (примерно) - это как тридцать букв в алфавите.
А когда букв 130.. ..и большая часть из них, собственно, одно и то же..
Хочется спросить авторов: ну, на хрена вот это..

Вы не поверите, авторы AVR - это два студента из Скандинавии.
А система команд типа LOAD - STORE мне не нравилась еще в I8080.
По командам, AVR ближе всего к 51-м. Это развитие этой системы команд.
Цитата(Wise @ 24.7.2010, 18:28) *
..Одна часть команд работает только с одними регистрами, другая - только с другими.
Карту придется рисовать (что ли) на листе ватмана, где будет указана память и что с чем может работать..

А что Вы хотите от наспех сделанного курсового проекта?
Прохожий
Цитата(Огурцов @ 24.7.2010, 19:28) *
В общем да, смотрите в корень - авр - народный проц, гораздо более удобный простой и понятный, на нем лабают чайники всех стран - новое поколение уже выросло и дало "плоды". А старое, которое было еще гораздо более профи, писало и выросло на пиках. Так что дело не МК vs МК, а в разработчик vs разработчик.

Я и смотрю на мучения уважаемого Wise.
Вроде бы не чайник.
А кроме ругани в адрес AVR при вынужденном переходе, пока ничего от него не слышно.
Я-то, к примеру, представляю себе, откуда растут ноги.
При проектировании ядра кто-то зажал ширину адреса внешних устройств.
Зачем их было вводить, как отдельную сущность, вообще непонятно.
Если только не предположить, что студенты брали за основу MSC51 и динамическую память в качестве RAM.
Как, собственно, там и было в самом начале.
Цитата(Огурцов @ 24.7.2010, 19:28) *
Вообще не читал. Подозреваю, дело в том, что про разный опт речь. А высокие цены, хотя бы на m128 уже года 2 минимум. Так что не удивляет.

А зря - поучительного там достаточно много...
Народ толпой переходит на ARM-ы.
Наступивши на одни грабли все быстро ищут другие, с более увесистой рукояткой.
Wise
..Пользователь один, в той теме про компаратор, сообщил мне, что на Си я буду думать про алгоритм, а в ассемблере – только про то, как правильно написать команды.

..Чушь полная.. Даже для AVR, думаю, что приноровлюсь, в итоге. А уж для PIC-ов..
Там, я давно не думаю о командах, это происходит автоматически, как при игре, например, в настольный теннис, рука сама поворачивает ракетку, чтобы правильно принять крутящийся в нескольких плоскостях шарик, а голова занята просчетом игры на несколько ходов вперед.

..Собственно, даже не делал библиотеку подпрограмм. У меня есть некоторая куча проектов, я знаю, примерно, где что лежит, и из таких готовых модулей компилирую новую программу. Присоединить пару файлов к проекту не проблема.

..Алгоритмы даже не главное. Большой круг и все мелкие подциклы, обычно, понятны сразу. Интересна оптимизация, то есть, так написать, чтобы выбросить/сократить строчку уже было нельзя.

..Поэтому, Си, как способ мышления, мне не интересен, в применении к программированию МК. С ним ли, без него, я размышляю о сути действий МК в смысле оптимального решения задачи. Но, ассемблер дает мне возможность сделать «конфетку», а что толку от Си – это набор шаблонов, которые не могу поменять и которые часто громоздки в конкретном случае.

..Однако, все поучают и поучают меня товарищи (о великой пользе Си), для которых алгоритм программы нарисовать на бумажке уже есть громадное достижение..
Designer56
как- то в молодости мне пришлось написать программку для 580-го вообще без трансляторов/компиляторов. Т.е. мнемокод я вручную перекодировал в 16- ричный. Где- то к-байт в целом. Просто потому, что у нас такая система была на работе, без диска совсем. С перфолент все вводилось. Дешевле было вручную сделать. Ничего, как ни странно, не очень долго с отладекой трахался. Мой приятель так же написал монитор для маленького самодельного контроллера на том же 580-м с клавиатуркой и люминесцентным 7- сегментным дисплеем.

Цитата(Harbinger @ 24.7.2010, 23:46) *
Так, может, в Латвии оно, развитие, как-то по-другому происходило? wink.gif



не, просто он упрямый
Прохожий
Цитата(Огурцов @ 24.7.2010, 20:20) *
Тогда как алгоритм, отличный от железа, будет в общем-то одинаков, что для авр, что для арм.

Тут сказать нечего.
Для PIC-ов все тоже самое.
Вы правы.
Каким бы не был "мотор", все самое интересное определяет периферия.
Прохожий
Цитата(Wise @ 24.7.2010, 21:38) *
..Пользователь один, в той теме про компаратор, сообщил мне, что на Си я буду думать про алгоритм, а в ассемблере – только про то, как правильно написать команды.

Причина перехода на С не в этом.
Сами понимаете, что выучить систему команд за месяц можно в совершенстве.
Так, чтобы потом о ней не думать.
По утверждению апологетов С, причин здесь несколько:
1. Меньшие временные затраты на само программирование.
Сам сталкивался с этим, когда делал терморегулятор на PIC18 с плавающей арифметикой.
2. Переносимость основных алгоритмов между платформами.
3. Возможность работы с Вашей программой другому индивидууму с минимальными затратами.
4. Возможность работы над проектом в составе коллектива программистов.
Лично для меня самый важный пункт - первый.
Все остальное, ПМСМ, значения не имеет.
Harbinger
Да тут я был бы апологетом по всем пунктам, и ещё по нескольким.
Но, когда сверху спускают аж два МК на выбор... и тот, у которого вчетверо меньше памяти, на 5 центов дешевле, и архитектура с юности знакомая... в общем, ASM forever, дабы впихнуть невпихуемое. И, блин, получается же!
Недавно делал обратный изврат - в контроллере о 64 К флэши занято аж полтора, причём писалось на Си и ни о каких оптимизациях не приходилось заикаться. Ну не нашлось ничего дешевле и меньше, да чтобы о двух уартах. В принципе, можно было на Tiny2313 сгородить (один из уартов симплексный - RS-485), но он в ту же цену, что та 64-килобайтная зверюга, а мороки больше.
Wise
Цитата
Причина перехода на С не в этом.
..По утверждению апологетов С, причин здесь несколько:


..Возможно.
Я-то один работаю, с давних пор, ну и подход, наверное, специфичный.
Поэтому, большинство перечисленных пунктов меня мало трогает.
А "меньшие временные затраты" - это спорно.
..К тому же, вот, написали вы один раз эту арифметику - ну и все, в другой раз время на именно это будет стремиться к нулю..
Прохожий
Цитата(Wise @ 24.7.2010, 22:31) *
..Возможно.
Я-то один работаю, с давних пор, ну и подход, наверное, специфичный.
Поэтому, большинство перечисленных пунктов меня мало трогают.
А "меньшие временные затраты" - это спорно.
..К тому же, вот, написали вы один раз эту арифметику - ну и все, в другой раз время на именно это будет стремиться к нулю..

Вот тут, Вы, пожалуй, правы.
Когда один, тогда все прелести С нивелируются, кроме пункта 1.
Недавний пример - управлялка для многофазной дуговой установки.
В центре PIC24FJ128GA108.
Функции:
1. Опрос порядка 100 входов.
2. Индикация состояния каждой из ячеек - авария, перегрев, неполадки с питанием, все это с помигушками.
3. Трехсимвольный семисегментный индикатор.
4. ЧМИ в виде кнопок + и -.
5. Индикация общего состояния девайса, коротыш, готовность и прочее.
6. Система управления током нагрузки.
7. Управление вспомогательными девайсами.
8. Связь с внешним миром - MODBUS/ASCII.
Время исполнения -3 полурабочих дня, где-то около 12 часов.
Вместе с отладкой связи с внешним компьютером.
Все на С и C++, включая отладочний софт для ПК в виде простейшей программулины на C++Builder-е.
Так вот, к своему стыду признаюсь, что из-за спешки на ассемблере изобразил только конфигурирование внешних выводов.
Хотя, у PIC24 ассемблер гораздо приятнее, чем у PIC18, скажем.
Harbinger
Цитата(Огурцов @ 24.7.2010, 22:52) *
Уяссе. Сколько ж вы зарабатываете за месяц ? Нечто о пяти зеленых нулях ?

Так, наверное же, указано реально затраченное время... wink.gif
Помнится, году так в 2006 дописывал один эфирный протокольчик. Затратил где-то 16 часов на протяжении 2 месяцев. В порядке хобби.
Тут вот даже три ноля ненаших нечасто получаются. "А жить-то надо, надо жить красиво..." - помните?
Прохожий
Цитата(Огурцов @ 24.7.2010, 23:52) *
Уяссе. Сколько ж вы зарабатываете за месяц ? Нечто о пяти зеленых нулях ?

Вы слишком хорошего мнения обо мне.
А домашние заготовки, о которых здесь уже говорилось?
Все по отдельности уже было ранее, правда, на 18-х PIC-ах.
Просто собрал все в кучу на несколько иной платформе.
С С-ями этот процесс значительно ускоряется.
А про 5 зеленых нулей...
Хотелось бы, но кто их даст?
Тут хотя бы четыре наших нуля.
А первая значащая цифра от трех до пяти...
А вообще - оплата труда в нашей профессии - отдельная тема для разговора.
Предлагаю открыть и поговорить на нее.
MrYuran
Цитата(Wise @ 24.7.2010, 20:38) *
Интересна оптимизация, то есть, так написать, чтобы выбросить/сократить строчку уже было нельзя.

А смысл?
Главное - не в алгоритмах или командах.
Главное - чтобы полученный исходник не был привязян к железу.
Если бы и был - то по минимуму и в строго оговоренных местах.
Например, в файлах типа hardware.h, lo_level.h или hal.h
Я уже не позволяю себе в тексте такие вольности, как P1OUT |= 0x40;
или даже LIGHTS_PORT |= HEATER_LIGHT_PIN;
а пишу так:
SetLight(HEATER_LIGHT,LIGHT_ON);
Теперь мне без разницы (в основном приложении), как называются регистры, каким уровнем включается светодиод (высоким или низким) - это всё описано один раз в специально отведённом месте.

Возможно, моё мнение сформировано под влиянием специфики - крупносерийный выпуск разных изделий на сходной программно - аппаратной платформе

Цитата(Wise @ 25.7.2010, 16:11) *
А уйти-то, я, конечно, уйду, из такой странной игры.. russian_ru.gif

А игра порстая- ЖЫЗНЬ
Есть правила, гласные и негласные, есть те, кто при исполнении, есть понятие целесообразности...
Форум - это просто некая проекция общества, со всеми вытекающими
MrYuran
Цитата(Wise @ 25.7.2010, 19:37) *
..Поэтому, когда схема построена так, что ни один элемент отбросить нельзя, когда из литературного текста или текста программы, не выбросить строчку, я вижу в этом гармонию и красоту..
..Какой в этом смысл - ответить затрудняюсь.

Когда начальник в очередной раз подходит ко мне и интересуется, как дела (в смысле, когда ж, наконец, будет готово), а я в ответ говорю, что старая программа вызывает во мне когнитивный диссонанс, и я решил переписать её заново, вместо того чтобы поправить десяток строчек, он смотрит на меня как-то странно...
Что он при этом думает, даже не представляю.
Wise
Цитата
Когда начальник в очередной раз подходит ко мне


..Возможно, мне повезло больше, у меня начальников нет. Есть только обязательства.
Поэтому, позволяю себе роскошь, делать свою работу хорошо, так, как понимаю это "хорошо".
..Такой вариант, кстати, когда-то выбрал сам..
Прохожий
Цитата(MrYuran @ 25.7.2010, 20:43) *
Когда начальник в очередной раз подходит ко мне и интересуется, как дела (в смысле, когда ж, наконец, будет готово), а я в ответ говорю, что старая программа вызывает во мне когнитивный диссонанс, и я решил переписать её заново, вместо того чтобы поправить десяток строчек, он смотрит на меня как-то странно...
Что он при этом думает, даже не представляю.

Здесь, ПМСМ, мы и наблюдаем два подхода к программированию.
1. Подход ООП, которого условно придерживается MrYuran.
2. Системный подход, апологетом которого является Wise.
Суть ООП в двух словах можно охарактеризовать как максимальное абстрагирование от "железа" и максимальное использование наработанной ранее "нетленки".
Суть системного подхода - бритва Оккама, т. е. максимальная лаконичность полученного результата.
В первом случае человек первым делом "вьет " себе привычное "гнездо", где ему тепло и хорошо.
Делается это по-разному. С помощью привлечения сторонних программных продуктов, ОС, к примеру.
Или технологии ООП, или того и другого вместе.
Т.е. человек строит систему под себя. "Железо" в этом случае является маленькой несущественной ее частью.
Второй подход - несколько иной.
Существующие аппаратные средства и программная модель ядра вместе с системой прерываний воспринимаются как готовая система.
В этом случае к ней добавлять ничего не надо. Все уже есть и так.
Если господам будет угодно, то можно поговорить о преимуществах и недостатков обоих методов.
Но только сделать это надо не здесь, а в разделе про программирование.
Если на то будет разрешение, могу открыть соответствующую тему.
Student Pupkin
Цитата(Прохожий @ 25.7.2010, 21:02) *
Если на то будет разрешение, могу открыть соответствующую тему.

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

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


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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

Мне трудно что-либо Вам советовать в данном случае.
У меня нет практического опыта работы в программистском коллективе.
Да и работа в команде не по мне. Не нравится.
Над программно-аппаратными проектами всегда работал в одиночку.
Начиная со схемотехники и заканчивая программами для МК и CPLD.
Ну и PCB тоже...
ПМСМ, здесь таких большинство.
Может быть MrYuran Вам поможет...
MrYuran
Цитата(Огурцов @ 26.7.2010, 23:26) *
Просто я хотел сказать. Что я сторонник жесткого ООП (с перечисленными (и м.б. не перечисленными) вами плюсами), максимального сведения задачи к набору иерархических, независимых кубиков, в ущерб быстродействию и необходимым ресурсам.

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

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

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




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

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

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

Нет, это совсем другое.
Это - языки стандарта МЭК 61131-3, предназначенные для программирования всякой пром. автоматики.
Более подробно можно посмотреть здесь.
Этими же языками пользуются вот эти товарищи.
А так же эти и эти и многие другие...
Это несколько иная сторона того же программирования, про которую многие и не знают даже.
MrYuran
Цитата(Прохожий @ 25.7.2010, 21:02) *
Суть ООП в двух словах можно охарактеризовать как максимальное абстрагирование от "железа" и максимальное использование наработанной ранее "нетленки".

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

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


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

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

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

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

Правильно.
Беда в том, что большинство выходцев именно из программистской среды начинают отнюдь не с изучения обобщенной модели электрической машины и ее частного приложения.
Работа начинается с создания классов и прочей ООП-шной дребедени, простите за резкость.
Не многие понимают, что на самом деле подход ООП ограничен иерархическими задачами, когда одно плавно вытекает из другого.
А большинство реальных, практических задач уникальны по-сути. И занимаются ими люди - специалисты именно в своей области знаний.
Есть еще одна сторона медали - использование РТОС в МК.
Но для этого должна быть отдельная тема.
_pasha
Сегодня прикрыл недельный траходром с 18-м пиком.
Суть: во всех мыслимых эмуляторах все работает, в железе - нет. Причем, уже почти( на 30% ) доверяю Протеусу. Сцуко, надоел С+асм - МСС18 другой возможности не оставляет кроме рулить самому. Какая же все-таки это гадость!
Проблема была в одном операторе - долго писАл для АВР, вот он и заштамповал голову - sublw k это ведь совсем не то, что subi r,k. Дальше шла запись по PLUSWx, в прерывании - и данные портились, но почему оно работало в протеусе, который на быстрой машине уже не говорит, что симуляция не в реалтайме, - не пойму.
Вывод: за асм убил бы.
orthodox
Цитата(_pasha @ 12.1.2011, 9:23) *
Вывод: за асм убил бы.

А что с теми, у кого асм? Их не любит Аллах?
Прохожий
Цитата(_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 не есть необходимость.
_pasha
Цитата(orthodox @ 13.1.2011, 17:44) *
А что с теми, у кого асм? Их не любит Аллах?


Вероятно, да, когда дело в одной строчке, иногда в одной буковке, из 1000+ строк файла. Хорошо, когда отловить это мона.

Цитата(Прохожий @ 13.1.2011, 19:46) *
Самая гадость - это AVR во всех его проявлениях.

Строители датчиков не сумели их приготовить...

Цитата
Сочетание С и ACM не есть необходимость.

Эх dash1.gif кабы так и было б... С МСС18 воевать уже научился, по Вашему рецепту - все переменные статик через командную строку , быстродействие удовлетворительное, врукопашную не намного лучше. Раздражает только то, что оно далеко от С99 и слишком много специфики получается.
MrYuran
Цитата(orthodox @ 13.1.2011, 18:44) *
А что с теми, у кого асм? Их не любит Аллах?

Они сами себя не любят
Harbinger
...или их не любит начальство, экономя 20 центов.
(Был такой случай. 2 кБ на всё про всё дали, выкручивайся как хочешь. В аналогичных изделиях др. производителей было 8...16).
_pasha
Цитата(Harbinger @ 14.1.2011, 9:35) *
2 кБ на всё про всё дали, выкручивайся как хочешь.

Это смотря где. На пиках - в 16С84 помещался декодер АОН/DTMF, генератор DTMF, запрос 500Гц, анализ индукторного вызова и контроль напряжения линии. Т. е. таблиц получалось 32*( 6+8 )*2 + настройки для тонального генератора(через разностное уравнение), кодовое расстояние кажись считал битиками, уж это никак не помещалось pardon.gif
_pasha
Цитата(evgeny_ch @ 15.1.2011, 8:24) *
Почти офтоп.
Паша, букву Ё из русского языка, кто думаете убрал?
Вотвот - этот самый козёл. smile.gif

Ё! Не пугайте, она ещё эст. Просто все стесняются её употреблять, как будто других ругательств нету.
© это все придумал Черчилль, в 18-м году.
Harbinger
Ё... smile.gif
...В крайнем случае, у французов останется. Citroёn. smile.gif

Цитата(_pasha @ 15.1.2011, 8:16) *
Это смотря где. На пиках - в 16С84 помещался декодер АОН/DTMF, генератор DTMF, запрос 500Гц, анализ индукторного вызова и контроль напряжения линии. Т. е. таблиц получалось 32*( 6+8 )*2 + настройки для тонального генератора(через разностное уравнение), кодовое расстояние кажись считал битиками, уж это никак не помещалось pardon.gif
Лихо. В моём случае (на 51 от NXP) больше половины памяти ушло на обработчики команд настройки.
MrYuran
Цитата(Harbinger @ 15.1.2011, 10:43) *
...В крайнем случае, у французов останется. Citroёn. smile.gif

Самое смешное, что без точек получилось бы "ситроЁн", а с точками - ситроэн.
Всё не как у людей...
Прохожий
Цитата(evgeny_ch @ 15.1.2011, 9:45) *
Большинству учоных, как источник хлеба, нужна новизна.
Когда новизна не придумывается, они затевают реорганизацию.
Это к чемуя?
Однажды придуманный конечный автомат, вне зависимости
от платформы, им же и остаётся.
Это даже Тьюринг не отрицал. pardon.gif

И это верно.
К чему этот конечный автомат во что-то заворачивать?
К примеру, во что-то объектно ориентированное...
Как я выяснил, это нужно, чтобы создать себе привычную среду программирования.
При этом вполне допустимо пустить в распыл даже принцип Оккама.
Вот такие современные пироги.
Тогда не надо задавать вопросов про то, почему развалилась СШ ГЭС.

Цитата(_pasha @ 14.1.2011, 9:07) *
Вероятно, да, когда дело в одной строчке, иногда в одной буковке, из 1000+ строк файла. Хорошо, когда отловить это мона.

Хотите, я Вам точно так же и на С сделаю?
Это опять же из области глубины познаний в кулинарии.
Цитата(_pasha @ 14.1.2011, 9:07) *
Строители датчиков не сумели их приготовить...

Ну да.
А вот эти строители и эти тоже из PIC-ов столько всякой всячины наделали...
И, странная вещь, работает все в миллионных тиражах годами.
Может, все-таки, в консерватории что-то не так?
Прохожий
Цитата(evgeny_ch @ 15.1.2011, 21:45) *
Может им и надо, но причём тут ГЭС?
К ихузкой специализации. smile.gif
Даже не понимают, что они себе роют.

А это издержки эффективного менеджмента в сочетании со всезнающим эмбеддерством.
Закидывание шапками того, о чем понятия в пустой голове совершенно не имеется.
Есть мнение, что 2-й гидроагрегат и так калеченный, проходил через точку резонанса несколько раз из-за вновь установленной автоматической системы управления.
Ну, и не выдержал, естественно.
Предыдущая система его бы не включила еще после первой остановки.
_pasha
Они мну зомбируют. Третье письмо подобного порносодержания за неделю. Ну не хочу я на плюсы переходить ни в каком виде! И вообще мне Си не нравится - пользуюсь по необходимости.
Дык нет жеж, они уже добрались до плисоводов - превращают в плюсовода. russian_ru.gif
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2024 IPS, Inc.