BlueZ 5.15

Может я дуб, но в вынях за пару сек настроил звук с мобилой с компа и наоборот.
С сабжем даже не знаю с кокой стороны подойти. И можно ли. Файлы слать да. Мышкой по экрану елозить. Но это же фигня.
Даже просто тупо включаю в кде - виден всем. Запомнить никак. Страшное такое секюрети.

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

блютуз пора уже выкинуть и забыть

Не, нужна вещь

блютуз пора уже выкинуть и забыть

И чем заменить предлагаете?

блютуз пора уже выкинуть и забыть

ололо. и по какому каналу ты предлагаешь гарнитуру подключать? wifi?

irda, очевидно

ололо. и по какому каналу ты предлагаешь гарнитуру подключать? wifi?

А почему бы и нет? Я как бы не в курсе.

все дело в мощности

Мышки с wi-fi уже есть.

блютуз пора уже выкинуть и забыть

Сделаем, как только покажите, на чем ещё беспроводное устройство может работать годами от одной литиевой батарейки CR2032 :)

Блюпуп ещё жив?

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

ZigBee?

Мышки с wi-fi уже есть.

ты так говоришь, как будто это хорошо...

ZigBee, nrf24l01+ (поголовно стоят во всех беспроводных мышах), СС101 от Ti и тому подобные, тысячи их!

что поломали?

Принимаю возражение. Однако:

ZigBee

вечные проблемы с лицензированием, многочисленные конфликты между альянсом ZigBee и разработчиками свободного ПО. Диагноз: не нужно.

nrf24l01+

Т.к. это обычный трансивер, а не SoC, то отсутствует стандартизированный высокоуровневый протокол. Каждый производитель лепит свой. При желании можно даже под тот же Bluetooth LE закосить. Диагноз: для проприетарных продуктов сойдет, но в эпоху Internet of things закрытые протоколы должны сгинуть.

СС101 от Ti

в линейке чипов СС (бывший Chipcon, теперь TI) либо трансиверы и проблема с ними описана выше, либо SoC с полностью закрытым стеком, для написания софта под который нужны компиляторы IAR (стоимостью не одну тысячу долларов). Лично я не против закрытых стеков (хотя и не одобряю их). Но завязывание на дорогие и, откровенно говоря, не самые лучшие инструменты — спасибо, не нужно.

лучше бы сделали реализацию HID, т.е. чтобы софт через bluez мог имитировать hid устройство. старые sony ericsson умели работать как клавиатура/мышь, а на новых телефонах такую функцию не встретишь.

Мышки с wi-fi уже есть.

Гигабитный канал на мышку или лох

Мышки с wi-fi уже есть.

небось в неё можно заодно и Torrent-клиента установить :-)

канонический

а православный?

И чем заменить предлагаете?

Чем-нибудь подальше от 2.4GHz.

В пятой версии наконец отрос cli. Используем bluetoothctl

Кто в курсе, объясните пожалуйста почему Bluetooth HID устройства так малочисленны и дороги. Мне нужны просто надёжная мышь и просто приличная полноразмерная (хотя бы более-менее) клавиатура. Мышь ладно, худо-бедно найдётся. А по клавам нахожу либо мультимедийное мини-нечто, либо навороченное нечто задорого.

Мне нужны просто надёжная мышь и просто приличная полноразмерная (хотя бы более-менее) клавиатура.

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

это канонический стек

И кто канонизировал сего святого?

Я так понял, что разрабы блюза зашевелились, по тому что это ядро 3.13 доковыряли, и сие поделие будет корректно фунциклировать с 3.13 и выше.

Про улучшалки 3.13 известно что:

В Bluetooth-стеке реализована возможность создания виртуальных AMP-контроллеров, поддержка установки режима DUT (Device Under Test), добавлена команда mgmt_set_bredr для включения и отключения функций BR/EDR, добавлена команда для установки статического адреса для контроллеров, поддерживающих режимы BR/EDR и LE, добавлена поддержка нового HCI-сокета для управления определённым HCI-устройством из пользовательского приложения.

Это понятно, продавать понты задорого заманчиво. Не понятно почему в сегменте Bluetooth HID устройств так мало этих самых устройств. Было бы их чутка по-боле, были бы ассортимент и более-менее здоровая конкуренция, которая таки родила бы приличные устройства. Но предлагают единичные модели. Bluetooth микруха так сложна или так огорожена патентами, что стоит сотни нефти?

Кто в курсе, объясните пожалуйста почему Bluetooth HID устройства так малочисленны и дороги.

При всей универсальности, малоподходящий для этого дела протокол.

