Котуинко

[Upgrader]

[uquote="Мурик",url="/forum/viewtopic.php?p=3697139#p3697139"]Вместо оптимизации алгоритма и кода, они ставят побольше ардуин... [/uquote]Нынче есть такая вещь как экономическая целесообразность.
Учитывая цену китайских ардуин, их можно лепить столько на сколько хватит фантазии.

[BOB51]

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

Касательно Мурика...
По сути ранее выложенного многофайловика в отношении комментария/замечания по его составлению/оформлению я лишь одно видел -
"некорректное использование лаподрыга при работе с МК" -
т.е. наш уважаемый ГУРУ Мурик считает применение лаподрыга при работе с микроконтроллерами ЕРЕСЬЮ.

Но ведь собственно МК на этом и основан - на прикладных операциях с выводами...
Другое дело, что на сегодня от самого ядра МК в его (МК) составе осталась самая малость - производители постарались понапихать в добавок к ядру кучу вспомогательных аппаратных модулей.
Дело в принципе неплохое.
Но, чтобы качественно те модули использовать необходимо детальное ознакомление с ПОЛНОЙ ДОКУМЕНТАЦИЕЙ (включая текущие ерраты).
Надежда на поставляемые производителем "заплатки" для различных компиляторов не всегда оправдана.
А сам процесс управления аппаратными модулями - в основе тот же "ПРИМИТИВНЫЙ ЛАПОДРЫГ" только на внутренней схемотехнике РСФ.
В то же время использование DIP микросборки требует и соответствующий подход в рамках микросборка-референс он же (референс) рассматривается как "система команд" для предоставленных разработчиком той микросборки ресурсов.
Тогда автора конструкции, использующей данный вид элементной базы НЕ ИНТЕРЕСУЕТ СОДЕРЖИМОЕ МИКРОСБОРКИ и основное внимание можно уделить самому проекту.
Ессно при таком подходе знание нюансов и возможностей самой IDE и базового функционала референса выходит на главное место.

В то же время имеется и второй подход -
использование DIP-микросборки с упором на работу с установленным на ней КОНКРЕТНЫМ КРИСТАЛЛОМ.
Но такой метод ничем не отличается от работы с "голым МК" - то же доскональное изучение полной документации плюс дополнительная проработка схемотехники конкретной микросборки. Преимущества там только в отсутствии расходов по монтажу мелких деталек.

Как варианты - промежуточное между первым и вторым подходом.
Причем ВСЕ варианты имеют право на применение.

Единственно чего для адуриньи ПОКА не хватает - это хорошо проработанного описания работы для самостоятельного написанием исходников средней сложности (в том числе и "многофайловиков").
При том, что элементам языка Си у популяризаторов ардуино-IDE уделено уже достаточно внимания (даже сверхдостаточно).
У меня сложилось впечатление что сегодняшние публикации по адуринье направлены на создание исключительно рынка "потребителей-школяриков", а методики реальной работы с имеющейся IDE искусственно умалчиваются/подавляются...
В том числе и при помощи "пассивного сопротивления" в рядах наших радиолюбительских ГУРУ.
Кому охота "конкурентов плодить"? Тем более с учетом С++ и разнообразия применяемых в тех DIP микросбороках МК...

[ARV]

у Мурик-а маниакальная страсть найти оправдание существующей в МК периферии, как будто цель применения МК не решение прикладных задач, а решение этих задач исключительно встроенными аппаратными средствами. этим страдают все, кто гонится за новомодными "решениями" - в соседней теме товарищ хвалится, как он сумел выкроить 3 или 4 ассемблерных команды в микроконтроллере, у которого что RAM, что FLASH имеет такой объем, что эта экономия равносильна добавлению пипеткой пары капель в Атлантический океан, а быстродействие этого МК такое, что ускорение за счет пары ассемблерных команд будет и того незаметнее. при этом признать, что это стрельба из пушки по воробьям нельзя - сразу упадет имидж продвинутого "разработчика"

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

