Научите мастерству на примере кода

[Ariadna-on-Line]

Вот мой код. Компилируется. Работает в Протеусе. Покажите методы (трюки) написания кода, компилирующегося более компактно, при сохранении функциональности. Хочу усвоить немного виртуозности в программировании. Буду благодарен за работоспособный код. С уважением.
ПС. Платформа - ATtinyCore / Плата ATtiny45/85 (Optiboot).

Вложения

Компил.png

(131.02 KiB) Скачиваний: 80

ATtiny85_OLED_MAX6675.rar

(14.38 KiB) Скачиваний: 67

Термостат.jpg

(163.47 KiB) Скачиваний: 83

[Eddy_Em]

Ардуина и мастерство - совершенно несовместимые вещи. Кстати, у аврок очень убогая периферия, а цена - огого!
Попробуйте современные 32-битные армы. На них намного веселей. Главное - по-человечески, без этих калокубов…
Я недавно на STM32F103C6T6 прикупил на алике полтора десятка девборд по ~90р за штучку. Еще чипов набрал (они около 60р были) + на работе, пока есть возможность, заказал F072 и F303, чтобы было. А то поломается в очередной раз что-нибудь на БТА, и быстро починить не выйдет. А так - все под рукой, можно для начала и наколенный вариант на макетке воткнуть, а там уж и плату вменяемую разработать.
Еще у китайцев есть аналоги STM32: всякие GD32, CS32 и прочие. Нувотоны тоже что-то на армах делают. Но там похуже с разработкой (нувотоны, ЕМНИП, вообще до сих пор невозможно прошить в линуксе, поэтому я их и забросил в дальний ящик).

[Martian]

Я бы кучу вызовов sendCommand обернул в цикл и подсунул массив команд - это не только бы удобнее читалось, но и константы можно было бы выпихнуть легко из оперативки.
Циклы сравнивал бы с 0.
Количество функций оптимизировать, иногда менее затратно два раза написать пару строк в одинаково, чем обернуть это в функцию и потратиться на вызов.

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

[Ariadna-on-Line]

Требуется просто пример виртуозного кода. Со всем остальным согласен.
ПС. На днях спросил цену АТтини85 в Дип-8 корпусе. Сказали - 500р. Понял - действительно, с АВРками пора завязывать.

[Martian]

на мой взгляд, виртуозный алгоритм важнее, а его кодирование само станет виртуозным.

что-то дорого для тиньки, это что за магазин?

[Eddy_Em]

На 88-й тиньке стоит стольник.

[Martian]

https://elrus.ru/search/?s-type=name&q= ... 1%82%D1%8C
https://ellipse.com.ru/index.php?route= ... _id=329948

[electroget]

Ariadna-on-Line писал(а):

Понял - действительно, с АВРками пора завязывать.

И что взамен?

[MLX90640]

Ха, нынче с любыми МК туго будет, хоть с AVR, хоть STM. На Али ищите, там дешевше.
А виртуозность и, скорее, компактность и скорость кода начиается с отказа от ардуинских DigitalWrite и DigitalRead, от программной эмуляции аппаратных интерфейсов.
Во-вторых, как бы банально это не звучало, но следует разобраться с работой этого вот дисплея на SSD1306.
В двух словах тут не расскажешь, как бы вот...

[Ariadna-on-Line]

Martian писал(а):

на мой взгляд, виртуозный алгоритм важнее...

что-то дорого для тиньки, это что за магазин?

Виртуозный алгоритм - придумывается. А вот пример виртуозного использования языка программирования для компактности кода - более интересная тема в данном случае. Про магазин нет смысла говорить - он не в Москве/СПб и тд.

[MLX90640]

Ну тогда изучайте язык программирования, чеж. Ардуинщики от С++ берут не более чем int Foo(); Gro::Foo(); bool и... и всё, пожалуй. Хотя, я так скажу, если алгоритм хреновый, то никакими виртуозными вые#$%ами на С++ не исправишь общей хреновости. Именно в хреновых алгоритмах там проблема, а не в неиспользовании плюшек языка.
Начните хотябы с того, что замените все "магические цифры" команд и регистров на текстовые осмысленные дефайны. Это первый шаг к читаемости кода. То есть, не 0х81, a SET_CONTRAST, ну и так далее.

