Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Как ПРАВИЛЬНО программировать на С++
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > Программирование
Страницы: 1, 2, 3, 4
777777
Цитата(neiver @ Aug 19 2010, 18:40) *
А так вкратце могу сказать, что программы на С++ получаются компактнее, быстрее и легче читаются аналогичных программ на Си.

Я, в принципе, охотно верю, но тем не менее не могу придумать, какие понятия в микроконтроллерных системах можно сделать классами. Слишком уж они отличаются от обычных программ.
MrYuran
Цитата(777777 @ Aug 20 2010, 12:32) *
Я, в принципе, охотно верю, но тем не менее не могу придумать, какие понятия в микроконтроллерных системах можно сделать классами.

Да хоть какие угодно.
Порт, например, чем вам не класс?
УАРТ?
АЦП?
Таймеры?
Есть физические данные, есть объекты в адресном пространстве, есть методы, работающие с этими данными и объектами.
Почему бы не соединить вместе?

Adc->Init();
Adc->StartConversion();
...
Uadc = Adc->GetResult();
777777
Цитата(MrYuran @ Aug 20 2010, 12:37) *
Да хоть какие угодно.
Порт, например, чем вам не класс?
УАРТ?
АЦП?
Таймеры?

Нет, это не классы. Это объекты, существующие в одном экземпляре. (Правда, в программировании есть понятие синглтона, но это все-таки экзотика). А класс - это в некий тип данных, как int или char. Можно создавать объекты таких типов в любом колчестве, они обладают некими свойствами. Примером класса может быть окно - можно создавать множество объектов такого класаа - окон с разными свойствами - размером, типом, - вызывать их методы с целью поменять их, выполнить какое-то действие - нарисовать на нем что-то и т.п. Можно например, как я писал в соседнем посте, создать класс кнопки и использовать его для обработки нажатий на кнопки, отличать длительное и короткое нажатие, выполнять полиморфно их обработку.
Цитата(MrYuran @ Aug 20 2010, 12:37) *
Есть физические данные, есть объекты в адресном пространстве, есть методы, работающие с этими данными и объектами.
Почему бы не соединить вместе?

Adc->Init();
Adc->StartConversion();
...
Uadc = Adc->GetResult();

Это лишь видимость С++, в реальности это ничем не лучше вызова обычных функций. А от объектно-ориентированного программирования польза будет только если пользоваться всеми его особенностями - инкапсуляцией, наследованием, полиморфизмом. А для этого нужно весь проект рассматривать как поле для взаимодействия объектов, а не просто переделать проект на С++ потому что это модная фича.
MrYuran
Цитата(777777 @ Aug 20 2010, 15:15) *
Это лишь видимость С++, в реальности это ничем не лучше вызова обычных функций. А от объектно-ориентированного программирования польза будет только если пользоваться всеми его особенностями - инкапсуляцией, наследованием, полиморфизмом. А для этого нужно весь проект рассматривать как поле для взаимодействия объектов, а не просто переделать проект на С++ потому что это модная фича.

Ну так и АЦП может быть внутренним, а может быть внешним и подключаться через дополнительный драйвер SPI или I2C. Плюс, их может быть несколько. Так что, налицо класс, несколько объектов (возможно, разных) и единая методика работы. Тут и полиморфизм, а возможно, и перегрузка методов (в зависимости от типа АЦП).

Цитата(777777 @ Aug 20 2010, 15:15) *
Нет, это не классы. Это объекты, существующие в одном экземпляре.

Ни разу не видел контроллер с одним портом smile.gif
Вот немного выше был пример, как можно очень удобно представить разрозненные пины разных портов как один обычный порт.
Лучшего примера, я думаю, не найти.
Ну и в конце концов, чуть приподнявшись и отвязавшись от железа, имеем обычную абстрактную программу, в которой можно применять все тонкости и возможности с++.
Я для пробы делал класс цифровых фильтров - очень удобно.
В одном объекте сосредоточен буфер с дискретными отсчётами, методы и выходное значение.
Опять же, можно сделать несколько разных фильтров с разными параметрами и характеристиками.

А уж если есть экранчик (хотя бы 128х64) и менюшки-поля-окошки, то тут уж вообще разговор молчит.
Однозначно, плюсы рулят.
dxp
Цитата(777777 @ Aug 20 2010, 18:15) *
Нет, это не классы. Это объекты, существующие в одном экземпляре.

То, что классы нужно заводить только при возникновении необходимости во множественном (> 1) использовании объектов, - распространенный стереотип-заблуждение. Классы - это просто типы, определяемые пользователем, и использовать их имеет смысл во всех случаях, когда описание программных сущностей удобно воспринимать в виде законченных объектов, даже если такой объект в программе всего один. Классы, как типы, определяемые пользователем, позволяют программисту провести близкие аналогии между объектами реального мира и сущностями программы, что значительно облегчает процесс разработки, т.к. выводит логику программы на более высокий уровень абстракции (от низкоуровневого железа). К тому же, это обстоятельство позволяет в значительной мере формализовать процесс проектирования программы - т.е. составить проект ("рыбу") будущей программы из кубиков структурной схемы еще до написания первой строки кода.