[oleg110592]

[uquote="BOB51",url="/forum/viewtopic.php?p=3697789#p3697789"]Единственно чего для адуриньи ПОКА не хватает - это хорошо проработанного описания работы для самостоятельного написанием исходников средней сложности[/uquote]
тут, имхо, вполне достаточно "описания":
https://alexgyver.ru/lessons/
плюс живые примеры с исходниками на этом же сайте.
з.ы. ссылка на этот сайт вроде уже была в теме, правда в обсуждении ардуиньего IDE:
Почему Arduino IDE – говно?
https://alexgyver.ru/platformio-%d0%b7% ... duino-ide/

[VladislavS]

[uquote="ARV",url="/forum/viewtopic.php?p=3697795#p3697795"]у Мурик-а маниакальная страсть найти оправдание существующей в МК периферии, как будто цель применения МК не решение прикладных задач, а решение этих задач исключительно встроенными аппаратными средствами.[/uquote]Ну это до тех пор пока ты ничего серьёзнее елёочной свистоперделки не делал. А когда ты, к примеру, формирователь стробов для АФАР делаешь, то можно FPGA cо всеми вытекающими поставить, а можно аппаратный таймер микроконтроллера задействовать. Потому что даже если ты успеешь отдрыгаться ногами, то получишь такой джеттер и ложные цели, что изделие можно будет выкинуть. То же самое с какими-нибудь графическими дисплеями, без DMA всё ляжет или будет рассинхронизировано. А USB, Ethernet и т.д. ты тоже без аппаратных модулей сделаешь? А ведь сейчас даже ёлочными свистоперделками модно с мобильника управлять.

[uquote="ARV",url="/forum/viewtopic.php?p=3697795#p3697795"]этим страдают все, кто гонится за новомодными "решениями" - в соседней теме товарищ хвалится, как он сумел выкроить 3 или 4 ассемблерных команды в микроконтроллере, у которого что RAM, что FLASH имеет такой объем, что эта экономия равносильна добавлению пипеткой пары капель в Атлантический океан, а быстродействие этого МК такое, что ускорение за счет пары ассемблерных команд будет и того незаметнее.[/uquote]Подход "и так сойдёт" выдаёт в тебе любителя, что впрочем ты и не скрываешь. Большинство не задумывается об этих нескольких ассемблерных командах просто из-за плохого владения аппаратными средствами. Но если я знаю как одно и то же действие сделать оптимально и неоптимально, почему я должен выбирать второе?

[uquote="ARV",url="/forum/viewtopic.php?p=3697795#p3697795"]при этом признать, что это стрельба из пушки по воробьям нельзя - сразу упадет имидж продвинутого "разработчика"[/uquote]Это код библиотеки. Он пишется один раз. Его надо написать наилучшим способом. Он потом будет применяться в десятках проектах и качество этой библиотеки автоматом переносится и в эти проекты. Может в каком-то проекте это и не надо будет, а в другом будет на тоненького проходить. Применяя оптимизированную библиотеку я буду знать, что там сделано всё возможное и не буду лезть в неё раз от раза.

