• Уважаемые посетители сайта esp8266.ru!
    Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
    Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru
  • Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Подключение датчиков типа 10-DOF - акселерометр, гироскоп, магнитометр, температура, давление...

pvvx

Активный участник сообщества
Подключение к ESP датчиков типа 10-DOF (акселерометр, гироскоп, магнитометр, температура, давление, …)

Отлаживаю драйвер для ESP8266 с датчиком на основе блока 10-DOF GY-91:


Пока драйвер успешно живет и тестируется в IRAM (тестовая трансляция и исполнение без прошивки в Flash, а только с загрузкой в память ESP8266 из Eclipse).

Развиваемая скорость сбора обработки данных, при 30% занятости CPU ESP8266 переваливает за 1000 точек на каждый параметр каждого датчика (это поток более 40 кбайт нативных данных в секунду).

Оптимально, чтобы не мешать работе SDK и прочему, решил настраиваться на поток не более 100 точек в секунду. Тогда, пример загрузки шины HSPI (с выводом на UART отладки), выходит примерно такой:
ESP-SPI-10-DOF.gifESP-SPI-10-DOF2.gif
Выходной формат нативных данных уже скорректирован по информации с самих датчиков, но float не применяется, т.к. далее будет необходимо осреднение данных для записи в лог, а в float ESP не успеет обработать такой поток.
Код:
IRAM only SDK Init.
Free Heap: 81096
Free IRAM: 60216
HSPI CLK = 1000000 Hz
Init BMP280...
BMP280 id: 58
Dig BMP280: 4a 6b a9 67 18 fc e8 92 38 d6 d0 0b c5 0a 19 01 f9 ff 8c 3c f8 c6 70 17
Regs BMP280: 0c b7 10 00 80 00 00 80 00 00
Temp: 20.75 C, Press: 79857 Pa
Init MPU9250..
ID MPU9250: 71
ID Mag: 48
Mag: 48 9a 00 7b ff ab ff 41 fe 10 12 00 00 48 9a ac ae a2 00
F(1): 2215,98720,M(-154,-105,-228),A(8164,7348,12076),G(-4,74,-116)
F(1): 2224,98720,M(-149,-96,-228),A(8108,7300,12076),G(-5,30,-86)
F(1): 2232,98722,M(-152,-96,-224),A(8116,7292,12048),G(5,71,-141)
F(2): 2237,98721,M(-154,-94,-222),A(8116,7372,12092),G(-17,12,-49)
F(1): 2241,98725,M(-143,-104,-227),A(8128,7356,12000),G(-12,46,-66)
F(1): 2244,98723,M(-153,-90,-226),A(8160,7380,11984),G(1,75,-159)
F(1): 2247,98724,M(-151,-97,-225),A(8140,7352,12152),G(8,70,-153)
…
Т.е. данные с датчиков полные, с фиксированной точкой. Например для температуры 2247 - надо делить на 100 и выйдет 22.47 С. С этим успешно справиться и java, отображающая данные на Web странице.

Концепция применения драйвера для народа пока не выработана. По этому и создал тему. Необходимо решить область применения или куда и как есть желание использовать. Только после этого драйвер приобретет вид возможный для публикации. Пока я его адаптирую только под свои нужды и уверен что народу такое не надо. Но побочный вариант, после консультации тут возможно родит отдельный открытый драйвер для всех :)

Пока видится такое использование (общие цели):
  1. Передача потока с датчиков в реал-тайм на какой-то внешний сервер.
  2. Накопление и осреднение данных этого потока для проекта сервера статистики с циклической записью данных за промежуток в 1 год с шагом от 5 до 15 минут с графическим выводом для web-свалки.
  3. Драйвер ориентирован на фоновую работу (работу по прерываниям).
