книги хакеры / журнал хакер / 109_Optimized

Наш клиент передает файл на телефон

L2CAP- и RFCOMM-сокеты

После длительных мучений с HCI и SDP мы, наконец, получаем возможность работать с простым, всем хорошо известным унифицированным интерфейсом UNIX-сокетов. Bluetooth-сокеты поддерживают L2CAP- и RFCOMM-адресацию. L2CAP-адреса специфицируются номерами PSM (Protocol and Service Multiplexor), RFCOMM — номерами каналов.

Вот так реализуется L2CAP-сервер:

int s=socket(AF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_L2CAP);

struct sockaddr_l2 loc_addr={0}; loc_addr.l2_family=AF_BLUETOOTH; loc_addr.l2_bdaddr=*BDADDR_ANY; loc_addr.l2_psm=htobs(0x1001); bind(s, (struct sockaddr *)&loc_addr,

sizeof(loc_addr)); listen(s, 1);

struct sockaddr_l2 rem_addr = {0}; socklen_t opt=sizeof(rem_addr); int client=accept(s,

(struct sockaddr *)&rem_addr, &opt); char buf[1024]={0}; ba2str(&rem_addr.l2_bdaddr, buf); printf("Connection from client %s\n", buf);

recv(client, buf, sizeof(buf), MSG_NOSIGNAL); send(client, buf, sizeof(buf), MSG_NOSIGNAL);

А вот так L2CAP-клиент:

int s = socket(AF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_L2CAP);

struct sockaddr_l2 addr={0}; addr.l2_family = AF_BLUETOOTH; addr.l2_psm = htobs(0x1001);

str2ba("11:22:33:44:55:66", &addr.l2_bdaddr); connect(s, (struct sockaddr *)&addr, sizeof(addr)); char buf[1024]={0};

send(s, buf, sizeof(buf), MSG_NOSIGNAL); recv(s, buf, sizeof(buf), MSG_NOSIGNAL);

Несмотря на большое сходство с TCP/IP, здесь хочется заострить внимание на нескольких моментах. Во-первых, унификация порядка следования байт в bluetooth своя, и функции преобразования тоже свои. Как можно увидеть, вместо htons (host to network short) здесь применяется htobs (host to bluetooth short) и далее по аналогии. Во-вторых, при работе с L2CAP

xàêåð 01 /109/ 08

нужно всегда учитывать MTU (Maximum Transmission Unit) и оперировать пакетами, равными или меньшими по размеру этому самому MTU. Получить MTU с сокета можно вот так:

struct l2cap_options opts; int optlen = sizeof(opts); getsockopt(sock, SOL_L2CAP,

L2CAP_OPTIONS, &opts, &optlen);

printf("Input MTU=%d Output MTU=%d\n", opts.imtu, opts.omtu);

А установить — вот так:

opts.omtu = opts.imtu = my_mtu; setsockopt(sock, SOL_L2CAP,

L2CAP_OPTIONS, &opts, optlen);

Фактически работа с RFCOMM-сокетами ничем не отличается от работы с L2CAP, за исключением нескольких моментов. Сокеты RFCOMM используют как поточные, а не пакетные:

int s=socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM);

Для адресации здесь применяются другие структуры с другими полями:

struct sockaddr_rc addr={0}; addr.rc_family=AF_BLUETOOTH; addr.rc_channel=(uint8_t) 1; str2ba("11:22:33:44:55:66", &addr.rc_bdaddr);

При приеме данных с RFCOMM-сокетов фрагментация — обычное дело. Ты попросил дать тебе 100 байт, вместо этого тебе дали 30 байт, потом 50 байт и потом еще 20 байт. В такой ситуации можно попросить вызов recv дефрагментировать поток с помощью флага MSG_WAITALL либо не забывать самостоятельно отслеживать длину принятых данных и собирать нужные куски вручную.

Итог

Теперь мы имеем на руках весь необходимый инструментарий, чтобы написать свои собственные клиент и сервер OBEX OBJECT PUSH. Осталась только реализация протокола, к счастью, он не так сложен. Выше была приведена таблица, иллюстрирующая обмен данными между клиентом, отправляющим файл, и сервером, этот файл принимающим. Реализацию клиента и сервера ты найдешь на диске, прилагающемся к журналу. z