Кстати, на том же С очень удобно заводить в структуру объекты, относящиеся к одному и тому же (по смыслу) месту программы, даже если таких структур нужна всего одна.
MrYuran
Цитата(dxp @ Aug 20 2010, 16:43) *
Кстати, на том же С очень удобно заводить в структуру объекты, относящиеся к одному и тому же (по смыслу) месту программы, даже если таких структур нужна всего одна.

Да, структура - частный случай класса.
ReAl
Ну вот как раз сегодняшний пример.
ATmega48. Программа сравнительно древняя на С (и нет желания её переписывать начисто, но что-то новое даже такого объёма будет сразу писаться на С++).
Дописывается кусочек функционала, понадобилось при входе в некоторый режим сохранить состояние некоторых выходов, выключаемых в этом режиме, а при выходе из режима восстановить. Ну всё понятно, заводится флаг нахождения в этом режиме (в режим может быть повторный вход, который теперь отличается тем, что сохраняь уже отключенные ножки не нужно) и буферная переменная для сохранения состояния выходов. Т.е. появляются две глобальных переменных файловой области видимости и связь между функциями через них.
На С++ все эти функции изначально объединяются в класс-«драйвер режима» и потом хоть обдобавляйся в этом классе приватных полей.
Казалось бы, между
Код
SomeModeOn();
SomeModeOff();

Код
someMode.On();
someMode.Off();

разницы не видно, «а она есть»©

Кстати, классы, изначально предназначенные для того, чтобы иметь только один экземпляр - вполне нормальное явление.
MrYuran
Цитата(alexvok @ Aug 19 2010, 14:32) *
С++ с примерами для AVR

Может, напишем сообща?
rolleyes.gif
Я уже название придумал.
"С++ в микроконтроллерах. Почему бы и нет?"
Экспортный вариант:
"С++ for microcontrollers. Why no?"

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

Спор "плюсы против бесплюсов" считаю таким же контрпродуктивным, как "асм против си".
Си вобрал в себя основные на тот момент методики структурирования ассемблера.
Плюсы - также включают основные методики из сишного программирования. То, что на си пишется в виде отдельного модуля, на с++ можно поместить в класс. Закрытые члены - это аналог static-функций и переменных. В общем, всё то же самое, только проще, короче, быстрее и нагляднее.
Точно так же, есть надстройки над с, дающие дополнительную абстракцию, например, компонентно-ориентированный диалект Nes-C, на котором написана TinyOS
neiver
Идея интересная. Я статью по этой теме пишу - никак не допишу... Времени мало. А тут книгу...
777777
Цитата(ReAl @ Aug 21 2010, 22:24) *
Кстати, классы, изначально предназначенные для того, чтобы иметь только один экземпляр - вполне нормальное явление.

Да это явление может и нормальное, я не спорю. Хуже когда этот класс в принципе не может иметь несколько экземпляров - это уже архитектурная проблема, говорящая о том, что классу тут делать нечего. Можно например написать класс CIdle, который будет инкапсулировать в себе бесконечный цикл, имеющийся в любом контроллере:
Код
class CIdle
{
CIdle()
    {
    sei();
    while(1)
        {}
    }
}

Применение
Код
main()
    {
    // инициализация периферии
    ...
    // дальше работают только прерывания
    CIdle idle;
    }

Но этот пример попахивает онанизмом, не находите? Даже если в него навтыкать указателей на функции и заставить их вызывать по кругу, пользы от него не прибавится.


Цитата(MrYuran @ Aug 23 2010, 11:33) *
"С++ в микроконтроллерах. Почему бы и нет?"
Экспортный вариант:
"С++ for microcontrollers. Why no?"

По-английски это не звучит, надо по-французски: pourquoi pas? smile.gif
Цитата(MrYuran @ Aug 23 2010, 11:33) *
У "плюсов" есть ещё один несомненный плюс. Прежде чем сломя голову что-то писать, надо сначала продумать структуру.
То есть, дополнительный организующий момент.

Да, это действительно полезно...
Andron_
по осени начал писать проект для сигнальника TI, решил на свой страх и риск использовать С++ и динамическое управление памятью в некоторых моментах.
поскольку продумать изначально удачную структуру умишка не хватило (в-смысле, не смог) структура программы получилась путанная местами и через чур замудренная. Сейчас дописываю... Естественно, что писалось полгода назад я уже наглухо забыл. В-принципе, мне нравится - с помощью Doxygen'овской документации весьма приятно дописывать.
Динамическое выделение пока также работает стабильно, я боялся худшего.

Немного неудобно использовать inline функции в классах - CCS 3.3 корявенько их разворачивает в редакторе во время отладки и по шагам ходит как-то неправильно местами.
ReAl
Цитата(777777 @ Aug 24 2010, 14:21) *
Да это явление может и нормальное, я не спорю. Хуже когда этот класс в принципе не может иметь несколько экземпляров - это уже архитектурная проблема, говорящая о том, что классу тут делать нечего.
Можно например написать класс CIdle, который будет инкапсулировать в себе бесконечный цикл, имеющийся в любом контроллере

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


