среда, 19 февраля 2014 г.

USB 3g модем на базе чипа Sierra SL8082 и Linux

Оставлю себе напоминание об этом периоде.
Linux 3.2.18, buildroot 05-2013.
В первую очередь - мне не надо переключать модем в режим модема) потому что он сразу в нем и нет всякой ерунды типа сидирома и флэшки.
Просто появляется четыре устройства (типично - ttyUSB0-3).
ttyUSB0 - предназначен для обмена с модемом по двоичному протоколу (полезно, чтобы не разрывать текущее соединение)
ttyUSB3 - обмен классическими AT-командами.
Однако для того, чтобы увидеть эти самые устройства, нам надо конечно же настроить ядро (make linux-menuconfig):
* Device drivers
    * USB Support
        * USB Serial converter support
            * USB Generic serial driver
            * USB friver for GSM and CDMA modems
            * USB Sierra wireless driver
В принципе, теперь на загрузке должно появится упоминание о ttyUSB* устройствах.
Можно даже и соединятся напрямую посылая команды в ttyUSB3, но удобнее для этого использовать pppd, а чтобы использовать для начала надо установить (make menuconfig):
* Packages
    * Network applications
        * pppd
После установки настраиваем pppd:
1.  Создаем файл /etc/ppp/peers/имя_соединения такого содержания:
 /dev/ttyUSB3 115200
 nobsdcomp
 nodeflate
 connect '/usr/sbin/chat -v -f /etc/ppp/chat-gprs'
 noauth
 noipdefault
 usepeerdns
 defaultroute
 debug
 nodetach
2. Напишем файл /etc/ppp/chat-имя_соединения:
  TIMEOUT         5
  ECHO            ON
  ABORT           '\nBUSY\r'
  ABORT           '\nERROR\r'
  ABORT           '\nNO ANSWER\r'
  ABORT           '\nNO CARRIER\r'
  ABORT           '\nNO DIALTONE\r'
  ABORT           '\nRINGING\r\n\r\nRINGING\r'
  ''                       \rAT
  TIMEOUT         12
  OK              ATE1
  OK              'AT+cgdcont=1,"IP","m2mstatic.beeline.ru"'
  OK              ATD*99#
После таких манипуляций мы уже можем проверить соединение: pppd call имя_соединения
На этом бы можно было и закончить но есть проблема раз - соединение периодически разрывается. Раз проблема решается добавлением в файл /etc/inittab строки :::respawn:pppd call имя_соединения.
Однако стала проявляться проблема номер два - обрыв может произойти из-за аппаратной проблемы в модеме, и вот тут и всплывает, что после такого обрыва файл порта ВНЕЗАПНО становится ttyUSB4 и соединиться мы уже ни с кем, понятно, не сможем( Грусть-печаль, помогает тут передергивание провода USB. Но как-то это не технологично, поэтому думаем, как программно отключать USB-хабы, додумываемся до такого:
echo 0 > /sys/bus/usb/devices/usb2/1-1/1-1.2/authorized (отключить)
echo 1 > /sys/bus/usb/devices/usb2/1-1/1-1.2/authorized (включить)
Удобно все это засунуть в отдельный скрипт:
echo 0 > /sys/bus/usb/devices/usb2/authorized sleep 5 echo 1 > /sys/bus/usb/devices/usb2/authorized sleep 5 echo 0 > /sys/bus/usb/devices/usb1/authorized sleep 5 echo 1 > /sys/bus/usb/devices/usb1/authorized sleep 5 date >> /var/gprs echo "gprs connect" >> /var/gprs pppd call gprs
И уже этот скрипт вызывать для создания соединения.
Ну и напоследок важный момент - маршрутизация. После создания тоннеля надо его прописать маршрутом по умолчанию. Для этого создаем файл /etc/ppp/ip-up с таким содержимым:
#!/bin/sh
route del default
route add default ppp0
А теперь точно все.

пятница, 7 февраля 2014 г.

Подключение датчиков температуры LM75, DS1621 в Linux

Увидел я в одном из наших изделий большую белую колбасу - на деле это оказался низкоомный резистор мощностью 8Вт для обогрева платы в прохладном климате.
Раз есть обогреватель - значит кто-то должен решать, когда его включать. На роль "кого-то" разработчики сначала определили один из клонов терморегурятора LM75, но впоследствие он был заменен на DS1621, ибо у последнего была встроенная EEPROM и не надо было после выключения питания заново прописывать уставки срабатывания (хотя это было и не трудно).
Это было очень краткое (надеюсь) вступление. Теперь по существу.
Как известно - все уже придумано за нас, особенно в такой могучей ОС, как Linux, нам же остается лишь скромная участь повторителей, поэтому приступим.
1. Для начала традиционно настроим ядро (make linux-menuconfig):
    Device drivers
    * I2C Support
        * Enable compatibility bits for old user-space
        * I2C device interface
        * I2C bus multiplexing support
        * Autoselect pertinent helper modules
    * I2C Hardware Bus support
        * GPIO-based bit-banging I2C
    * Hardware monitoring support
        * Dallas Semiconductor DS1621 and DS1625
2. Теперь конкретизируем тип датчика на шине. Лезем в боард-файл своей платформы (например, board-sam9m10g45.c) и там пишем:
    static struct i2c_board_info __initdata ek_i2c_devices[] = {
   {
        I2C_BOARD_INFO("ds1621", 0x48),
        .type = "ds1621",
    },
}
и в этом же файле в функции инициализации платы прописываем i2c:
at91_add_device_i2c(0, ek_i2c_devices, ARRAY_SIZE(ek_i2c_devices));

В принципе, после перекомпиляции ядра в каталоге /sys/bus/i2c/device/x-yyyy/ появятся как минимум три файла - temp1_input (текущая температура), temp1_max (температура отключения), temp1_min  (температура включения), скорее всего файлов будет больше - зависит от типа терморегулятора.

Если что-то идет не так, то очень помогут диагностировать проблемы два комплекта утилит: lm-sensors и i2c-tools. Оба пакета можно подключить в Package selection for the target/Hardware handling.
В самом примитивном случае пользоваться ими можно так:
i2cdetect -y 0 (покажет все устройства на шине 0)
sensors (покажет данные с датчиков, обнаруженных на шине.

Вроде ничего не упустил.