Минимальный шаг записи усреднения зависит от размера flash. Для основы берется 4 Мегабайтная flash в модуле ESP8266, с распределением до 3-х мегабайт под циклическую запись годового буфера данных за последний год, с износом flash через год*кол-во возможных перезаписей для конкретной flash. Это где-то от 10000 лет :) Быстрее китай-SDK убьет сектора со своей перезаписью настроек WiFi…
Жду комментов, рекомендаций и метод оптимизаций и т.д. под это дело... Да и вообще куда ещё в народном творчестве возможно использовать данную связку ESP-X-DOF?
Особо приветствуются указание открытых проектов отображения 3D данных с таких датчиков для Web концепции (java/ajax/flash/swf/...).

PS: драйверы для АрДурино не предлагать - они не умеют работать в фоне или требуют мультизадачной системы, да ресурсов, которых нет у ESP8266 и ESP32. Тем более у Дурины Spiffs, который не даст никому работать своими задержками и множественными перезаписями flash c длительными стираниями, во время которых работа ESP невозможна.
 
Последнее редактирование:

pvvx

Активный участник сообщества
А как такое можно делать? Если можно, чуть подробнее.
А что мне за это будет? :) Это надо с примерами и всё такое, типа в git проект мне создавать и выкладывать...
-----
Вот сделал для вас:
https://github.com/pvvx/iramsdk
Что дадите в замен? Или просто смоетесь? :)
 
Последнее редактирование:

windalser

New member
А что мне за это будет? :) Это надо с примерами и всё такое, типа в git проект мне создавать и выкладывать...
-----
Вот сделал для вас:
https://github.com/pvvx/iramsdk
Что дадите в замен? Или просто смоетесь? :)
Спасибо. Попробовал, компилируется, пример работает.. Как я понял, это полезно для разработки отдельных кусков программы, которым не требуется связь по wifi,
например, какого-нибудь драйвера.
Хотя, мне первоначально представлялось, что это добавка к полному pvvx SDK как инструмент для быстрой отладки.. когда кусочек IRAM резервируется для загрузки тестов..
Мы используем ESP8266 в качестве WiFi модемов для приборов охранной сигнализации. Как запасной канал связи наряду с GSM модемом. Управляем at-командами. Ничего особенного.. Но работают нормально.
От lua я отказался из-за требовательности к ресурсам. Есть интерес к Aрдуино - Дурине :)
У меня опыт программирования на языке C небольшой.
Имеется b-модуль ESP32 . Опробовал несколько простых тестовых программ на нем под UDK от CHERTS. На виртуальной Linux машине toolchain также работает.
Я бы сказал, что там все очень близко к ESP8266 с точки зрения программирования (только FREE RTOS). Даже появилась альфа-реализация Ардуины для него - http://esp32.com/viewtopic.php?f=2&t=102 .
Думаю, что ESP32 весьма перспективен, хотя в настоящее время им занимаются единицы..
 

pvvx

Активный участник сообщества
Я бы сказал, что там все очень близко к ESP8266 с точки зрения программирования (только FREE RTOS). Даже появилась альфа-реализация Ардуины для него - http://esp32.com/viewtopic.php?f=2&t=102 .
Думаю, что ESP32 весьма перспективен, хотя в настоящее время им занимаются единицы..
От куда и зачем у вас ESP31 (бета ESP32), если пишут что их раздавали всего 200 шт? Вы же на СИ не пишите и тестить пока там нечего.
Китайцам делать нечего - раздавать образцы тем, кто их даже не может програмить?
В принципе это и есть подход Espressif - сделать всё как можно хуже и дольше... :)
Особой ценности у ESP32 может и не случиться, если цена модуля будет в 2 раза больше, только в мире Дурины. За 3 цены модуля ESP-12 уже идут модули с OpenWRT.
Спасибо. Попробовал, компилируется, пример работает.. Как я понял, это полезно для разработки отдельных кусков программы, которым не требуется связь по wifi,
например, какого-нибудь драйвера.
Хотя, мне первоначально представлялось, что это добавка к полному pvvx SDK как инструмент для быстрой отладки.. когда кусочек IRAM резервируется для загрузки тестов..
И такое есть, но оно в непотребном виде - не для публикаций, т.к. будут требовать всё готовое к нему для обслуживания загрузок и прочего, а этого пока нет - большинство манипуляций делается в ручную и не автоматизировано...
Чтобы скинуть https://github.com/pvvx/iramsdk и то потребовалась куча времени хоть на какие прически кода, Make и прочего... Целей всё выкладывать и расписывать у меня нет. Только то, что предлагаю, c участием, чтобы был хоть какой толк. Например эта тема с датчиками... Свою то задачу с ними я решу, но вот общество никаких предложений пока не дает - значит им это не надо.
 