xelax
Цитата(MrYuran @ Aug 23 2010, 11:33) *
У "плюсов" есть ещё один несомненный плюс. Прежде чем сломя голову что-то писать, надо сначала продумать структуру.
То есть, дополнительный организующий момент.
Кстати, данная тема именно с этого и началась - с вопроса об оптимальной структуре.


Я то наивно полагал, что продумывать структуру программы необходимо вне зависимости от языка программирования. biggrin.gif

Выскажу кромольную мысль:
На архитектуру язык программирования влияет лишь косвенно. Этап перехода с С на С++ уже давным давно закончился (если кто-то ещё не заметил). Все более или менее крупные и что немаловажно УСПЕШНЫЕ компании специализирующиеся на разработке софте (и эмбеддед в том числе) начинают с UML или подобного дизайна. Да собственно это и есть основной этап. А в получившейся на выходе архитектуре-софте любая команда индо-китайских тупокодеров добьёт код за пару месяцев.
MrYuran
Цитата(xelax @ Aug 25 2010, 12:38) *
Я то наивно полагал, что продумывать структуру программы необходимо вне зависимости от языка программирования. biggrin.gif

Ну, иерархическая модель классов более располагает к структурированию, чем рассыпные модули си.
ReAl
Я бы сказал так — по сравнению с С язык С++ более жёстко наказывает за непродуманность структуры.
dxp
Цитата(ReAl @ Aug 25 2010, 18:19) *
Я бы сказал так — по сравнению с С язык С++ более жёстко наказывает за непродуманность структуры.

Скорее более явно показывает (подчеркивает) корявости в этом контексте.
Waso
Цитата(neiver @ Aug 19 2010, 21:40) *
Примеры есть у меня, есть и свой подход к программированию для систем с сильно ограниченными ресурсами на С++(на примере AVR).
Будет свободное время - напишу статейку по этой теме (если будут желающие её читать smile.gif ).
А так вкратце могу сказать, что программы на С++ получаются компактнее, быстрее и легче читаются аналогичных программ на Си.

Цитата(MrYuran @ Aug 23 2010, 14:33) *
Может, напишем сообща?
rolleyes.gif
Я уже название придумал.
"С++ в микроконтроллерах. Почему бы и нет?"

Желающие читать такие статьи есть! Вот по крайней мере я, например! Так-что жду с нетерпением.
А как наберете с десяток статей - соедините их в книгу и будете барыши получать. wink.gif
sergeeff
Цитата(Waso @ Sep 3 2010, 09:35) *
А как наберете с десяток статей - соедините их в книгу и будете барыши получать. wink.gif


Наивность впечатляет...
Waso
В чем же она заключается, наивность-то?
DRUID3
Цитата(xelax @ Aug 25 2010, 11:38) *
Этап перехода с С на С++ уже давным давно закончился (если кто-то ещё не заметил).

Да... я заметил. Закончился. Как и жизнь C++. Мало того - когда о Cpp забудут на C еще будут писать целые системы.

Цитата(xelax @ Aug 25 2010, 11:38) *
Все более или менее крупные и что немаловажно УСПЕШНЫЕ компании специализирующиеся на разработке софте (и эмбеддед в том числе) начинают с UML или подобного дизайна.

biggrin.gif ... Эмбэддед буржуи часто называют JavaME. А "подобный дизайн"... Так все с него начинают. Даже строители зданий из железобетонных блоков.

Цитата(xelax @ Aug 25 2010, 11:38) *
Да собственно это и есть основной этап. А в получившейся на выходе архитектуре-софте любая команда индо-китайских тупокодеров добьёт код за пару месяцев.

Я сомневаюсь, что для 8-и битника стиральной машины нужна прям-таки команда индусов и менеджеров с UML диаграммами в руках.

Цитата(MrYuran @ Aug 25 2010, 11:48) *
Ну, иерархическая модель классов более располагает к структурированию, чем рассыпные модули си.

biggrin.gif ага... И к постоянному переструктурированию. Сколькими способами можно разбить белый лист на подчасти!? Не даром в том же C++ есть все что-бы нарушить инкапсуляцию "если очень надо"... Ну а полиморфизм - это ли не повод накидать в проект всего чего не лень? То, что при этом он, зачастую теряет не только обозримость, но и простую читабельность(х.з. какую там из реинкарнаций и где вызывают - и не все IDE такие же функциональные как мелкософтовская визуалстудия). Ну а уж если появилась иерархическая модель классов - это верный признак, что от первоначальной архитектуры отказались biggrin.gif biggrin.gif biggrin.gif , но переписать все заново не представляется возможным ввиду отсутствия времени совместно с запутанностью и нечитабельностью уже написанного кода.


Хорошая статья что-бы задуматься - а туда ли в жизни направляешь стопы свои... wink.gif
MrYuran
Цитата(DRUID3 @ Sep 5 2010, 22:11) *

