Как стать автором
Обновить

next.module: публичное обсуждение и рекомендации автору

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров3.4K
Всего голосов 17: ↑15 и ↓2+19
Комментарии65

Комментарии 65

И здесь каждый миллиметр играет роль: 44х44 лучше чем 42х42, 46х46 лучше чем 44х44, 48х48 лучше чем 46х46 и т. д. Оптимальным размером будет скорее всего что-то вроде 48х48, 50х50 или 52х52.

смею предположить что размер заточен под заказ плат на JLCPCB. Там платы меньше чем 50х50 то ли только за доставку оплата, толи за копейки.

Трудно сказать чем обусловлен выбор автором такого размера, но он явно мал. Свершенно непонятно зачем делать модули такими маленькими и что мешает сделать их чуть больше по площади.

Да не трудно, размер минимизирован настолько чтобы на него помещались модули M.2 https://www.sparkfun.com/search/results?term=m.2

И все притензии по поводу ESP32S3 по ходу мимо.
Там большое разнообразие микроконтроллеров со своими экосистемами.
По сути next.module - это хардварная оболочка вокруг M.2
Вполне нормальный бизнес. Вокруг Arduino и Pi возникло много оболочек и неплохо живут.

Вот только модульность добавляет головной боли с логистикой. Думаю больше десятка плат в проекте не появится, да и то не все будут доступны. В этом плане придется делать как Flipper, предлагая шаблоны для сторонних плат.

Если это система прототипирования, то на модулях придётся размещать много чего, кроме М.2 и площадь платы должна быть достаточна для этого.

M5Stack не зря выбрала формат 5х5.

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

M5Stack, полагаю, был выбран из анализа размеров аккумуляторов и дисплеев на тот момент. И у них обособленная экосистема. Я бы не брал с них пример.
Завтра аккумуляторы, модули и дисплеи станут меньше и они сами пожалеют о выбранных габаритах.

Аккумуляторы - да, но дисплеи?! :)

Дисплеи уже сейчас приходится рассматривать через лупу. Я однозначно предпочту 5- сантиметровый дисплей 3-сантиметровому.

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

Аккумуляторы - да

касательно next.module - действительно не просто будет подобрать аккумулятор в таких габаритах и достаточно емкий (хотя бы на час работы стойки)

Ну конечно, - это же очевидно.

Возможно автор и не планирует дисплей.
У него для дисплея даже нет подходящего интерфейса.
Скорее всего планирует управлять со смартфона через браузер.
Это ж всё упирается в сценарии использования. Хотя без дисплея их станет сильно меньше.

Планирует (см. мой коммент выше).

Но интерфейса то нет! Значит не планирует.

А то сразу бы озаботился вместо Ethernet контроллера поставить тачскин контроллер или клавиатурный контроллер.

Он то ли в ролике, то ли в Телеграме говорит, что собирается размещать микро-дисплеи между модулями.

Если он думает вывести пару линий из M.2,

https://cdn.sparkfun.com/assets/learn_tutorials/1/2/0/6/SparkFun_MicroMod_Interface_v1.0_-_Pinout.pdf

то конечно микродисплей типа такого по I2C подключит без проблем.

Но как он из этого сделает открытый фреймворк для разработчиков будет интересно.
Конструкторы - нереально сложная вещь в плане программного фреймворка, да еще на ограниченных ресурсах памяти. Придется делать невероятно абстрактный и запутанный слой. Достаточно посмотреть на HAL известных производителей.

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

Дисплей на I2C выносится в любое место и на любое расстояние на раз-два. Например дисплей моего ПЛК выносят на два метра. А он работает между тем по SPI на 20 МГц!

И я о том же - нечего ему делать сбоку между плат.

Посмотрел ссылку - круто - как это я раньше пропустил эту статью?..

Есть очень разные места установки дисплеев. Например в одном нашем агрегате есть четыре дисплея, они не выведены наружу. Они внутри, их не видит юзер. Они только лишь для обслуживающего персонала, чтобы быстрее диагносцировать проблемы. Дисплеи настолько дешевы, что их дешевле ставить чем светодиоды. Но при этом они гораздо информативней.

