Я долго думал над проблемой объединения кучи микроконтроллеров (МК AVR) в общую сеть. Хотелось иметь простой протокол, в идеале - UART. Но он во-первых не умеет разруливать коллизии, и во-вторых вообще-то даже не предусматривает присутствие нескольких устройств на общей шине!
Но нас такими глупостями не испугаешь.
Поскольку UART мне был нужен также "для самых маленьких" МК (вплоть до tiny13), его пришлось программить самому. Ну а раз пишем сами, то и правила устанавливаем свои :)
Описать сеть я мог бы так: один ПК, много МК на общей шине, полный дуплекс, т.е. отдельные линии RxD и TxD, ПК рассылает на всех разом, МК могут инициировать связь с ПК (но не друг с другом). Схема будет под катом.
В итоге был реализован немного расширенный UART-протокол общения с ПК, который вообще-то полностью совместим с generic-UART, имеет обнаружение коллизий, режим пакетной передачи и позволяет иметь на линии сколь угодно много МК, каждый из которых совершенно свободно может передавать данные в сеть, как только пожелает.
Особенности: никаких арбитров, маркеров, "ответов-только-если-спросили" и прочих ограничений. Абсолютная демократия!
То есть посылаешь в сеть широковещательное "Кто тут?!" и получаешь в ответ аккуратные пакеты, содержащие ответ с адресом каждого МК. Никакой каши.
В виде бонуса, каждому МК можно поставить 3 светика, которые будут отражать соответствующие системные флаги "Линия занята", "Коллизия" и "FRAME ERROR".
Как же я этого добился?!
суббота, 20 октября 2012 г.
понедельник, 15 октября 2012 г.
Пишем приложение для Android в Appcelerator (Titanium Studio)
Небольшой tutorial "как писать приложения под Android" от человека, который под телефоны никогда ничего не писал, Java не знает и вообще PHP-разработчик.
PHP-разработчики не всегда знают Java, зато они все должны знать JavaScript. Есть такая штука, Titanium Studio, позволяет писать мобильные приложения на JavaScript. Она еще и бесплатная. Какая удача!
PHP-разработчики не всегда знают Java, зато они все должны знать JavaScript. Есть такая штука, Titanium Studio, позволяет писать мобильные приложения на JavaScript. Она еще и бесплатная. Какая удача!
четверг, 11 октября 2012 г.
Не работает CURLOPT_CONNECTTIMEOUT_MS
Очередной квест при работе с curl.
Нужны были таймауты в миллисекундах, версия libcurl 7.21, версия php 5.3, т.е. условиям соответствует.
Но не работает..
тестовый код
Т.е. даже никаких тебе About to connect и Trying 192.168.0.1, сразу Closing connection, и хоть ты волком вой.
Пробовал переустанавливать libcurl, php5-curl, не помогло.
Полез в гугл по запросу "curlopt_connecttimeout_ms, timeout was reached" и вышел на спасительный комментарий в мануале:
http://www.php.net/manual/ru/function.curl-setopt.php#104597
т.е. если libcurl использует стандартный name resolver, в процессе резолвинга посылается сигнал SIGALRM, который libcurl принимает за таймаут!
Установка опции nosignal решила проблему.
curl_setopt($ch, CURLOPT_NOSIGNAL, 1);
Нужны были таймауты в миллисекундах, версия libcurl 7.21, версия php 5.3, т.е. условиям соответствует.
Но не работает..
тестовый код
$ch = curl_init();выводит
curl_setopt($ch, CURLOPT_URL, "http://192.168.0.1/");
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT_MS, 300);
curl_setopt($ch, CURLOPT_VERBOSE, 1);
$res = curl_exec($ch);
var_dump($res, curl_error($ch));
* Closing connection #0
* Timeout was reached
bool(false)
string(19) "Timeout was reached"
Т.е. даже никаких тебе About to connect и Trying 192.168.0.1, сразу Closing connection, и хоть ты волком вой.
Пробовал переустанавливать libcurl, php5-curl, не помогло.
Полез в гугл по запросу "curlopt_connecttimeout_ms, timeout was reached" и вышел на спасительный комментарий в мануале:
http://www.php.net/manual/ru/function.curl-setopt.php#104597
The problem is that on (Li|U)nix, when libcurl uses the standard name resolver, a SIGALRM is raised during name resolution which libcurl thinks is the timeout alarm.
т.е. если libcurl использует стандартный name resolver, в процессе резолвинга посылается сигнал SIGALRM, который libcurl принимает за таймаут!
Установка опции nosignal решила проблему.
curl_setopt($ch, CURLOPT_NOSIGNAL, 1);
SOLVED
среда, 3 октября 2012 г.
Интересное поведение mkdir в php
Внезапно обнаружилось, что mkdir не работает с указанием прав так, как от нее ожидается. По крайней мере при запуске скриптов из крона.
Пытаешься указать ей права 770 - папка создается как 750.
Пытаешься 777 - создается как 755. Явно просматривается ограничение по umask.
Но что интересно, chmod() на 770 говорит ОК, следом тут же проверка fileperms() говорит 770, НО по факту в ФС - 755! Ну нихрена себе, мир рушится! Как я теперь могу доверять PHP?!?
В итоге было выяснено, что пых работает с umask 0022.
Вызов umask(0002) перед файловыми операциями привел права в норму, но поведение chmod+fileperms все равно удивляет.
Значит надо запускать php-fpm с явным заданием umask 0002 например.
Однако в дефолтном /etc/bashrc было задано 0002. WTF?!?
Оказалось, что крон просто не цепляет bashrc!
Пытаешься указать ей права 770 - папка создается как 750.
Пытаешься 777 - создается как 755. Явно просматривается ограничение по umask.
Но что интересно, chmod() на 770 говорит ОК, следом тут же проверка fileperms() говорит 770, НО по факту в ФС - 755! Ну нихрена себе, мир рушится! Как я теперь могу доверять PHP?!?
В итоге было выяснено, что пых работает с umask 0022.
Вызов umask(0002) перед файловыми операциями привел права в норму, но поведение chmod+fileperms все равно удивляет.
Значит надо запускать php-fpm с явным заданием umask 0002 например.
Однако в дефолтном /etc/bashrc было задано 0002. WTF?!?
Оказалось, что крон просто не цепляет bashrc!
среда, 26 сентября 2012 г.
Сколько ест компьютер
Сегодня скуки ради взял мультиметр, включил его в разрыв шнура питания БП компа и замерил ток. Давно меня интересовала эта цифра.
В биосе график был ровный, в районе 0.35A, во время загрузки - скакало от 0.35 до 0.45 ампер, после загрузки цифра вернулась к значению 0.30-0.32A.
Запустил Red Alert 3, скоро кулеры взвыли, а ток вырос до 0.45-0.55A.
Замеры в ждущем режиме показали 0.03A.
ИТОГО: потребление системника в ждущем режиме - 6.5Вт, а при работе где то 60-120Вт.
Конфигурация:
* Intel SSD SA2M160G2GC
* Intel(R) Core(TM) i5 CPU 760 @ 2.80GHz
* 2x2Gb DDR3-1333
* Asus P7H55-M/USB3
* Простенькое Видео HD6670
Самое главное забыл, БП какой то RealPower CG-400W (400Вт).
UPD: померял ваттметром, 70..80..90..100 при загрузке, около 80 в режиме простоя, 135 в режиме игры, 5 в ждущем.
Ваттметр такой
В биосе график был ровный, в районе 0.35A, во время загрузки - скакало от 0.35 до 0.45 ампер, после загрузки цифра вернулась к значению 0.30-0.32A.
Запустил Red Alert 3, скоро кулеры взвыли, а ток вырос до 0.45-0.55A.
Замеры в ждущем режиме показали 0.03A.
ИТОГО: потребление системника в ждущем режиме - 6.5Вт, а при работе где то 60-120Вт.
Конфигурация:
* Intel SSD SA2M160G2GC
* Intel(R) Core(TM) i5 CPU 760 @ 2.80GHz
* 2x2Gb DDR3-1333
* Asus P7H55-M/USB3
* Простенькое Видео HD6670
Самое главное забыл, БП какой то RealPower CG-400W (400Вт).
UPD: померял ваттметром, 70..80..90..100 при загрузке, около 80 в режиме простоя, 135 в режиме игры, 5 в ждущем.
Ваттметр такой
вторник, 25 сентября 2012 г.
FastCGI "Primary script unknown"
Столкнулся сегодня с сабжевой проблемой, косяк произошел после обновления nginx с 0.7.67 на 1.2.3.
Сайты стали отдаваться с ошибкой 404 и текстом "File not found". Что интересно, не все сайты.. Некоторые работали.
Долго бил во всяческие бубны, поднимал php-cgi на локальном порту вместо php-fpm через сокет, права проверял, конфиги пересмотрел раз 10, включал логи php-fpm, nginx-а. Вырисовывалось, что работают сайты, которые не используют ЧПУ (у них ссылки ведут на реальные скрипты, старые совсем сайтики).
ЧПУ сайтов у меня основано на обработке 404й ошибки и подмене SCRIPT_FILENAME на конкретный файл MVC-контроллера.
В итоге собака была зарыта в include fastcgi_params;
Раньше эта строка стояла под определением SCRIPT_FILENAME, и как то это работало, несмотря на то, что include fastcgi_params шло ниже и по идее должно было переопределять SCRIPT_FILENAME. После обновления же nginx видимо поменялось поведение.
Была мысль, что обновленный nginx и файл fastcgi_params обновил, однако время изменения файла было далеко в прошлом.
В общем проблема решилась установлением строки include fastcgi_params; на первое место во всех секциях по обработке php.
Сайты стали отдаваться с ошибкой 404 и текстом "File not found". Что интересно, не все сайты.. Некоторые работали.
Долго бил во всяческие бубны, поднимал php-cgi на локальном порту вместо php-fpm через сокет, права проверял, конфиги пересмотрел раз 10, включал логи php-fpm, nginx-а. Вырисовывалось, что работают сайты, которые не используют ЧПУ (у них ссылки ведут на реальные скрипты, старые совсем сайтики).
ЧПУ сайтов у меня основано на обработке 404й ошибки и подмене SCRIPT_FILENAME на конкретный файл MVC-контроллера.
В итоге собака была зарыта в include fastcgi_params;
Раньше эта строка стояла под определением SCRIPT_FILENAME, и как то это работало, несмотря на то, что include fastcgi_params шло ниже и по идее должно было переопределять SCRIPT_FILENAME. После обновления же nginx видимо поменялось поведение.
Была мысль, что обновленный nginx и файл fastcgi_params обновил, однако время изменения файла было далеко в прошлом.
В общем проблема решилась установлением строки include fastcgi_params; на первое место во всех секциях по обработке php.
четверг, 23 августа 2012 г.
Basic authorization logout
Как разлогиниться, если используешь Basic-авторизацию или, по-другому, HTTP-авторизацию?
Как оказалось не так уж просто, но все же возможно, причем вся логика - на серверной стороне, а значит метод кроссбраузерный!
Все что потребуется - контролировать пару флагов в сессии.
Суть в том, что если юзер авторизован - в сессии хранится его ID, а раз уж ID есть, то и пароль с логином спрашивать ни к чему. Однако есть и другой флаг, назовем его reauth, который показывает, что мы затребовали выход из системы.
При взведении этого флага сессия юзера очищается, а логин-пароль принудительно прячутся (т.е. метод getEnvLoginPasswd() просто говорит "а нету, пытай меня сволочь немецкая!"), это важно, иначе чуда не произойдет.
Как оказалось не так уж просто, но все же возможно, причем вся логика - на серверной стороне, а значит метод кроссбраузерный!
Все что потребуется - контролировать пару флагов в сессии.
Суть в том, что если юзер авторизован - в сессии хранится его ID, а раз уж ID есть, то и пароль с логином спрашивать ни к чему. Однако есть и другой флаг, назовем его reauth, который показывает, что мы затребовали выход из системы.
При взведении этого флага сессия юзера очищается, а логин-пароль принудительно прячутся (т.е. метод getEnvLoginPasswd() просто говорит "а нету, пытай меня сволочь немецкая!"), это важно, иначе чуда не произойдет.
Подписаться на:
Сообщения (Atom)