Как приручить свой Bluetooth. Часть 7

Честно говоря я и сам не ожидал, что простой рассказик «о том как окучить простенький модуль Bluetooth» выльется в целый сериал. Ну что ж, терпите! А я постараюсь писать интересно и увлекательно.

Сегодня мы займёмся передачей файлов. Поскольку скорость передачи у модулей HC-03/05 не очень большая, то передавать с компа на комп фильмы вряд ли имеет смысл. Давайте прикинем, сколько времени нам понадобиться скопировать какой-нибудь 700-мегабайтный фильм.

Формула для расчета простая:

t = V / s

здесь t — время в секундах, V — размер файла в килобайтах, s — скорость передачи в кБайт/с.

Подставляем значения и получаем:

t = 700000 / 20 = 35000 секунд.

Это чуть меньше 10 часов. Как говорится — комментарии излишни!

Но наша программа не коммерческая. Вообще, наша задача — научиться работать с модулями HC-03/05, получить максимум практики работы с ними. Если сразу подключать эти модули к микроконтроллеру, то придется очень часто изменять код программ, затем компилировать и заливать. Это не очень удобно, поскольку на каждую итерацию будет теряться масса времени, а кроме того, будет тратиться ресурс записи-стирания микроконтроллера. Поэтому, мы «играемся» с модулями в Питоне и на компах.

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

Иное дело — двоичная информация. Представим себе, что при передаче исполняемого кода какой-нибудь программы изменился всего один бит. То есть один из множества байтов в файле стал другим. Это значит, что исполняемый код программы будет работать не так как задумывалось. То есть программа станет нерабочей. Нам это точно не подходит!

Программа должна передавать двоичную информацию со 100% гарантией, что ни один бит не претерпел искажения.

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

Если контрольные суммы не совпали, то — понятно, информация где-то исказилась. В этом случае приёмная сторона должна послать передающей стороне запрос на повторную пересылку.

А что если и во второй и в третий раз придёт кусок с искажениями? Не будем же мы так до бесконечности пытаться его переслать! В общем количество повторных попыток должно быть ограничено каким-нибудь разумным значением. Например, 3 или 5.

Если после исчерпания количества попыток мы так и не смогли переслать кусочек информации, то, как говорит психолог Алексей Капранов — «Очень жаль!»

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

Кроме того, в результате такого усложнения алгоритма связи реальная скорость передачи информации окажется ещё ниже. Сейчас сложно сказать — на сколько ниже, но если для себя взять за ориентир цифру «на 10% ниже», то, я думаю, мы много не потеряем.

Однако, это всё скучная теория. Я понимаю, что народу хотелось бы практики, да повеселее. Ну, тогда переходим к следующей части.

 

 

Advertisements

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s