вторник, 12 августа 2008 г.

N560

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

Открывать КПК как-то стремно стало. Боюсь, что обратно я его соберу с еще большими повреждениями. Решил забить на встроенный динамик. При желании можно и наушники для громкой связи использовать задрав громкость до предела. Не выход конечно... А вот с клавиатурой все печальнее. Сначало я думал, что на каждое нажатие кнопки приходит два скан кода один за другим. И думал, что смогу отрезать второй, который приходит слишком рано. Благо перехват скан кодов уже реализован в LooxLight'е. А тут оказалось все куда печальнее. Там не два скан кода приходит. А один "одновременный". Как бы это описать. Ну вот PC клавиатуре там настоящие скан коды. А в клавиатуре КПК, там просто значение у которого каждый бит занчит нажатую кнопку. Значение состоит из двух слов, старшее для стрелочек, а младьшее для всех остальных кнопок. И вот я по логам LooxLight'а наблюдаю следующую картину:
2003.01.02 17:33:38.0000: 6f7dacca: 8f7ddf4c: Char 00040004, cur=00000004, next=00000005, 8f7ddf4c, 8f7ddc64
И так на каждое нажатие. На любое нажатие левое слово = правое. В результате нажимаем стрелочку влево, а получаем и влево и еще какое-то нажатие. И наоборот. Короче хрен обьяснишь. Думаю это как-то завязано на то, что такие клавиатуры обычно реализуются через "матрицу" контактов или хз как и какие-то две ветки там замыкает. А может я и не прав. Сейчас сделаю временное решение, чтобы дисплей хоть разблокировать можно было, а потом буду думать...

Временное решение:
Сравнивать коды клавиш таким образом, что fix(нажатой кнопки) == fix (образца):

UINT fix (UINT x) {
UINT y = (x & 0xFFFF) | (x >> 16);
return y | (y << 16);
}

понедельник, 11 августа 2008 г.

Зедаржки в Java

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

1. Пускать приложение с schedtool -n -20 -R -p 1 -e /opt/mywire/bin/mywire
Данная команда позволяет запустить приложение в realtime группе с приоритетом 1. Все приложение linux имеют приоритет 0 независимо от nice level'а. Таким образом работа нашего mywire всегда приоритетнее любой задачи.

2. В некоторых критичных нитях, с помощью обращения к native методу происходит установка приоритета в значение 40. Таким образом внутри самого приложения нити имеют разные приоритеты. Это опасно и может привести к блокировкам!

3. Для того, чтобы ни в коем случае mywire не оказался в свопе, память лочится с помощью обращения к native методу mlockall.

4. Сам java процесс пускается со следующими опциями:

-Xms30m -Xmx64m -XX:PermSize=15m -XX:MaxPermSize=30m
-XX:+UseTLAB -jvm server
-XX:MaxGCPauseMillis=20 -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode
-XX:+CMSClassUnloadingEnabled
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
-XX:+BackgroundCompilation

Количество памяти, которое я отдаю под heap выбранно таким образом, чтобы сразу после сборки мусора (full gc), свободной памяти было где-то 60%.

Надеюсь ничего не забыл. Как результат мы имеем задержки порядки 10-16мс. При том, что библиотека quartz сама работает с дискретеностью в 10мс. Тоесть если ей сказать, что таску нужно запустить через 5мс, она ее все равно запустить через 10.

К сожалению раз в час происходит full gc или что-то типа того и это влечет за собой неожиданные задержки. Величина зависит от того, как совпадут время срабатывания и начало сборки мусора. В среднем это 200мс. Бывает и 500мс и 700мс. Будем думать как это побороть.

Вот графики:
Latency:


Память.


Видно, что в момент сборки мусора был всплеск задержек.

Предугадывая вопросы:
Java - чтобы писать быстрее.

Latency - в данном случае, это разница времени момента срабатывания таймера и времени, в которое данный таймер должен был сработать. Тоесть, например, если было сказано спать 100мс, а таймер проспал 120мс, то задержка 20мс.

Важность Latency заключается в том, что опрашивать некоторые датчики необходимо весьма часто, скажем датчик движения 2 раза в секунду. В моем варианте датчик движения замыкает размыкает контакты конденсатора давая ему зарядится, таким образом датчик напряжения 1-wire успеет заметить какой-нибудь заряд, даже если он пропустит сам импульс. Так вот если Latency будет слишком высокой (скажем 2-3 секунды), то срабатывания датчик может просто остаться незамеченным.

Кто озадачился вопросом, почему датчик движения не может сам сообщить о срабатывании, отвечу: 1-wire сеть может иметь только одного master'а, все остальные slave'ы.

Home Portal

Домашний портал. Эта та страничка, что стоит в браузере как home page. Отсюда я/жена читаю новости, смотрю погоду за окном (графики влажности, температуры), наблюдаю за работой сервера и т.д. Предназначен он для home automation (ну там энергосберегающий умный дом (smarthouse) и т.д.). Работа в свободное время. Сбор информации и управление 1-wire, в будущем будет еще X-10 (управление светом), камеры и т.д.. Много всего написано, но на сервере на production сервере еще не выложено. Сам портал напроч AJAX'ный, перегрузок страниц не требует. В качестве платформы Jboss Portal + DOJO (следующие портлеты будут без dojo, но на GWT). В качестве ядра, standalone java process со стеком spring + termware + quartz и т.д.

Но вообще пост не об этом, а о двух подряд идущих анонсах в ленте torrent.net.ua (см. скриншоты).

Картинка 1
Картинка 2
Картинка 3