[uquote="ARV",url="/forum/viewtopic.php?p=3697795#p3697795"]на самом деле в любительских проектах важен единственный фактор - преодоление самого себя. для кого-то переход от задержек в цикле к задержкам по таймеру является Эверестом, для кого-то наоборот. и никакие байты или микросекунды принципиально ничего не решают, как и оптимальность. я пользуюсь ногодрыжной библиотечкой I2C уже больше 10 лет, не смотря на то, что аппаратная поддержка этого интерфейса встроена в 90% микроконтроллеров из моего обихода - и ни разу еще не испытал дискомфорта. и чо? я считаю, что мой подход много лучше "аппаратного", ибо позволяет один и тот же код верхнего уровня применять на любой аппаратной платформе - хоть даже ARM, при этом изменения кода будут только в макросе установки уровня на пине и макросе считывания уровня с пина. по-моему, переносимость кода стоит больше, чем выигрыш пары микросекунд при общении с внешней периферией.[/uquote]Переносимость достигается не ногодрыгом, а прописыванием чёткого интерфейса взаимодействия между модулями. Даже интерфейс к ногодрыгу может быть универсальным и аппаратнонезависимым. Ну вот возьмём твой I2C. Что мешает определить базовые функции чтения/записи в него и в модулях всяких I2C-устройств пользоваться ими? Класс какой-либо памяти или датчика не должен ничего знать о том как в микроконтроллере реализован I2C. Да хоть и ногодрыгом, если в чипе нет аппаратного или нет возможность подключить его к нужным ногам. Пока ты несколько лет самолюбуешься какую красивую ёлочную гирлянду сделал, через меня проходят десятки проектов, с самой разнообразной периферией. В процессе их реализации нарабатываются программные модули, которые я потом могу быстро использовать в других проектах. Сейчас темп разработки такой, что неделя на прошивку это считай вечность. Обычно срок стоит "вчера".

Чтобы не быть голословным, покажу пример такого аппаратнонезависимого программного модуля. Микросхемы EEPROM сериии 24Cxx все разом, раз уж ты заговорил про I2C. При специализации этого шаблона ему указываются классы TI2C и TDelay. Абсолютно неважно как они реализованы, аппаратно, таймерами, ногодрыгами или циклами ожидания. Он будет работать на любой аппаратной платформе совершенно одинаково. Да, я изначально потрачу чуть больше времени на написание класса TI2C, чем среднестатистический коекакер. Но это окупится когда я хотя бы пару раз применю его на других I2C-микросхемах даже не заглядывая внутрь. Вот она и скорость разработки и переносимость!

EEPROM_AT24C.h

(5.88 КБ) 177 скачиваний

PS: У меня даже лозунг родился в процессе написания этого поста. "Я думаю о каждой ассемблерной команде там где это нужно, чтобы потом не думать об этом там где не нужно".

[ARV]

к примеру, формирователь стробов для АФАР делаешь

вот помню давеча лепил на даче как раз такой модуль стробов и как раз для дачной АФАР - ну, сами понимаете, без АФАР на даче сущая беда! тут на форуме каждые 99 из 100 этим озабочены, а вообще в интернете - их миллиарды!

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

я так понимаю, написать 100500 строк кода - это и есть оптимальность с вашей точки зрения? а с моей - чем меньше энергии затрачено, тем лучше. энергосбережение, блин - модный, кстати, тренд а остальным пусть МК занимается - он уже энергосберегающий, опять-таки, в модном тренде

Это код библиотеки. Он пишется один раз. Его надо написать наилучшим способом.

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

Обычно срок стоит "вчера"

это да. вот, к слову, жена меня так и пилит: когда АФАР сделаешь, когда АФАР сделаешь? сделал вот давеча - снова пилит: когда джиттер до наносекундного интервала доведешь, когда джиттер доведешь? все ей вынь да положь "вчера"

А ведь сейчас даже ёлочными свистоперделками модно с мобильника управлять.

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

Вот она и скорость разработки и переносимость!

это все ровно до момента, когда встретится неподдерживаемый этой библиотекой чип - и тогда придется делать все то же самое, что и раньше. т.е. ничего не поменяется. но времени на эту сверхуниверсальную (на самом деле нет) либу вы потратили столько, что я успел бы спиться, если бы все это время в сутки по 1 бутылке пива выпивал бы. особенно если учесть, что для её написания надо освоить (и следить за обновлениями) С++... и ради чего?

ради того, чтобы на форуме любителей блеснуть гениальностью? сами же говорили, что на другом форуме вашу либу охарактеризовали весьма своеобразно (лень искать, чтобы вас процитировать).

[VladislavS]