Это всё конечно хорошо, в теории.
А в реальности никто не даст 20 лет на вылизывание кода, как в случае с академическим миниксом.
Зачастую цикл жизни изделия составляет от 2 до 5 лет.
Да и не в каждой конторе работают гении уровня Таненбаума.
Так что, оставшимся остаётся довольствоваться прозой и использовать общепринятые методики и наработки.
Тем более что действительно, лучше сегодня выпустить актуальное, хоть и несколько сырое изделие, чем завтра сидеть с вылизанным, но никому не нужным...
sigmaN
Цитата
Хорошая статья что-бы задуматься - а туда ли в жизни направляешь стопы свои...
А вы никогда не слышали как Торвальдс критикует микроядра? smile.gif bb-offtopic.gif
neiver
Цитата(sigmaN @ Sep 7 2010, 00:52) *
А вы никогда не слышали как Торвальдс критикует микроядра? smile.gif bb-offtopic.gif

Торвальдс и Си++ усиленно критикует.
Мне нравится, что Steven Dewhurst ему на это отвечает.
halfdoom
Цитата(Ink @ Aug 3 2010, 10:08) *
но когда у вас будет огромный проект, вы встряните и будете долго понимать, как же так получилось непонятно.
Вот большой проект: http://www.freebsd.org/cgi/cvsweb.cgi/src/. C++ есть только в библиотеках для C++. Ничего, не встряли. А NetBSD из той-же серии так вообще на тьму платформ портирована, и во многом благодаря здоровому консерватизму.
Dima_G
Цитата(halfdoom @ Sep 7 2010, 16:21) *
Вот большой проект: http://www.freebsd.org/cgi/cvsweb.cgi/src/. C++ есть только в библиотеках для C++. Ничего, не встряли. А NetBSD из той-же серии так вообще на тьму платформ портирована, и во многом благодаря здоровому консерватизму.

А в чем плюс то голого сишного подхода? Никто не спорит, что все, что пишется на С++, можно сделать и на Си.
Вопрос - какими средствами и какой надежностью.

SasaVitebsk
Мне кажется, всётаки, что сравнение переходов ASM->C и C->C++ некоректно. Так как первый решает главную задачу - убирает зависимость программиста от процессора (не от переферии). Эта задача глобальна для эмбеддера. И эта задача решается как академически так и практически. Соответственно повышается переносимость, возможность заимствований. Вроде бы переход C->C++ академически решает те же задачи. Но, на мой взгляд дальнейшие шаги в данной области целесообразны лишь при однотипных задачах.
Например, если программист непрерывно работает с графикой, то лучше потратить кучу времени написать и вылизать соответствующие классы работы с графикой. Но если он сегодня работает с ШД, а завтра с CAN, а послезавтра с графикой, то возникают нюансы.
Собственно эти нюансы просты. Написал я свои классы на тему конечных автоматов - потратил время. Вылизал - потратил время. А далее написал 10 проектов никакого отношения к этому не имеющещих. Через 2 года у меня появилась тема где, казалось бы можно применить наработки по конечным автоматам. И что будет? Я потрачу минимум неделю чтобы всё вспомнить и проникнуться высоким уровнем моих наработок, ещё неделю чтобы соотнести то решение с новым проектом. Естественно выяснится, что в чистом виде это чуть-чуть не подходит. И надо добавить пару новых свойств и чуть подправить реализацию. Причём лучше это сделать так, чтобы новый класс работал бы и со старым приложением. Надо честно признаться (хотя бы себе), что создавать новый класс, производный от старого, учитывая что старый писали тоже вы и, учитывая, что вы просто не учли вот этот вот нюанс, что вылез в новом проекте, вы не станете. Далее вам опять придётся проникнуться всеми нюансами разработки вашего класса, опять потребуется время для написания и отладки, чтобы через год-два вам мифически было бы проще всё это использовать.
Конечно, можно сказать что это произойдёт в случае низкого уровня программиста. А я вам возражу, что в случае низкого уровня программиста этот класс придётся переписать заново, а не чуть-чуть подправить.

По-моему, С++ это всётаки удел крупных контор с большим коллективом программистов, с чётким разделением задач, с проектами близкой направленности, с хорошей документированностью наработок и т.д и т.п. Пытаться одному программисту "охватить необъятное" (читай ... изучить и использовать все новейшие течения в области программирования) будет провальным. Из-за физической невозможности.
one_man_show
В своей практике стараюсь сделать примеры применения своего "творчества", чтобы легче передавалось по наследству и самому быстрее въезжать, что наваял лет пять тому назад. Времени и терпения писать документацию по своим наработкам в 99% случаев не хвататет, поэтому примеры применения с коментариями выручают. Какой язык программирования при таком подходе уже не имеет значения.
Harvester
Цитата(Waso @ Sep 3 2010, 19:07) *
В чем же она заключается, наивность-то?


bb-offtopic.gif
А Вы давно покупали книги по электронике/программированию?
halfdoom
Цитата(Dima_G @ Sep 7 2010, 12:40) *
А в чем плюс то голого сишного подхода? Никто не спорит, что все, что пишется на С++, можно сделать и на Си.

