AVR на Си++

[mazda]

передача данных в функции в этой ситуации отстствует потом что есть оптимизация и createpad действительно ничего не потребляет и нигде не создаёт кроме команд во флэше на чтение запись

не в качестве коментариев, этот макрос является обёрткой, за ним создаётся список create... с которым потом и идёт работа, a1 a2 это подставленные имена, что бы не добавлять генератор имён по номерам.

[Reflector]

[uquote="mazda",url="/forum/viewtopic.php?p=3237719#p3237719"]передача данных в функции в этой ситуации отстствует потом что есть оптимизация и createpad действительно ничего не потребляет и нигде не создаёт кроме команд во флэше на чтение запись[/uquote]
Оптимизация то есть, компилятор функцию может заинлайнить, но если передаешь 8 констант и 8 переменных, то я бы на одинаковый результат сильно не рассчитывал...
Покажи что у этой createpad внутри, тогда понятнее будет.

[mazda]

я как раз расчитываю, сколько не проверял, было нормально.

про виртальный порт интересно, но подозреваю что вариант с тем что компилятор не правильно что то поймёт точно так же может быть, поэтом и нужно проверять дизасм

[Ярослав555]

[uquote="ARV",url="/forum/viewtopic.php?p=3237530#p3237530"]по-моему, надо соблюдать чувство меры и в стремлении абстрагироваться от "нижнего уровня", иначе в этом увлечении можно за деревьями леса не увидеть.[/uquote]
Видимо это Вы еще с stm32 не работали. Запилили они свои МК. Поняли что слишком сложно периферию сделали. Начали stl делать, поняли что идут не туда. Сделали HAL. И Cube. И теперь юзер мышкой в кубе кликает галочки, куб генерирует проект под нужную среду, юзер открывает проект, видит поля - код писать здесь, и пишет там код. Понял что допустил косяк в настройке. Открыл куб, перетыкал галочки, перегенерил проект (меняется всё что угодно кроме полей с Вашим кодом).
Порт - объект, обращение через методы... Если мне память не изменяет. Последний раз под стмки почти год назад писал.

[Reflector]

Посмотри тут, там есть и выхлоп на ассме. Хотя подход старый, сейчас можно проще сделать, c variadic templates и без библиотеки loki.

[mazda]

скажем так, под ПК я пишу не так как в этих примерах, а обычный ооп на c#, потому как экономить так чильно не нужно.
под виртуальную среду 3d max тоже не так, там так не получится вообще, там тема другая.
соответственно под стм когда буду учиться, сначала буду писать как в примерах, а через год другой может что то придётся выдумывать

[ARV]

это Вы еще с stm32 не работали

я вообще с С++ не работал... в моём понимании прелесть ООП в возможности динамического создания-удаления экземпляров объектов, чего, пожалуй, даже на STM32 сложновато будет добиться, хотя в принципе возможность размещения исполняемого кода в ОЗУ - это предпосылка... а что там шаблоны позволяют делать - с этим я знаком очень поверхностно... для AVR все экземпляры классов исключительно статические, что сводит ООП к достаточно объемному кодописанию... это вот такое моё имхо

[mazda]

[uquote="ARV",url="/forum/viewtopic.php?p=3237744#p3237744"][quote="Ярослав555"]для AVR все экземпляры классов исключительно статические, что сводит ООП к достаточно объемному кодописанию...[/uquote]

статические, но не объёмному, код коротче чем без ооп

[Ярослав555]

[uquote="ARV",url="/forum/viewtopic.php?p=3237744#p3237744"]в моём понимании прелесть ООП в возможности динамического создания-удаления экземпляров объектов, чего, пожалуй, даже на STM32 сложновато будет добиться[/uquote]
Я тут для меги644 вот код потихоньку пишу, с динамическим выделением памяти. Суть в том что на этапе старта платы, МК сканирует сеть 1-провод и найденные устройства складывает в буфер. Так вот я подумал - а нафига мне нужны всякие служебные буферы и переменные после сканирования? Вот и переделал функции в структуры, которые в процессе работы динамически создаю и потом удаляю в конце.
В старой программе вообще казус какой-то: программист в динамике выделяет массив под найденные устройства. Это 10 байт на каждое. А быть их может не одна сотня. Вот и получится что плата в аут уйдет. Толи делалось на пофиге, толи завтык - спросить уже некого, разбежались еще до моего прихода.

P.S. Выделять на стеке не вариант - я функции пуляю между делом, поэтому эти все буферы и флаги должны жить между пулами до окончания процесса. А вообще для тренировки и развития навыков хочется таким позаморачиваться

[ARV]

в AVR вы ничего не выделите динамически из понятия ООП, ибо весь код должен быть только в FLASH. если вдруг (я не в курсе) таблицы виртуальных методов компилятор помещает в ОЗУ, то ничего, кроме проигрыша в RAM и скорости исполнения вы так же не получите. ну а динамическое распределение памяти под данные - почему бы нет? но ООП тут совсем никаким боком...

[mazda]

не давно была такая задача, жаль отложить пришлось, но опишу:

в процессе работы возникают разные сообщения, причём шина, количество данных и частота их появления заранее не известны, и появляются не ожиданно.

пришла такая идея, в динамике выделить массив для этих сообщений, а потом создавать их перегруженным new оператором, и в нём самом проверять есть ли место, и если нет места, останавливать все процессы, ждать пока сообщения разошлются и продолжать.