119

трюки открыса

О переполняющихся буферах написано много, о переполнении целочисленных/вещественных переменных — чуть меньше, а ведь это одна из фундаментальных проблем языка Си, доставляющая программистам массу неприятностей и порождающая целых ворох уязвимостей разной степени тяжести, особенно если программа пишется сразу для нескольких платформ. Как быть, что делать? Мыщъх делится своим личным боевым опытом (с учетом всех травм и ранений, полученных в ходе сражений), надеясь, что читатели найдут его полезным, а он тем временем в госпитале с сестричкой…

01pаконсуров,ноонзакон

Фундаментальность проблемы переполнения целочисленных переменных имеет двойственную природу. Стандарт декларирует, что результат выражения (a+b) в общем случае неопределен (undefined) и зависит как от архитектурных особенностей процессора, так и от характера компилятора. Положение усугубляется тем, что Си (в отличие от Паскаля, например) вообще ничего не говорит о разрядности типов данных, больших, чем байт. long int вполне может равняться int. И хотя начиная с ANSI C99 появились типы int32_t, int64_t, а некоторые компиляторы (в частности, MS VC) еще черт знает с какой версии поддерживают нестандартные типы _int32 и _int64, проблема определения разрядности переменных остается. Одним процессорам выгоднее обрабатывать 64 битные данные, другим — 32 битные, и потому выбирать тип «на вырост», то есть с расчетом, чтобы в него точно влезли обозначенные значения, — расточительно и негуманно.

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

заворот по модулю, физическим аналогом которого могут служить обычные механические часы. Хинт: 3+11=2, а вовсе не 14! Вот так неожиданность! И ищи потом, на каком этапе вычислений данные превращаются в винегрет! А искать можно долго, и ошибки возникают даже в полностью отлаженных программах, стоит только скормить им непредвиденную последовательность входных данных.

LIA-1 (смотри приложение «H» к Стандарту ANSI C99) говорит, что в случае отсутствия заворота при переполнении знаковых целочисленных переменных компилятор должен генерировать сигнал (ну или, в терминах Microsoft, выбрасывать исключение). Поскольку знаковый бит на x86 процессорах расположен по старшему адресу, заворота не происходит, и некоторые компиляторы учитывают это обстоятельство при генерации кода. В частности, GCC поддерживает специальный флаг '-ftrapv'. Посмотрим, как он работает?

Исходнаяфункция,складывающая двазнаковыхчислатипаint

foo(int a, int b)

{

return a+b;

}

КомпиляциякомпиляторомGCCсключамипоумолчанию

Очевидно, что результат работы этой функции непредсказуем, и, если сумма двух int’ов не влезет в отведенную разрядность, нам вернется черт знает что. А вот теперь используем флаг '-ftrapv':

КомпиляциякомпиляторомGCCсключом'-ftrapv'

jmp short loc_8048400 ; -> нормальное продолжение

__addvsi3 endp

Сложение с флагом '-ftrapv' безопасно, но… как же оно тормозит! Кстати, на уровне оптимизации '-O2' и выше флаг '-ftrapv' игнорируется. Но даже без всякой оптимизации он не ловит переполнения при умножении и, что самое печальное, поддерживается не всеми компиляторами.

02пишемзаконсами!

На самом деле для «безопасного» сложения чисел у нас есть все необходимые ингредиенты. Причем оно будет работать с любым компилятором на любом уровне оптимизации и с достаточно приличной скоростью (уж во всяком случае побыстрее, чем __addvsi3 в реализации от GGC). Функция безопасного сложения двух переменных типа int в простейшем случае выглядит так:

Функциябезопасногосложения

#include <limits.h> /* здесь содержатся лимиты всех типов */

int safe_add(int a, int b)

{

if(INT_MAX — b < a)

return _abort(ERROR_CODE); return a + b;

}

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

03отправляемсявплаванье