Последнее редактирование:

pvvx

Активный участник сообщества
Это Вы просто неправильно датчики позиционируете. :) Назовите их "i2c sensor" и люди к Вам потянутся. Не все же знают: что такое 10DOF.
А я их на SPI гоняю с их встроенным FIFO (у MPU9250 512 байт). I2C не потянет толпу датчиков на одной шине при нормальных скоростях. И I2C убивает рабочее время CPU ESP826 - I2C пусть в Ардуино и Lua используют, я стараюсь эту тормозную шину не пользовать, но по ней тоже в данном проекте ещё будут другие датчики, которые медленные... :) Пару раз в секунду можно отработать на 400кГц I2C.
 
Последнее редактирование:

pvp

New member
Да и вообще куда ещё в народном творчестве возможно использовать данную связку ESP-X-DOF?
Ну вот, например, у меня так:
в качестве 9-DOF использован POLOLU minIMU-9 V3, Информация по скоростям с каждого колеса берётся с ABS автомобиля (пока при помощи ELM327). Плюс ещё лазерный измеритель расстояния до дорожного покрытия. Соответственно, корректирую наклоны кузова авто (поперечный и продольный), решая задачу 6-DOF (магнетометр на данный момент не использую) и учитывая продольное и центробежное ускорения, рассчитанные по скоростям колёс. Сейчас это работает через USB HID на AT90USB162. Обсчитывается (якобиан там и кватернионы) на компе в C# WinForms. Хочу сделать всё через вай-фай и чтобы в ДЖАВЕ всё считалочь и через аякс бралось компом. Соответсвенно, производительности ESP8266 не потребуется (так как всё будет по прежнему обсчитываться компом), но отображаться будет в браузере, сл-но никакого отдельного приложения для компа.
upload_2016-3-4_17-46-4.png
 
Последнее редактирование:

pvvx

Активный участник сообщества
Соответсвенно, производительности ESP8266 не потребуется (так как всё будет по прежнему обсчитываться компом), но отображаться будет в браузере, сл-но никакого отдельного приложения для компа.
У вас мало точек отсчетов в секунду. По моим расчетам там нормально более 100 точек в секнуду, а если датчиков много, то это уже нормальный поток и требуется производительность для съема и упаковки этих данных для пересылки. По этому никакие I2C не годятся. Только SPI и FIFO.
Развиваемая скорость сбора обработки данных, при 30% занятости CPU ESP8266 переваливает за 1000 точек на каждый параметр каждого датчика (это поток более 40 кбайт нативных данных в секунду).
В итоге передача по WiFi с 10DOF уже 40 килобайт в секунду. А ещё надо вставлять метки времени и какую-то синхронизацию их с приемником.
Только такие скорости позволяют кое-как определиться к примеру с простым движением рук человека. А машина - она большая и тяжелая. Т.е. неуклюжая и имеет малые силы для больших ускорений... до одного Же. Если только не об столб :)
 
Последнее редактирование:

pvp

New member
В итоге передача по WiFi с 10DOF уже 40 килобайт в секунду. А ещё надо вставлять метки времени и какую-то синхронизацию их с приемником.
:)
А это проблема для EPS - 40 kb/sec? Требуется только передать, например, UDP пакетом сырые данные на хост и всё. А хост сам всё посчитает. Или я чего-то не понял в ваших рассуждениях. Обработку на борту можно пока и не делать. Потом допилится.
О каких метках времени идёт речь - номер пакета прилепить (+1 байт к пакету) и всё. Если номера последовательны - значит всё гуд и пропусков нет. Считаете свои дирижёрские гестуры. Вы же знаете с каким темпом данные быдет вылпёвывать MPU (с каким-то, но постоянным). Мне кажется, стоит поток гнать исключительно по UDP. Никаких вам поисков начала-конца, как в случае с tcp. все простенько и быстренько. Ага?
 

