[k155la3 26]

1. С чего начать (фундаментальное) изучение BLE (можно с Bluetooth).

Как-бы  "быстрый старт", но с фундаментальных основ, те без даташитов на пару тысяч страниц.

Прикладной критерий - интересует создание сети с радиусом до 100м с топологией "звезда". К-во абонентов 5-10.

"Сверхзадача" - уйти от проводного соединения.  Скорость передачи относительно RS485/UART ориентировочно, пусть будет 19200. Размер пакета 20 - 100 байт. Периодичность обмена "центра" с каждым "клиентом"  (их 5 - 10 шт) от 5 секунд до  минуты (задается/настраивается) 

Центр - контроллер с SPI. "Абоненты" - также контроллеры с SPI.

Интересует работа на максимально "низком" уровне ("сетевой-прикладной", если есть), UART/AT-команды не предлагать.

2. С какой аппаратной части (чип/модуль) имеет смысл начать "практику" ?

3. (предлагается "удаленка", надо определиться, возможно ли освоение в удобоваримые сроки "с нуля")

[makc 199]

1 час назад, k155la3 сказал:

1. С чего начать (фундаментальное) изучение BLE (можно с Bluetooth).

Как-бы  "быстрый старт", но с фундаментальных основ, те без даташитов на пару тысяч страниц.

Прикладной критерий - интересует создание сети с радиусом до 100м с топологией "звезда". К-во абонентов 5-10.

Что в центре звезды? На какой ОС, какая платформа и т.п.?

Для начала могу посоветовать почитать https://habr.com/ru/post/505078/, https://habr.com/ru/post/532298/, https://habr.com/ru/post/533580/ и https://habr.com/ru/post/538834/

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

1 час назад, k155la3 сказал:

"Сверхзадача" - уйти от проводного соединения. Скорость/трафик небольшие, 9600/раз в минуту/5 секунд

Не понял, что вы имели в виду при подобном описании скорости. Какая средняя скорость передачи и частота обмена?

1 час назад, k155la3 сказал:

2. С какой аппаратной части (чип/модуль) имеет смысл начать "практику" ?

У условиях дефицита могу предложить https://cnx-software.ru/2022/01/02/komplekt-dlya-razrabotki-xt-zb1-zigbee-ble-za-1-9-vklyuchaet-risc-v-modul-bl702/

Его основной плюс - небольшая цена и доступность на АлиЭкспрессе со сроком поставки около месяца, по крайней мере по моему личному опыту.

Вполне рабочий модуль, по опыту BLE работает стабильно, но, естественно, есть своя специфика по документации и SDK. Хотя на фоне других китайских контроллеров SDK у этого BL702 совсем не так плох, как мог бы быть. Но есть и свои нюансы: в частности, работа стека BLE намертво прибита к FreeRTOS и без FreeRTOS не живёт, т.к. обработка BLE оформлена в виде тасков FreeRTOS, существующих в виде статических библиотек. Открытой документации на HCI этого контроллера нет, реверсить всё это хозяйство совершенно бесполезное занятие.

1 час назад, k155la3 сказал:

3. (предлагается "удаленка", надо определиться, возможно ли освоение в удобоваримые сроки "с нуля")

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

[jcxz 197]

1 час назад, k155la3 сказал:

Центр - контроллер с SPI. "Абоненты" - также контроллеры с SPI.

Раз в центре - контроллер, а не ПК, то почему именно BT? А не ZigBee к примеру?

[k155la3 26]

15 минут назад, makc сказал:

(1) Что в центре звезды? На какой ОС, какая платформа и т.п.?

(2) . . . если не лезть в детали реализации BLE-стека. Но поскольку, как правило, он поставляется в виде статических библиотек, то шансов туда залезть практически нет, т.е. весь вопрос сводится к тому, чтобы понять, как его правильно готовить.

(3) Не понял, что вы имели в виду при подобном описании скорости. Какая средняя скорость передачи и частота обмена?

(4) . . .  Но есть и свои нюансы: в частности, работа стека BLE намертво прибита к FreeRTOS и без FreeRTOS не живёт, . . . 

 

Спасибо за инф.

(1) "Деталей" по реальной задаче у меня пока нет. Есть "общая постановка". В центре сети - STM32F103xxxx. За ОС информаци нет, в ближайшее время уточню (хотел сразу спросить у предполагаемого заказчика, но заболтались и не уточнил).