Насколько там мелкий шрифт имеет мало значения. Гораздо важнее поместить максимум информации. Поэтому шрифт выбирается самый мелкий. Кому надо может посмотреть через камеру мобильника, он увеличит изображение.

Да, конечно. Я собираюсь рассматривать все возможные варианты.
Микродисплей сбоку это, безусловно, не основной вариант, но почему собственно нет?

Компактному конструктиву - компактные дисплеи.
Дисплеи планируются небольшие. OLED, IPS и монохромные. С SPI или I2C интерфейсом.
Для больших экранов можно разработать отдельный модуль с RGB-интерфейсом, но я сомневаюсь, что это будет востребовано.

Для прототипирования можно использовать самую простую и дешевую макетку. Не обязательно 42х42 мм, можно 85х85 или любую другую. В нее модули next.module вставляются без проблем

Есть 2 варианта модулей CPU на старте:
- ESP32S3 - основной вариант, мощный и недорогой.
- MicroMod с M.2 - был добавлен по просьбам трудящихся, позволяет выбрать из 10 разных платформ.

Помимо этого возможно появление (в том числе силами сообщества) модулей CPU с любыми другими процессорами от древних и дешевых МК до систем на чипе на linux. Лишь бы они обеспечивали работу межмодульного интерфейса и успешно компоновались в модуль (не обязательно 1х1)

Про выбор размера плат расписал в отдельном комментарии ниже

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

в ведении, еще до ката хотелось бы в 2 словах понять что это такое и зачем

Там до ката ссылка на оригинальную статью автора, где он подробно рассказывает о проекте.

Наоборот, на платах должен быть ключ, однозначно определяющий правильную её установку.

В идеале не только ключ, но и "заглушить" один контакт и вынуть ножку с ответной части. Да, меньше питания или gpio, но за то надежность и защита.

Автор в своих материалах упоминает  ... но при этом не упоминает Arduino.

как раз готовлю материал на схожую тему. Действительно, упускается большой рынок. Помимо этого можно просто сделать условный переходник с nano на next.module или просто avr контроллер на такую же плату. Так что не факт что потерял, может это еще в планах:)

каждый миллиметр играет роль: 44х44 лучше чем 42х42

если толщина платы 2мм, а стойка 10 мм, то самый интересный размер стороны будет 48мм - тогда сложив 4 платы будет куб


Я автор проекта next.module. Хочу сразу сказать спасибо за публикацию. Это сигнал для меня, что я недостаточно понятно рассказываю о проекте, так что буду навёрстывать.

Если это система прототипирования, наподобие Arduino — это одно, если это модульная система для создания устройств в корпусе — это второе, если эта система предполагает практическое применение для реальной автоматизации — это третье.

Это всё вместе. И конструктор для настольного прототипирования (с этого всё начиналось), и платформа для сборки устройств в корпусе, и система для реальной автоматизации.

Модули жестко крепятся друг к другу стойками, а межмодульные разъёмы достаточно надёжны. Это даёт мне надежду на надежную работу всего в целом, даже если вы собрали из модулей систему автоматизации для более-менее ответственной задачи. Все разъёмы, элементы управления и индикации расположены так, чтобы их легко было вывести из корпуса, они выглядели эстетично и были удобны. Корпус предполагается печатаемый на 3D-принтере, я предложу решения и проекты корпуса когда они будут готовы, пока до этого далеко. Для автоматизации уже представлен ряд модулей с промышленными интерфейсами и входами-выходами, распространенными в автоматизации. Так что да, для реальной автоматизации next.module тоже подойдет.

next.module не идеально подходит для всего этого, он лишь балансирует между возможностями и ограничениями чтобы подойти для как можно более широкого круга задач.

Если это продукт для профессионалов, способных работать в ESP32 SDK — это одно, если это продукт для массового рынка (а-ля Arduino) — это совсем другое.

Электрически next.module - это микроконтроллер и набор микросхем, с которыми МК взаимодействует. Программировать МК можно на чём угодно. Кто хочет - в Arduino IDE, кто хочет на bare metal. Тут конструктив не накладывает ограничений, а все принципиальные схемы модулей открыты.