Я же написал про портирование на множество платформ. На момент портирования NetBSD лишь для немногих из них был вменяемый компилятор С++. Соответственно и у нас имеется определенное количество наработок на голом С, причем многим из них уже за 10 лет. Смысла в переписывании нет.
Цитата(Dima_G @ Sep 7 2010, 12:40) *
Вопрос - какими средствами и какой надежностью.
Сисадмин говорит, что предыдущая инкарнация нашего сервера под FreeBSD имела аптайм 3.5 года и была обновлена из-за переезда на новое железо.

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

Ну и классика сравнения этих языков для встраиваемых систем: "есть два пути: можно грамотно использовать все возможности C либо ограниченный набор возможностей C++" - кто сказал это не помню, но сказано верно.
MrYuran
Цитата(Harvester @ Sep 7 2010, 15:27) *
bb-offtopic.gif
А Вы давно покупали книги по электронике/программированию?

Если я вижу стоющую книгу, я её покупаю не задумываясь, на конторские деньги либо на свои.
DRUID3
offtop

Цитата(sigmaN @ Sep 6 2010, 23:52) *
А вы никогда не слышали как Торвальдс критикует микроядра? smile.gif bb-offtopic.gif


Цитата(neiver @ Sep 7 2010, 11:32) *


Авторитет Торвальдса все-таки сильно завышен. Нет, разумеется он молодец - написать свою до конца работоспособную ОС-ку еще в студенческие годы(когда вечно не хватает времени) и "раздать ее людям"... Но... Если задуматься - студенческую ОС без прикладного софта напарить можно разве что тем людям которые профинансировали "сапфировые носители" для украинской центральной библиотеки. Да и писать UNIX, пусть и самобытный, по книжке это не одно и то же, что придумать UNIX. Чувствуете разницу?

В те далекие годы столменовский GNU и "опенсоус" набирали силу, появился GCC - который на данный момент, что бы там не говорили, является одним из лучших компиляторов. А что произошло бы если "опенсорщики" подхватив самые конструктивные идеи общими стараниями создали бы еще и ОС без изъянов? Не создали... И поныне... И именно благодаря Линусу и его Linux'у. Если какое-то из социальных потрясений не остановить - его нужно возглавить? Так? Кто и когда решил сделать ставку на архитектурную быдло-поделку - а первые версии ядра ну ничегошеньки из ряда вон выходящего не демонстрировали - навсегда останется под покровом тайны. Но факт фактом. И здесь понемногу начинает закатываться звезда Столмена - эдакого эксцентричного мечтателя и восходит Торвальдса - жизнерадостного практика со здоровым видом. Хм rolleyes.gif , есть над чем задуматься... Даже в каком-то документальном фильме видел сценку - Столмена награждают премией Линукса - на что он сам в ответ язвит "Ха, это все равно что Хан Соло награждал бы премией Альянс Повстанцев" (прочтите эту фразу несколько раз... и подумайте)...

Я когда-то Вам, sigmaN, не ответил(не было времени на развернутый ответ) что-же быдлокодерского в Линуксе. В самом коде - качественно ничего. Но в архитектуре - это "в лоб" написаный UNIX переживший несколько конструктивных потрясений. Ну каГбЭ бульварный роман написанный на безупречном русском wink.gif .

Кстати темные силы мировой закулисы не столь коварны(там точно нет русских или украинцев - иначе голову Столмена нашли бы под Белой Церковью, в лесу, делов то smile.gif ) сколь дальновидны. Ни для кого не секрет, что дикие народности типО иранцев, украинцев, русских и китайцев беззастенчиво используют свободное ПО (которое писАли люди со всего мира) в том числе и в военной технике. Не повод ли задуматься - а стОит ли при этом "раздавать" самое лучшее wink.gif ...


P.S.: да, я сторонник теории заговоров и не стыжусь этого tongue.gif ...

P.P.S.: "диким народностям" стоит задуматься, что не все "свободное ПО" одинаково полезно biggrin.gif , и верные инвестиции сеодня(инвестиции интеллекта в том числе) завтра могут обернуться качественным(ключевым) преимуществом в целой отрасли. Это на просто на каждом углу кричать "о, свободное ПО... а-а-а-а...у-у-у-у... э-э-э-э... Покупайте наше свободное ПО" biggrin.gif rolleyes.gif ...

P.P.P.S.: готов поспорить, что та же история и с т.н. "нейронными сетями" - как по мне, то это "каша из топора". Жаль, что это уж совсем-совсем оффтоп...


end_offtop
sigmaN
Блни, а зря оффтоп прикрыли.
Вот щас про Торвальдса потроллить бы, а))))

Цитата
Сисадмин говорит, что предыдущая инкарнация нашего сервера под FreeBSD имела аптайм 3.5 года и была обновлена из-за переезда на новое железо.

Прям 3.5года без единого ребута??? Я в восторге!