(2) Самоцели "нырять" глубоко в стек желания абсолютно нет. Наоборот, надежда на "попользоваться на всем готовом", в частности "повыше" по классификации OSI, чтобы не думать о пакетах, организации логической сети, изоляции рядом работающих сетей, распределении радиоканалов итд. Иначе проще использовать обычный трансивер.

Цитата

. . . . BLE-стека. Но поскольку, как правило, он поставляется в виде статических библиотек, . . . 

        (?) т.е. сам стек "живет" вне чипа приемопередатчика, нужен внешний контроллер с софтом стека ? 

(3) Скорость передачи относительно RS485/UART ориентировочно, пусть будет 19200. Размер пакета 20 - 100 байт. Периодичность обмена "центра" с каждым "клиентом"  (их 5 - 10 шт) от 5 секунд до  минуты (задается/настраивается) 

(4) FreeRTOS - Ok

 

[jcxz 197]

2 часа назад, k155la3 сказал:

2. С какой аппаратной части (чип/модуль) имеет смысл начать "практику" ?

Смотря какие требования к остальной части. Лучше наверное использовать МК со встроенным RF-модулем. Например - STM32WB55. Там BLE-стек крутится на отдельном ядре (CM3), а пользователю остаётся в неограниченное использование CM4-ядро.

[k155la3 26]

1 минуту назад, jcxz сказал:

Раз в центре - контроллер, а не ПК, то почему именно BT? А не ZigBee к примеру?

Исходная постановка - "на BLE". Другие варианты тоже рассматриваю, в том числе и ZigBee.

Первый позыв "порыв" использовать трансиверы, но он прошел, когда подумал как организовывать сеть, автоматический выбор/перебор каналов, защиту от соседних сетей итд. 

2 минуты назад, jcxz сказал:

Смотря какие требования к остальной части. Лучше наверное использовать МК со встроенным RF-модулем. Например - STM32WB55. Там BLE-стек крутится на отдельном ядре (CM3), а пользователю остаётся в неограниченное использование CM4-ядро.

Ok спасибо, надо "покурить" 

Пока инф. достаточно, смотрим-читаем. Курим.

 Спасибо.

[jcxz 197]

10 минут назад, k155la3 сказал:

Ok спасибо, надо "покурить" 

Похожие есть у TI: CC13x0, CC26x0. Там вроде тоже CM3 - для пользователя и CM0 - для стека. Но с ними не работал (в отличие от STM32WB55), только поверхностно просматривал.

ЗЫ: STM32WB55 будет однозначно поинтереснее "народного" F103.  

[makc 199]

40 минут назад, k155la3 сказал:

(1) "Деталей" по реальной задаче у меня пока нет. Есть "общая постановка". В центре сети - STM32F103xxxx. За ОС информаци нет, в ближайшее время уточню (хотел сразу спросить у предполагаемого заказчика, но заболтались и не уточнил).

Тогда непонятно, через что должен связываться с остальными узлами сети этот STM32F103xxxx.

40 минут назад, k155la3 сказал:

(?) т.е. сам стек "живет" вне чипа приемопередатчика, нужен внешний контроллер с софтом стека ? 

Нет, стек живёт внутри этого же контроллера вместе с прикладным софтом. Просто прикладной софт это одни задачи FreeRTOS, а стек BLE - другие.

40 минут назад, k155la3 сказал:

(3) Скорость передачи относительно RS485/UART ориентировочно, пусть будет 19200. Размер пакета 20 - 100 байт. Периодичность обмена "центра" с каждым "клиентом"  (их 5 - 10 шт) от 5 секунд до  минуты (задается/настраивается)

Пролезет спокойно без особых усилий.

36 минут назад, jcxz сказал:

Смотря какие требования к остальной части. Лучше наверное использовать МК со встроенным RF-модулем. Например - STM32WB55.

У упомянутого выше BL702 RF-модуль тоже встроен, но как мне кажется купить проще и дешевле именно его, а не какой либо продукт ST.

23 минуты назад, jcxz сказал:

Похожие есть у TI: CC13x0, CC26x0. Там вроде тоже CM3 - для пользователя и CM0 - для стека. Но с ними не работал (в отличие от STM32WB55), только поверхностно просматривал.

Ещё вопрос какой там интерфейс с CM0, на котором крутится BLE. Иногда делают работу через AT-команды, что совершенно неэффективно с моей точки зрения.

[jcxz 197]

2 часа назад, makc сказал:

Ещё вопрос какой там интерфейс с CM0, на котором крутится BLE. Иногда делают работу через AT-команды, что совершенно неэффективно с моей точки зрения.

