-
Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram
TLSR8251 + LCD + термометр = LYWSD03MMC XIAOMI Bluetooth термометр
- Автор темы pvvx
- Дата начала
так я о том же.
Я же Вас спросил нафига 16 ядер?
В каких задачах они реально используются на полную и пашут часами.
Конечно, можно купить железку 1000$ за чип, а можно и за 200$ за чип делать тоже самое и за тоже время, если не играть в игрушки.
pvvx
Активный участник сообщества
Описано в самом начале.
В сборке Linux или OpenWRT к примеру.
Не может. Для игр CPU дороже, но медленнее в раб. программах.
pvvx
Активный участник сообщества
Завершился ещё один тест Xiaomi LYWSD03MMC B1.9 с CR2025 - дешевая батарейка CR2025 из набора 8 батареек за 60..80 руб наконец сдохла - SoC термометра ушел в deep-sleep с последними показаниями рабочего напряжения в милливольтах:
и ожиданием повышения за 2.2V для нового старта...
Почти 9 месяцев... Из этих наборов CR2032 обычно работает в 2 раза меньше чем какой оригинальный Panasonic CR2032 за 300..350 руб шт...
и ожиданием повышения за 2.2V для нового старта...
Почти 9 месяцев... Из этих наборов CR2032 обычно работает в 2 раза меньше чем какой оригинальный Panasonic CR2032 за 300..350 руб шт...
Я спросил о Вашем опыте, а не байки из интернета.
pvvx
Активный участник сообщества
У меня более 25 только BLE устройств с CRxxxx батареями. Кто-то дохнет всегда, менять можно скопом, в некоторых и по 2 батареи CR2032 (LYWSD02).
Во многие вставляются и работают CR2016 по 6..7 месяцев.
pvvx
Активный участник сообщества
Вам и был дан ответ, и не один: время сборки пакетов-проектов = время / кол-во ядер-потоков. Когда будет 128..256 ядер с TDP до 150Вт - надо брать. А пока там кВт, особенно у Intel, то нафиг сидеть в жаре и шуме вентиляторов....
можете пример конкретный привести, чтобы решить что надо брать.
Время сборки пакета + время записи его микроконтроллер+ время написания программы+ ...
И как это время изменится если 4 ядра или 32 или 128?
Ну и много информации Вы с этих 25 устройств реально обработали? Какой процент от того что они излучили или накопили.
pvvx
Активный участник сообщества
В среднем будет меньше в разы от кол-ва ядер-потоков.
На примере сравнения с вашем 4 ядерным к 32-х - в 8 раз.
Т.е. вместо 30 минут - менее 4-х минут. А с учетом увеличения скорости всяких SSD, объемов ОЗУ (файловых кэшей) и частот ядер - минуты три.
Для малых проектов ещё актуальнее, т.к. время собрать-порошить и проверить субъективно уменьшается и процесс выходит непрерывным и не напрягает лишний раз нажать кнопку сборки (и прогона тестов). Нет нужды в прерывании процесса для ожидания и как и нужды в мучениях с "красными глазиками" при использовании отладки с Jtag и ковыряниями в регистрах с точками останова. Вписываете вывод лога в непонятных местах и через несколько секунд получаете ответ от реального устройства в понятном вам текстовом виде.
И так-же при подборе оптимальных алгоритмов и оптимизации на реальном железе, т.к. требует ещё большее ко-во итераций пересборки всего, в основном из-за глобальных смен опций на весь проект. Но это вам не грозит, т.к. ваши проекты такого не предусматривают.
pvvx
Активный участник сообщества
Причина вашего непонимания известна.
Некоторые люди используют для изменения кода только текстовый редактор и асм. Как в очке Arduino. А другие – разные IDE, где в режиме реального времени наглядно предоставлены все зависимости, изменяющиеся на ходу. В Arduino всего несколько строк и нет возможностей изменения его зависимостей и свойств. Тупой единичный, заранее заданный шаблон – 2 кубика на пару комбинаций . А у других миллионы разных кубиков имеющих необъятное кол-во зависимостей, из которых они могут сложить итоговый объект.
Так вот сообщаю вам, что уже давно даже в текстовых редакторах используют режим наглядного отображения итоговой страницы, а не её внутреннего кода. И 99% современного кода занято переводом из машинного представления в наглядный для человека вид. Но вы не можете использовать аналогичное представление (в цикле процесса разработки с программированием) из-за использования устаревшего подхода и древнего оборудования.
pvvx
Активный участник сообщества
В программировании и разработке существуют множественные зависимости. И большая часть объектов представляет из себя черный ящик. Тупейшая задача трех тел не решается, а имеет только частные решения (см “бифуркация”). Обратитесь к представлению текущих ИИ, с их весовыми коэф-ми в узлах. Тут всё аналогично – необходимо иметь обратную связь для настройки этих “коэф-ов”. И чем быстрее процесс обратной связи – тем быстрее будет оптимизирована (обучена) система под задачу. А у вас один прогон “обратной связи” занимает часы, вместо секунд. Для ускорения он должен производиться в режиме реального времени. Но пока в этой цепи есть человек, обладающий ограниченным быстродействием и скорость более определенного – его субъективного восприятия не требуется и невозможна. С развитием вычислительной интеграции можно будет удалить человека и из этой цепи - временно оставить на заключительный контроль итога: шлепнуть печать “ОТК” 
pvvx
Активный участник сообщества
@nikolz - В корпоративной среде при программировании или разработке группой один цикл обратной связи растягивается на годы. По этой причине необходим индивидуум, который охватит все объекты за раз и выдаст готовую структуру коэф-ов (картостроение). Вас учили по другому – паковке - тупить над каждой страницей кода, который будет выкинут по итогу, как ненужный и не подходящий для решения итоговой задачи.
pvvx
Активный участник сообщества
Информацию с датчиков обрабатывают исполнительные устройства. Это основное их назначение и таких больше.
По поводу остальных "устройств": А сколько вы реально обработали, излучили или накопили при взгляде на часы на стене?
Приплюсую туда и другой ваш вопрос, по поводу что дает более качественный инструмент:
Награда в Хобби – это когда индивидуум сравнивает свои “вычисления” с ответом реально созданного и ответы совпадают. Плюс имеются возможности это воплотить, произвести, попробовать. По этому, я понимаю, что Вам тяжко или невозможно осознать, что Ваша жизнь потеряна и в ней нет места хобби. Её нагнули ещё во время вашего обучения в вузе, заставляя заучивать ненужные вещи и пресмыкаться перед “педагогами”, а не создавать свой путь, иметь выбор и возможности, изучать, пробовать…
У меня проекты умных устройств для ориентации в пространстве незрячих.Информацию с датчиков обрабатывают исполнительные устройства. Это основное их назначение и таких больше.
По поводу остальных "устройств": А сколько вы реально обработали, излучили или накопили при взгляде на часы на стене?
Приплюсую туда и другой ваш вопрос, по поводу что дает более качественный инструмент:
Награда в Хобби – это когда индивидуум сравнивает свои “вычисления” с ответом реально созданного и ответы совпадают. Плюс имеются возможности это воплотить, произвести, попробовать. По этому, я понимаю, что Вам тяжко или невозможно осознать, что Ваша жизнь потеряна и в ней нет места хобби. Её нагнули ещё во время вашего обучения в вузе, заставляя заучивать ненужные вещи и пресмыкаться перед “педагогами”, а не создавать свой путь, иметь выбор и возможности, изучать, пробовать…
Один с вибросенсором - 600 КБайт flash, Второй с TTS -2 Мбайта flash.
При этом датчик TOF потребляет 20 мА, вибросенсор потребляет от 30 до 100 mA.
Экономить батарейки на годы не получится.
Надо бы передать информацию без проводов и практически непрерывно.
Оба проекта это устройства 6x4 см2 весом 40 гр .
--------------------------
В итоге чипы TELINK не катят от слова вообще.
------------------------------------
А вот ESP82xx катят и конкурентов нет.
-----------------
Можете что-то предложить вместо ESP?
pvvx
Активный участник сообщества
Есть разница в цепи приема-передачи, а не в потреблении питания.
Для стандартных протоколов BLE для мышей и клавиатур - 1000 опросов в секунду.
Протокол WiFi вообще не имеет возможности realtime на уровнях в миллисекундах.
Любой другой современный MCU - ARM, RISK-V,...
На сегодня, по производительности и внутренней интеграции ESP является сам худшим и самым глючным (в основном из-за "впихнуть невпихуемое").
А для проектов использующих множественные интерфейсы и ограниченную RAM - MCU без MMU вообще не годится. Тем более в такой области - для незрячих. Должна быть надежность.
pvvx
Активный участник сообщества
WiFi микрофонов что- то не видать, а BLE есть. Проф. audio используют свои проприетарные протоколы.
Перед WiFi не стоит задачи связи с минимальными задержками. Там задача передача больших объемов и на каждой стадии-подуровне IP связи используется буферизация, стеки, для которой нет никаких возможностей у ESP. Из-за буферизации и распределения RF таймига в WiFi задержки скачут от сотен мкс до секунд.
Используйте данный чип по его назначению заложенном при разработке – ESP8266 это кристалл ESP8089 (без каких либо изменений на сегодняшний день) = устаревший SDIO-WiFi адаптер. Не имеет поддержки никаких “стеков” из-за малого RAM и низкой производительности. Всё делает система, а ESP8089 просто передает и принимает RF фреймы. А фрейм у WiFi 2 мал. И 8 кило достаточно для подержания приемного и передающего RF буфера. Программа обслуживания WiFi заливается по SDIO в IRAM… И это весь заложенный в ESP функционал.
Перед WiFi не стоит задачи связи с минимальными задержками. Там задача передача больших объемов и на каждой стадии-подуровне IP связи используется буферизация, стеки, для которой нет никаких возможностей у ESP. Из-за буферизации и распределения RF таймига в WiFi задержки скачут от сотен мкс до секунд.
Используйте данный чип по его назначению заложенном при разработке – ESP8266 это кристалл ESP8089 (без каких либо изменений на сегодняшний день) = устаревший SDIO-WiFi адаптер. Не имеет поддержки никаких “стеков” из-за малого RAM и низкой производительности. Всё делает система, а ESP8089 просто передает и принимает RF фреймы. А фрейм у WiFi 2 мал. И 8 кило достаточно для подержания приемного и передающего RF буфера. Программа обслуживания WiFi заливается по SDIO в IRAM… И это весь заложенный в ESP функционал.