Вещественные переменные, в отличие от целочисленных, работают чуть медленнее, хотя… это еще как сказать! С учетом того, что ALU- и FPU-блоки современных ЦП работают параллельно, для достижения наивысшей производительности целочисленные и вещественные переменные должны использоваться совместно (конкретная пропорция

xàêåð 01 /109/ 08

определяется типом и архитектурой процессора). Главное, что x86 и некоторые другие ЦП поддерживают генерацию исключений при переполнении вещественных переменных. Но умолчанию она выключена, и включить ее, увы, средствами чистого Си нельзя, но вот если прибегнуть к функциям API или нестандартным расширениям… Рассмотрим следующую программу:

Активацияисключенийприработесвещественными переменными

#include <float.h> #include <stdio.h>

main()

{

//объявляем вещественную переменную

//(это может быть также и float) double f = 666;

//считываем значение управляющего слова

//сопроцессора через MS-specific функцию int cw = _controlfp(0, 0);

//задействуем исключения для следующих ситуаций cw &=~(EM_OVERFLOW|EM_UNDERFLOW|

EM_INEXACT|EM_ZERODIVIDE|EM_DENORMAL);

//обновляем содержимое управляющего

//слова сопроцессора

_controlfp( cw, MCW_EM );

// в блоке try мы будем делать исключения

__try{

// в бесконечном цикле вычисляем f = f*f while(1)

{

// выводя его содержимое на экран printf("%f\n", f = f * f);

}

}

except(puts("in filter"), 1)

// а тут мы ловим возникающие исключения!

{

puts("in except");

// для упрощения обработка исключений опущена

}

}

В зависимости от компилятора (и процессора) этот пример будет тормозить в большей или меньшей степени. В частности, на x86 вещественное деление намного быстрее целочисленного. С другой стороны, компилятор MS VC выполняет вещественное сложение в разы медленнее главным образом потому, что не умеет сохранять промежуточный результат вычислений в регистрах сопроцессора и постоянно загружает/выгружает их в переменные, находящиеся в памяти. GCC такой ерундой не страдает,

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

Кроме того, вещественные переменные имеют замечательное значение «не число», которое очень удобно использовать в качестве индикатора ошибки. У целочисленных с этим настоящая проблема. Одни функции возвращают 0, другие — -1, в результате чего возникает путаница, а если

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

А с вещественными переменными все просто и удобно. И это удобство стоит небольшой платы производительностью. z

121

laMoboT

/ lAMObOT@GMAIl.COM /

Устанавливаем индикатор в торец

Ключевая дорожка на плате

Грамотно прокачанная пушка

Девайс в сборе

dvd

На диске ты найдешь исходник программы, прошивку в виде hex-файла, софт для программатора

PonyProg, докумен-

тацию на контроллер и изображение печатной платы, по которому ты сумеешь повторить ее методом ЛУТ или фоторезиста.

катора.Какможнодогадатьсяпокартинке,каждыйцифровой разрядсостоитизсемисегментов.Производителииндикаторов договорилисьобозначатьсегментыбуквами,сверхнегои далеепочасовойстрелке:a,b,c,d,e,f.Сегментg—средний горизонтальный.Каждыйсегмент,посути,обычныйсветодиод. ВиндикатореDA-04этисветодиодывнутрисоединеныанодами иобщийконтактвыведеннаружу.Чтобырациональноиспользоватьпространство,мынебудемтуполепитькаждыйдиодк линиипорта,раздуваяшлейфна16жил,аиспользуемстробирование.Этопозволитсократитьколичествопроводниковдо девяти.Соединимсегментыобоихразрядовпараллельно,то естьa1 a2,b1 b2,ит.д.Будемпоследовательнозажигатькаждыйразрядпутемкоммутациитолькоодногоанода,иделатьэто мыбудемоченьбыстро,чтобыниктонезаметиллегкогообмана. Сетчаткачеловеческогоглазадовольноинертнаипоэтому никакойразницынаблюдательнеобнаружит.Соединяемпары а1 а2,b1 b2,c1 c2,d1 d2,e1 e2,f1 f2,g1 g2слиниямипорта

Aконтроллерачерезтокоограничивающиерезисторы.Аноды индикатораприсоединяемклиниямPB0,PB1черезключина биполярныхтранзисторах.