Причём тут AT-команды? Это 2-ядерный МК, а значит взаимодействие думаю такое же, как и у всех многоядерных МК: через общую память и межъядерные прерывания. В WB55 точно так и есть. А у CC13xx/CC26xx имеется картинка в мануале:

И описание тоже говорит об этом.

Скорее всего - для M3-ядра (системного) есть некоторая оболочка (API) для вызова функций RF-ядра. Внутри это API использует разделяемую память + межъядерные прерывания. В мануале говорится о некоем "Radio doorbell module":

The radio doorbell module (RFC_DBELL) is the primary means of communication between the system
CPU and the radio CPU, also known as command and packet engine (CPE). The radio doorbell contains
a set of dedicated registers, parameters in any of the RAMs of the device, and a set of interrupts to both
the radio CPU and the system CPU.

Думаю - производитель должен предоставлять API, которое внутри взаимодействует через этот самый Doorbell модуль с ПО в RF-ядре (которое скорее всего предоставляется в виде бинарника). Естественно - никаких костылей в виде каких-то UART-ов с AT-командами здесь в принципе не нужно.

2 часа назад, makc сказал:

У упомянутого выше BL702 RF-модуль тоже встроен, но как мне кажется купить проще и дешевле именно его, а не какой либо продукт ST.

Из описания непонятно - там единственный CPU для пользовательского приложения и RF-части? Или два отдельных (как у WB55 и CC13xx/CC26xx)?

2-е будет на порядок лучше в плане удобства и возможностей для решения прикладных задач, чем одноядерный МК. Как бы хорошо ни было написана прошивка RF-части. А вот качество её написания - под большим вопросом (это же китайское изделие? тогда тем более). Это качество может вообще угробить работу прикладного пользовательского ПО.

[makc 199]

3 часа назад, jcxz сказал:

Причём тут AT-команды?

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

3 часа назад, jcxz сказал:

Из описания непонятно - там единственный CPU для пользовательского приложения и RF-части?

Из описания всё понятно - одно ядро RISC-V на 144 МГц с поддержкой float. Ядро Sifive E24, если быть точным.

3 часа назад, jcxz сказал:

2-е будет на порядок лучше в плане удобства и возможностей для решения прикладных задач, чем одноядерный МК.

Для прикладного разработчика с точки зрения API и логики работы это одно и тоже, поэтому не совсем понимаю в чём вы видите разницу на порядок и в каких попугаях считается эта разница. С точки зрения энергопотребления одно ядро может быть даже лучше, чем два, особенно с учётом того, что на работу CM0 со стеком BLE никак повлиять нельзя, т.к. там крутится прошивка от производителя без исходников (это гипотеза, а не утверждение).

[jcxz 197]

4 часа назад, makc сказал:

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

Связать 2 ядра внутри одного многоядерного МК с общей разделяемой памятью???   Вы такое где-то видели? Можете привести примеры такого "решения"?

4 часа назад, makc сказал:

Для прикладного разработчика с точки зрения API и логики работы это одно и тоже, поэтому не совсем понимаю в чём вы видите разницу на порядок и в каких попугаях считается эта разница.

А я не совсем понимаю - как Вы не видите разницы? между:

a) CPU полностью ваш, можете планировать работу своего ПО как вам угодно, как удобнее; всё время CPU ваше, полностью до такта, и нет отвлечений CPU на обслуживание неких задач с заранее неизвестной продолжительностью этих отвлечений, цикличности отвлечений и необходимой максимальной латентности для этого обслуживания.

б) вашей задаче приходится делить время CPU с некоей задачей (задачами), требующими периодически отвлечения CPU на выполнение своих функций (в ISR или задачах ОС) на заранее вам неизвестное и непрогнозируемое время.

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

Во 2-м случае ваша прикладная задача может оказаться несовместимой с работой RF-стека. И возможно вы даже не узнаете об этом до начала разработки.

Это уже не говоря о возможных багах в том, чужом ПО. Одно дело - если баги на отдельном ядре, и совсем другое - баги в общем ядре. Во 2-м случае вероятность нарушения вашего прикладного ПО из-за бага в RF-сервисе намного выше. А баги в чужом закрытом коде - вещь очень неприятная и весьма вероятная.

4 часа назад, makc сказал:

С точки зрения энергопотребления одно ядро может быть даже лучше, чем два, особенно с учётом того, что на работу CM0 со стеком BLE никак повлиять нельзя, т.к. там крутится прошивка от производителя без исходников (это гипотеза, а не утверждение).