Но, от меня для модуля CPU ESP32S3 точно будет разработан SDK на базе ESP-IDF с простым API доступа к ресурсам всех модулей. С синхронными и асинхронными способами обращения к модулям. С возможностью сконфигурировать девайс человекочитаемой конфигурацией. Он будет доступен в исходниках.

Наличие этого SDK вовсе не отрицает возможных альтернатив, включая Arduino. Более того, планируется адаптация прошивки IoT Manager под next.module, который сам по себе разработан в Arduino IDE.


Я просто не анонсирую и не обсуждаю варианты, которые пока не существуют и за разработку которых я сам на сегодня не берусь. Впрочем это тоже может измениться. Мы сейчас обсуждаем проект на стадии прототипа

Отлично, я только высказал свои соображения со стороны, надеюсь они чем-то помогут. А так - ждём модули в продаже (и желательно по гуманной цене :)

скажите - а в чем великое отличие ESP32S3 от ESP32 ?
Или там просто "чуть лучше характеристики" ?

(я - профан в микроконтролллерах, поэтому непонятно изза чего спор %) )

  • Внутрисхемная отладка и прошивка без необходимости использования отладчика или специального адаптера. Нужен только USB-кабель

  • Более быстрые ядра

  • Более быстрый интерфейс с ОЗУ

  • Наличие RGB-интерфейса

Поддерживаю выбор ESP32S3, однако, ядра там не быстрее. Зато там 500 кб ОЗУ можно почти как угодно сегментировать (компилятор не ругнется, что данные в сегмент не влезают), т.к. оно на железном уровне не поделено, как у ESP32. И PSRAM быстрее, и адресуется больше. Опять же, USB OTG имеется, хоть и недопиленный до сих пор.

По поводу Arduino vs ESP-IDF не вижу больших противоречий, можно любое использовать. Но для массовости и доходчивости, конечно Arduino нужно приводить в качестве базы. Особо продвинутые про IDF всё и так поймут.

Ядра XTensa LX7 быстрее, чем LX6 примерно на 20% на тех же тактовых частотах.
Из 512 Кб SRAM доступно около 320 Кб

Сорри, не собирался спорить, уточнял на основе эмпирических данных. Просто, я ждал эти 20%, но не смог их увидеть, по крайней мере, в вычислениях (собственно, где и ждешь прироста). Всё копейка-в-копейку как на ESP32. Тут у товарищей такие же наблюдения https://www.esp32.com/viewtopic.php?t=800&start=20 . Ну, да ладно, может, это еще какие-то сырые библиотеки, кривые руки и т.п. Не хуже ведь... А с памятью - я не про 320, а про то, что гибче стало с data, bss, IRAM, DRAM.

Я конечно извиняюсь, но какие 20% вы тут обсуждаете? Для каких таких задач вам не хватает мощности ESP32?

Нам для всех хватает, но помериться CoreMark'ами всё равно интересно

По поводу ESP32 я бы больше переживал не о мощности MCU, а о том, что это колосс на глиняных ногах с десятком рахитичных GPIO.

Что не так с GPIO ESP32S3?

Не с самими GPIO, а с их количеством. После Mega с её 84 DI/DO и 16 AI на это недоразумение ESP32 даже смотреть не хочется.

О чём вообще эти "инженеры" думали, когда снабжали ESP32 десятком GPIO (вместо сотни)?

Я для синтеза звука использую, а что, i2s имеется ))) Да, вот так. Но Teensy дороже раз в 5. И потом, это просто мое хобби. И ESP32 мне нравятся, не скрываю.

Да понятно. По скорости я опирался на оценку производительности от самих Espressif в CoreMark. Можете найти их на 3 странице даташитов на ESP32 и ESP32S3

smart_alex предложил контакт в шине для 12В. А если ещё больше абстрагироваться, то в шине нужен "определяемый пользователем" контакт. Который не завязан ни на какие gpio основного процессорного модуля и не используется по-умолчанию и который может быть использован как для сквозной передачи 12В от модуля который это напряжение создает, так и для любого напряжения/сигнала.

Мне ещё на ум приходит пин Vref :)

Отсюда вывод: если уж использовать 1х формат компоновки модулей, то это должно быть соединение максимум 3-4 модулей и никак не больше.