Добавлено after 1 minute 20 seconds:
[uquote="ARV",url="/forum/viewtopic.php?p=3237760#p3237760"]в AVR вы ничего не выделите динамически из понятия ООП[/uquote]

это не так, но если писать на GCC шном СИ++ то придётся написать new и delete через malloc, но подробно не вспомню


код во флэш и так, выделяется оперативка для полей объектов, байты если хотите, них есть начало и размер, и это самое начало тпо передаётся методу, глобальные объекты жрут оперу, они загружаются своими констркторами в озу, как и на пк

[Reflector]

[uquote="ARV",url="/forum/viewtopic.php?p=3237760#p3237760"]в AVR вы ничего не выделите динамически из понятия ООП, ибо весь код должен быть только в FLASH. если вдруг (я не в курсе) таблицы виртуальных методов компилятор помещает в ОЗУ, то ничего, кроме проигрыша в RAM и скорости исполнения вы так же не получите. ну а динамическое распределение памяти под данные - почему бы нет? но ООП тут совсем никаким боком...[/uquote]
Не важно AVR или STM32, там и там динамически объекты создаются очень редко, я лично ни разу не создавал. Другое дело выделение памяти под данные, о чем пишет Ярослав555, но тогда разница между С и С++ тоже минимальная, в одном случае вызываешь new, в другом - malloc.

[mazda]

в конце концов если так приспичит сильно можно не писать на контроллеры

[Ярослав555]

[uquote="Reflector",url="/forum/viewtopic.php?p=3237766#p3237766"]но тогда разница между С и С++ тоже минимальная, в одном случае вызываешь new, в другом - malloc.[/uquote]
А как же рост над собой и самосовершенствование? Мне 29, не хочется всю жизнь 8 битные МК ковырять. Вот и леплю ООП там где можно и без него. Иногда на Qt делаю софтинки. Может через годик-два попробую вакансии просмотреть...

[mazda]

[uquote="Ярослав555",url="/forum/viewtopic.php?p=3237796#p3237796"]Мне 29[/uquote]
совпадение?

Вакансии посмотреть в каком смысле? Где?

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

[Ярослав555]

[uquote="mazda",url="/forum/viewtopic.php?p=3237797#p3237797"]Вакансии посмотреть в каком смысле? Где?[/uquote]
в интернетах, по знакомым спрашивать. Пока точно не знаю. На $400/месяц сидеть как-то маловато. Хотелось бы на какой-нибудь хороший проект попасть. Ну это розовая мечта. Чет эти станки меня уже достали. Чего я только не пилил - и котельная была, и станки контактной сварки, и частотники, и линии сортировки фруктов-овощей, и станки для собирания-склейки картонной тары, и станки для сбивания деревянных ящиков, и станки для прокатки металопрофиля... Теперешняя работа самая удачная. Не то чтобы меня выганяли хотя бы из одной работы - надоело, стало скучно, денег мало. Закрыл проекты, сгреб вещи и пока.

[mazda]

может если опыт хороший самом станки делать и продавать?
это будет совсем не 400$

[Ярослав555]

[uquote="mazda",url="/forum/viewtopic.php?p=3237866#p3237866"]может если опыт хороший самом станки делать и продавать?
это будет совсем не 400$[/uquote]
Чтобы самому машину сделать надо хороший цех иметь. Браться за модернизацию-реставрацию токарных, фрезерных - такое себе. Слышал недалеко в Одессе уже таким занимаются. Мой план потихоньку учить ООП, книжки умные читать и через пару лет я буду знать что делать.

[Аlex]

[uquote="ARV",url="/forum/viewtopic.php?p=3237760#p3237760"]если вдруг (я не в курсе) таблицы виртуальных методов компилятор помещает в ОЗУ, то ничего, кроме проигрыша в RAM и скорости исполнения вы так же не получите[/uquote]Таблицы создаются указателей на методы, а не самих методов. Да и не факт ещё, что она размещается в RAM. По сути, эти указатели константные, и компилятор, возможно, разместит таблицу во флеши. Можно проверить, если что.
Но. Необходимости в создании виртуальных методов, в большинстве случаев, нет. Только в специфических ситуациях - когда необходимо для каждого экземпляра-наследника создавать свою копию метода. Подобное, в классическом проганье, встречается очень редко.

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

[ARV]

Да и не факт ещё, что она размещается в RAM. По сути, эти указатели константные, и компилятор, возможно, разместит таблицу во флеши.

именно это я и имел ввиду. это, с моей точки зрения, и перечеркивает все плюсы от С++: все экземпляры объектов - статические, т.е. неизменные. В этом случае С++ выполняет роль очень продвинутого препроцессора, компонуя исходники более логичным образом, а по сути - те же неизменные функции (методы)...

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

но при статических экземплярах классов из этой затеи не выйдет ничего. конечно, если компилятор не будет создавать экземпляр в виде VMT+данные в ОЗУ. но если будет, то AVR-овского ОЗУ точно не напасешься.

В общем, плюсов очень много

плюс - это два минуса, один из которых повернут на 90 градусов см. выше - в условиях AVR этот минус превращает С++ в "Си два креста", имхо. хотя меня нельзя считать экспертом в этой области: я честно признаюсь, что С++ владею в объеме "с трудом читаю, но не говорю"