В этом случае одноядерная работа тоже хуже: Если код на M0 написан так, что не кладёт ядро спать (или слишком долго держит ядро в run-режиме), то перенос такого кода на CM4 приведёт к увеличению потребления, так как ядро намного более сложное и стоимость (в амперах) длительности работы CM4 намного больше стоимости CM0.

Один из главных выигрышей многоядерных МК над одноядерными состоит как раз в том, что выполнение каких-то простых, но длительных задач можно положить на простое малопотребляющее ядро, а мощные тяжёлые ядра держать бОльшую часть времени во сне, пробуждая на короткое время только на требуемое время. Как раз такая идеология применена в линейке МК LPC43xx: там как раз 1 или 2 ядра M0 и одно M4. Именно с такой целью и сделано.

[makc 199]

1 час назад, jcxz сказал:

Связать 2 ядра внутри одного многоядерного МК???   Вы такое где-то видели? Можете привести примеры такого "решения"?

Например, вот здесь (AT32WB415).

Вообще я не вижу разницы, где находятся эти МК - на одном кристалле или на разных. С точки зрения изоляции функций это то же самое, что некий CM4 + дискретный BLE-модуль, но только на одном кристалле.
Понятное дело, что работа через UART не так эффективна, как через почтовый ящик на быстрой внутренней шине или разделяемую память.

1 час назад, jcxz сказал:

А я не совсем понимаю - как Вы не видите разницы? между:

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

Например, у Silabs EFR32MG21B Gecko тоже одно ядро, на котором крутится стек и приложение. И всё успешно работает. Зачем платить больше, если не видно разницы? (с)

1 час назад, jcxz сказал:

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

Любая задача может просто не влезть по каким-то другим причинам. Универсального решения нет.

1 час назад, jcxz сказал:

Во 2-м случае ваша прикладная задача может оказаться несовместимой с работой RF-стека. И возможно вы даже не узнаете об этом до начала разработки.

А может оказаться совместимой и тогда более дешевый/доступный вариант оказывается в выигрыше. Поэтому есть этап прототипирования на макетах (отладочных платах), есть расчёты сложности задач и т.п. способы инженерной оценки требований. Естественно всё это нужно учитывать при разработке. Повторюсь, что универсального решения нет и нельзя гарантировать, что решение из двух ядер CM4+CM0 будет всегда и везде "на порядок лучше".

1 час назад, jcxz сказал:

Один из главных выигрышей многоядерных МК над одноядерными состоит как раз в том, что выполнение каких-то простых, но длительных задач можно положить на простое малопотребляющее ядро, а мощные тяжёлые ядра держать бОльшую часть времени во сне, пробуждая на короткое время только на требуемое время. Как раз такая идеология применена в линейке МК LPC43xx: там как раз 1 или 2 ядра M0 и одно M4. Именно с такой целью и сделано.

Всё так, в теории. С концепцией big.LITTLE я знаком. А дальше начинаются частности и разогнанное ядро CM0 не уходящее в сон может внезапно оказаться более дорогим по потреблению, чем грамотно уходящее в сон ядро CM4.

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

[jcxz 197]

2 минуты назад, makc сказал:

Например, вот здесь (AT32WB415).

Ссылка некорректная - не открывается.

2 минуты назад, makc сказал:

В целом я говорю лишь о том, что если поставленная задача решается, то в чём проблема?

А если не решается? Есть уверенность, что она решается, если вы даже не знаете - что именно и сколько времени выполняется в закрытом проприетарном коде? А если на момент разработки она выполнялась, а потом вышло обновление проприетарного ПО - и перестала выполняться? что делать?

Пример одноядерной работы: ESP8266. Прикладное ПО и RF-стек - на одном ядре. И разработчики плюются от него - на форумах слышал, что в некоторых случаях эта проприетарная часть может вдруг задуматься где-то в недрах стека на время до ~100 мсек! И "задуматься" с запрещёнными прерываниями!   

А ваше ПО в это время пыталось двигателем рулить в реалтайме....  

 

2 минуты назад, makc сказал:

Любая задача может просто не влезть по каким-то другим причинам. Универсального решения нет.

Если задача влазит на отдельный МК, то значит она влезет и на отдельное ядро многоядерного МК.

2 минуты назад, makc сказал:

и нельзя гарантировать, что решение из двух ядер CM4+CM0 будет всегда и везде "на порядок лучше".

Я в своей практике слишком часто наступал на грабли в проприетарном закрытом ПО. Из-за которых получали много проблем. Некоторые из этих проблем тянулись годами. И так и не решались. Один проект из-за таких багов у нас вообще закрылся. ~Полгода работы коллектива разработчиков - коту под хвост! Всё пришлось начинать заново на новой платформе.  Из-за того, что производитель проприетарного кода не спешил исправлять баги, а мы не могли ждать годами исправления бага.

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

 