Разводка

Разъемы для подключения шлейфа и прочего я решил не ставить и паять напрямую — в первую очередь из-за отсутствия в продаже нормальных соединителей с шагом 1,27 мм, а также из-за банальной экономии места. Даже самый миниатюрный разъем занял бы треть площади платы. На фиг такой расклад. Девайсик уместился на односторонней плате с двумя перемычками, габариты которой менее 25х40 мм. Места в «Дрозде» хватает с запасом. На картинке наглядно проиллюстрирован процесс разводки.

Изготовление

Вэтотразприизготовлениипечаткиязаморочилсяпополной

программе.Применилфоторезист,шаблоны,УФ-лампу,NaOhи FeCl3(рекомендуюпосмотретьэтотметодвинтернете—очень полезнаяштука).Моистараниянепрошлидаром,ияполучил рисунокпроводниковвысокогокачества!Тыможешьсделать печатнуюплатулюбымспособом,которыйосилишь.Оптимальным,пожалуй,будетметодлазерногоутюга.Картинкусразводкойплатыввысокомразрешенииищинадиске.Размеры платыдлясамостоятельногоизготовления:38на21,5мм.Когда протравишь,незабудьзалудитьдорожкииконтактныеплощадки(какуменя).Будетпрощепаятькрохотныедетали.Более того,твоеустройствобудетвыглядетьгораздоприличнее.

Впервую очередь капитально впаяй 78M05. Земляной

Распайка шлейфа. Ориентир — красная жила

вывод этой детали является еще и радиатором, поэтому положи туда побольше припоя, чтобы тепло лучше рассеивалось. И еще — не вздумай припаять регулятор напряжения легкоплавким припоем! Даже при входном напряжении, находящемся в рамках допустимых значений, он может очень сильно греться и банально отпаяться. Затем установи C1, C2, C3. Желтая бобышка С1 — это танталовый конденсатор. Он полярен (при его впайке имеет значение, где минус, а где плюс), положительная ножка у него там, где полоска. С2 и С3 впаивай любой стороной, они керамические. С помощью тестера проверь полярность и номинал напряжения на площадках под микроконтроллер: на пятой площадке относительно шестой, должно быть примерно 5 В. Может быть чуть больше, поскольку в нашей схеме пока ничто ничего не потребляет (это называется «режимо холостого хода»). Но если тестер показывает напряжение больше 5,5 В, а то и все 9 В, то тут что-то не ладно. Если норма, смело впаивай все остальное. В самую последнюю очередь сделай две проводные перемычки от транзисторов. И не забудь приделать кнопочку, ее лучше будет вывести на левую сторону корпуса «Дрозда».

Теперь займемся индикатором и шлейфом. Я специально развел плату так, чтобы максимально упростить этот момент. Распайка очевидна из картинок. У индикатора проводками соедини одноименные сегменты. Для механической устойчивости можешь залить это место эпоксидной смолой (естественно, после проверки правильности соединения, иначе может быть очень обидно).

После сборки смой флюс/канифоль с платы. Сделать это можно спиртом или бензином. Если ты использовал какойто особенный флюс, прочитай на упаковке: возможно, он смывается обычной водой. Проделать эту операцию лучше после того, как зальешь прошивку, проверишь и отпаяешь программатор. Флюс надо смыть обязательно, а то некоторые виды флюсов со временем становятся токопроводящими и устройство перестает работать.

Сейчас займемся установкой счетчика внутрь корпуса «Дрозда». Первым делом выпаяй большой транзистор IRF из родной схемы. Мы заменим его IRL3502 — аналогичным, но срабатывающим от логического уровня на затворе. По цоколевке они абсолютно идентичны, поэтому вопросов тут быть не может. Возьми резистор 2,2 кОм и припаяй между затвором (если смотреть спереди, затвор — это первая ножка!) и землей.

Это позволит избежать непроизвольных выстрелов или по крайней мере странных шептунов во время инициализации контроллера. В бета-версии этой схемы затвор к земле я не

/ fackadmin@mail.ru / / dlinyj@real.xakep.ru /