Верно, так и есть

Отсюда же и второй вывод: для всей системы базовыми должны быть горизонтальные компоновки 2х, 4х, 6х и так далее.

Так и есть, во многих случаях большие горизонтальные компоновки будут выгоднее. Модули вплоть до 3x3, 3x2, 4x1, 4x2 уже разработаны. Просто они не попали в первую партию прототипов, поэтому в видео о них ни слова.

На мой взгляд, в размерах плат экосистемы next.module 42х42 мм заложена бомба замедленного действия, которая уже сейчас является тормозом для развития и успешности проекта и грозит похоронить его в будущем.

42х42 это критически мало. Если посмотреть презентационное видео, то на нём хорошо видно, что автор (задумчиво) крутит на экране рендеры модулей и через раз говорит, что тут не уместилось то, а тут не уместилось это и так далее чуть ли не по каждому модулю.

На самом деле нет никакого идеального размера для модулей. Какой размер ни выбери - всегда что-нибудь не поместится. А если выберешь очень крупный формат, то будут полупустые платы модулей и громоздкий девайс в результате.
Я много экспериментировал с форматами модулей от 40х40 до 50х50 и эмпирически выбрал 42х42 мм. На сегодня я считаю его идеальным балансом, хотя руки чешутся сделать чуть компактнее.
В видео я всегда рассказываю про технические нюансы и сложности, видео с презентацией - не исключение. При любом другом формате модулей нюансы и сложности тоже были бы, но уже другие.

У меня только один вопрос остался: а в чём смысл миниатюризации? Почему хочется сделать ещё компактнее?

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

Смысл миниатюризации в удобстве пользования и эстетике

Поэтому, мой добрый совет: никаких «переворотов платы на 180 градусов»

next.module широко использует боковые поверхности девайса для вывода разъёмов, индикаторов и кнопок. Представьте, что модули нельзя поворачивать. То есть модуль с разъёмом на боку будет всегда располагать свой разъём только с одной стороны девайса и никак иначе. Все девайсы будут иметь разъёмы с одной стороны) Либо придётся делать разные платы чтобы вывести разъём в ту или иную сторону. Все эти варианты плохие. Либо распишите вашу концепцию, возможно я не понял.

и никаких «маркировка и назначение GPIO совпадают только если вы правильно вставили модуль», даже если это несколько ограничит функционал

Маркировка пинов есть только на плате модуля DBG LED, на котором есть LED-индикаторы, которые хочется подписать. Его всегда без проблем можно повернуть, ориентируясь на стрелочки. На других модулях нет маркировки и нужно только обратить внимание на 1-3 перемычки снизу, ориентируясь на подсказки стрелками.

Наоборот, на платах должен быть ключ, однозначно определяющий правильную её установку.

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

Это всё понятно, у меня встречный вопрос: на какую аудиторию рассчитан проект и какое количество пользователей предполагается охватить?

Возможности - это обратная сторона сложности. Вы уверены, что массовый пользователь обладает таким уровнем абстрактного мышления, чтобы пересчитывать номера GPIO по таблицам и вообще думать в такой плоскости?

Это хороший вопрос
Да, next.module в текущем его виде целится в более узкую и более продвинутую аудиторию, чем arduino, m5stack и многие другие.
На тех, кому распределить пины и распределить модули по шинам оптимальным образом - по приколу и в кайф.

Я уже года два имею дело с проектом и архитектурой Lavritech, которая ушла на этом пути гораздо дальше next.module - у вас 2, а там до 6-7 слоёв хардверной абстракции.

В этом нет ничего плохого, кроме того, что чем сложнее архитектура - тем меньше пользователей (со всеми вытекающими для проекта).

Бесспорно

нужны либо «толстые квадратные» пины, либо покрытие их чем-то вроде золотого напыления, обеспечивающее надёжный контакт.

Пины уже квадратные и с покрытием. Впрочем, и их тоже нужно еще тестить на надежность

Что и как выводить — вопрос дискуссионный, как минимум, набор разных напряжений, земля, I2C, SPI, GPIO/UART, возможно отдельный разъём для RS485.

Можете объяснить, зачем нужно выводить эти шины наружу? Я не понял идею