[uquote="ARV",url="/forum/viewtopic.php?p=3697850#p3697850"]я так понимаю, написать 100500 строк кода - это и есть оптимальность с вашей точки зрения?[/uquote]Если в результате получается более оптимальный код, чем от одной строки, то да. Это же библиотека, она пишется один раз.

[uquote="ARV",url="/forum/viewtopic.php?p=3697850#p3697850"]а с моей - чем меньше энергии затрачено, тем лучше. энергосбережение, блин - модный, кстати, тренд а остальным пусть МК занимается - он уже энергосберегающий, опять-таки, в модном тренде [/uquote]Вот видишь, ты сам говоришь "пусть МК занимается". А у меня другой подход. Лишней работой занимается компилятор один раз. А МК потом экономит энергию постоянно.

[uquote="ARV",url="/forum/viewtopic.php?p=3697850#p3697850"]почему-то СТАНДАРТ С++ обновляется чаще, чем успевают все ознакомиться с ним,[/uquote]Причём тут С++? Это всего лишь инструмент. Мощный инструмент. Профессиональный инструмент. Что он быстро обновляется - иллюзия. На самом деле приходится годами ждать новых востребованных функций. Не успевает ознакомиться тот кто и не пытается этого сделать. И вообще, я ни слова о выборе языка программирования не говорил. Выбор ногодрыгать или нет, писать оптимальный код или кое-как не зависит от языка. При том что последние возможности С++17 очень сильно помогают нам эмбеддерам эффективно работать. А будет ещё лучше.

[uquote="ARV",url="/forum/viewtopic.php?p=3697850#p3697850"]а еще модно мужикам в юбках и на шпильках ходить. вы ходите?[/uquote]А даже если и хожу, это как к данной теме относится?

[uquote="ARV",url="/forum/viewtopic.php?p=3697850#p3697850"]это все ровно до момента, когда встретится неподдерживаемый этой библиотекой чип - и тогда придется делать все то же самое, что и раньше.[/uquote]Ну ты опять ничего не понял. Я же тебе только что рассказал про универсальные интерфейсы между модулями. Ну поменяется нижний уровень, напишем новый, всё остальное останется рабочим. Если я по каким-то причинам перехожу на другой чип, то по любому приходится писать под него новый код. Но если я перепишу модуль I2C, то всё что работает поверх него автоматом заработает. Это любитель может позволить себе сидеть всю жизнь на одном чипе, а нам приходится программировать всё что умеет выполнять код.

[uquote="ARV",url="/forum/viewtopic.php?p=3697850#p3697850"]т.е. ничего не поменяется. но времени на эту сверхуниверсальную (на самом деле нет) либу вы потратили столько, что я успел бы спиться, если бы все это время в сутки по 1 бутылке пива выпивал бы. особенно если учесть, что для её написания надо освоить (и следить за обновлениями) С++... и ради чего?[/uquote]Ты не поверишь, но у профессионалов тоже выдаются скучные зимние вечера. И вместо того чтобы бухать, я лучше почитаю "что там новенького" придумали. Тем более что это мой инструмент и им надо владеть в совершенстве.

[uquote="ARV",url="/forum/viewtopic.php?p=3697850#p3697850"]ради того, чтобы на форуме любителей блеснуть гениальностью?[/uquote]Всё с точностью до наоборот. Я выбираю самые простые кусочки кода, чтобы показать идею и не отпугнуть тех кто не очень подготовлен, но желает учиться. Если показывать самый хардкор, то это отпугнёт 99% даже сильных духом.

[uquote="ARV",url="/forum/viewtopic.php?p=3697850#p3697850"]сами же говорили, что на другом форуме вашу либу охарактеризовали весьма своеобразно (лень искать, чтобы вас процитировать).[/uquote]Ну это просто от непонимания. Кто-то на китайском читает, а мне там одни драконы мерещатся, и что?

[BOB51]