Затем, Wire.begin(); //initialize I2C - что это такое и что оное выполняет в начале каждой отправки команды? Почему бы это не перенести вовне, перед началом всей связи с дисплеем? Интерфейс I2C конфигурируется один раз, и как правило он имеет одну и ту же скорость для всех подключенных на шину устройств.
А что такое SSD1306_Mini::displayX() ? Что оное делает и почему цикл до ((128*64/8)/16) То есть, не ясно, почему только 1/16 часть полного кадра? И зачем каждый раз начинать заново обмен для каждого байта, если данные изображения можно загрузить за один раз, передав единожды адрес дисплея и байт управления, а дальше уже полностью отправлять байты для всего кадра. А почему вложенный цикл на 16 посылок, да еще с каким-то параметром off ? Попытались таким образом отрисовать картинку чтоль? Но это делается не в момент отправки в дисплей, а заранее. В дисплей отправляется по-быстренькому уже подготовленный заранее буфер с полностью сформированными графическими данными.
А отрисовкой занимаются другие функции. В основном на основе попиксельной отрисовки. То есть, пишется функция типа SetDot(x, y, color), и в ней уже преобразуются прямоугольные XY-координаты в плоскости дисплея в постраничный формат байтов, понимаемых дисплеем. А SetDot() вызывается из графических функций построения, например, из DrawLine(x0, y0, x1, y1) и попиксельно закрашивается в определенных координатах.

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

[Мурик]

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

Библиотеки ардуины не оптимальные и только отказавшись от них полностью можно получить какой-то результат.

[veso74]

Мурик писал(а):

Библиотеки ардуины не оптимальные и только отказавшись от них полностью можно получить какой-то результат.

Хватит этих клише. В библиотеки только полон макросов, которые уже находятся "под одной крышей" для многих типов плат. Сделали то, что новичку делать не положено. Чтобы не занимать свой ум непонятными словами. Столь близкими английскому языку.

Но! учимся писать один тип микроконтроллера, пишем для всех: и ATmega, и ATtiny, и новые ATtiny, и STM32, и ESP32, и ESP8266, и Teensy, и RP2040, даже и даже некоторые PICs. Все операторы одинаковые, знаете операнд для одного микроконтроллера, используете командную строку для всех (понимаем, что "под его" делает что-то другое для конкретного типа). Нет "ползания" по пдф-ам и для регистрам с заглавными буквами до бесконечности . А занимаетесь только логикой будущего устройства. Тема "плюсов" (и "минусов") бесконечна.

Последний раз редактировалось veso74 Сб сен 10, 2022 20:55:11, всего редактировалось 4 раз(а).

[Martian]

двумя дефайнами Set и Clear и не нужно ни сравнение, ни вызов функции, которая и результата-то даже не возвращает, а ещё и от типов зависит

[MLX90640]

veso74 писал(а):

учимся писать один тип микроконтроллера, пишем для всех: и ATmega, и ATtiny, и новые ATtiny, и STM32, и ESP32, и ESP8266, и Teensy, и RP2040, даже и даже некоторые PICs. Все операторы одинаковые, знаете операнд для одного микроконтроллера, используете командную строку для всех]