Те-же логитековские клавиатуры со своими ресиверами работают годами (до 3-х лет), от одного комплекта батареек. По Bluetooth - неделю максимум.

Пусть не выкинуть и забыть. Но в сабже он все равно кривой.

вечные проблемы с лицензированием, многочисленные конфликты между альянсом ZigBee и разработчиками свободного ПО. Диагноз: не нужно.

А уж какие проблемы с USB IF... Давайте USB тоже выкинем.

Т.к. это обычный трансивер, а не SoC, то отсутствует стандартизированный высокоуровневый протокол. Каждый производитель лепит свой.

Извини, я тебя расстрою. Сильно высокоуровневый протокол будет жрать много батареи, так как by design избыточен для большинства задач.

При желании можно даже под тот же Bluetooth LE закосить. Диагноз: для проприетарных продуктов сойдет.

Для OpenHardware оно очень популярно, тем более что их «проприетарный» протокол состоит чуть более, чем полностью из MAC адреса, CRC16, данных и ACK'ов. Там закрывать нечего, это и так всем ясно.

но в эпоху Internet of things закрытые протоколы должны сгинуть.

Хочешь интернет - делай как я: nrfки звездой в конфигурации multiceiver и роутер с донглом, который на wifi подсеть выдает web-API, чтобы дергать всем этим хозяйством.

Т.к. это обычный трансивер, а не SoC, то отсутствует стандартизированный высокоуровневый протокол

Хочешь микроконтроллер - бери msp430 RF серию и пихай какой хочешь протокол туда. RF варианты есть и у AVR, и у других вендоров.

для написания софта под который нужны компиляторы IAR (стоимостью не одну тысячу долларов)

facepalm. Ты с продукцией Ti работал? У них даже под их Simpliciti который в часах Chronos есть блобики с которыми нормально линкует msp430-gcc см. OpenChronos. Так что для написания софта даже с проприетарными блобами гогно-IAR не нужен. Ну и описание регистров камня есть, так что Simpliciti выпилить не проблема.

А уж какие проблемы с USB IF

А какие проблемы у разработчиков свободного ПО с USB IF?

http://www.opennet.ru/opennews/art.shtml?num=38238

А, ну про это я слышал. Но тут проблемы железячные и к линуху не относятся, в отличии от zigbee.

facepalm. Ты с продукцией Ti работал?

Да, я работал с продукцией Ti. Конкретно — с CC2540, т.к. меня интересовало сверхнизкое потребление, низкая стоимость (по этим причинам дополнительный контроллер для HCI лепить не хотелось) и совместимость с мобильными устройствами (отсюда BLE, а не ZigBee и прочее). Если интересно, почему мне не подошёл Simpliciti и к чему я упомянул IAR, читаем драму.

Извини, я тебя расстрою. Сильно высокоуровневый протокол будет жрать много батареи, так как by design избыточен для большинства задач.

Я не расстраиваюсь, т.к. есть решения от Bluegiga. Они умудрились интерпретатор скриптового языка засунуть на техасовский SoC, чтоб обойти привязку к IAR :) И ничего, работает, много кушать не просит. CSR вообще какие-то виртуальные изолированные окружения гоняет на своих чипах, чтоб BT-стек огородить от пользовательских приложений, а минимальные примеры прошивок у них по 2к строк на С. И тоже годами работают от литиевых батареек.

<накипело>Я, конечно, не одобряю всю эту лабуду и излишнуюю абстракцию там, где и без неё бы всё работало, но таков рынок. Всем нужен минимальный time-to-market, отсюда и скриптовые языки и виртуалки на микроконтроллерах. Докатились...</накипело>

Что касается программной части, так в блутусе (хоть в старом, хоть в LE) есть развитая система профилей GATT на все случаи жизни (device info, heart rate sensor, proximity, battery, thermometer...), благодаря которым достигается высокая степень совместимости между устройствами и приложениями. Если это не высокоуровневые протоколы, то что тогда? И жрут они действительно немного, как бы странно это не выглядело на первый взгляд.

Для OpenHardware оно очень популярно, тем более что их «проприетарный» протокол состоит чуть более, чем полностью из MAC адреса, CRC16, данных и ACK'ов. Там закрывать нечего, это и так всем ясно.

Не поверишь, но BLE тоже состоит только из преамбулы, 32-битного адреса, десятка байт данных и 24-битного CRC. Т.е. тоже особо закрывать нечего. И тем не менее, в потребительских устройствах почему-то зигби не найти, какой бы «опенсорсный» он не был (хотя о чём это я говорю... Когда это опенсорсность, мнимая или реальная, была критерием широкого распространения технологий? :)). Везде либо BLE, либо NFC (но это немного не в ту степь).