Лично я абсолютно согласен с Торвальдсом, что такие вещи как ядро ОС на С++ лучше не писать.И аргументирует он своё мнение.
Один мой знакомый говорит что типа забивать гвозди можно и ноутбуком... Конечно, он на много круче, чем обычный молоток, но... улавливаете мысль, нам то гвоздь забивать надо и в деле забивания гвоздя - молоток зэ бэст.
А ещё Торвальдс правильно сказал как-то что-то типа: компиляторы, языки - всё это инструменты в наших руках и если мы будем идти на поводу у своих инструментов или не делаем чего-то, потому что нам не позволяют наши инструменты, то как-бы пора бы может быть нам сменить профессию или поменять инструменты. (как-то так, за достоверность не ручаюсь)
Но, конечно, тема вообще холливарная пошла....завязывать надо..

P.S. Без оффтопа жить тяжело. Чё, мож и вправду на шараге зарегиться...... smile.gif
Сергей Борщ
Цитата(sigmaN @ Sep 8 2010, 02:01) *
Один мой знакомый говорит что типа забивать гвозди можно и ноутбуком... Конечно, он на много круче, чем обычный молоток, но... улавливаете мысль, нам то гвоздь забивать надо и в деле забивания гвоздя - молоток зэ бэст.
Сравнение некорректно. Ноутбук изначально не предназначен для забивания гвоздей. Есть такие специальные пневматические молотки, для которых гвозди выпускаются в кассетах. Вот это больше похоже - можно с чувством, не спеша, накачивая мышцу забивать ручным молотком, а можно нажав кнопку загнать пневматическим. Плата - стоимость инструмента (читай - необходимость изучать С++) и несколько более высокая стоимость гвоздей в кассете по сравнению с гвоздями россыпью в ящике (читай - некоторые накладные расходы типа кода вызова конструкторов). Но если покупать гвозди не по одинаковому количеству, а, скажем, закупить количество гввоздей, которое можно забить за час одним и вторым инструментом, то выясняется, что это количество гвоздей в кассетах уже подходит под понятие "мелкий опт" и по мелкооптовым ценам гвоздь даже с дополнительной кассетой стоит дешевле, чем гвоздь без кассеты по розничным. Вот такое сравнение мне кажется более похожим на C/C++.

Ну или сравните лопату и экскаватор. Только лопату берите не с Джамшутом впридачу, а с профессиональным копателем. И посчитайте, сколько надо заплатить профессиональному оператору лопаты за рытье траншеи, скажем, м*м*км и сколько будет стоить та же работа, выполненная экскаватором с профессиональным оператором экскаватора за рычагами. И сравните затраченное в обоих случаях время.
sigmaN
Нет, точно пора завязывать, оффтоп же!
halfdoom
Цитата(sigmaN @ Sep 8 2010, 02:01) *
Прям 3.5года без единого ребута??? Я в восторге!

Поскольку он периодически хвастался растущим аптаймом, то на 3 году я решил поинтересоваться "а не зря ли мы его кормим" (имелся в виду сисадмин). Действительно, uptime был за тысячу с лишним дней, все порты были аккуратно обновлены и даже пересобраны некоторые системные библиотеки и демоны. Но ядро оставалось прежним и перезагрузок не требовалось.
neiver
Господа/Товарищи/Эмбеддеры/Радио коты (нужное подчеркнуть), я таки худо-бедно да дописал ранее обещенную статью про организацию ввода-вывода для МК семейства AVR на Си++.
Собственно, статья состоит из двух основных частей. Первая - обзорная о том как ввод-вывод организуется на цистом Си. Вторая - как это можно сделать на Си++.
Конструктивные комментарии/замечания/пожелания приветствуются.
MrYuran
Цитата(neiver @ Sep 9 2010, 19:30) *
Господа/Товарищи/Эмбеддеры/Радио коты (нужное подчеркнуть), я таки худо-бедно да дописал ранее обещенную статью про организацию ввода-вывода для МК семейства AVR на Си++.

Отличная статья!
И намного нагляднее, чем 6 страниц руками махать.
Рекомендую разместить в разделе статей.
Обсуждение здесь
Сергей Борщ
Цитата(neiver @ Sep 9 2010, 18:30) *
Конструктивные комментарии/замечания/пожелания приветствуются.
Опенофис показал множество опечаток. Периферия пишется через "е" - это сразу бросилось в глаза. Продолжаю читать.

Код
#define PortaBits (*((Bits*)&PORTA))
пропущен volatile

Код
    static void Set()
    {
        *(uint8_t*)(PORT + __SFR_OFFSET) |= (1 << PIN);
    }
Снова пропущен volatile

Код
    typedef TPin<Porta, 0> Pa0;

....
    Pa0.SetDirWrite(); // <- разве тут не должно быть Pa0::SetDirWrite() ?
WHALE
Код
void LCDwrite4(uint8_t value)
{
    LDP &= ~(1<<LCD_D7|1<<LCD_D6|1<<LCD_D5|1<<LCD_D4); //clear data bus
    
    if(cmd & (1 << 0))
        LDP |= LCD_D4;
    if(cmd & (1 << 1))
        LDP |= LCD_D5;
    if(cmd & (1 << 2))
        LDP |= LCD_D6;
    if(cmd & (1 << 3))
        LDP |= LCD_D7;
}


