Котуинко

[BOB51]

С ref компилируется то, что прописываем в пределах основного файла проекта *.ino.
Я же поставил более сложную задачу - вытянуть кусок не в меру увеличившегося файла из *.ino в отдельный внешний файл (уход от "плоской линейного" проекта с внешними библиотеками на "более пушистый" с выносным файлом, содержащим обращения как к содержимому основного, так и к содержимому подключенных к основному файлу библиотек.
Результат меня вполне устраивает.
Так что теперь немножко перерывчика, распечатка, вычитка и анализ сделанного и тогда можно уже и практикой на адуринье заняться.
Полученный результат меня весьма радует.



ПЫ,СЫ,
Забыл добавить...
Способы доступа к объектам (и их составляющим) в "выкушенном" фрагменте зависят от того, где при помощи конструктора (а может и без оного) был создан объект.
Ежли в самом файле *.cpp внешней библиотеки - это одна варианта (тогда много легче получается), ежли в основном файле*.ino - это самое тяжкое.
А так в основном инициализируются "лапозависимые" библиотеки - это те, где определение выводов (или задание определенных констант) делает пользователь.
Ибо тогда объект класса путем подключения *.h файла класса в заголовочник "выкуси" в область видимости "выкуся" не попадает (объект создан за пределами библиотеки).
Но... то также подлежит проверке (пока предположение).

Касательно доступа к объектам, созданным в *.ino...
Пока только ссылка удалась. И на том Мурр-мрямсь!

[BOB51]

Классы... ссылки ... объекты....
БЫРРР!!!....
Мозги ШИПЯТ....

Продлолжемс баловство с моногофайловыми проектами.
Библиотеки специально не выделяю в отдельные папки с загрузкой в каталог
C:\Documents and Settings\.........\Мои документы\Arduino\libraries
а оставляю в папке проекта, дабы изменения вносились легче (ранее сброшенное не мешалось).
На сей раз датчик DHT11 и его обработка арсеналом ардуино-референса
(а не то,что предлагается как
C:\Documents and Settings\.......\Мои документы\Arduino\libraries\DHT_sensor_library
- зачем еще чего-то, ежли быстродействие МК и средства референса позволяют это самостоятельно описать?? ).
Пока с возвратом в консоль - вывод на дисплейчик NJU6432 и вариацию для MAX7219 чуток попозже положу, как выберу модель отображения - куда влажность, а куда температуру сунуть и как символами- кракозябрами отметить для семисегментников великий творческий заморочко...

Хотя драйвер для NJU в проекте уже подключен.

my_dht_4.rar

(9.73 KiB) Скачиваний: 194

Схема практически все на тех же "кубиках" - разве что добавилась DHT11.
http://img.radiokot.ru/files/20529/1zfvbsxt9g.GIF


УПС...

Скомпилировалось то... ДА НЕ РАБОТАЕТ В ЖЕЛЕЗЕ...
(Выполняется только однократная фиксация показаний)

А вот этот "предшественник" индикацию в консоли проводит вполне успешно
и стабильно:

my_dht_3.rar

(9.36 KiB) Скачиваний: 175

Бум разбираться - где ошибки застряли...


Ну и .....

Всего-то ошибка в цикле перебора массива:
вместо правильного
for (byte cntp=0; cntp<=4; cntp++)
было НЕПРАВИЛЬНОЕ
for (byte cntp=0; cntp<=5; cntp++)

Итогом имеется прожка с отображением на индикаторе на основе стекла с NJU6432
и отсылкой блока данных в терминалку IDE

my_dht_5.rar

(10.08 KiB) Скачиваний: 187

Эта на макетке весьма неплохо работает!

[BOB51]

ОСЕННИЕ ЦИПЫ
Итог предварительных разборок с АДУРИНЬЕЙ...
Имеем "приплюснутую надстройку", причем вполне дееспособно-работоспособную.
А вот инструкции по её использованию/применению... И... НЕТУ...

В наиболее ближнем прложении можно рассматривать вот этот учебник
https://yadi.sk/i/JFTyZ_cMAsZvlA
(как всегда полежит пару неделек - до 14-го сентябру, затем удалю)
данну книжу исходя из интереса надо бы в СУНДУК определить...

По крайней мере при освоении классов С++ я ее в качестве опорного материала использую.
Одначе там несколько замечаний:
1. в радиолюбительстве принято ставить сначала глобальные объявления (public),
затем локальные (private).
в книже указано, что первыми (или по умолчанию) идут локальные (private) с последующим объявлением глобальных (public).
2. Практически все варианты касаются объявления, описания и создания в пределах основного *.ccp файла,
а в случае с адуринкой меня больше интересует вынос класса во внешний файл (библиотеку) и последующие взаимосвязи основного текста с внешними библиотеками. Это уже дополнительные читки примеров из литературы по адуринье и собственные тесты...
Вобчемс...
arduinoIDE как С++ для МК
кушать можно...
И отнюдь не в виде "примитив-школярства"!

[oleg110592]

BOB51 писал(а):

По крайней мере при освоении классов С++ я ее в качестве опорного материала использую.

посоветую отца основателя С++ почитать - Страуструпа "Язык программирования с++".
из отзывов о книге:

К тому моменту, как я взялся за чтение этой книги, я почти 10 лет писал на C/C++, причем, как мне тогда казалось, писал недурно. Но только запоем прочтя Страуструпа, понял, насколько убогий примитив выходил из-под моих пальцев: справедливости ради, надо сказать, что такой же примитив выдают на-гора и не меньше 80% остальных считающих, что знают С++. Не так много на моей памяти было книг, способных сделать революцию в мышлении: эта книга оказалась именно таковой. Это было как просветление для буддиста или вид Эльдорадо для рыцаря Круглого Стола - до меня дошло, что я вообще не понимал сущности языка C++, и использовал его в стиле забивания гвоздей микроскопом. То, что я считал сферой возможностей языка, оказалось собачьей будкой на фоне мегаполиса... Черт, это просто потрясающая книга. Лучшая, посвященная C++, и только справедливо, что написал ее создатель языка. Для всех пишущих на C++ - однозначный must have.

[BOB51]

Посмотрим по мере возможности...
(ссыль на "где можно скачать без торрента" не помешала бы)


Я выбираю тот материал, где есть разжевывание некоторых "азов", упущенных в более поздних публикациях "по умолчанию" (из предположения "это вы уже в школе проходили").
Кроме прочего - практически ВСЕ учебные пособия по СИ имеют две крайности:
1. в учебном материале "общего назначения" за основу берется материал для работы на ПК;
2. в учебном материале "прикладного назначения" (Си для МК) основное внимание уделяется работе с "лаподрыгом" (включая объявления РСФ и прочего низкоуровневого)...
Оба случая рассматривают в качестве примеров исключительно "плоскую модель" без перекрестных вызовов из библиотек и применения внешних файлов "выкуся".
Этот этап уже достаточно понятен (как и плюсы/минусы каждого из них и "хотелки" по недостающему материалу).
С учетом особенностей ардуино IDE особо остро стоит вопрос работы с "надстройкой" - создание и использование внешних файлов.
А вот тут и .... практически полное отсутствие информации.

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

В отношении адуринки, как я понимаю, разработчики IDE использовали подобный метод - только в более совершенном исполнении - создали дополнительную надстройку над "стандартными" компиляторами для каждого из применяемых в IDE семейств. Причем "надстройка" привязана к конкретным платформам (разрабатывается и обновляется производителями платформ (платок)).
А уже та "надстройка" составлена с учетом требования С++ (возможно и иных "дополнительных компиляторов" jawa и фитон ).
Размещение у оного Материала вероятнее всего не в каталоге IDE, а в скрытом каталоге
C:\Documents and Settings\User\Local Settings\Application Data\Arduino15
однако анализ того, что там лежит требует уровня ПРОФЕССИОНАЛЬНОГО ПРОГРАММИСТА...
К сожалению - не для меня.
В отличии от "стандартных учебников" в ардуине сразу идет создание класса во внешнем файле - минуя стадию описанную в учебном курсе: объявление, описание класса и создание экземпляра в основном файле *.сср...
Вот в кратце как-то так...

Пока же идет этап изучения и тренировочных проектов-извратов для определения правил написания и рамочных ограничений в работе с исходниками.
Будет время - доконаю проект с DHT11 до "стандартного" индикатора на MAX7219....
А уж потом выложу всю последовательность "сборки" относительно "библиотеки" для DHT11 - от первичного проекта до внешнего драйвера-библиотеки, методы которой используются во "внешней выкуси".

[oleg110592]

первая же ссылка гугла на pdf второго издания:
http://8361.ru/6sem/books/Straustrup-Ya ... niya_c.pdf
кто может лучше разжевать азы С++ чем создатель языка.
Насчет "внешних файлов" можно глянуть, как пример, ардуиновский проект Marlin 3D Printer Firmware:
https://github.com/MarlinFirmware/Marlin
там раздельно см. например:
MarlinSerial.h
MarlinSerial.cpp
и все файлы в одной кучке

[BOB51]

"Профессиональные" библиотеки содержат "смесь" - часто и СИ и ++ ...
Причем не факт, что в каждом случае полная информация для взятия в качестве шаблон-примера сгодится.
О том ранее уже говорилось.
Да и для детального и корректного анализа нужен надлежащий уровень "выше среднего".
Легче самому проработать варианты - гораздо приятнее и понятнее что и откуда вылазит.
Вот к примеру ранее разобранный "спотыкач" https://radiokot.ru/forum/viewtopic.php ... 5#p3684695
....
ТАм могут попасться и варианты "класс использует метод другого класса" - а оные зависят от того, где создание объекта,включающего в себя оный метод было выполнено...
Ну и много подобной рутины.

[BOB51]

ПЛОСКИЙ ШТОПОР
(однофайловый проект)
и как с оным бороться...

Итак еще один вариант проекта с расширенным комментарием.

my_dht_10.rar

(9.97 KiB) Скачиваний: 269

Суть дополнений -
как и в случае "ассемблерного слэнга" создан единый дополнительный файл
дефайн-описаний общих для проекта констант и типов.
Включая и константы для инициализации объектов классов внешних библиотек.
Как пример "выкусь" (в *.ino закомментированная), которая вынесена во "внешний набор"
из print.h и print.cpp...
Из размышлений садомазохизма массив данных, считанных из датчика DHT11 (dht_buf)
оставлен ПОКА за пределами драйвера датчика. Там же и интересный вариант в смысле
подключения заголовочника от mxDht.h но отсутствия ссылки на объект в параметрах функции
prints_nju
ВОТЬ...

Далее ешшо чуток поизмываюсь над исходником...

[ARV]

BOB51, вы бы архивы свои выкладывали бы в ZIP-е, потому как RAR утомляет...

[BOB51]

ДЫК... че попало под лапу - с тем и работаем...

А у ZIP то версия не та, то ешшо чавось...
На ХР любой проводник мои "упаковки" открываеть - посему особо и не заморачивался.
В принципе можно и посмотреть чего из мал устаревших 7ZIP... Но не самые последние...
Попробую учесть на следуюшший раз...

Вроде вот такой вариант возможен...

my_dht_10.zip

(14.66 KiB) Скачиваний: 164

[BOB51]

Обещаный вариант под MAX7219

my_dht_12.zip

(11.77 KiB) Скачиваний: 162

общая схемка макета
http://img.radiokot.ru/files/20529/1zkc4usncg.GIF

dht10_12.pdf

(275.5 KiB) Скачиваний: 129

собственно железяка настольная
http://img.radiokot.ru/files/20529/1zkc523h4e.jpg
База та же, что и для NJU6432 (приведенный выше my_dht_10.zip).
Заменен собственно сам индикатор и драйвер индикатора да чуток инициализации (там вариантов моного может быть).
Смотрим исходник, комментируем "кошерстность", отмечаем собственные интересы.

На этом входной курс "среднеуровневого ОБЯЗАТЕЛЬНОГО МИНИМУМА" для адуриньи можно считать завершенным.
Далее обычное "догрызание по прециденту" - по мере возникновения вопросов в текущих проектах.
Фанатично вгрызаться, забросив все иные вопросы не есть хороший стиль...
(однако МИНИМУМ таки частенько приходится форсированно грызть).

Отдохнемс малость...

[Мурик]

общая схемка макета

Ну чё, КРУТО! Ногодрыг рулит!
У МК есть аппаратные I2C и SPI, но нет, нужно их реализовать обязательно программно.
Такое впечатление что схему разрабатывал маленький котенок, а не кот.

[BOB51]

Это разборка с правописанием (создание многофайловиков).
Аппаратные средства и их стандартные библиотеки составлены профи
и не так наглядно демонстрируют процесс работы
по созданию собственных библиотек и "выкуси" с перекрёстными связями.
Упор именно на самостоятельную работу по написанию проекта
"на среднем уровне".
Да и " обкатка" предположения о том, что ардуино IDE является
средой С++ для микроконтроллеров.
Далее повисло в планах теста предположение для бою пилса (по мере настроения)
с той же начальной схемкой (из принципа посмотреть адаптацию и ранее
сделанные предположения).
Однако... на чистой теории для "положить в ящичек" ...

Посмотрямс по ходу работ...

[Upgrader]

Upgrader писал(а):

Longan Nano: RISC-V микроплата стоимостью всего $5
https://servernews.ru/993269?from=relat ... rce=993191

Крутой и дешевый аналог ардуины?

[BOB51]

С платами "сторонних производителей" я бы был поосторожнее...
То, что общепризнано и выпускается "от фирмы" заниматься можно, а вот с новыми и любительскими версиями...
Опять же все описания особенностей применения придется САМОМУ отрабатывать.
STMки представлены как
STM32 Cores by STMicroelectronics версии 1.6.1
Вот из того, что там заложено/предлагается и выбираем (из типичных "прикладных" (про-мини/нанкоподобных)) только blue pill
http://img.radiokot.ru/files/20529/1kukf69ch0.JPG
можно считать доступным. Однако на всякий случай надобно еще иметь в запасе фирмовый программатор от STM (tlink ST-Link V2)
А в самой IDE предварительно установить штатный
Arguino SAM Boards (32-bits ARM Cortex M3) by arduino текущая версия 1.6.12 - это под ArduinoDue, но компилятор завязан и для STMок как часть компонент IDE.

Касательно иных МК, не входящих в комплект поставки IDE "по умолчанию"использую "добавки" вот по сему списочку:

Код:

https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json
http://arduino.esp8266.com/stable/package_esp8266com_index.json
https://mcudude.github.io/MicroCore/package_MCUdude_MicroCore_index.json
https://mcudude.github.io/MiniCore/package_MCUdude_MiniCore_index.json
https://mcudude.github.io/MajorCore/package_MCUdude_MajorCore_index.json
https://mcudude.github.io/MightyCore/package_MCUdude_MightyCore_index.json
https://mcudude.github.io/MegaCore/package_MCUdude_MegaCore_index.json
https://raw.githubusercontent.com/sleemanj/optiboot/master/dists/package_gogo_diy_atmega8_series_index.json
https://raw.githubusercontent.com/sleemanj/optiboot/master/dists/package_gogo_diy_attiny_index.json
http://www.dragino.com/downloads/downloads/YunShield/package_dragino_yun_test_index.json

[Мурик]

Крутой и дешевый аналог ардуины?

Описание по ссылке очень краткое.
У МК неплохой набор периферии и нужна нормальная либа для ардуины чтобы ее задействовать. Или как обычно ногодрыг для всех случаев? Тогда даже 10% возможностей МК получить не получится. Современные МК (особенно старшие модели) содержат много различной периферии (например есть модели с 14 и более таймерами, в т. ч. 32-ух битные с различным доп. функционалом) и нужно грамотно ее использовать что позволит с помощью одного МК решить туже задачу что используя 10 ардуин и не оптимальный код в ArduinoIDE. А такое не редкость среди ардуинщиков. Вместо оптимизации алгоритма и кода, они ставят побольше ардуин...

То, что общепризнано и выпускается "от фирмы" заниматься можно, а вот с новыми и любительскими версиями

То что официально поддерживается "от фирмы" давно устарело.

Вот из того, что там заложено/предлагается и выбираем (из типичных "прикладных" (про-мини/нанкоподобных)) только blue pill

Просто нужно снять ограничение называемое "ардуина" и писать в IDE для этих МК. Тогда список доступных МК значительно расширится.

Arguino SAM Boards (32-bits ARM Cortex M3) by arduino текущая версия 1.6.12 - это под ArduinoDue, но компилятор завязан и для STMок

Компилятор не для AVR или STM, а для ARM.
Он генерирует код для процессора. Поэтому не важно какая фирма выпускает МК. Главное чтобы процессорное ядро было одинаковое.

[BOB51]

Мурик
Самый оптимальный код - под "чистым ассемблером".
В том числе и в вопросах использования по максимуму встроенной периферии.

Только вот... почему-то такой подход весьма редко применяют (за исключением разве что профессионалов да разрабов самих МК у изготовителя).

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

Насчет правильности вывода...
Когда-то и за гибрид С/С++ в рамках адуринки да о многофайловиках для адуриньи я тоже говаривал - сколько ШИПЕНЬЯ было? и кито прав оказался?


Пока надо ГЛАЗКАМ немножко отдых дать...

[Мурик]

Самый оптимальный код - под "чистым ассемблером".

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

В том числе и в вопросах использования по максимуму встроенной периферии.

То есть под асмом доступно больше регистров периферии или она становится более функциональной?

Применение нескольких МК/СБИС в проекте отнюдь не слабость проекта, а разумное использование имеющихся ресурсов.

Только в том случае когда это обосновано. Иначе это некомпетентность разработчика.

Да и подход к адуриноподобным как к отдельному МК с набором встроенной периферии, используемой "по максимуму" есть ТУПИКОВОЕ решение.

Кто вам такую глупость сказал или сами придумали?

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

Человеку сказали - "Ты раб и не имеешь прав и будешь делать все что тебе скажут и в замен ничего не получишь, кроме ударов плетью". Вот это примерно то что вы написали. Если вы готовы с подобным мирится, ваше дело.

Как ранее уже говорилось - можно использовать аппаратные особенности ПК, минуя API пользователя ОС и БИОС ПК, но таковые программы будут работать исключительно на данной версии материнки, не допуская переноса на любой иной ПК.

Допустим была разработана ОС для всех существующих устройств, как для ПК, так и для МК. Что в итоге. На ПК нет интернета, нет 3D, да и вообще графики только текст, нет USB, нет многозадачности и многого другого (ведь не все МК это аппаратно поддерживают и для совместимости все что не поддерживается исключено). Вы бы хотели такой ПК?
Надеюсь понимаете в чем изъян вашего предложения?

Хочеш чего с эксклюзивом - иди в среду разработчика МК

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

и долби дотошно документацию на КАЖДЫЙ ИЗ ПРИМЕНЯЕМЫХ КРИСТАЛЛОВ

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

работай в рамках СТАНДАРТИЗИРОВАННОГО референса

Проблема в том что он заточен под меги и все. Возможности остальных МК (тех же STM32) полностью использовать не получится и мощный МК будет задействован как мега и приемуществ не получите.

[BOB51]

Мурик
По Вашему "чистый ассемблер" также не имеет права на применение?

Под ЯВУ того, что можно сделать под ассемблером выполнить не удастся в связи с теми же ограничениями, что создают удобства использования ЯВУ.
Да и применяемые алгоритмы совершенно разные во многих случаях.
Касательно "глубокого доступа" - опять же аналогия с ПК - смысл писать на уровне аппаратных ресурсов программу, которая является пользовательским приложением в рамках имеющихся в ОС ресурсов?
В то же время ... строить комп ради простого приложения также неразумно.

Вот Вы ВСЕХ стараетесь под STM32 подстроить...

В моей наработке нет разницы в том, какую материальную базу применять -
отдельные МК MCS51, PIC среднемладшие, AVRки под ассемблером или ардуиноподобные DIP микросборки под Си.
Главное, чтобы можно было получить от каждой разновидности достаточную для решения текущих задач отдачу.

Для того и изучение методов работы с ардуино IDE в рамках "среднего уровня" - то, против чего Вы интенсивно протестуете.

[Мурик]

По Вашему "чистый ассемблер" также не имеет права на применение?

Я этого не писал. Я про то что набылокодить можно на любом ЯП. Нужно писать оптимальный код чему не способствует ардуина.

Под ЯВУ того, что можно сделать под ассемблером выполнить не удастся в связи с теми же ограничениями, что создают удобства использования ЯВУ.

Примеры пожалуйста применительно работы с периферией. Что асм позволит с ней делать такого что недоступно из ЯВУ?

Касательно "глубокого доступа" - опять же аналогия с ПК - смысл писать на уровне аппаратных ресурсов программу, которая является пользовательским приложением в рамках имеющихся в ОС ресурсов?

Смысл писать программу для компа как для МК? Платформы разные и подходы к программированию отличаются.

В то же время ... строить комп ради простого приложения также неразумно.

Вы компы строите? Ну-ну.
ОК, запустите простое приложение для компа на МК. Расскажите что получится.

Для того и изучение методов работы с ардуино IDE

Без ArduinoIDE никак не можете?