pvvx

Активный участник сообщества
А это проблема для EPS - 40 kb/sec? Требуется только передать, например, UDP пакетом сырые данные на хост и всё. А хост сам всё посчитает. Или я чего-то не понял в ваших рассуждениях. Обработку на борту можно пока и не делать. Потом допилится.
О каких метках времени идёт речь - номер пакета прилепить (+1 байт к пакету) и всё. Если номера последовательны - значит всё гуд и пропусков нет. Считаете свои дирижёрские гестуры. Вы же знаете с каким темпом данные быдет вылпёвывать MPU (с каким-то, но постоянным). Мне кажется, стоит поток гнать исключительно по UDP. Никаких вам поисков начала-конца, как в случае с tcp. все простенько и быстренько. Ага?
UDP - проблема. Потеря данных.
При загрузке в 30% на чтение c датчиков (CPU будет занят 30%) и по TCP уже проблема.
Легко поднимается до почти 800Гц (по акселям и дусам) (даже с моим софтовым i2c в мк). Только что попробовал. Но это не суть данной темы.
Каким образом, если I2C - это 400кГц, а для снятия 1000 показаний надо минимум 10 тактов I2C на один байт, а необходимо считать более 20 - т.е. не менее 20*1000*10 = 200000 тактов шины I2C. И всё это время CPU будет занят I2C и не сможет отрабатывать WiFi.
 

pvp

New member
UDP - проблема. Потеря данных.
При загрузке в 30% на чтение c датчиков (CPU будет занят 30%) и по TCP уже проблема.
UDP ведь проще - не надо соединение устанавливать и т. п.
Забиндился - и плюй в порт, ничего не слушая, разве нет?
Всегда так поступал, если какие-то анные нужны на постоянной основе каким-либо узлам в подсети. Обязательно проверю, какие потери будут с рассылкой от ESP по UDP.

А почему проц будет занят на 30%? SPI же аппаратный и по прерываниям, не так ли?
Или это сдк столько кушает сейчас?

Да, и попробуйте гестуры на 100Гц обрабатывать. Мне кажется, что этого более чем достаточно (покрутил сейчас свою инерциалку в руках - ну нет никаких задержек, всё плавненько, видос что-ли выложить?)
 
Последнее редактирование:

pvvx

Активный участник сообщества
А почему проц будет занят на 30%? SPI же аппаратный и по прерываниям, не так ли?
Или это сдк столько кушает сейчас?
А кто будет читать регистры SPI на медленной внутренней шине ESP8266 и выставлять СS-ы на разные микросхемы? Время на вход и выход из прерывания вы тоже не учитываете?
I2С сделать по прерываниям не представляется возможным. Это надо 800 кГц прерывания :)
Читать побайтно из SPI по прерываниям тоже невозможно. Даже поблочно. Слишком короткие блоки.
Да, и попробуйте гестуры на 100Гц обрабатывать. Мне кажется, что этого более чем достаточно.
Пробовал - всё Ok.
 

pvvx

Активный участник сообщества
Так зачем Вам тогда 1кГц опроса?
Для акселерометра и прочих данных.
Картинка загрузки получившегося дана в первом сообщении. Код теста давался в другой теме :)
Вам бы не городить винегрет - любой современны смартфон дает ваши данные на 100 Гц.
 

pvvx

Активный участник сообщества
Зачем? Как быстро вы будете руками-то размахивать? С частотой сети (50Гц) что-ли?
Руками - это условно. Мне нужны все показания, включая яркость, давления и прочие. И желательно векторные :p
Как понимаю, вы хотите меня уговорить использовать I2C и не получить результата :)
UDP на WiFi - это оно и есть - потеря данных в минимум 1% при чистом эфире.
Может для вашего авто это и подойдет. Там всё равно какие данные оно будет получать, а какие не получит.
 
Последнее редактирование:
Сверху Снизу