мое недолгое знакомство с исходниками "библиотек" ардуины заставляет меня сильно сомневаться в том, что с ними стоит связываться. не раз встречал там использование динамически выделяемых строк для абсолютно простейших сравнений, применение float повсеместно в вычислениях и т.п. использование ООП иногда вырождается в классику - вызов трех-четырех вложенных (наследуемых) функций только для того, чтобы выяснить, установлен флажок или нет. конечно, компилятор все это "упрощает", но вот пониманию это не способствует.
большинство проектов представляет собой типичный макаронный код.
зачем во все это лезть?! разве для вас проблема разобраться с алгоритмом циклического буфера и написать свой вариант "драйвера" USART? разве для вас проблема настроить порт на вход или выход и опросить его пин? или в чем проблема, чтобы копаться в этой большой "наработанной" куче?
если применять ардуину, как платку с компонентами, то все эти "поддержки" в виде форумов, сайтов, библиотек, IDE и т.п., имхо, только мешают.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Вот потому и стоит вопрос о методиках создания как собственных "внешних файлов" или как библиотек или как простого выноса текстовых фрагментов за пределы основного файла. И "в рамках референс-минимума", а не в деталировке для конкретно применяемых компиляторов. Т.е. уровень "среднедостаточного пользователя". Хотя бы в виде понятных шаблонов. Ибо там таки "смесь" С++ и GCC (да и чего иного понатыкано - не только ведь AVRки используются). А прямое управление "по максимуму" я и под ассемблером соорудить в состоянии. Только для чего? Значительно легче комбинированный проект создать из МК с прожками под ассемблером и базовым обработчиком в виде адуринки или среднесложные проекты на нанке/про-мини или синетаблетке. А чего посложнее мега2560 и по жирнее. Надо б систематизировать дополнения к базовому референсу относительно наноподобных микросборок - это достаточно "ходовые" модули. Хотя в то же время те дополнения касаются только модулей на основе мега328.... Да на втором плане "взаимовключение файлов" - но то не ранее разбора с уже "укушенным". Так что пока больше тренировки и заметки по работе с "правилами правописания" да просмотр вариантов изменения алгоритмов ассемблер/ардуино IDE/Cи.
Значительно легче комбинированный проект создать из МК с прожками под ассемблером и базовым обработчиком в виде адуринки или среднесложные проекты на нанке/про-мини или синетаблетке. А чего посложнее мега2560 и по жирнее.
проблема только в том, что не существует общего интерфейса ардуинки с ассемблером, и то, что вы задумываете, ставит крест на платформонезависимости, поскольку ассемблер платформозависим по определению. и заниматься скрещиванием ужа и ежа, имхо, пустая трата времени. я уверен, что ни вы сами не сделаете для себя ничего путнего, ни кто-то еще не воспользуется плодами ваших трудов.
но переубеждать я вас не намерен, продолжайте бег про граблям. я вполне могу удовлетвориться наблюдением со стороны, как я в очередной раз окажусь прав
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
проблема только в том, что не существует общего интерфейса ардуинки с ассемблером, и то, что вы задумываете, ставит крест на платформонезависимости, поскольку ассемблер платформозависим по определению. и заниматься скрещиванием ужа и ежа
Вот те и ... Как это не существует? Внешнее устройство исполняется как отдельная конструкция с МК, для которого программа написана под ассемблером, и обеспечивает обмен данными посредством любого из стандартных физических интерфейсов - SPI, I2C, rs232, да хоть мой побитовой синхронизации (что в программаторе для АТ89С2051/4051)... Блок адурины все это обрабатывать умеет - а как уж взаимодействие на программном уровне обмена/интерпритации данных обозвать/замутить - то широкое поле самодеятельности. Кстати на том макете (https://radiokot.ru/forum/viewtopic.php ... 1#p3472041) как раз УЖА С ЕЖОМ скрестить весьма неплохо получилось (ПК с терминалкой и командным интерфейсом, ядро на АТ89S52 и исполнительный блок на attiny2313).
МУРИК - там речь идет о том, что в IDE применяется много разного содержимого
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Мурик Я уже просил одного из участников "водолейства" просмотреть и прокомментировать мои заметки о способах выноса файлов. Ответ был отрицательный. ...и потекла снова вода размышлений о целесообразности работ с различными МК... Вы же снова вместо конкретики подключились к водолейству, оставив "вне внимания" сам вопрос с которого и начато было водолейство. Могу повторится - если в состоянии - проверьте то, что тут указано было насчет вариантов подключения внешних файлов в проекте для адуринок: https://radiokot.ru/forum/viewtopic.php ... 1#p3673681 возможно с точки зрения специалиста там чего-то иначе выполнить можно или какой вариант добавить.
А зачем - может таки лучше докопать адуринью до необходимого минимума с точки зрения разумно-практического применения? В "чистом Си" и так народу хватает. А в отношении адуринки или супернавороты или суперпримитив. Как раз серединка и ПУСТА. Есть запас времени на отработку и разделгде пока народу не так уж и много. При том, что практическое применение данного вида элементной базы весьма интенсивно расширяется. Лучше уж не водолейством заниматься а конкретикой диапазона возможного применения/освоения.
Не стоит преувеличивать, но и недооценка также весьма вредное дело. Кстати... весьма полезно самому просматривать различие в конструкциях алгоритмов "чистого ассемблера" и того, что для адуриньи прилагается (в общем-то Сишные конструкции). Результат обоюдно полезен. Речь именно о "чистом асме", а не об ассемблерных вставках интегрированного в СИ компилятора - там совершенно разные приемы для построения программ применяются. Upgrader я пока что синю таблетку и WeMos D1R1 присолил до окончания изучения вопроса по правописанию многофайловиков (вынос отдельных фрагментов и взаимовключенные фрагменты текста программы). Было б там "стандартное GCC", или чего поконкретнее в описании - легче было бы. А так судя по простому одноуровневому вынесению, что выше выложено было, - и как Си и как Си++ проходит. Для других МК там еще и джава с питоном где-то "в засаде" поджидают. Вобщем есть за что "подергать" да по книжам полазить.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 27
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
Ммммяяяяууууууууу!
И будет свой блекджек со шл#хами.
