AVR на Си++

[mazda]

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

[Ярослав555]

CyberVad писал(а):

Лучше объясните - на кой чёрт этот замороч с плюсами: классы, наследники, инкапсуляция методов, полиморфизм и прочий бред? Почему нельзя написать просто на си?

Гибкость кода. Один раз описав класс и связи между объектами, я за десяток минут добавляю хотелки клиента уже будучи на объекте. А мой предшественник тратил неделю-две барахтаясь по всему коду, и часто говорил - это невозможно. Инкапсулируя какой-то функционал в класс, я забываю о внутренней механике. Летом был объект, где мы делали модернизацию большого портового элеватора. Делали без остановки. Моя задача была стыковать модернизированные РП с ПЛК и старую систему управления. С одной стороны я мастером модбасс пуляю, с другой прикидываюсь старым контроллером с проприетарным интерфейсом. В программе я создавал виртуальные исполнительные механизмы, которые имели привязку в модбас. ПЛК тогда у меня был просто модулем ввода-вывода. Если это писать без объектного подхода, это было бы нечто.

[mazda]

наконец таки пошли комментарии здорового человека

[Аlex]

Праграмист да ищё и дохтур - круто !

[mazda]

не програмист

[Аlex]

Открою Вам тайну - Вы и не доктор

[mazda]

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

[Аlex]

Конечно же шучу
PS: Ладно, офф уже пошёл

[mazda]

Товарищи, куда вы пропали?
Вы же сами говорили что нужно показать о чём речь и продолжим, а то без примеров не понятно.
Вот примеры, давайте продолжать, вопрос не не об чём вообще то.

[Siarzhuk]

mazda писал(а):

Товарищи, куда вы пропали?

Воду возим.

mazda писал(а):

...а то без примеров не понятно.

Если и был пример, то пример того, что чистый незамутнённый продакшен-код ну никак не годится для представления концепции, потому как скорее представляет извилистость пути разработки. То бишь данно-конкретно изначально просматривается идея создать шаблон класса работающего с моторчиками - что есть верная дорога, но, затем, реальность в виде отставного сапога-загазчика жиди́тся докупить правильные моторы и темплейтик клонируется и быстренько захачивается под новый тип мотора - и ну а вишенкой на куче - выбор шаблона по #ifdef-у! После этого уже и шаблон с 77-ю параметрами не способен произвести то нервно-паралитическое впечатление, что должен был бы. Впрочем, без возможности заглянуть на его [шаблона] реализацию всякое наше суждение о необходимости 77-ти параметров обречено быть поверхностным и спекулятивным. Объявление темплейта продемонстрируйте, пожалуйста, для поддержки конструктивности дальнейшего разговора. Есть подозрение, что используется метапрограммирование вами не совсем чтобы сказать по Уставу.
PS: и да, тем несчастным, что повелись вам помогать надо хоть чуть-чуть беречь здоровье - используя форматирование кусков кода, которые постите, для упрощения распознавания замыслов с экрана.

[mazda]

Как раз про шаблон двигателя речь не шла, я просто кинул тексты как есть не редактируя. Странные рассуждения о жадности заказчика не в тему будут, эти моторы там и были изначально, тут скорее опасения разные. Но это не по теме. По теме реализация односвязных списков объектов разных классов без затрат оперативки, которая в этих примерах используется.

Добавлено after 2 minutes 46 seconds:

Siarzhuk писал(а):

То бишь данно-конкретно изначально просматривается идея создать шаблон класса работающего с моторчиками - что есть верная дорога, но...

Именно объекты - моторчики и не вызыаются в односвязых списках о которых речь шла с самого начала.

Добавлено after 2 minutes 46 seconds:

Siarzhuk писал(а):

темплейтик клонируется и быстренько захачивается под новый тип мотора

Тип мотора тот же.

[Siarzhuk]

mazda писал(а):

По теме реализация односвязных списков объектов разных классов без затрат оперативки, которая в этих примерах используется.

И каких советов вы хотите получить показывая использование, но не показывая реализацию? Что скрывается за createpad, что скрывается за thread? Не полезем в дебри - ограничимся первым примером. Программисты хорошо читают код, но не мысли в чужой голове по поводу этого кода.

[mazda]

В том то и дело что хочется увидеть как это реализовал бы кто нибудь другой, в этом смысл.

createpad(a1,a,1);

a1(_write,_H); - вывести 1

if( a1(_read,_pullup) )... проверит есть ли 1 на пине 1 порта А

ну так это то же не то, это не списки, вот эмитация потоков их использует, а пины не причём



если нужно какуюто сокращённую версию:

create_line( abrvalg ); - создали список

где то после объявления списка в глобальном namespace
create_line_point( abrvalg, abrvalg01, любой код );

где то в функции после объявления списка но безотносительно узелков списка
call_line( abrvalg ); - вызов всего кода из узелков списка


не много про количество параметров привода, 70 с хвостиком это не много, посмотрите сколько у частотников на шпиндели, за сотню бывает.

[ARV]

createpad(a1,a,1);

a1(_write,_H); - вывести 1

if( a1(_read,_pullup) )... проверит есть ли 1 на пине 1 порта А

по-моему, надо соблюдать чувство меры и в стремлении абстрагироваться от "нижнего уровня", иначе в этом увлечении можно за деревьями леса не увидеть. if( a1(_read,_pullup) ) ничем не понятнее, информативнее, логичнее и красивее тупейшего if(PORT & (1<<PIN))...

[mazda]

то есть вы предлагаете например все 32 пина контроллеров атмега32 просто помнить по номеру?

при том что даже многие сишники стараются ставить хотя бы дефайны для того что бы дать пинам имена.