2 минуты назад, makc сказал:

Предлагаю прекратить сравнивать подобные абстракции,

Это не абстракции, а предыдущий печальный опыт. Примеры я привёл выше.

[makc 199]

20 минут назад, jcxz сказал:

Ссылка некорректная - не открывается.

Исправил. На всякий случай ещё раз - https://www.arterychip.com/en/product/AT32WB415.jsp

21 минуту назад, jcxz сказал:

А если не решается? Есть уверенность, что она решается, если вы даже не знаете - что именно и сколько времени выполняется в закрытом проприетарном коде? А если на момент разработки она выполнялась, а потом вышло обновление проприетарного ПО - и перестала выполняться? что делать?

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

22 минуты назад, jcxz сказал:

А ваше ПО в это время пыталось двигателем рулить в реалтайме....  

... продолжим фантазировать ... двигатель-то гиперзвуковой. ;-)

23 минуты назад, jcxz сказал:

Если задача влазит на отдельный МК, то значит она влезет и на отдельное ядро многоядерного МК.

Если она работает на 144 МГц, то не факт что она взлетит на 80 МГц (вычислительная задача). Есть много разных ограничений по времени, периферии, доступности каналов DMA, латентности прерываний и т.п. Вы сами это прекрасно знаете. :-)

25 минут назад, jcxz сказал:

Я в своей практике слишком часто наступал на грабли в проприетарном закрытом ПО. Из-за которых получали много проблем. Некоторые из этих проблем тянулись годами. И так и не решались. Один проект из-за таких багов у нас вообще закрылся. ~Полгода работы коллектива разработчиков - коту под хвост! Всё пришлось начинать заново на новой платформе.  Из-за того, что производитель проприетарного кода не спешил исправлять баги, а мы не могли ждать годами исправления бага.

Соболезную, мне тоже хватало проблем как в открытом коде, так и в проприетарном. Самая большая беда заключается в том, что BLE HCI почти у всех этих контроллеров по сути черный ящик, соответственно какой бы мы не выбрали, всё равно попадаем в зависимость от производителя и его воли/возможности исправлять недоработки в стеке BLE. Так что хрен редьки не слаще.

27 минут назад, jcxz сказал:

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

Обжигались и не раз. Но это не значит, что больше и пытаться не стоит. ;-)

27 минут назад, jcxz сказал:

Это не абстракции, а предыдущий печальный опыт. Примеры я привёл выше.

Ок. Но тогда вопрос: у каких контроллеров BLE-стек открыт и доступен для модификации с точки зрения наличия полного описания логики работы HCI и RF-части?

[jcxz 197]

30 минут назад, makc сказал:

Исправил. На всякий случай ещё раз - https://www.arterychip.com/en/product/AT32WB415.jsp

А где там говорится о:

6 часов назад, makc сказал:

связать два ядра с помощью копеечных UARTов

? Судя по описанию - там вообще единственное ядро. Или я чего-то не заметил? Ткните носом, плиз.

13 минут назад, makc сказал:

С тем же успехом проблемы могут возникнуть и в закрытом проприетарном коде, который крутится на выделенном ядре CM0. Разве нет?

Да, могут. Но вероятность того, что это нарушит работу вашего прикладного ПО - на порядок ниже. (тот самый порядок, о котором писал выше)

13 минут назад, makc сказал:

Соболезную, мне тоже хватало проблем как в открытом коде, так и в проприетарном. Самая большая беда заключается в том, что BLE HCI почти у всех этих контроллеров по сути черный ящик, соответственно какой бы мы не выбрали, всё равно попадаем в зависимость от производителя и его воли/возможности исправлять недоработки в стеке BLE. Так что хрен редьки не слаще.

Не всё равно. Выше приводил пример - длительный запрет прерываний в ESP8266. Если бы этот код выполнялся на отдельном ядре, то вашему коду это фиолетово. Аналогичное поведение внутри единственного ядра скорей всего поставит крест на прикладной реалтайм задаче.

Я не говорил, что отдельное ядро решает все проблемы. Я говорил, что оно уменьшает их многократно. Может даже на порядки.

13 минут назад, makc сказал:

Ок. Но тогда вопрос: у каких контроллеров BLE-стек открыт и доступен для модификации с точки зрения наличия полного описания логики работы HCI и RF-части?

Не знаю таких.