[uquote="oleg110592",url="/forum/viewtopic.php?p=3697801#p3697801"][uquote="BOB51",url="/forum/viewtopic.php?p=3697789#p3697789"]Единственно чего для адуриньи ПОКА не хватает - это хорошо проработанного описания работы для самостоятельного написанием исходников средней сложности[/uquote]
тут, имхо, вполне достаточно "описания":
https://alexgyver.ru/lessons...[/uquote]
Это простые примеры "начального уровня".
При разростании проекта возникает необходимость и свои библиотеки создавать и "выкуси" делать.
Вот с этими вопросами и "напряженка"...
Не говоря уже об "залезании во глубины" - то УДЕЛ ПРОФЕССИОНАЛОВ.
Вопрос самостоятельного правописания затруднен еще и по причине гибрида из Си и С++.
В то же время С++ для МК в виде примеров практически отсутствует.
Вроде как часть "начального уровня" усвоилась... Остальное вероятно всплывет по мере работ с практическими проектами,
т.е. "по прециденту".



ОЙ_ОЙ_ОЙ!!!
от той ссыли ...
сайт только открылся и комп с синим экраном перезапустился!!!

убёг антивирем тестить!!!...

[ARV]

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

я понимаю и принимаю данный аргумент, когда применяю attiny13 с 512 словами программы и 64 байтами ОЗУ. я не понимаю и не принимаю этот аргумент, если взят МК, в котором от оптимальности кода судьба проекта практически не зависит.

А у меня другой подход

ну да, главное - чтобы МК было легче, а себя жалеть зачем?

А даже если и хожу, это как к данной теме относится?

просто стало понятно, почему так следите за модой

Ну ты опять ничего не понял.

ладно, раз уж мы перешли на ты, скажу, что ты сам ничего не понял. в моем исходном посыле от "нижнего" уровня остались только макросы дряганья пинами, а все остальное - как раз и было "надстройкой верхнего уровня". ты благополучно прозевал этот момент. фишка в том, что ногами может дрыгать ЛЮБОЙ МК, а аппаратная поддержка есть не у любого, и тем более она не одинакова. по этой причине моя (на самом деле чужая) либа переживет твою, ибо в ней НИЧЕГО, кроме двух (ладно, четырех - еще настройка направления) макросов менять не придется НИКОГДА ДЛЯ ЛЮБОГО МК, которые будут выпущены в ближайшие 1000 лет. и чем тогда твоя либа лучше? тем, что вместо двух (ладно - четырех!) макросов тебе надо править 100500 шаблонов и т.п. классов?!

Всё с точностью до наоборот.

ты предлагаешь освоить профессиональный инструмент, чтобы потом кодить любительские поделки? уволь - я в своё время отказался от изучения С++ только за одно то, что это кошмар нерожденного. кстати, Java по той же причине меня не привлекла. паскаль ругают за многословность - но та многословность, что требует С++/Java и рядом не стояла с паскалевской! хаос из кнтекстно-зависимого нагромождения символов - это не любительский подход.

кстати, почему "наоборот"? ты же все равно несешь свой код, чтобы сверкнуть им даже если он с твоей точки зрения крайне примитивный. так что тут все правильно было сказано

Ну это просто от непонимания.

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

[oleg110592]

[uquote="BOB51",url="/forum/viewtopic.php?p=3697882#p3697882"]Это простые примеры "начального уровня".[/uquote]
там есть например "Уроки>Продвинутые уроки>Arduino>Пишем свою библиотеку"
[uquote="BOB51",url="/forum/viewtopic.php?p=3697882#p3697882"]ОЙ_ОЙ_ОЙ!!! от той ссыли ...[/uquote]
проверил Chromium Firefox крайние версии версии с расширением uBlock Origin - нормально открывает

[BOB51]

Снова споры о "курицей и яйце"...

Может таки лучше от крайностей идти на компромиссную
всеядность среднего уровня с гурманством в более освоенной
каждым сфере?
Да пользоваться взаимодополнением тем собратьев
ко всеобщему удовольствию?
Сожрать и курку и яечко (пока спорят и вокруг не смотрят)