Да ну, это не самый лучший выбор. Нельзя одинаково хорошо написать для столь разных микроконтроллеров как ATtiny и STM32, поскольку у них совершенно разные аппаратные возможности. Взять даже тот же I2C. В STM32 (кроме F1/F3) этот интерфейс может работать практически полностью автоматически, не требуя ручного отслеживания старт- и стоп-состояний, с автоматической передачей адреса ведомого. И посему, используя одну и ту же функцию для разных микроконтроллеров, получаем недоиспользование возможностей навороченных МК.
Работа эмбеддера, как программиста микроконтроллеров, в корне отличается от работы обычного программиста компьютерных приложений как раз тем, что эмбеддер обязан знать "железо" микроконтроллера и использовать его возможности. Как раз не нужно отгораживаться от этого, а наоборот, вникать в особенности работы железа и использовать их для создания как раз этого самого ""виртуозного" кода.
А тот же ESP8266 - так это ж вообще совершенно иная вещь, практически без документации, с внешней памятью программ, да еще и с радиомодулем на борту. Ну и как вот управляться с радиомодулем прикажете, если в ATtiny его вообще нету.
Ну а взять если более сложные "материи", такие как встроенный в STM32 контроллер TFT-панелей, или встроенный контроллер SDRAM-памяти. И ведь даже классический двустрочный знакосинтезирующий дисплей WH1602 на STM32 может работать через выделенный контроллер FSMC для интерфейса 8080 или 6800. То есть, никаких DigitalWrite вообще не нужно, все сигналы управления и передачи формируются совершенно автоматически, нужно лишь просто записать байт в указанный адрес из общего адресного пространства, и все сигналы сформируются автоматически встроенным модулем FSMC. То есть, то, что на ATtiny требовало огромную кучу действий, на STM32 укладывается в несколько инструкций.

Последний раз редактировалось MLX90640 Сб сен 10, 2022 21:10:14, всего редактировалось 1 раз.

[veso74]

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

Проблемы начинаются тогда, когда такой начин написания кода начинает вытеснять серьезные устройства, с логикой, которая должна работать по-другому. Идите и объясните такому специалисту, что такие устройства там работать не должны . Он не поймет и скажет: устройство делает ту же работу, как Вашего серьезно написанный девайс с серьезным кодом и серьезным железом / и по другой цене.

Последний раз редактировалось veso74 Сб сен 10, 2022 21:13:20, всего редактировалось 1 раз.

[Eddy_Em]

veso74 писал(а):

приятно видеть мальчика 4-го класса, который сделал сложную программу на напр. Arduino и хвастается перед друзьями

Я таких толпы видел. Мягко говоря, дауны. Скачал этот даун из интернета непонятный ему код, слепил абы-как, и, внезапно, оно у него заработало. Он вообще понятия не имеет, как его МК устроен, что там в коде — зато светодиодики сияют. И ладно бы этот мудак остался в районе своего курятника со своим абдуринством. Но нет же, потом они лезут в "электронщики" и начинают уже на более высоком уровне калокубить!

Под каждое конкретное семейство МК нужно писать конкретный код. И любая универсализация закончится плачевно. Фигачить софтовый UART на камне, где есть 4 аппаратных (да еще и умеющих по DMA работать). А флоаты совать туда, где они не нужны, да еще и на камнях, не умеющих флоаты? А особенно весело смотреть, как абдуринщик, накачавший кучу "скетчей", у которых есть взаимные аппаратные пересечения, удивляется: а чего это у меня ни хрена не работает??? Да блин, даже элементарный 1-wire у них через такую жопу сделан, что просто хочется застрелить мороженой курицей автора сего "творения"!

Последний раз редактировалось Eddy_Em Сб сен 10, 2022 21:15:09, всего редактировалось 1 раз.

[veso74]

Извините: они только 4-го класса. Не судите так строго. Есть время, они научится / если захочет. Лучше спорить о программном коде, чем идти по другим "склонам" жизни.

Последний раз редактировалось veso74 Сб сен 10, 2022 21:17:29, всего редактировалось 1 раз.

[Eddy_Em]

Да хоть первого! Нельзя без знаний лезть туда, где эти знания остро необходимы. Вы ему в первом классе еще линукс покажите и научите админить. Угу... Без элементарного знания английского ничего не выйдет. Я уж молчу о базовой подготовке: минимум года 3-4 нужно читать разнообразную литературу, прежде, чем что-то начнет получаться в элементарном пользовании компьютером. А для программирования страдать придется еще дольше.

[MLX90640]

Мальчик из 4-го класса делает так, как ему позволяет его детский ум, и это совершенно естественно в его возрасте. Он и не создаст ничего сверхсложного, не будет использовать алгоритмы аналитической математики, фильтры Калмана и преобразование Фурье, не будет управлять BLDC-мотором через FoC, и даже навряд ли будет самостоятельно писать парсинг сообщений от того же SIM800. Ему достаточно простецких и уже написанных функций, а то и вообще даже визуального языка программирования по типу FlowCode.

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