читаем драму.

Ну с 8051 все ясно. Из Tiшного хлама я только в сторону того, что с msp430 смотрю. SDCC к сожалению насколько помню даже C99 не полностью поддерживает. Так что ничего удивительного, что блобики чужие не может проглотить. Хотя меня больше в SDCC бесит, что он трактует весь файл, как один элемент линковки, и положить функцию в отдельную секцию, или подчистить потом неиспользованные ф-ции нельзя, что для мк с небольшим количеством флеша критично.

CSR вообще какие-то виртуальные изолированные окружения гоняет на своих чипах, чтоб BT-стек огородить от пользовательских приложений, а минимальные примеры прошивок у них по 2к строк на С. И тоже годами работают от литиевых батареек.

CSR насколько знаю, шьют свои либы в масочное ПЗУ, а юзеру предлагается тупо дергать API, который у них мягко говоря наркоманский. Но при этом флешку интегрировать в кристалл жмотится, потому на всех HC-05 и подобных модулях торчит отдельная флешка с прошей.

И тем не менее, в потребительских устройствах почему-то зигби не найти, какой бы «опенсорсный» он не был

Датчики протечки, умнодомы - там зигби навалом. Хотя умнодомы это своя, особенная атмосфера. Там по сей день knx, rs485 и пафосные выключатели за 400 баксов/штука.

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

Хм, есть данные по потреблению/сравнительные таблицы? Я пока для себя на nrf24l01 остановился, ибо в розницу 1 бакс за модуль, и при грамотном управлении питанием будет годами от батарейки работать.

Но при этом флешку интегрировать в кристалл жмотится, потому на всех HC-05 и подобных модулях торчит отдельная флешка с прошей.

Да, так и было раньше. Но теперь есть CSR101x.

Хм, есть данные по потреблению/сравнительные таблицы?

Выдержка из даташита на BLE112

Power mode              Min Typ Max    Unit
-------------------------------------------
Active mode TX 2 dBm            36      mA
Active mode TX -2 dBm           30      mA
Active mode TX -6 dBm           28      mA
Active mode RX              25          mA
Power mode 1                235         μA
Power mode 2                0.9         μA
Power mode 3                0.4         μA

Выдержка из даташита CSR1010:

RX / TX active: ~16mA @ 3V peak current

Hibernate <1.5μA

Dormant (All functions are shut down. To wake them up, toggle the WAKE pin) <600nA

Idle ~1mA

Я не говорю что это плохо или хорошо. Мне как-то всё равно, я пользуюсь проводными мышами.

Многовато. У nrf24l01 в среднем ~ 10 mA при приеме/передаче. В стендбае ~320uA

Полноценные SoC сравниваешь с трансивером? ;)

Так в твоем примере указано потребление радиочасти, не?

небось в неё можно заодно и Torrent-клиента установить :-)

И пару троянов. Велкам ту ботнет.

так и представляю разговоры:

-- у тебя сколькиядерная мышка?

-- 4ёх..

-- фууу позорняк, я купил на днях восьмиядерную!

:-D

Это потребление всего SoC целиком, вместе с 8051/XAP ядром. Максимальное — в момент приёма/передачи, минимальное — в самом глубоком режиме сна.

Table 9.1 shows CSR1010 QFN total typical current consumption measured at the battery.

Кстати, у вышедшего в прошлом году модуля BLE113 (на основе CC2541) потребление при приёме/передаче ещё меньше (правда, в режимах сна немного больше):

Power mode                                          Min Typ Max    Unit
-------------------------------------------
Active mode TX 0 dBm                                    18.2       mA
Active mode TX 0 dBm with TPS62730                      14.3       mA
Active mode RX, standard gain                           17.9       mA
Active mode RX 0 with TPS62730, standard gain           14.7       mA
Active mode RX 0 with TPS62730, high gain               16.7       mA
Power mode 1                                            270        μA
Power mode 2                                            1          μA
Power mode 3                                            0.5        μA

С режимами сна все понятно. Скорее всего мельче технология - больше токи утечки. Меня больше сейчас интересует FRAM серия Ti, потому как по характеристикам FRAM уделывает флеш, в том числе и по потреблению (9uA против 2200uA)

Несколько раз ковырял это поделие. Какая-то кошмарная смесь питона, гтк и пары либ.

Глючит кошмарно, падает на ровном месте. Количество ошибок в гуе зашкаливает все мыслимые пределы...

В одном проекте, где неверная команда оператора влетела бы в копеечку, делал запись циклического системного лога событий в FM24W256. FRAM действительно отличная штука :)