В аргументе фукции value на cmd замените.
А вообще-то отличная статья,спасибо!
Сергей Борщ
Подход замечательный. Обязательно использую в ближайшем проекте - надо будет крутить несколько шаговиков.
ReAl
Цитата(Сергей Борщ @ Sep 10 2010, 12:57) *
Подход замечательный. Обязательно использую в ближайшем проекте - надо будет крутить несколько шаговиков.
+1
Нутром чуял, что что-то такое реально сделать, но всё страшно за Александреску взяться :-) Точнее, за глубокое влезание в шаблоны.
Увы, у меня С++ больше как «С с классами» идёт, хоть я и понимаю, что этого мало.

p.s[0] Отличная иллюстрация того, что программисты на С борятся с аппаратурой (вручную маски битов собирают), а программисты на С++ борятся с компилятором (заставляют его делать тупую работу).

p.s[1] По поводу лицензии.
scmRTOS тоже поначалу была (L)GPL, но там не совсем понятно с использованием в проектах с закрытыми исходниками вот таких библиотек уровня исходников. И Гарри перевёл её на нечто MIT/BSD-подобное.
halfdoom
Цитата(ReAl @ Sep 10 2010, 15:43) *
p.s[0] Отличная иллюстрация того, что программисты на С борятся с аппаратурой (вручную маски битов собирают), а программисты на С++ борятся с компилятором (заставляют его делать тупую работу).

Позволю себе добавить, что отличная, но однобокая иллюстрация. Автор абсолютно не упоминает о возможности описания проекта на языках с гораздо более гибкими и удобными конструкциями. Ведь никто не обязывает втискивать себя в прокрустово ложе препроцессора C или шаблонов C++. Современные скриптовые языки вроде ruby или python позволяют эффективно описать проект (причем не только МК но и всю периферию) и автоматически сгенерировать все требуемые макроопределения, функции, файлы конфигурации и документации, причем генератор легко может учитывать особенности целевого компилятора или ассемблера. При этом сложность описания не ограничивается парой портов.

Приведу усеченный пример:
Код
require 'atmega162'
require 'unitimer'

M = ATMega162.new

M.device_name = "My Super Device"
M.clksrc = :FAST_CRYSTAL
M.clkfreq = 14.3e6
M.bldr_size = 2048

M.hw_version = [1, 2]
M.fw_version = [1, 1]

#
# Pins configuration
#
M.dp :A, 0, :KBDR0,     :IN,  :PULLUP    :desc => "kbd row 0"
M.dp :A, 1, :KBDR1,     :IN,  :PULLUP    :desc => "kbd row 1"
...
M.dp :C, 0, :LED_A,    :OUT,  :INIT1,        :desc => "Display1, seg A"
M.dp :C, 1, :LED_E,    :OUT,  :INIT1,        :desc => "Display1, seg E"
M.dp :C, 2, :LED_C,    :OUT,  :INIT1,        :desc => "Display1, seg C"
M.dp :C, 3, :LED_F,    :OUT,  :INIT1,        :desc => "Display1, seg F"
M.dp :C, 4, :LED_B,    :OUT,  :INIT1,        :desc => "Display1, seg B"
M.dp :C, 5, :LED_D,    :OUT,  :INIT1,        :desc => "Display1, seg D"
M.dp :C, 6, :LED_G,    :OUT,  :INIT1,        :desc => "Display1, seg G"
M.dp :C, 7, :LED_H,    :OUT,  :INIT1,        :desc => "Display1, seg H"

#
# define pins group for display segements
#
M.dg :LED_SEGMENTS, 8, [:LED_A, :LED_B, :LED_C, :LED_D, :LED_E, :LED_F, :LED_G, :LED_H]

#
# unitimer configuration, period 20uS, mode - OCR
#
M.unitimer(20e3, :OCR)
M.UT.add "05S",     500e3, :timer_05s_handler
M.UT.add "LED",        200, :led_timer
M.UT.add "MODBUS",    :MODBUS_TIMER_TICK, :mb_timer
...
M.sources=%@
  main.c
  leds.c
  control.c
  heater.c
@

Функциональность объекта ATMega162 имеющего общим предком семейство МК АВР понимает не только определения портов и групп битов, но и может быть расширена за счет подключения дополнительных модулей как unitimer в этом примере. Так, аналогичные расширения имеются для шин Modbus, Microlan, pcuart, пресловутого 44780, sed1520. Более того, поскольку уже все описано на языке высокого уровня, генератор учитывает конфигурацию фьюзов и генерирует соответствующие секции Makefile'ов учитывая особенности AvReal или avrdude.