creatpad оптимизирован так что после компиляции зачастую равен обычным логическим операциям с портом, нужно будет как нибудь дизасм прикрутить показать из чего что выходит.

creatpad передаётся в шаблоны и функции в качестве параметра




моторчики - bautz E644 B-MGB-K по осям, на сверление - GMN TSS 62

про запоминание по пинов по номерам это напрямую плохой совет, на данный момент в работе 4 прошивки для 4 контроллеров, как помнить?
Был у меня лет 10-12 назад проект на ПК в среде внутреннего скрипта 3d Max по симуляции физики, сам проект ушёл вникда но коекакой опыт оставил, там было нельзя создавать классы, объекты и тд, при этом вроде как язык высокого ровня абстракции и мне преходилось создавать большие массивы и просто нумеровать данные, пока работа шла я всё помнил, но когда через год решил посмотреть что там да как, глянул и ужаснулся, и это при наличии очень подробных комментариев

Последний раз редактировалось mazda Пн ноя 20, 2017 08:09:13, всего редактировалось 1 раз.

[ARV]

то есть вы предлагаете например все 32 пина контроллеров атмега32 просто помнить по номеру?

с чего вы это взяли? в моём надуманном примере вместо реального порта и его пина - макросы.

creatpad оптимизирован так что после компиляции зачастую равен обычным логическим операциям с портом, нужно будет как нибудь дизасм прикрутить показать из чего что выходит

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

[mazda]

ARV писал(а):

дестяку пинов без перегрузки мозга...

4*32 = 128

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

в том то и прелесть "мета абстракций" типа createpad, thread, menu, createadc, timer и тд что помнить их внутренности не нужно

[Reflector]

ARV писал(а):

по-моему, надо соблюдать чувство меры и в стремлении абстрагироваться от "нижнего уровня", иначе в этом увлечении можно за деревьями леса не увидеть. if( a1(_read,_pullup) ) ничем не понятнее, информативнее, логичнее и красивее тупейшего if(PORT & (1<<PIN))...

Шаблонный класс пина или порта - это то, с чего начинается большинство библиотек на плюсах. Ты сам недавно писал, что когда делал индикацию методом чарлиплекса, то создавал структуру хранящую адреса PORTx, DDRx и маску пина, а шаблон и так все это про пин знает, причем там нет никакой структуры и все данные являются обычными константами. В 2010-м была одна тема с такой либой для AVR, там был даже класс виртуальных портов, т.е. создаешь список пинов, которые затем рассматриваются как один порт, причем этот список сортируется, удаляются дубликаты портов, объединяются маски пинов, выбирается стратегия записи в эти порты в зависимости от того разброса ли пины по одному или группами и т.д.... И это все делается на стадии компиляции, на старом С++98, где еще variadic templates не было. В коде mazda есть такой фрагмент где это бы пригодилось:

Код:

___B8B( bus,
a0, atmega32_dip40_pin26,
a1, atmega32_dip40_pin27,
a2, atmega32_dip40_pin28,
a3, atmega32_dip40_pin28,
d0, atmega32_dip40_pin20,
d1, atmega32_dip40_pin19,
d2, atmega32_dip40_pin18,
d3, atmega32_dip40_pin21,
d4, atmega32_dip40_pin22,
d5, atmega32_dip40_pin23,
d6, atmega32_dip40_pin24,
d7, atmega32_dip40_pin25,
...


В простейшем случае каждая пара параметров заменяется одним, в идеале вместо 24-х параметров будет всего 2. Я так с LCD поступаю, там 8/16 бит данных плюс до пяти отдельных бит, не считая размера, типа экрана, ориентации и таймингов, причем это для софтового режима, а в аппаратном вместо кучи пинов передается нужный банк FMSC/FMC:

Код:

using lcd1 = LcdFmc<SSD1298, 320, 240, 16, LcdRot::Auto, FmcBank1, PinG<8>, 9, 9, 1, 16, 1, 1>;
using lcd2 = LcdSoft<S6D1121, 320, 240, 8, LcdRot::Tablet, PinF<1>, GpioG<0xFF>, PinF<7>, PinF<0>, PinG<9>, PinE<2>, 2, 14>;


Два одновременно работающих экрана использующих один базовый класс, один потребляет 7*2, второй 6*2 байт ОЗУ и то просто потому, что они запоминают текущее окно и позицию, а первый еще и ориентацию.

[mazda]

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

а вообще creatpad это не класс и не структра, это функция


a0 a1 и тд это не параметры вообще

[Reflector]

mazda писал(а):

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

Допустим нужно передать 8 данных, которые разбросаны по разным пинам и портам, тогда создаешь виртуальный порт:

Код:

using data = PinsList<PinA<0>, PinA<1>, PinB<5>, PinB<6>, PinB<7>, PinA<3>, PinA<4>, PinA<5>>;


Теперь его можно передать одним параметров в другой шаблон, а внутри просто написать data::write(...). Если этот виртуальный порт достаточно умен, то он обойдется одной записью в PA и одной в PB.

а вообще creatpad это не класс и не структра, это функция

Если это функция, значит a1 и т.д. - переменные потребляющие ОЗУ. Простой шаблонный пин ничего не потребляет и его передача в другой шаблон ничего не стоит.

a0 a1 и тд это не параметры вообще

Тогда для чего они там? Если макрос их игнорит и фактически они там в качестве комментариев, то можно вместо:

Код:

___B8B( bus,
a0, atmega32_dip40_pin26,
a1, atmega32_dip40_pin27,


эти комментарии и добавить:

Код:

___B8B( bus,
atmega32_dip40_pin26,  //a0
atmega32_dip40_pin27,  //a1


Или я что-то не так понял?