Настраиваемое ядро для Arduino

"О, тёпленькая пошла..." Наконец в конфигураторе "правильный" проц появился. Ещё с часами непонятно, часы есть, идут, но при первом подключении пишет NO DATA и пока не пнёшь, т.е. не запишешь в них время в основных настройках не появляется. А температуру нормально читает.

 

Странно. Раз время в них пишется, значит пишется правильно. Мож, с батарейкой чего, что соскакивают? Не замечал у себя проблемы с DS3231.

А если не из конфигуратора, а просто открыть монитор порта и раз несколько скормить команду GET=DATETIME - что будет?

Строго говоря, время в основных настройках - это чисто справочная инфа. Лучше ориентироваться на показания на вкладке "Данные" - добавить датчик DS3231 и смотреть с него, чего там.

 

Да, кит...ы хреновы, похоже в модуле диод не туда повернули Днём разберусь.

 

Пришла термопара MAX6675, вот думаю - внедрить поддержку этого дела в ядро? Всё равно надо баловаться с ней, пробовать Наверное, потихоньку припилю.

 

Значит так: обновил всё (в том числе и софт!) на гитхабе, добавил поддержку MAX6675, заодно подправил некоторые найденные косячки. Ну и ввёл новые - куда ж без этого

Поскольку у MAX6675 тип показаний - температура, и дабы не вводить новый тип показаний - пришлось исправлять архитектурный косяк, где целая часть температуры хранилась в одном знаковом байте. Сделал сейчас два байта под температуру до запятой, и байт - под сотые доли градуса, т.е. диапазон температур теперь [-32767,32767].

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

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

По поводу MAX6675: подцепляется к SPI, есть в настройках датчика "медленный режим" - если вдруг с датчика не читает - пробуем установить его, чтобы делитель на SPI сделать побольше.

Подцепил пришедшую сегодня термопару, проверил - показывает. Погрел зажигалкой - показывает. Т.е. на первый взгляд - всё шевелится.

Если что - поправлю найденные косяки, не вопрос.

З.Ы. Ну теперь мы вообще сурьёзные ребята - у нас и термопары в комплекте искаропки

 

Кстати сказать - поддержка Nextion работает, поступил заказ на реализацию общения с Nextion, я выкусил эти классы из ядра - всё отлично работает (впрочем, на симуляторе я до этого проверял, но всё же).

 

Шо ещё добавить из датчиков? Какой-нибудь BMP180? Надо пошукать, что у меня в закромах валяется до лучших времён

 

Щаз насыпем ... что тут под рукой? BME280, LM75, TSL2561, INA219, BMP180 - это I2C, вон ещё проводки торчат О, RC522, ACS712, MAX31855 - ну это похоже на 6675 по интерфейсу, формат данных немного отличается. Дальше продолжать ? Я при старте запускаю сканер I2C и все найденные адреса заношу в таблицу, потом сверяю с тем что в конфиге, а дальше я что то затупил

 

Всё! Надо тормозить, размер уже не лизе У 2 нуль, нуль скачал последнюю версию её беру за основу. Добавлять по одному датчику в конфиге как-то не по феншую. Надо разбить на группы. Здесь уже есть DIGITALPORT и ANALOGPORT, надо добавить SPIGROUP, I2CGROUP и ещё наверно ONEWIRE т.к. здесь не только DS18B20, но ещё iButton DS1990a и куча других.

 

Смысел? Всего всё равно не предусмотришь, а на I2C и SPI какие проблемы? Параллельно всё и сейчас работает - те же DS3231 и Si7021 прекрасно висят на I2C и не жужжат, будучи добавленными по отдельности

Ну я понял, что есть куда стремиться Потихоньку буду расширять функционал, во всяком случае - в пределах того, что у мну есть в наличии.

Зачем это делать, не понял? Адреса поддерживаемых датчиков и так известны ядру, на примере того же BH1750 - он поддерживает всего два адреса на шине I2C, оба - ядро знает

 

А я предупреждал Забейте на мелкие камни - и проблема размера рассосётся

 

Код (C++):

#if defined(CORE_DS3231_ENABLED) || defined(CORE_BH1750_ENABLED) || defined(CORE_SI7021_ENABLED)
#include <Wire.h>

Эта строчка может разрастись до хрен его знает каких размеров и про неё надо помнить. В случае, если в группе есть хоть один датчик, разрешаем группу и про эту строку можно забыть. И с другими так же.

 

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

Щас скачал адафрутовскую библиотеку Adafruit_BMP085, подключил BMP180, выдаёт по коду из примера:

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

 

Имеется в виду настройку в CoreConfig.h - типа, включить поддержку I2C - я правильно понял? Чтобы по одной этой настройке подключать Wire?

 

Вот именно, сейчас каждый датчик инициализирует I2C, а 7021 вообще на 400КГц - зачем? И куча проверок DUE или нет, когда выбирается номер шины. Ведь проц мы никак на ходу поменять не можем, достаточно при инициализации указать её номер. А DS18B20 = зло Отбирает 3Кб памяти???

 

CoreConfig.h

Код (C++):

#define CORE_I2CGROUP_ENABLED
#ifdef CORE_I2CGROUP_ENABLED
  #define CORE_BH1750_ENABLED // поддержка датчика освещённости BH1750 (шина I2C)
  #define CORE_SI7021_ENABLED // поддержка датчика влажности Si7021 (шина I2C)
  #define CORE_DS3231_ENABLED // поддержка часов реального времени DS3231
  #define CORE_BME280_ENABLED
#endif

Ну и дальше по списку...

 

Дык это всё на этапе компиляции, пущай препроцессор работает - жалко что ли? Смысл как раз в том, что только на этапе компиляции можно определить - есть ли второй I2C, например. Что касается DS18B20 - ну тут уж ничего не попишешь, там 1-Wire со своими плюшками.

То, что каждый датчик на I2C один раз при инициализации покличет Wire.begin - ничего страшного в этом не вижу, от слова "совсем": всё равно это происходит только при старте ядра в работу

Про кучу проверок "DUE или нет" - это препроцессор, в прошивку эти проверки не попадают для платы, где нет второго I2C.

Смысла не вижу так на группы разделять, вот честно. Потому как можно только один датчик на I2C иметь - зачем вводить лишние усложнения?

 

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

Какие плюшки? У DS три основные плюшки: сброс, чтение и запись байта. И на их основе ещё несколько высокоуровневых процедур.

 

Поиск устройств на шине - забыли? Код объёмный там, и он юзается в проекте.

Ну она меня не напрягает - препроцессор от этого не потеет пока

Что касается инициализации I2C - я оптимизирую, чтобы звалась только один раз

 

Единственный и состоит из тех же трёх, ну это на потом. Сейчас I2C и SPI интереснее, обложился датчиками, як тот партизан гранатами Будем пробовать.