Пы.Сы.
Старые добрые ХР не всегда корректно на новинки от инета реагируют...
Может просто опера старого образца сбойнула...
Вроде вирей не наблюдается....

Но лучше не рисковать...
Воть и пользуемси только тем, что общедоступной и для любого компа
стянуть без приключений можно...


И библиотеки тоже разного типа бывают
а описывается (в тех, что попадались ранее) максимум один/два варианта.
Там же разница в месте инициализации объекта класса и соответственно возможности использования методов и полей объекта при создании " выкуси"/новой собственной библиотеки, которая будет использовать "чужие" методы.
Вот тот вопрос и затыком был.
Пока вроде все прояснилось...
Разве что как приткнуть extern...?
Эта "приставка" используется при создании объекта без явного указания конструктора (вернее без явного определения/описания-стоит в *.срр за описанием методов при инициализации... Затем то имячко и используется.
Но... Как-то не по феншую (Страуструпу)...
И относительно ассемблера extrn несколько иначе заявляется...
Вобчемс... Пока отложил на свободно мозго...

[VladislavS]

[uquote="ARV",url="/forum/viewtopic.php?p=3697884#p3697884"]я понимаю и принимаю данный аргумент, когда применяю attiny13 с 512 словами программы и 64 байтами ОЗУ. я не понимаю и не принимаю этот аргумент, если взят МК, в котором от оптимальности кода судьба проекта практически не зависит.[/uquote]Это ты зацепился за пример где разница в 3-4 ассемблерных команды на одной операции записи в регистр. А на форуме попадаются такие фрагменты кода, которые можно оптимизировать на порядок (да, да в 10 и более раз!!!).

[uquote="ARV",url="/forum/viewtopic.php?p=3697884#p3697884"]ну да, главное - чтобы МК было легче, а себя жалеть зачем? [/uquote]Неправда. Именно о себе я и думаю. Я пишу модуль I2C один раз и больше к нему не возвращаюсь. Зато когда ты видишь I2C в описании микросхемы тебя бросает в пот, а я просто интересуюсь в какой регистр записать/считать данные и делаю это парой строк. Скорость реализации проектов как раз растёт. Это значит что я в итоге трачу на него меньше времени, жалею себя.

[uquote="ARV",url="/forum/viewtopic.php?p=3697884#p3697884"]в моем исходном посыле от "нижнего" уровня остались только макросы дряганья пинами, а все остальное - как раз и было "надстройкой верхнего уровня". ты благополучно прозевал этот момент. фишка в том, что ногами может дрыгать ЛЮБОЙ МК,[/uquote]Ты сколько раз в жизни переходил на другой МК? Если бы всё ограничивалось дрыганьем ногами...

[uquote="ARV",url="/forum/viewtopic.php?p=3697884#p3697884"]и чем тогда твоя либа лучше?[/uquote]Тем что каждый модуль занимается своим делом. Я же показал тот же 24Сxx, которому по барабану где работать. Кто мешает мне подсунуть ему ногодрыжный I2C? Который ты, кстати, всё равно будешь переделывать на другом МК хотя бы из-за времянки.

[uquote="ARV",url="/forum/viewtopic.php?p=3697884#p3697884"]ты предлагаешь освоить профессиональный инструмент, чтобы потом кодить любительские поделки?[/uquote]Нет! Это ты почему-то хочешь мне приписать это желание. Повторяю, я ни слова не писал про выбор языка программирования. Это тебя почему-то как чёрта от ладана корёбят безобидные плюсики.

[uquote="ARV",url="/forum/viewtopic.php?p=3697884#p3697884"]на симпозиуме гуру - место гурских либ, на форуме любителей - не место будь проще, и люди к тебе потянутся.[/uquote]Это ты так решил? На этот форум заглядывают такие супербизоны, что я просто дошколёнком себя чувствую. Да и любитель любителю рознь. Человеку свойственно любопытство и познание нового. Я бы умер, если бы 20 лет занимался только AVR.

[ARV]

А на форуме попадаются такие фрагменты кода, которые можно оптимизировать на порядок (да, да в 10 и более раз!!!)

и что с того? если код размером в 100 байт уменьшить до 10 байт - много ли это принесет пользы при общем количестве этих самых доступных байт в 64000?

Зато когда ты видишь I2C в описании микросхемы тебя бросает в пот

неужели ты писатель, а не читатель? когда я беру в руки новый МК, я даже не читаю про его аппаратный модуль I2C - он не требуется мне для моей либы так что пот мне неведом по определению.

я просто интересуюсь в какой регистр записать/считать данные и делаю это парой строк

я готов спорить, что это требует даже для такого профи, как ты, не менее часа на чтение документации и на выходе будет БОЛЬШЕ пары строк. вот сейчас могу взять твою либу из твоих примеров, открыть её, и там на работу с регистрами модуля I2C будет больше двух строк - я говорю это еще не видев твоего кода. но уверен, что спор не проиграю.

Если бы всё ограничивалось дрыганьем ногами

для меня в случае с I2C только этим все и ограничивается. я так специально всё устроил в своей практике

Я же показал тот же 24Сxx, которому по барабану где работать

в attiny13 тоже заработает?

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

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

Я бы умер, если бы 20 лет занимался только AVR

я бы тоже - но много времени отнимает РАБОТА, поэтому для меня не все так плохо бедные вы профессионалы... может, пожалеете нас, любителей, и не будете заставлять мучиться так же, как и вы? мы ж точно передохнем все... мы ж не такие закаленные, как вы...

[BOB51]

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

[VladislavS]

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

Спойлер

Код: Выделить всё

#pragma once

namespace ADT7410
{

template<typename TI2C, uint32_t num>
class TADT7410
{
  public:
    TADT7410(){}
    static _inline_ bool Read_1gradlsb(int8_t *data)
    { 
      uint8_t tmp[2];
      if( TI2C::ReadReg(hw_adr,(uint8_t)0x00, tmp, (uint8_t)2) )
      {
        *data = Convert2Grad((tmp[0]<<8) + tmp[1]);
        return true;
      }
      else return false;
    }
  private:
    //Преобразовать считанное значение в целые градусы
    static _inline_ int8_t Convert2Grad(uint16_t x)
    {
      if(x&0x8000)
        return ((x>>3)-8192)>>4; //Отрицательная температура
      else
        return x>>7; // Положительная температура
    }
    
    static_assert(num<4,"Only 0...3 ADT7410 numbers");
    static constexpr uint8_t hw_adr = 0x90 + ((num&0x3)<<1);
};

} //namespace ADT7410

И по быстрому их читаем.

Код: Выделить всё

#include "i2c_F0.h"
#include "ADT7410.h"

I2C::TI2C<(uint32_t)I2C1,I2C::I2CTiming::SysCLK_100kHz>::Init();
I2C::TI2C<(uint32_t)I2C2,I2C::I2CTiming::SysCLK_100kHz>::Init();

using T0 = ADT7410::TADT7410<I2C::i2c1,0>;
using T1 = ADT7410::TADT7410<I2C::i2c1,1>;
using T2 = ADT7410::TADT7410<I2C::i2c1,2>;
using T3 = ADT7410::TADT7410<I2C::i2c1,3>;
using T4 = ADT7410::TADT7410<I2C::i2c2,0>;
using T5 = ADT7410::TADT7410<I2C::i2c2,1>;
using T6 = ADT7410::TADT7410<I2C::i2c2,2>;
using T7 = ADT7410::TADT7410<I2C::i2c2,3>;

int8_t T[8];
 
T0::Read_1gradlsb(&T[0]);
T1::Read_1gradlsb(&T[1]);
T2::Read_1gradlsb(&T[2]);
T3::Read_1gradlsb(&T[3]);
T4::Read_1gradlsb(&T[4]);
T5::Read_1gradlsb(&T[5]);
T6::Read_1gradlsb(&T[6]);
T7::Read_1gradlsb(&T[7]);

Всё быстрее, чем я тут на форуме спорю

[ARV]

Всё быстрее, чем я тут на форуме спорю

а все почему? потому что в споре ты лукавишь, как наперсточник а по факту вместо пары строк

простенький класс на один экран кода.

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

кстати, про attiny13 так не ответил...

Добавлено after 4 minutes 48 seconds:

Аппаратные модули обычно оставляю на экстренные нужды.

я вот сколько ни пытался понять, так и не смог: почему USART в работе прост, а I2C - сложен? я как раз про аппаратную реализацию говорю. при том, что реализация без аппаратуры - примитивна до одури. думаю, в продвинутых МК типа ARM сложность аппаратной реализации еще выше...

[VladislavS]

[uquote="ARV",url="/forum/viewtopic.php?p=3697940#p3697940"]а все почему? потому что в споре ты лукавишь, как наперсточник а по факту вместо пары строк

простенький класс на один экран кода.

[/uquote]Тупо считать регистр с температурой из одного датчика заняло бы действительно пару строк. Но я же забочусь о себе, мне потом с этими датчиками работать. Поэтому лучше сразу сделать по фэншую.

[uquote="ARV",url="/forum/viewtopic.php?p=3697940#p3697940"]и класс этот, чтобы понять, надо иметь уровень знания С++ ну хотя бы в половину твоего, что далеко не всем доступно. мне, например, потребуется немало времени, чтобы просто понять, что к чему. а уж чтобы свой вариант "быстренько набросать" - и подавно а я в ООП не первый год...[/uquote]Да там же стандартный каркас - шаблонный класс с пустым конструктором, одним открытым и одним закрытым методом. Это всё от пальцев отлетает когда пишешь. Особенно странно, что ты не первый год и не понимаешь...

[uquote="ARV",url="/forum/viewtopic.php?p=3697940#p3697940"]кстати, про attiny13 так не ответил...[/uquote]А что не так с тинькой? GCC на неё есть. ОЗУ у неё с гулькин нос, но тут все методы static inline, стек считай и не нужен, параметры все на регистрах прокрутятся. Подсунешь ему ногодрыжный I2C и всё взлетит. Вся прелесть этого кода, что там на этапе компиляции выберется только то что нужно и соптимизируется хочешь по размеру, хочешь по скорости.

[ARV]

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

ну опять не лги уж... чтобы аппаратный модуль I2C заработал, тебе пары строк будет мало - если уж на чтение регистра надо две ну и там своя фигня - адрес выставить в одном регистре, что-то задать в другом... короче - весь "низ" будет "на пару экранов кода" и "десяток простеньких классов" я имею ввиду для каждого "нового" типа МК. на верхнем уровне у нас обоих одинаково - просто get_temperature() а снизу - у тебя куча аппаратуры со своими заморочками, а у меня только дрыгоног двух пинов.

А что не так с тинькой?

с тинькой все так - речь о твоей либе на все случаи жизни и на все века она тиньку поддерживает?

[VladislavS]

[uquote="ARV",url="/forum/viewtopic.php?p=3697975#p3697975"]с тинькой все так - речь о твоей либе на все случаи жизни и на все века она тиньку поддерживает?[/uquote]У меня нет никакой "одной либы на все случаи жизни". Зато есть классы, которым благодаря определённому интерфейсу с нижним уровнем по барабану на каком контроллере работать. Пару таких я сегодня показал.

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

[ARV]

Зато есть классы, которым благодаря определённому интерфейсу с нижним уровнем по барабану на каком контроллере работать.

ну что ты доказал? что умеешь делать классами то, что я делаю без оных? только классами получается в 2 раза длиннее и в 4 раза сложнее.

Добавлено after 1 minute:
и в 6 раз непонятнее для большинства