Тут зависит от концепции вашей системы. Нет документа, который чётко формализует что же вы делаете.

В данном случае предполагалось, что есть внутренние модули, есть корпус, на корпусе есть внешние разъёмы для подключения внешних блоков расширения.

Это то, что у Wiren Board и Lavritech называется WBIO.

Ааа, нее. Концепция такая:
Всё, что на межмодульном интерфейсе - всё остаётся внутри корпуса устройства. Модули могут выводить разъёмы наружу - GPIO, дискретные и аналоговые входы и выходы, интерфейсы. Все выводимые наружу сигналы имеют минимально необходимые защиты (от статики, перегрузки и т.п.)

Если немного увеличить площадь платы, как было описано выше, то можно либо добавить пины 12 В в разъёмы (возможно не по одному, а по 2-3-4 пина) или дополнительно установить какие-то детали, например кнопки, на боковую поверхность модуля.

Если посмотрите на подсистему питания и на реализацию, например, транзисторных выходов, то обнаружите, что в next.module создательно сделано так, чтобы все потенциально мощные потребители не нагружали питание девайса. Потому что если их питать от девайса, то это решение тяжело масштабировать и тяжело объяснить пользователю почему питание проседает и как это исправить. Ведь транзисторных выходов может быть 8, а может быть 256 и нагрузки пользователь подключит к ним разнообразные.

Почему кстати именно 12В по вашему необходимы? Почему не 24В или любое другое напряжение?

Насколько я понял, вы собираетесь подводить дополнительные напряжения при помощи шлейфов. Почему бы хотя бы часть из них не подвести через пины?

12 - это не догма, просто один из возможных и востребованных вариантов.

Смотрите какая концепция.

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

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

Мощность этого отдельного блока питания и выходное напряжение выбирается исходя из требований потребителя. Если есть группа реле на 24В, то ставим блок питания на 24В с соответствующей мощностью.

Посмотрите на типовые схемы подключения к DI и DO. В них блок питания, питающий датчики и реле - внешний по отношению к девайсу.

Понятно.

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

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

Однако и тут опять выбран самый дорогой путь.

В промышленных устройствах делают так:

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

Диод в схеме управления реле не лучший вариант. Он замедляет отключение реле в 10 раз.

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

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

Про "уровни отвественности" - какой-то непонятное определение. Если дивайс планируется для реально ответственных применений, то там вот такие делают схемы. В вашей архитектуре об ответственности явно думалось меньше всего.

Когда бывают разные напряжения питания, то сразу специфицируют верхнюю границу, делают аналоговые входы с делителями и работают во всем диапазоне.

Про удобство ремонта тоже не понял логику. Какое это удобство если надо заниматься двумя источниками вместо одного.

Вы там не нарастите так количестов выходов что прям понадобится более мощный источник для управления оптосемисторами или реле. Поставили источник на пару ампер и хватит за глаза для такой системы. Один пин на ваших разъемах специфицирован на 3 ампера.

"Грязное" питание по полной программе вы получите когда подключите два источника питания (особенно если они на разных фазах сидят) с двух концов этой этажерки. Даже оптроны не спасут от FTB помех. Кстати, не забывайте ставить резисторы и в подключенных к земле ногах оптронов.

Все же такая многоплатная архитектура вызывает вопросы по цене владения.
Тут дорого все.
- Небольшая модификация межмодульной шины приведет к необходимости переделки всех плат. Либо дизайн быстро морально устареет. Уже сейчас восходит I3C и другие перспективные интерфейсы.
- Узкая межмодульная шина удорожает дизайн из-за допролнительных микросхем расширителей IO
- Такое количество плат обойдется дороже чем одна или две.
- Печать уникального корпуса тоже дорого.
- Собирать и разбирать такую сборку - трудоёмко.
- Отлаживать осциллографом тоже нереально трудоемко. До промежуточных плат просто не добраться.

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

И только одинокий ESP32 как бы намекает, что по задумке наверно хотели сделать бюджетно.

Думаю если бы был конкурс на худшую архитектуру, то эта бы победила.

Захотелось провести конкурс на худшую архитектуру

Зарегистрируйтесь на Хабре, чтобы оставить комментарий