Значительным преимуществом данного подхода является и то, что вся конфигурация собрана в один или несколько однородных файлов, что резко снижает вероятность непреднамеренных ошибок.
ReAl
Цитата(halfdoom @ Sep 11 2010, 08:54) *
Позволю себе добавить, что отличная, но однобокая иллюстрация. Автор абсолютно не упоминает о возможности описания проекта на языках с гораздо более гибкими и удобными конструкциями.
...
Приведу усеченный пример
И Вам спасибо за иллюстрацию, или, по крайней мере, её фрагмент.
Зато пример автора полный, по которому можно учиться и которым можно пользоваться :-)
Если бы, чтобы уйти от упрёка в однобокости, в такой объём кто-то попытался бы втиснуть «чуть менее, чем все» возможности, то это было бы несколько страниц реферативного журнала, по которому можно было бы узнать о спектре идей, но ничему нельзя было бы научиться. Такое тоже полезно и это ждёт своего автора.
Каждая иллюстрация однобока, и только их множество создаст более-менее полную картину.
На то и фрум.

MrYuran
Цитата(halfdoom @ Sep 11 2010, 09:54) *
Позволю себе добавить, что отличная, но однобокая иллюстрация.

Ну так представьте народу второй бок, в виде контр-статьи. Чтобы можно было пользоваться, а не голословно.
halfdoom
Цитата(ReAl @ Sep 11 2010, 10:27) *
Если бы, чтобы уйти от упрёка в однобокости, в такой объём кто-то попытался бы втиснуть «чуть менее, чем все» возможности, то это было бы несколько страниц реферативного журнала
Наверное да, от обзорных статей всегда ожидаешь большего чем они, как правило, содержат. Что, конечно, ни сколько не умаляет их ценности.
dxp
Цитата(halfdoom @ Sep 11 2010, 12:54) *
Позволю себе добавить, что отличная, но однобокая иллюстрация. Автор абсолютно не упоминает о возможности описания проекта на языках с гораздо более гибкими и удобными конструкциями. Ведь никто не обязывает втискивать себя в прокрустово ложе препроцессора C или шаблонов C++.

То, о чем вы говорите, - это ортогональная вещь. Нативный код - это нативный код, и он обладает такими свойствами, которые не заменят никакие кодогенераторы. Есть отличный кодогенератор COG, который позволяет писать определения прямо в исходном коде. И в ряде случаев это действительно удобная и мощная штука. Но пример использования С++, приведенный в обсуждаемой статье, не нуждается ни в каких кодогенераторах - он предельно лаконичен, полон, прост в использовании и эффективен. Да, он сложен в реализации. Все эти трюки тов. Александреску - это высший пилотаж плюсового программирования, они требуют глубокого понимания концепций языка, а это приходит только с опытом его использования. Вот это и есть главная проблема для эмбеддеров - такого опыта у них, как правило, нет (по вполне объективным причинам). Поэтому этот код с шаблонами, списками типов и прочим для большинства - китайская грамота. Хотя при наличии отлаженной библиотеки можно использовать и не страдать. Необходимость вникать потребуется в случае портирования ее на другую платформу.

Но в любом случае есть мотив осваивать подобные средства. А автору статьи - большущий респект: очень нетипично для эмбеддера поднять такой уровень понимания С++! В статье навести корректуру (поправить опечатки, ошибки) и однозначно поместить в библиотеку форума.
halfdoom
Цитата(MrYuran @ Sep 11 2010, 11:39) *
Ну так представьте народу второй бок, в виде контр-статьи. Чтобы можно было пользоваться, а не голословно.
Была такая идея, но все сильно завязано на нашу внутреннюю инфраструктуру на экспозицию которой никто добро не даст. Со временем попробую отделить мух от котлет.


Цитата(dxp @ Sep 11 2010, 14:49) *
То, о чем вы говорите, - это ортогональная вещь. Нативный код - это нативный код, и он обладает такими свойствами, которые не заменят никакие кодогенераторы. Есть отличный кодогенератор COG, который позволяет писать определения прямо в исходном коде. И в ряде случаев это действительно удобная и мощная штука.

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

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

Замечание насчет нативного кода не ясно - код созданный на базе описателей является нативным и даже оптимизированным под конкретный МК или компилятор.
BSVi
Уже некоторое время пишу на плюсах в эмбеддед-проектах. Довольно удобно получается. Я бы не сказал, что плюсы не прощают архитектурные ошибки. Скорее, плюсы сужают область поиска правильной архитектуры - каждая сущность - класс. Кроме того, существует куча паттернов, о которых так много говорят программеры для "старших братьев". Собственно, сейчас изучением паттернов я и занят. После статьи я понял, что стоит почитать еще и Александреску.
neiver
Я исправил высказынные замечания и некоторые опечатки.
Вот исправленная версия.

PS.
Если кто хочет опубликовать статью у себя - пожалуйса!
Ссылаться можно на мой Git репозиторий:
AvrCpp
sigmaN
Великолепная статья!
Самому очень понравилась!
Немного пропиарил ))
DI HALT'у тоже понравилась и теперь её можно лицезреть у него на сайте

P.S. аффтар жги ещё! это очень круто wink.gif

И да, ВСЕХ С ДНЕМ ПРОГРАММИСТА!!!!
Чистого и безглючного кода нам всем cheers.gif
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.