Мега-часы. 1. Просто часы, но с WiFi

Занимаясь на выходных разборкой и сортировкой скопившегося имущества, практически внезапно обнаружил давно забытые детали. Ну как забытые … я конечно помнил, что они где-то есть, но уж очень давно не держал их в руках. Ну и плюс ко мне в руки попали платы на 8051 микроконтроллере, со встроенным приемопередатчиком. Просто так баловаться не интересно, поэтому необходимо совместить приятное с полезным.

Скажу сразу, просто еще одни часы делать мне не интересно – один раз я уже делал аж 2 года назад, до сих пор работают у тещи. Внутри ардуинка и sure 3208

20131113_165232

Что у нас из приятного образуется? Во-первых, более большой и цветной индикатор.

В старых часах был одноцветный (только красный) индикатор, в котором была кучка светодиодов, расположенных 32 рядами по 8 штук. В новых будет аналогичная матрица, только умеющая уже 3 цвета и с матрицей светодиодов 64 на 16. Из-за размера светодиодов (в старой 5мм, в новой 3мм) разница в размерах не очень большая.

Во-вторых, использованная в первых часах микросхема DS1307 обладает небольшим уводом времени. Примерно минуту в неделю. Нет, я там приделал кнопки для коррекции времени, но это же несерьезно в 21м-то веке. Ловить всякие радиосигналы точного времени для меня безсмысленно, ибо лень. А вот подцепиться к WiFi и сбегать за точным временем в интернет к специализированному серверу – вот это да, уже стоит подумать.

И наконец, просто часы – это не интересно. Так как основное их место жительство будет кухня, то надо заставить их что-нибудь делать полезное. Курс доллара там показывать и радио играть. Или еще какую полезную работу выполнять. Список полезной работы будет уточняться по мере того, как я буду откапывать запчасти 🙂

Итак, пока часы. Схемы рисовать не буду, потому что 99% всего будет состоять из соединения проводками.

Для начала берем 2 индикатора sure 3216 и соединяем их приложенными к ним же проводами. Потом берем arduino leonardo и wifi shield. Все родное, итальянское, поэтому соединяем все в кучу. Достаем из пакетика мастеркитовский MP1095 и опять же соединяем проводками с ардуинкой. Все подписанное к подписанному (SDA к SDA, SCL к SCL и так далее).

И наконец соединяем полученный бутерброд из 3216 к ардуинке. На пины А0-А3. В нижеприведенном куске кода любой ардуинщик разберется, что куда подключается.

//Analog In 0 as PF7
//Analog In 1 as PF6
//Analog In 2 as PF5
//Analog In 3 as PF4
ht1632c ledMatrix = ht1632c(&PORTF, 7, 6, 5, 4, GEOM_32x16, 2);
ht1632c::ht1632c(const uint8_t data, const uint8_t wr, const uint8_t clk, const uint8_t cs, const uint8_t geometry, const uint8_t number)

И теперь добавляем магию, сиречь программирование. Я не стал сильно раздумывать, поэтому тупо собрал в одну кучу примеры общения с RTC, с NTP, c WiFi и с индикатором.

#include <ht1632c.h>
#include <Wire.h>
#include <RealTimeClockDS1307.h>
#include <SPI.h>
#include <WiFi.h>
#include <WiFiUdp.h>

ht1632c dm = ht1632c(&PORTF, 7, 6, 5, 4, GEOM_32x16, 2);

int status = WL_IDLE_STATUS;

char ssid[20] = "multik";  //  your network SSID (name)
char pass[20] = "MyVerySecretPassword";       // your network password
int timeshift=3; // GMT offset

unsigned int localPort = 2390;      // local port to listen for UDP packets

IPAddress timeServer(129, 6, 15, 28); // time.nist.gov NTP server

const int NTP_PACKET_SIZE = 48; // NTP time stamp is in the first 48 bytes of the message

byte packetBuffer[ NTP_PACKET_SIZE]; //buffer to hold incoming and outgoing packets
WiFiUDP Udp;

char clock[4];
int clockset=0; // does need to set clock from NTP?
int clockprocess=0; // we start asking clock server?

void setup() {  
  Serial.begin(9600);
  while (!Serial) {
    ; // wait for serial port to connect. Needed for Leonardo only
  }
  // check for the presence of the shield:

  while (WiFi.status() == WL_NO_SHIELD)
    Serial.println("NOWIFI");

  String fv = WiFi.firmwareVersion();
  if ( fv != "1.1.0" )
    Serial.println("FIRM");

  status = WiFi.begin(ssid, pass); // start connecting

  dm.clear();
  dm.setfont(FONT_8x16B);

  RTC.switchTo24h();
}

void loop()
{
  if(clockset==0)
  {
    //Serial.println("Setting clock");
    if(status==WL_CONNECTED) // ok, we online
    {
      //Serial.println("WiFi con");
      if(clockprocess==0)
      {
        Udp.begin(localPort);
        sendNTPpacket(timeServer); // send an NTP packet to a time server
        clockprocess=1;
      }
      else
      {
        if ( Udp.parsePacket() ) 
        {
          //Serial.println("packet received");
          Udp.read(packetBuffer, NTP_PACKET_SIZE); // read the packet into the buffer

          //the timestamp starts at byte 40 of the received packet and is four bytes,
          // or two words, long. First, esxtract the two words:

          unsigned long highWord = word(packetBuffer[40], packetBuffer[41]);
          unsigned long lowWord = word(packetBuffer[42], packetBuffer[43]);
          // combine the four bytes (two words) into a long integer
          // this is NTP time (seconds since Jan 1 1900):
          unsigned long secsSince1900 = highWord << 16 | lowWord;
          //Serial.print("Seconds since Jan 1 1900 = " );
          //Serial.println(secsSince1900);

          // now convert NTP time into everyday time:
          // Serial.print("Unix time = ");
          // Unix time starts on Jan 1 1970. In seconds, that's 2208988800:
          const unsigned long seventyYears = 2208988800UL;
          // subtract seventy years:
          unsigned long epoch = secsSince1900 - seventyYears;
          // print Unix time:
          //Serial.println(epoch);


          // print the hour, minute and second:
          //Serial.print("The UTC time is ");       // UTC is the time at Greenwich Meridian (GMT)
          //Serial.print((epoch  % 86400L) / 3600); // print the hour (86400 equals secs per day)
          int h=(epoch  % 86400L) / 3600;

          RTC.setHours(h+timeshift);
          //Serial.print(h);Serial.print(':');
          //if ( ((epoch % 3600) / 60) < 10 ) {
          // In the first 10 minutes of each hour, we'll want a leading '0'
          //Serial.print('0');
          //}
          int m=(epoch  % 3600) / 60;

          //Serial.print((epoch  % 3600) / 60); // print the minute (3600 equals secs per minute)
          RTC.setMinutes(m);
          //Serial.print(m);Serial.print(':');
          //if ( (epoch % 60) < 10 ) {
          // In the first 10 seconds of each minute, we'll want a leading '0'
          //Serial.print('0');
          //}
          int s=epoch % 60;
          //Serial.println(s);
          //Serial.println(epoch % 60); // print the second
          RTC.setSeconds(s);
          RTC.setClock();
          clockset=1;
        }
      }
    }
    //    else
    //    {
    //      Serial.println("WiFi NOT con");
    //    }
  }
  else
  {
    // Serial.println("Clock already setted");
  }
  int x=0;
  int clr=GREEN;
  delay(1000);
  RTC.readClock();
  sprintf(clock, "%02d", RTC.getHours()); // RTC.getMinutes(),RTC.getSeconds());

  dm.setfont(FONT_8x16B);
  dm.putchar(x,0,clock[0],GREEN,0,BLACK);
  dm.putchar(x+9,0,clock[1],GREEN,0,BLACK);  

  // first :
  dm.plot(x+18,4,clr);
  dm.plot(x+18,4+1,clr);
  dm.plot(x+18+1,4,clr);
  dm.plot(x+18+1,4+1,clr);
  dm.plot(x+18,4+4,clr);
  dm.plot(x+18,4+1+4,clr);
  dm.plot(x+18+1,4+4,clr);
  dm.plot(x+18+1,4+1+4,clr);

  sprintf(clock, "%02d", RTC.getMinutes()); //,RTC.getSeconds());
  dm.putchar(x+21,0,clock[0],GREEN,0,BLACK);
  dm.putchar(x+30,0,clock[1],GREEN,0,BLACK);
  // second :
  dm.plot(x+39,4,clr);
  dm.plot(x+39,4+1,clr);
  dm.plot(x+39+1,4,clr);
  dm.plot(x+39+1,4+1,clr);
  dm.plot(x+39,4+4,clr);
  dm.plot(x+39,4+1+4,clr);
  dm.plot(x+39+1,4+4,clr);
  dm.plot(x+39+1,4+1+4,clr);

  sprintf(clock, "%02d", RTC.getSeconds());
  dm.putchar(x+42,0,clock[0],GREEN,0,BLACK);
  dm.putchar(x+51,0,clock[1],GREEN,0,BLACK);

  dm.sendframe();
  //Serial.println(clock);

}

// send an NTP request to the time server at the given address
unsigned long sendNTPpacket(IPAddress& address)
{
  //Serial.println("1");
  // set all bytes in the buffer to 0
  memset(packetBuffer, 0, NTP_PACKET_SIZE);
  // Initialize values needed to form NTP request
  // (see URL above for details on the packets)
  //Serial.println("2");
  packetBuffer[0] = 0b11100011;   // LI, Version, Mode
  packetBuffer[1] = 0;     // Stratum, or type of clock
  packetBuffer[2] = 6;     // Polling Interval
  packetBuffer[3] = 0xEC;  // Peer Clock Precision
  // 8 bytes of zero for Root Delay & Root Dispersion
  packetBuffer[12]  = 49;
  packetBuffer[13]  = 0x4E;
  packetBuffer[14]  = 49;
  packetBuffer[15]  = 52;

  //Serial.println("3");

  // all NTP fields have been given values, now
  // you can send a packet requesting a timestamp:
  Udp.beginPacket(address, 123); //NTP requests are to port 123
  //Serial.println("4");
  Udp.write(packetBuffer, NTP_PACKET_SIZE);
  //Serial.println("5");
  Udp.endPacket();
  //Serial.println("6");
}

В итоге получилось вот это

015dbb46cc547788abd94e57ccc08f1ec8fa680f70

И видео

Что получилось в итоге? Часы запускаются и пытаются подключиться к WiFi с заранее заданным SSID и паролем. Как только им это удается, то они запрашивают NTP сервер о точном времени и как только получают ответ, обновляют соответствующие значения в RTC. А пока все это крутится, то часы просто берут уже сохраненное ранее время и показывают его.

Просто и дешево. Но для дальнейшей работы необходимо немного расширить функционал и научиться обрабатывать ошибки. К примеру, если WiFi есть, а интернета в нем нет и так далее. Ну и предусмотреть … скажем так, подключение внешних устройств, в качестве которых будет как минимум одна Raspberry Pi плата. Опять же, фотодиод для замера освещенности надо поставить …

В общем, есть что писать в следующем посте 🙂

Карпутер. 5. Пора программировать!

Что-то давно ничего не писал. Наверное, новогодние праздники помешали. Но алкомарафон закончился, поэтому неплохо бы вернуться к нашему контроллеру.

Отступать больше некуда, поэтому пора перенести наши наработки в реальность. Или говоря простым языком, заставить железный контроллер выполнять нашу задачу.

Так как программировать лучше дома, сидя в тепле и уюте, то я ничего сразу паять не буду. И более того. вам не советую. Лучше всего сначала все “обкатать” в контролируемой обстановке, когда возникновение ошибок сведено к минимуму.

Возьмем наш первоначальный алгоритм. Если напряжение поднялось больше 13В, то замкнуть реле ближнего света. Где мы тут можем ошибиться? Да везде – от подбора резисторов для делителя напряжения до распайки реле и неправильного подсоединения. Поэтому сокращаем возможность ошибки до минимума: вместо делителя напряжения бортовой сети воспользуемся обычным переменным резистором, а вместо реле – обычным светодиодиком. Как подключать – я уже писал в предидущем посте. Но если у вас, как и у меня, плата discovery, то там уже есть светодиодики (а значит, вероятность ошибки снижается еще сильнее).

Что бы не ошибиться и быть наглядней, я воспользуюсь макетной платой и специальными проводами для нее. Все это доступно там же, в любом магазине электроники.

01a9541850ca680e486975cc6dcf78e69f85d7241d

Как видно из фотографии, я подключил переменный резистор к GND и 3V, а вывод движка резистора – на PA1. В итоге даже в самом плохом случае, когда я выверну резистор “до упора”, на ножку контроллера попадут безопасные 3 вольта.

Теперь пора описать, где и как писать код. Открываем сгенерированный пару постов назад код и находим в левой панели фаил main.c. В нем ищем кусок кода while(1), как показано на картинке

p1

Вот все, что будет расположено между фигурными скобочками и будет выполняться бесконечно (для тех. кто знаком с ардуиной, это void loop()). Писать надо на языке С, обучать которому я тоже тут не буду.

Еще одно отступление – как управлять выводами. У ардуины есть кошмар под названием port mapping (это когда при смене контроллера все назания ножек меняются и программы перестают работать), на stm тоже до недавнего времени такой кошмар был. Именно был, сейчас все проще.

Итак, если вы посмотрите на микроконтроллер, что обнаружите, что ножки нумеруются от PA0 до PF15. Все функции используют следущую нумерацию ножек – Блок от А до F и номер ножки в блоке.

Переведение ножки PC12 в “высокое” состояние

HAL_GPIO_WritePin(GPIOC,GPIO_PIN_12,GPIO_PIN_SET);

А ножку PE15 – в “низкое”

HAL_GPIO_WritePin(GPIOE,GPIO_PIN_15,GPIO_PIN_RESET);

Выдаем на 1й канал ЦАП значение переменной s

HAL_DAC_SetValue(&hdac, DAC_CHANNEL_1, DAC_ALIGN_12B_R, s);

И мной написанная (или подправленная) функция для чтения значения АЦП

static int GetADCValue(uint32_t Channel,uint32_t Count)
{
int val = 0;
ADC_ChannelConfTypeDef sConfig;
sConfig.Channel=Channel;
sConfig.Rank=1;
sConfig.SamplingTime=10;
HAL_ADC_ConfigChannel(&hadc,&sConfig);

for(int i = 0; i < Count; i++) { HAL_ADC_Start(&hadc); HAL_ADC_PollForConversion(&hadc,1); val += HAL_ADC_GetValue(&hadc); } return val / Count; }

Как видно из кода, работает только с ADC1 (ссылки hadc).

В посте описать все невозможно, поэтому рекомендую заглянуть в "Firmware", которую скачал STMCube, и посмотреть там примеры.

Итак, вот мой код

if(GetADCValue(2,3)>2048)
{
HAL_GPIO_WritePin(GPIOE,GPIO_PIN_15,GPIO_PIN_SET);
}
else
{
HAL_GPIO_WritePin(GPIOE,GPIO_PIN_15,GPIO_PIN_RESET);
}

В чем его суть? Если значение, которое прочитали из АЦП, больше 2048, то перевести ножку PE15 на высокий уровень. Если меньше, что наоборот, на низкий.

В чем магия? Магия в двух вещах. Первое, это значение АЦП. Оно может быть от 0 до 4095 (3В на ножке). Как им распорядиться, решать вам. А второе - ножка PE15 на плате подключена с зеленому светодиоду.

Компилируем, заливаем (иконка с буковками LOAD во втором ряду) и наслаждаемся своей первой программой.

Сам код (полностью готовый и скомпилированный) можно взять отсюда http://multik.org/carsim/carputer.rar

Что дальше? А дальше пишем, отлаживаем и снова пишем. Пока не будет готово то, что требовалось изначально.

Желаю удачи в написании своих проектов!

А я чуть попозже напишу о том, как перенести написанное в "железо". Печатные платы и прочие радости радиогубителей 🙂

Карпутер 4. Кормим микроконтроллер

Сегодня пост будет самым зубодробительным для большинства автомобилистов. Придется вспомнить школьную физику за 5й класс и закон Ома оттуда. Но я покажу, где взять помощи 🙂

Итак, перед нами стоит 3 задачи.

1) Накормить микроконтроллер.
2) Дать данные. То есть позволить микроконтроллеру собирать всякую нужную ему информацию.
3) Позволить ему чем-либо управлять.

В чем основная проблема? Проблема как ни странно, в бортовой сети автомобиля. Напряжение в ней гуляет от 9 вольт до 14,5 вольт с возможными выбросами до 60 вольт. Попутно в этом самом “напряжении” есть куча шумов, всплесков и прочей гадости.

А микроконтроллеры очень нежные. Питаются только 5ю вольтами или 3,3мя. И желательно, что бы эти вольты не гуляли туда сюда больше 5%. То же самое и с входами-выходами. Те же самые условия, только еще желательно, что бы ток, проходящий по ним, не превышал единицы миллиампер. В случае необходимости ток может быть поднят до десятка-другого миллиампер, но это уже черевато.

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

Для питания “на быструю руку” давно придуманы готовые схемы. В любом приличном магазине электроники можете произнести слово “L7805” и вам за 10-15 рублей вынесут маленькую черную штучку, которая получает на входе от 8 до 30 вольт, а на выходе выдает стабильные 5 вольт. Вот тут (multik.org/carsim) вам собранная в proteuse схема на поиграться (carsim-power).

car-power1

Сколько бы вы не давали на “вход” напряжения, на выходе всегда будет около 5В. В чем подвох? Подвоха два. Во-первых, на холостом ходу (когда к ней ничего не подключено) эта штука потребляет единицы миллиампер. Для обычных условий эксплуатации это нормально, а вот если делать что-то типа сигналки, когда схема постоянно подключена к аккумулятору, это .. некрасиво. Во-вторых, если вы задумаете “снимать” с стабилизатора 1-1,5 ампера (хинт – это почти готовая зарядка для телефона), то вы внезапно обнаружите, что стабилизатор греется. Почему? Потому что он вынужден куда-то тратить те вольты, которые оказались ненужными. Считайте сами: пусть будет в бортовой сети 13,4 вольта. Телефон хочет 5В и 1А для своего заряда. Значит стабилизатору надо рассеять где-то (13,4-5)*1=8,4 ватта. Это вполне себе нехилая грелка. И именно поэтому у этого стабилизатора есть металлическое ушко, за которое его прикрепляют к радиатору (Кстати, радиатором может быть любая массивная железная часть автомобиля). Но повторюсь, для обычных применений это вполне себе штуковина.

Но если мы заранее задумаемся о снижении напряжения и тока питания, то есть варианты. К примеру LP2950. Он включается точно так же, как и 7805, но во-первых, на холостом ходу ест десятки микроампер, а во-вторых, больше 100 миллиампер с него не снять. Для многих схем этого может хватить.

Но что делать, если по каким-то причинам надо больше 1,5 ампер и радиолюбителей (что бы собрать блок питания) нет под боком? Тогда на выручку придут готовые DC-DC преобразователи. По сути это собранные и оттестированные блоки питания в миниатюрных корпусах. Например NSD15-12S5 (вход 9.4-36В, выход 5В и 3А) или наш МПА15А (вход 9-18В, выход 5В и 3A). На самом деле их куча, стоит только поискать. В чем их плюсы? Ну, они не греются, имеют встроенные фильтры, управление, защиту от КЗ и прочее, что полагается иметь блокам питания. Основной их минус в цене: от тысячи рублей и выше.

В своих схемах я пользуюсь всеми вышеперечисленными вариантами, но обычно тяготею к первому – больно дешево и просто.

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

Первый: делитель на резисторах. Просто ставим в цепь два резистора, в точке их соединения забираем данные. Уровень напряжения в точке будет равен входному напряжению * соотношение номиналов резисторов. А ток можно подсчитать по закону Ома – i=u/r Опять же, я понимаю, что это тяжко, поэтому вот очередная схема в протеусе, которая позволит “поиграться” (там же файл carsim-power-res). Ну или набрать в поисковике “калькулятор делителя напряжения”.

carsim-power-res copy

Справа можно увидеть амперметр (показывает миллиамперы) и вольтметр. Наша задача – добиться таких сочетаний резисторов R1 и R2, что бы на микроконтроллер не приходило больше 3В (если ардуино, то 5) и потребление тока было минимальным (а то так повесим с десяток датчиков, сжигающих на резисторах по 10 миллиампер и получим 0,1 ампера, способных посадить аккумулятор в “ноль”). Казалось бы, простая задача? Но давайте снова посмотрим на то, что может происходить в бортовой сети. От 9 до 60 вольт … Если сделать совсем классический вариант, то 99% времени напряжение на ножке контроллера будет составлять доли вольта. Как-то некрасиво.

Поэтому обычно рассчитывают делитель на входное напряжение 0-15В, а всплески (которых может и не быть) убирают отдельным элементом. Есть много схем, но я предпочитаю самую простую в изготовлении: на вход, перед делителем, ставлю защитный диод (он же супрессор, он же TVS). Скажем, китайский SA15 пропускает через себя все, что попадает в диапазон 0-15 вольт. Остальное он убирает и убирает довольно качественно (в смысле после него конденсатор если и нужен, то только для сглаживания). Минус у него только один – если что, то он (диод) превращается в простое короткое замыкание, заставляя сгорать всё что можно перед собой. Для 99% случаев этого достаточно, а для оставшегося 1% существуют предохранители. Схемы я нарисую в следующем посте.

ВАЖНО: нельзя использовать “делители напряжения” для схем, где есть напряжения больше нескольких десятков вольт. Просто небезопасно для здоровья. Для этого есть второй вариант.

Вторым вариантом ввода сигнала в микроконтроллер является оптопара. Внутри оптопары стоит светодиодик, который своим светом управляет транзистором, “включая” или “выключая” выходы. У оптопары главный плюс в следующем: легко можно измерять наличие сотен и тысяч вольт. Самая обычная оптопара легко “развязывает” до 1500 вольт. Минус же тоже существенный: с её помощью нельзя (практически, да) измерять уровень сигнала. Только “есть” или “нет”.

Кнопки и прочие выключатели обычно присоединяются в микроконтроллер напрямую – там обычно неоткуда возникнуть “бякам”. Если возможность есть, то либо опять поставить на входе супрессор, либо стабилитрон с керамическим конденсатором. Опять же, страшные схемы в следующем посту.

С вводом разобрались. Теперь с выводом. Сначала я начал писать свой текст, но потом вспомнил, что есть отличный пост на эту тему. Не мой, но это же не повод не считать его отличным?

062-Как подключить к микроконтроллеру нагрузку?

Моими любимыми способами являются использование “составного транзистора Дарлингтона” и “полевой транзистор”. Тут их переписывать не буду, ибо все прекрасно описано по ссылке выше. Мой выбор между способами простой: если надо коммутировать что-то до 5-10 ампер или быстро включать-выключать, выбираем транзистор. Выше – реле через составной транзистор. Быстро включать-выключать большие нагрузки мне не приходилось, но думаю, схем на всяких тиристорах и симисторах навалом.

Что бы проиллюстрировать вообще все вышеприведенное, вот вам очередная схема (она же в файле carsim-final)

carsim-final

Думаю, вдумчиво читающим уже почти все понятно, но на всякий случай прокомментирую. Слева вверху я сымитировал бортовую сеть автомобиля. Можно переключиться на 12В, 13,4, 16В и на регулируемое. Правее – стабилизатор напряжения на 5В. Слева внизу – делитель напряжения на резисторах R1 и R2 и развязка через оптопару U2. Правее стабилизатора две схемы включения нагрузки – через N-канальный полевой транзистор IRF610 и через сборку Дарлингтона ULN2003A.

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

В общем, схема выглядит достаточно страшной, что бы напугаться окончательно, особенно с непривычки. Но открою страшный секрет: для отладки нашей первоначальной задачи достаточно к плате с микроконтроллером дополнительно прикупить обычный переменный или подстроечный резистор на 500 Ом и выше. Индикатором срабатывания будет “пользовательский” светодиод, который есть на большинстве плат. Но как обычно, об этом в следующем посту.

Карпутер. 3. Выбираем микроконтроллер.

Итак, со схемами в proteus наигрались, теперь голова полна идеями, хотелками и желалками. Но ни одна идея не реализуется сама собой, поэтому надо выбрать “движок” для нее.

Как выбирают контроллер?

Во-первых, по личным предпочтениям. Кому-то нравится одна архитектура, кому-то другая. У кого-то уже есть опыт с одними микроконтроллерами и ему лень изучать другие … Но я считаю, что раз опыта и предпочтений нет, поэтому – stm32. Вам на данном этапе все равно, а мне потом спасибо скажете.

Во-вторых, по скорости. Если задача сложная, то думаю понятно, что работающий на 72МГц контроллер обгонит работающего на 16МГц (грубо – у кого больше литраж у двигателя, тот быстрее разгонится или больше увезет). А если устройство работает от батареек, то наоборот, устройство работающее на 16МГц легко даст фору работающему на 72х (опять же, чем больше литров, тем чаще на заправку надо будет ездить). Но на данном этапе нам совершенно все равно, какая скорость у контроллера – для нас подойдет любая.

И наконец, по числу портов и их возможностями. Все порты делятся на два типа: цифровые и аналоговые. Цифровые оперируют уровнями типа “есть сигнал” и “нету сигнала”, а аналоговые – “какой уровень у сигнала?”. Говоря другими словами – кнопки, выключатели и прочие переключатели – это цифровые, а всякие регуляторы, измерители и прочее – аналоговые. На каждую кнопку, релюшку или измеритель надо по одному порту (конечно, есть куча возможностей, как от этого уйти, но пока нам этого не надо). И крайне рекомендую при выборе зарезервировать пару портов под всякие доделки и внезапно всплывшие идеи.

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

Что будем делать-то? В смысле для чего мы все это затеяли? Давайте начнем с простого. Пусть будет система автоматического включения света в машине. Как пример использования: садимся в машину, включаем зажигание, заводим машину и через некоторое время наш контроллер включает фары. Выключили зажигание – все выключилось. Сплошные бонусы: стартеру легче крутить двигатель – фары не отбирают лишних ампер и вам не надо будет помнить о включении фар.

Какой будет алгоритм работы?

1. Измеряем напряжение бортовой сети
2. Напряжение меньше 13В? если да, иди на п.1
3. Подождать 5 секунд.
4. Включить фары.

Все, никаких заморочек. Просто и совсем не страшно. Как видно, нам потребуется всего 2 порта: один аналоговый для измерения напряжения в сети и один цифровой, для управления релюшкой фар.

(отступление) Не хотите фары включать? Ну тогда например можно автоматически включать и выключать компрессор в пневмосистеме. Или в зависимости от температуры включать нагреватель или вентилятор. В общем, подойдет любой вариант “измерил что-то и как это что-то достило такого-то уровня – включил или выключил нечто”.

Вернемся к нашим баранам. Нам нужен микроконтроллер, у которого есть как минимум 1 аналоговый порт на вход и 1 цифровой порт на выход. Сейчас смешно, да. Но потом всего будет не хватать и начнутся мучения.

Теперь готовимся скачать много из сети. Для начала нам нужна программа STM32CubeMx. (Все поисковики ее легко находят, но вот прямая ссылка http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1533/PF259242?sc=stm32cube там мотайте страницу в самый низ и справа будет маленькая красная кнопочка Download).

Зачем нужна эта программа? Как я писал в первом посте, STM32 имеют один, но очень большой и неприятный минус – очень сложно начать с ними работать. В этих микроконтроллерах очень много возможностей и вариаций, поэтому даже просто запустить его составляет очень большую проблему. Команды инициализации, предназначенные для одной серии, не подходят для другой. Один и тот же порт может выполнять разные функции на разной частоте, причем все это настраивается в четырех или пяти местах. В общем, реальный кошмар после атмеловских контроллеров и 99% причин неработащих программ.

Вот и придумали этакий “генератор кода инициализации”, когда можно мышкой не торопясь повыбирать порты и их функции. При этом идет одновременный контроль правильности использования порта и непересечение его с другими функциями. В общем, скачивайте, распаковывайте и запускайте программу (может потребовать java, так что тоже ставьте). Как ставить программы, нажимая next, я рассказывать не буду 🙂

stmcube1

Перед вами откроется очень информативное окно. New Project – это создать новый проект, Load Project – загрузить старый, который редактировали раньше. Нам естесственно надо выбрать создать новый. И тут …

stmcube2

И тут перед вами откроется окно, в котором собрана вся (почти) линейка микроконтроллеров. Первая вкладка – MCU Selector позволяет выбрать подходящие контроллеры в их голом виде. Слева в табличке функционал, справа – подходящие контроллеры. Скажем, нужно нам в нашем проекте использовать одновременно ethernet и часы реального времени, так значит ставим галочки и получаем, что нам подходят 88 микроконтроллеров из 590 (на момент написания). Но эта вкладка для продвинутых пацанов.

Нам нужна следующая вкладка, которая называется Board Selector. Тут уже можно выбрать готовые платы, со всем распаянным. Сразу рекомендую нажать кнопку “>>”, которая будет показывать изображение платы.

stmcube3

Механизм тот же самый – слева выбираем что хочется, а справа получаем список того, где это есть. Потом открываем веб-сайт ближайшего магазина электроники и смотрим на наличие и цену. Лично у меня есть платы STM32L100 и STM32F3 (именно она изображения на скриншоте). Так как F3 мне нравится больше, то и в дальнейшем я буду использовать именно эту плату. Но повторюсь, вы можете использовать любую плату или процессор – главное, что бы он вам подошел по характеристикам.

Выбрав плату или процессор, жамкаем на кнопоку ОК в самом низу. Компьютер немного подумает и потом выдаст примерно вот такую картинку.

stmcube4

Слева будут всякие возможности, которые умеет процессор, а справа – как и на что распределены ножки и процессора. Если вы вышли сюда из выбора плат, то программа сама показала, что на плате куда подключено. Как видите, все ножки помечены разными цветами.

Желтенькие и светлозеленые – ножки, назначение которых изменить нельзя. Питание, земля и прочие подобные ножки.
Оранживенькие – ножки, на которые повешено то, что есть на плате и что можно либо отключить, либо заиспользовать. У меня это кварцевые резонаторы, гироскоп с компасом, USB порт и так далее.
Зелененькие – это ножки, на которые тоже повешено то, что есть на плате, но это ТО – кнопки, светодиодики и прочее. Грубо говоря, отличие только в сложности с точки зрения контроллера. Таким же цветом будут обозначаться и ножки, которые вы выделили для вашего проекта.
Серенькие – свободные ножки, которые можно использовать.

“Пришпилленость” ножки означает, что программа не может менять ее назначение, как бы этого ей не хотелось. Дело в том, что если у вас нету предпочтения, какой именно порт для чего использовать, то программа постарается “раскидать” их так, что бы микроконтроллер был наиболее функциональным.

Как менять назначение ножек? Есть два способа. Первый – это просто мышкой ткните на ножке. Вот для примера я ткнул на ножке, которая у меня подключена к голубой кнопке.

stmcube5

Как видите, эта ножка может выполнять аж 17 функций, но сейчас она работает как GPIO_Input (я ниже объясню, что это значит).

А второй способ – воспользоваться левой вкладкой и включить нужную функцию.

stmcube6

Как видим, у функции вообще горит желтый предупреждающий знак, который показывает, что что-то с ней не то. Открыв ее, можно увидеть подсвеченным красным подфункцию. В данном случае это IN1. Подведя мышку к красному, можно узнать, что с чем конфликтует. В данном конкретном случае можно увидеть, что 1й канал 1го аналого-цифрового преобразователя конфликтует на ножке процессора PA0, которая уже стоит в режиме GPIO_Input. Белиберда, да? Но ничего. Для примера можно обидеться и раз нам не дают использовать IN1, выбрать IN3, что бы это не значило. И обратите внимание, на рисунке процессора справа одновременно начнет показываться как “занятая” соответствующая ножка процессора. В нашем случае это PA3, в левом нижнем углу.

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

Итак, как же понять, какие функции можно повесить на ножку? Что бы не забивать голову, я опишу только наиболее нужные и часто используемые функции. Назначение других можете узнать сами, когда прижмет (но 90% это никогда не понадобится).

Итак, что можно выбрать?

ADC – Или АЦП, аналогово-цифровой преобразователь. Показывает значение напряжения. У большинства АЦП есть каналы, к которым он может подключаться. А каналы напрямую подключены к ножкам. То есть когда вам надо измерить напряжение на 1,2 и 3й ножке, то микроконтроллер на самом деле будет выполнять примерно следующее “подключить ацп к ножке 1, измерить, подключить ацп к ножке 2, измерить, подключить ацп к ножке 3, измерить”. В принципе, для большинства задач этого достаточно, ведь измерение одного канала занимает от 1 до 10 мс. Но есть задачи, когда необходимо реально одновременно измерить напряжение на несколких ножках. В таком случае используют два или больше АЦП. Например, в F3 серии аж 4 АЦП, поэтому мы можем измерять 4 уровня одновременно. Если мы заиспользуем все доступные ресурсы, то сможем за 0,1с измерить 59 аналоговых выводов (ардуинщики, вы рыдаете? :).

DAC – или ЦАП. Цифро-аналоговый преобразователь. Преобразует некоторое значение в уровень сигнала на выходе. Обычно один DAC имеет от 1 до 10 выходов, каждый из которых можно регулировать отдельно.

TIM – таймеры. Срабатывающие “раз в нное время” сигналы. На таймерах в stm делается очень многое – от PWM (управление сервомоторами и яркостью) до подсчета частоты смены сигнала на входе. Немножко к ним имеют отношение RTC – часы реального времени (которые считают минуты и секунды, а не тики и такты) и WDG – системы, которые автоматически перезагружают контроллер, если он завис, но я их касаться не буду

USART/UART – контроллеры для связи с “внешним миром”: с компьютерами, с другими контроллерами и так далее.

И наконец GPIO. Это порты общего назначения. То есть на них можно вешать все, что душе угодно. Они могут быть GPIO_Input – порт, работающий на вход (который принимает сигнал “есть” и “нет”) и GPIO_Output – порт, работающий на выход (который выдает сигнал “есть” и “нет”). Вы можете увидеть GPIO_Reset – это означает, что порт находится в хз каком стоянии и GPIO_EXTI – это выход прерывания. В общем лишнее на данном этапе.

Все ножки маркируются следующим способом: [подсистема]_[функция]. Пример:

ADC1_IN6 – 6й вход 1го АЦП контроллера
DAC1_OUT1 – 1й выход 1го ЦАП контроллера
USART1_TX – порт передачи 1 контроллера связи.

Но вернемся назад. Из всего выше перечисленного нам нужен один ADC ввод и один GPIO_Output вывод. Для ввода я заиспользую ADC1_IN2 (ножка PA1), а для вывода GPIO_Output – PC5. Они расположены на одной стороне реальной платы, поэтому мне будет удобно с ними работать. И что самое главное, они не конфликтуют ни с чем, что уже есть на плате.

stmcube7

Щелкаем и меняем назначение нужных нам ножек. Обратите внимание на то, что у PA1 нет булавки, а у PC5 – есть. Это та самая функция переназначения портов, когда вдруг функционал будет конфликтовать, а нам нет разницы, откуда его брать. Что бы “прикрепить” функционал к ножке, надо просто правой кнопкой мышки по ней щелкнуть и выбрать Signal Pinning. Теперь ни одна сволочь не отберет у нас ее :). Кстати, там же можно и дать название ножке, что бы не запутаться.

stmcube8

Согласитесь, так немного красивее? И так по всем ножкам-функциям, которые нам потребуются в нашем будующем устройстве. Не подходит что-то – возвращяемся назад и выбираем другую плату/микроконтроллер. Но я буду считать, что мы этот этап успешно преодолели и с большим трудом выбрали и назначили так нужные нам аналоговый порт на вход и цифровой порт на выход.

Можно сохранить проект на всякий случай, ибо это только начало.

Теперь щелкаем следующую вкладку – Clock Configuration. И у некоторых сейчас порвет мониторы 🙂

stmcube9

На этой вкладке вы можете увидеть, с какой скоростью работают внутренности микроконтроллера. Эта вкладка очень полезна тогда, когда мы озабочены энергопотреблением микроконтроллера. Играясь тут, можно легко на порядок понизить энергопотребление микроконтроллера. Но нам это не надо, поэтому переходим на следующую – Configuration

stmcube10

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

На картинке мы видим включенный контроллер ADC1 (для него нужны контроллер DMA, NVIC и RCC) и контроллер GPIO (Для него нужен RCC). В общем, давайте поверим, что нам это надо.

На этом экране у нас есть возможность тонкой настройки. Жмем на ADC1

stmcube11

Тут собраны все тонкие настройки для данного контроллера. Особо менять нечего, за исключением подсвеченного – Continuous Conversion Mode. Поставьте его в Enabled. Данная галочка говорит, что мы желаем запрограммировать контроллер так, что бы он постоянно мерял свои входы. И более того, измерянные значения сразу присваивал переменным. Ну ленивый я, пусть железка сама все делает 🙂

Аналогичную картинку можно получить и по GPIO портам.

stmcube12

Тут можно тоже поизменять разные параметры, но нам тут менять тоже ничего не надо.

В общем, полезная вкладка, особенно когда начинаешь использовать более сложные вещи, как USART или USB – здесь можно настроить все.

И наконец, последняя вкладка – Power Consumption Calculator. Тут можно прикинуть, сколько электричества будет потреблять микроконтроллер.

stmcube13

Но подчеркиваю, именно прикинуть. Ибо система не знает, сколько потребляет то, что еще подключено к этому контроллеру. На приведенном выше скриншоте я уже понажимал все кнопки. Согласно картинке, если мы ничего не будем подключать к этому микроконтроллеру, то на полной мощности он будет потреблять 30 миллиампер. Или говоря другими словами, от одной батарейки АА он проработает 3 с лишним суток. И это я не тыкал в различные режимы энергосбережения …

Итак, остался один последний шаг. Сгенерировать исходный код, котрый будет компилироваться и прошиваться в контроллер. На панели сверху есть кнопка “шестеренка с палкой”. Нажимаем ее и …

stmcube14

Заполняем, где будут располагаться файлики и как мы обзовем проект. Так же выберем, для какой среды разработки будет генерироваться исходный текст. Выбор небольшой и все предлагаемые системы – полный шлак (тут конечно у каждого свои фломастеры, но тот же бесплатный CoCox уделывает Keil как бог черепаху), поэтому выберите MDK-ARM, как наиболее описанную в русском интернете.

Если вы запускаете генерацию в первый раз, система предложит скачать Firmware Package именно для вашего процессора. Ждем пока скачает и нагенерирует.

stmcube15

Увидели это окошко? Поздравляю! Вы прошли большую часть пути. Остался еще один шаг. Всего один …

Открываем браузер на https://www.keil.com/download/product/ и выбираем MDK-ARM v5. Вам дадут анкету, в которой реально проверяется только email. Проверяется – в смысле их сервер подключается к вашему серверу и проверяет валидность ящика, поэтому емайлы типа 2@1.co не проходят. Остальное нужно только для того, что бы выбрать, на каком языке потом вам напишет продавец со словами “купите у нас”. Как обычно, у данной версии есть ограничения и самым главным из которых является ограничение в объеме кода в 32 килобайта. Поверьте, это довольно приличный объем для микроконтроллеров и вам его хватит надолго. Но если вас это напрягает, то сами знаете где можно найти вылеченную версию совершенно бесплатно.

На данном этапе можете спокойно идти пить чай. Версия, которую вам предлагают, занимает 500 мегабайт и скачаться мгновенно не может. А самизнаетекакая версия занимает еще больше, потому что в нее напихали всякого нужного и ненужного.

Как обычно, рассказывать как ставить программы с помощью нажатия кнопки next, я не буду. Единственное, что при первом запуске вылезет Packs Installer – дождитесь, пока он отработает и закрывайте его. Так что ставьте Keil и в той папочке, куда сохранили проект, найдите каталог Projects, в нем MDK-ARM и там ваш файл с типом mVision4 Project. Нажимаем на него …

stmcube16

Я тут его немного сплющил, но вы увидите именно это. Теперь нажимаем на кнопочку, которая во втором ряду, под “открыть”. Похожа на папку для бумаг, в которую входит стрелочка. Ну или на клавиатуре F7. Этим мы запускаем компиляцию всего того, чего мы нагородили выше.

stmcube17

И только после того, как вы увидели в окошке снизу строчку 0 Errors(s), 0 Warning(s) вы можете поздравить себя – у вас есть полностью готовая прошивка для микроконтроллера. Ну и что, что она пока ничего не делает, зато 90% нашей первоначальной задачи уже выполнено. Теперь вы можете идти в магазин и покупать реальный микроконтроллер за реальные деньги. И у вас есть уверенность, что он заработает.

А вот как и что подключать к контроллеру – это уже в следующем посте.

Карпутер. 2. Все не так страшно …

Отписываясь на форумах, я обнаружил что после предложений “давай сделай, это же не сложно” получал в ответ “не, у меня с электричеством плохо, боюсь чего-нибудь сжечь” или другие подобные ответы. Товарищи, господа и пацаны! Поверьте, автомобиль по своей сути – набор проводков, предохранителей и выключателей. Даже “мозги” машины внутри себя состоят из большого количества выключателей. Так что придется сделать отступление и помочь овладеть этими переключателями.

Раз вы читаете это, значит у вас есть компьютер и браузер. Открываете браузер и идете на http://www.labcenter.com/. Там все по английски, но вам нужен раздел Downloads, а там скачать prodemo.exe. В этом здоровом файле находится редактор схем и печатных плат. А так же симулятор этих самых электрических схем. То есть вы можете как угодно “коротить”, “вешать сопли” и развлекаться другими способами: никакого урона электронике вы не нанесете.

proteus_screen

Со скачанным с сайта есть одна засада: он не сохраняет и не печатает нарисованного. Но в интернете можно найти уже вылеченное и даже руссифицированное. Если сами не можете, спросите и вам ответят. В интернете же легко можно найти и инструкции, как и что делать с ним, поэтому я буду очень короток. Нет, я пойду другим путем.

Вот тут http://multik.org/carsim/ лежит готовый проект для proteus (просто скачайте файл carsim.dsn и кликните на нем – он откроется в proteus). Он довольно приблизительно имитирует электропроводку обычной машины. Знающие электрику начнут кривить носом и искать ошибки (а они там есть), а незнающие могут нажать слева внизу кнопочку “play” (треугольник вправо, если кто не понял) и поиграться. Поиграться в буквальном смысле: выключатели выключают и включают лампочки, а пипикалка пипикает.

При этом схема полностью отражает реалии: скажем, можно заменить предохранитель на имеющий более низкий номинал (Выделите мышкой предохранитель и нажмите Ctrl-E, там увидите что-то типа 2А) и увидеть, как он сгорает при попытке включить нагрузку.

Итак, что бы было понятно что к чему, пройдусь по схеме слева-направо.

proteus1

Здесь имитация генератора и ключа зажигания (SW1), аккумулятора и отключателя массы (SW2) вместе с главным предохранителем. Вольтметр показывает напряжение в “бортовой сети”.

proteus2

Тут имитация работы ближнего и дальнего света. Переключатель SW3 имеет три положения – выключено, ближний свет и дальний свет. Лампы L1 и L2 отвечают за “ближний”, а L3 и L4 – за “дальний”.

proteus3

Эта часть имитирует салонный свет. 5 выключателей – это концевики дверей и багажника. Пока любой из них замкнут (соответствующая дверь открыта), будет гореть свет в салоне или лампочка L5.

proteus4

Здесь можно поиграться с “уровнем топлива в баке”. Красивой стрелочки я не нашел, поэтому можете считать вольтметр за цифровой индикатор уровня горючего.

С последней частью предлагаю разобраться самим, главное громкость поменьше сделайте 🙂

Итак, я буду считать, что наиболее нетерпеливые наигрались, а некоторые даже пошли читать инструкции или даже смотреть (в гугле “proteus начинающим” выдаст все необходимое).

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

Кнопки. Бывают нормально замкнутые (концевики в дверях) и нормально разомкнутые (кнопка сигнала). Принцип простой: нажал, она сменила состояние (замыкала цель – теперь размыкает) и будет в таком состоянии, пока ее не отпустить.

Выключатель. Такой же, как кнопка, только состояние фиксируется (держать не надо)

Переключатель. Полностью аналогичен выключателю, только коммутирует несколько выходов. Пример – SW3 выше. Или замок зажигания.

Енкодер. Тот же переключатель, только после переключения на последний выход начинает с первого. Самое распространенное применение – крутилки громкости на современных магнитолах. Можно вращать в любую сторону сколько угодно раз.

Переменный резистор (он же переменное сопротивление). Штука, меняющая свое сопротивление в зависимости от каких-то условий. Наиболее распространенный пример – датчик уровня топлива. Много топлива – сопротивление маленькое, мало – сопротивление большое.

И … в принципе все. Все остальные датчики можно рассматривать как комбинацию предидущих. Скажем, датчик Холла (используется как датчик скорости в раздатке/коробке и на колесах) – для наших целей это тот же самый переменный резистор, только его переменность зависит от магнитного поля. Датчик температуры – это выключатель или опять же резистор, состояние которых зависит от температуры. Датчик дождя – это резистор, который реагирует на отраженный каплями воды свет от стоящего рядом светодиодика.

Да, особняком стоят всякие OBD, CAN и прочие, но там все в цифре и я этого коснусь потом.

Как читать разные датчики я опишу через пару постов. Сейчас могу упомянуть только то, что из-за нежности микроконтроллеров ничего нельзя подключать “напрямую”.

С обратным управлением все гораздо проще: микроконтроллеры “дохлые” и поэтому без транзисторов/релюшек не обойтись вообще никак. Типовые схемы я тоже опишу.

Согласитесь, совсем не страшно же? Тогда в следующем посту будем выбирать конкретный микроконтроллер под ваши нужды.

Карпутер. 1. Предисловие и выбор микроконтроллера

Хотел начать с обычного отсыла к классике (“этим постом я начинаю …”), но потом передумал. Начну обыкновенно.

Итак, после продажи машины и разборок с банком у меня появилось немного свободного времени, которое тут же начали заполнять мысли о не сделанном и недоделанном. А недоделанного у меня оказалось прилично: от дописывания диагностики машины через OBD и заканчивая переводом “из соплей на скрутках” различных доделок для машины.

С одной стороны, можно просто взять и забить на все это, ибо машины уже нет и тестировать особо не на чем. А с другой стороны, машина потом появится и снова вспоминать, чего не доделано и где это недоделанное валяется? Ну и свободное время позволяет более подробно описать тот путь, который может быть кто-то будет повторять.

Для начала я решил составить список того, что у меня недоделано (просто скопирую из форумных постов)

1) Контроллер второго аккумулятора. Штука с вольтметрами, контролирующая подключение второго аккумулятора. Есть подобная у t-max, но она вся в светодиодиках и тупая. Алгоритм грубо говоря такой: смотрим на напряжение на первом аккумуляторе, как превысило 13В (значит завелись), подключаем второй (для зарядки и теде). Если на первом долгое время 12В, значит можно отключить второй — мы на стоянке. Если ниже, то не отключать — мы лебедимся и второй аккумулятор нужен. Ну и кнопочка принудительного подключения второго, если первый на стоянке разрядился по каким-то причинам. У водителя индикатор с вольтами и кнопочка.

2) “Сумматор баков”. У многих машин есть два источника горючки (скажем, бензин и газ), а у некоторых их три (два бака с бензином и газ). Суть — выводить на штатный указатель уровня сумму уровней баков. Например, от нуля до четверти — первый бак, от четверти до половины — второй и от половины до полного — газ. Или еще как. Дополнительно выравнивание нелинейности датчиков уровня, когда то стрелка не двигается, то начинает падать. И специальная фича для патриотоводов — обработка уровня “приборка пикнула” так, что бы она не пищала при каждом торможении-разгоне.

3) “Корректор спидометра”. Меня напрягает 10-15% погрешность спидометра даже на штатных колесах. Меня напрягает нелинейность этого вранья. И стоит сменить размерность колес, как все привычки типа “раз стрелка на 90, значит я еду 85” приходится “перепривычивать”. Дополнительно была мысль сделать вывод “поехали — включи ближний свет/ДХО”, что бы не дергать переключатели руками и не зажигать фары перед заводом зимой.

4) “удлинитель выключателей”. Грубо говоря — управляемые удаленное релюшки. Например поставил свет вокруг, и к нему вместо кучи силовых проводов тащишь один силовой потолще и один управляющий. Или для компрессора сзади или для усилителя … в общем, везде, где надо управлять чем-то мощным и это мощное далеко от водителя.

Поначалу я хотел сделать все это по принципу “одна задача – один контроллер”. Причем навскидку получалось, что с любой из этих задач в одиночку справится практически любой микроконтроллер, доступный к покупке в магазине.

Но после прикидывания схем внезапно выяснилось, что очень многие функции дублируются. Скажем, для многих применений полезно знать напряжение в бортовой сети. И как индикатор для ответа на вопрос “заведен ли двигатель?” и как точку отсчета для некоторых корректировок. И если собрать 5 схем, то что, к аккумулятору тянуть 5 проводов от разных точек? А как настраивать все это безобразие? Городить кучу кнопок и выключателей и обрамлять все это светодиодами?

В общем, постепенно я пришел к идее “один микроконтроллер на всё”. Поначалу я опасался того, что эта электронника нежная, не любит автомобильных условий … Но годовые испытания в режиме “вот счас доделаю” показали, что обычный микроконтроллер “из магазина” спокойно переносит условия в машине и вообще, его поведение очень сильно отличается от моих первоначальных представлений.

Ну раз один микроконтроллер на все, то надо выбирать, на чем делать. Опыт у меня большой, поэтому имею возможность сравнить. Ну вот и сравниваю.

Attiny, они же tinyAVR контроллеры. Основной их плюс – в распространенности. Они существуют в разных корпусах, с разным числом выводов, есть куча примеров схем и кода. Из минусов можно отметить то, что из-за широкой номенклатуры нет решений “все в одном”. И в итоге получается, что даже для изготовления одной схемы надо покупать отдельный программатор, разбираться с фьюзами и прочим. А это все стоит денег (скажем один более-менее приличный программатор стоит на порядок дороже контроллера) и окупается только на десятках собранных схем. Но для простых задач им нет равных.

AtMega или Adrduino. Те же самые плюсы, что и у “тинек”, но добавляется то, что все решения уже идут готовыми. Подключил плату к компьютеру, настучал в окошке код и он уже выполняется. Главный минус же состоит в том, что все эти решения рассчитаны на “сделал максимально быстро, не считаясь с затратами”. Отсюда совершенно дикие цены как на сами платы, так и на модули расширения (shield, шилд). Скажем, самая дешевая плата в классическом (для ардуинки) формате стоит от тысячи рублей, при этом функционала на ней – кот наплакал. А цены на самые дорогие, с чуть-чуть большим набором портов легко упрыгивают за сотню баксов.

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

Следующими идут миниатюрные компьютеры. Paspberry Pi, OLinuXino и так далее. Основной плюс – внутри них работает привычный многим Linux, код можно писать практически на чем угодно и они подключаются к монитору или обычному телевизору. Так как основное предназначение у них тоже самое, что и у ардуинок, то и минусы те же самые – дикие цены как на сами компьютеры, так и на платы расширения к ним. Плюс все эти компьютеры совершенно (ну по сравнению с вышеперечисленным) не имеют портов ввода вывода и обладают диким энергопотреблением.

К этому описанию можно смело добавить разные платы с Android внутри. Плюсы и минусы абсолютно те же самые. Для планшетов еще пойдет, а для встраиваемой электроники – никак.

И наконец, моя нынешняя вершина – микроконтроллеры stm32. У есть один, но очень большой и жирный минус: в них совершенно невозможно разобраться “с наскоку”. Даже простая задача “помигать светодиодиком” для начинающего легко может вылиться в многочасовое копание в документации, которая к тому же вся на английском. Все остальное – сплошные плюсы: от широчайшего арсенала портов и интерфейсов до дикой производительности. Как дополнение – архитектуру stm32 для своих микроконтроллеров используют несколько производителей, поэтому средств разработки – дикие горы, на любой вкус, любую задачу и на любой кошелек.

Скажем, возьму самую дешевую плату для разработки на stm32 – STM32L100C-DISCO. 256 килобайт памяти для программ (ардуинки и прочие уже рыдают), 16 килобайт ОЗУ, работает на 32Мгц, кроме АЦП (16 каналов!) и ЦАП имеет кучу аппаратных(!) интерфейсов типа I2C и 40 с лишним портов ввода-вывода. По меркам stm – это микроконтроллер начального (нет, начальнейшего) уровня. И вот эта плата, с уже готовым программатором и парочкой светодиодиков стоит в два раза дешевле самой дешевой ардуинки.

А стоит сравнять стоимость, как уже можно получить STM32F3DISCOVERY, где добавят гироскоп с компасом, кучку светодиодиков, поднимут объем ОЗУ до 48килобайт и частоту процессора до 72Мгц. После этого увеличат число портов ввода-ввывода практически в два раза и добавят горку аппаратных интерфейсов.

А за цену какой-нибудь arduino mega можно взять офигенный набор разработчика с LCD экраном и дичайшими возможностями.

Более того, подлая st обеспечила более-менее приличную совместимость снизу-вверх. То есть написав программу для “младшего” микроконтроллера, потом с минимальными переделками ее можно перенести на более “старший” микроконтроллер. Нет ни путаницы с обозначениями портов, ни с их функционалом.

Думаю, после этого вам станет понятным, какие микроконтроллеры я буду использовать в дальнейших разработках 🙂

Безопасность – она превыше всего …

… или день адреналина.

День начался хорошо: внезапно в мире сошлись три вещи: я, деньги и магазин, где продаются “концевики” от daewoo nexia. По такому радостному случаю я прикупил еще провода для “прикуривания” (а то зимой народ заводить нечем, а катать не всегда получается), пару светоотражающих жилеток (по типу как дорожные рабочие носят или гибдд), комплект наклеек и фильтр салона.

Наклейки тоже не простые, а вовсе даже световозвращающие. Машина у меня темная, пассажирами в ней часто бывают люди довольно далекие от руля … в общем, что бы ночью у кого-то было меньше шансов снести мне дверь.

IMG_0046

IMG_0047

Просто отрываем защитный слой и наклеиваем на торец двери. Получается примерно так.

IMG_0044

Хоть фотография была сделана днем, я потом проверил вечером: от фонарика блестят и контраст с машиной очень сильный. Что и требовалось получить. Одно НО: обратите внимание: в пакетике 2 наклейки, а не одна. Я взял 4 комплекта и теперь у меня мысли, куда бы еще наклеить оставшиеся 🙂

Про концевики даже писать нечего: отверткой выкрутил старый, перецепил фишку и на его место вкрутил новый концевик. Дело на 5 минут даже при отсутствии отвертки (ну нож-то должен быть в машине).

И по внезапному же стечению обстоятельств, я был записан на сервис поменять тормозные диски и колодки. И те и те были живы и до их износа было далеко, но в процессе “раскатывания” Дрыня я сделал так, что один из дисков повело и теперь при плавном торможении на небольшой скорости торможение машины происходило рывками. Сам виноват – самому и платить.

Машину на подъемник, пока висит, осматриваем на предмет “а как бы где чего?”.

IMG_0055

Начал течь сальник ступицы на правом заднем колесе. На замену!

Машину на подъемник, колодки и диски долой, все меняем, собираем и уезжаем, не забыв предварительно понажимать на тормоз, что бы колодки прижались. Казалось бы, все?

А фигу. Отъехав буквально на пять километров, при очередном торможении я услышал резко усиливающийся прерывистый и скрежещущий звук. Вот реально, была тишина (окна были открыты) и вдруг уши закладывает. Пока я анализировал звук, справа показался дымок, который набирал силу и хорошо так дымил. Первая мысль “горю, надо телефон взять, что бы видео как у Тулупова получилось!”. А вторая “вот перед соседями по дороге неудобно – Можайка в сторону центра и так забита, а тут я загоревшись, пару полос дополнительно перекрою …”. Хорошо, что и так был в правой полосе, врубил аварийку, сполз на повороте и побежал за огнетушителем в багажник. Пока бежал, пришла другая мысль “а чего это я бегу? Надо быть солидным, да и Дрынь застрахован сверху донизу ..”. В общем, к месту дыма я подошел уже не как вспугнутый воробей, а как “гордый орель”.

А Дрынь не хотел гореть. Пока я подходил, дымок стал жиже и потом вообще перестал. “Огня без дыма не бывает”, поэтому я поставил огнетушитель и стал искать, чего загорелось. Жар чувствую … и все. Жар идет из колесной арки. “Ага, криворукий сервисмен чего-то не так сделали и тормоза клинануло! Хотя чего он мог не так сделать, если я рядом стоял и смотрел …”

В общем постоял, подождал, пока жар спадет, полазил … и ничего не нашел. Колодки, как им и положено, разведены, нажимаешь педаль тормоза (пятилитровой бутылью с водой) – сводятся. Чем-то сгоревшим воняет – но чем не поймешь, да и дорога рядом. Звоню в сервис, обрисовываю ситуацию. В ответ “ну давай потихоньку назад, если чего-звони”. Ну потихоньку, так потихоньку. Врубаю аварийку и по обочине попилил. А пилить далеко, ибо все развороты я уже проехал.

Припилил в сервис, скинули колесо, стали смотреть. Ну все на месте, ничего не клинит и так далее. Крутили колеса, нажимали педали, пока один из глазастых не обратил внимание.

Вот видео.

http://youtu.be/zSfbrPLseLQ

Обратите внимание на зазор между суппортом и диском. Он и так небольшой, а тут еще и плавает. Сняли …

IMG_0061

А вот и канавки, которые диск проточил …

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

Снятый диск на токарном станке обточили (биение было порядка 2х миллиметров) и собрали все назад. При сборке более опытный обратил внимание, что нам подсунули левые колодки.

Коробочка правильная

IMG_0059

А вот колодки – левые

IMG_0062

Слева – правильные, справа – неправильные. Когда держишь в руках разница ощутима. В общем, теперь у меня “пачти как бремба”, только синие. Покатались, потормозили “в пол”. Ничего. Значит, проблему решили … Кто бы мог подумать, что у УАЗа такие маленькие допуски в тормозах 🙂

А салонный фильтр я так и не поменял. Просто не смог понять как … Лазил “каком кверху”, фотографировал …

Леново, привет!

Как понятно из предыдущего поста, я отказался от SGS4A. Повторюсь: основной причиной стала крайне непродолжительная работа от аккумулятора. Для смартфона было подвигом продержаться сутки в режиме бережного использования (а в обычном у меня повсюду были зарядки). В остальном – шикарный агрегат.

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

Сначала я ударился в крайности: хотел взять texet tm-511R. Неубиваемый телефон с диким временем автономной работы. Остановило только то, что он не умеет никак синхронизировать контакты. Вообще. А потом я попросту не смог его найти в магазинах поблизости. Хотя судя по интернет-сайтам этих магазинов, этот телефон у них был.

Потом решил вспомнить, для чего же я использую смартфон. В результате получилось следующее:
– Часы и будильник.
– Погодопоказыватель. В духе “брать ли зонтик” и “не замерзну ли я”.
– Музыкоигралка через проводную или bluetooth гарнитуру. Где-то по 3-4 часа минимум и каждый день.
– Навигация с пробками и без онных. Час в день примерно. Обычно вечером, когда мне надо выбрать, по какой нычке до дома доехать.
– Кофетуалеточиталка фейсбучиков, одноглазников и вконтактиков. Минут 15-20 в день.
– Книгочиталка. От 15-20 минут до 2-3 часов.
– Изредка по инету прошвырнуться или видео посмотреть. Совсем изредка какая-нибудь игрушка класса “tower defence”

И в принципе все. То есть мне не нужно 100500 гигов пямяти, много ядер процессора и прочих NFC с системой отслеживания взгляда и подсчета калорий.

На платформу мне пофиг. Хоть iOS, хоть Android, хоть WinRT. Все что мне надо, есть под все платформы.

Начал смотреть на то, что предлагается рынком. Благодаря активным действиям Марины Рожковой, из списка претендентов сразу был исключен Highscreen Boost. Пусть дальше маркетоидит и пиарит. Хотя может телефон и неплохой.

Потом был составлен список смартфонов с большой батарейкой. В этом мне очень сильно помог http://helpix.ru/articles/battery-test.html Правда там есть не все телефоны, но по разным обзорам можно достаточно точно установить корреляцию.

Следующим шагом стало отсеивание тех смартфонов, про которые ничего не известно таким ресурсам как 4pda.ru и xda-developers.com. Критерий простой: чем больше тем или страниц, тем больше вероятность, что все возможные глюки или фичи найдены, разжеваны и обрисованы.

И как-то кандидатов не осталось. Lenovo P780. Всякие характеристики и прочее можно прочитать в куче обзоров, поэтому повторяться не буду.

И сразу же первые впечатления по сравнению с S4A

– Да, он кое-где подтормаживает. На кофетуалетных приложениях и иногда. Для меня некритично.
– Да, у него разрешение экрана меньше. Но я не вижу разницы. Для меня и там и там гладко.
– У него чудесно настроенная вибра. Это просто надо щупать. Словами … ну она мягче и приятней.
– Карточку на 64Гб сожрал.
– У него прямо из коробки есть режим “как usb флешка”. Да, я в курсе, почему этот режим выкидывают. Но начхать, мне он нужнее, чем всякие рассуждения об удобстве мифических пользователей и программистов.
– В телефоне нету горы предустановленного и нестираемого дерьма на все случаи жизни. Одна игрушка (на первый взгляд город надо строить и развивать), загрузчик антивируса (на кой он на смартфоне?), какой-то навигатор и клиент твиттера. Может, потом удалю. А может и забью.
– Да, он не работает из коробки с WiFi каналами выше 11. Но пара команд из консоли и больше нет проблем.
– Да, у него нет 5GHz WiFi. Мне пофиг.
– Да, у него в комплекте OTG шнурок (бум считать, что бесплатно) и через него можно флешки читать и другие телефоны заряжать. Попробовал. Прикольно.

А теперь совершенно невозможное для 99% современных смартфонов. Включено все, что включается: от синхронизаций до интерфейсов, никаких заморочек с заморозками, остановками и прочим. Включил, понаставил всего, чего надо, дождался конца зарядки и пошел использовать в обычном режиме (только постоянно убирал подальше зарядки. рефлекс уже …). Еще раз: все настройки по умолчанию, как было из коробки.

battery

Маленький горбик посредине – это я к компьютеру подключал для синхронизации музыки.

Пока, самсунг …

Вот и подошел к концу период активного пользования смартфоном Samsung Galaxy S4 Active.

Ну и по традиции маленький обзор, ибо я абсолютно уверен что у S5 будут абсолютно те же проблемы.

К самому телефону “в общем” и к его программной начинке претензий нет. Все работает, мигает и переливается, как надо. Ничего нигде не тормозит, не лагает и не крутит колесиками.

А вот с аппаратной частью у этого телефона проблемы. Реальные.

Самая главная проблема: это аккумулятор. При включении всех штучек и дрючек, которыми манит вас реклама, телефон работает максимум полдня. Повторюсь: половину дня!

При вырубании всего лишнего – можно растянуть на день. При жесткой экономии, отстреле и заморозке приложений, выключении всяких блутусов и вайфаев на ночь – сутки. Не больше.

А недавно вообще случилось странное. Конечно, это проблема возникла только у меня, да и то недавно. При включении gps&glonass телефон перестает заряжаться. То есть он показывает, что заряжается, но индикатор аккумулятора неопровержимо доказывает обратное. Зарядки и шнурки – фирменные, купленные в фирменном же магазине по фирменным ценам. А для меня наличие GPS – критично.

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

И наконец, USB порт. Он тупо разболтался. Ну или я так думаю, что разболтался. Будучи подключенным к компьютеру и просто лежа на столе, он любит забавляться “хозяин, я подключился к компьютеру. Ой, хозяин, я уже отключился от компьютера. А нет, погодите-ка …”

Прошивки. Если коротко, то они есть. Всякие. С рутом, без рута, минимальные и забитые софтом. проблем с этим нет.

А так, если не отходить далеко от розетки – шикарный телефон. Будет лежать у меня для тестов.

Если вам стало мало avr …

… или добро пожаловать в ад, ардуинщик!

Любой человек, который использует в своих проекта arduino, рано или поздно сталкивается с тем, что ему перестает хватать возможностей имеющегося микроконтроллера. Те, кому просто не хватает ножек, пытаются мигрировать на mega, остальные ищут шилды с необходимым функционалом или начинают изобретать свои. Но любому дрыгоножеству рано или поздно наступает предел: не хватает! Наиболее малодушные спрыгивают на raspberry или другие подобные платы, а считающие что они сильны духом начинают смотреть на другие платформы.

У меня есть и ардуинки и “малинки” и кучка других плат, поэтому я вполне резонно считал, что в микроконтроллерах я далеко не чайник и знаю, с какой стороны пины дергать … В общем, через друзей ко мне поступило предложение сделать довольно простенькую (на фоне уже сделанных проектов) систему. Но на stm32. В памяти сразу всплыла отладочная плата stm32f3discovery, купленная “на сдачу” при очередной закупке и пылящаяся в закромах. Даже не обсудив условия, соглашаюсь: форсированное обучение новой платформе, да еще и на живом проекте, всегда лучше “ну вот посижу вечерком, побалуюсь проектиками …”. Дополнительным бонусом стало изучение микроконтроллеров, на которых построено управление раздаточной коробкой и климатом в моем УАЗе.

Лирическая завлекалка: (из описания) … плата на базе микроконтроллера STM32F303VCT6 включает в себя встроенный отладчик ST-LINK/V2, акселерометр, гироскоп, электронный компас STMEMS, разъем MiniUSB, светодиоды и пользовательские кнопки. Процессор работает на частоте до 72МГц и предоставляет пользователю 90 каналов ввода-вывода. И все это продается за 600 рублей. В одном из самых дорогих магазинов. Аналогичный функционал (ну почти аналогичный: таких скоростей и объемов памяти нет) на ардуине будет стоить около 7-8 тысяч рублей. А отладчиков с аналогичными возможностями на ардуинках вообще нет как класса.

И тут я совершил первую ошибку, впрочем вполне понятную в моем положении: не посмотрел на поддержку микроконтроллера производителем. Ну в самом деле, ведь они делают микропроцессор и плату на нем, а значит должна быть и документация и примеры … Как же я ошибался … В общем, выбрали микроконтроллер и плату просто по необходимому функционалу. Ей оказалась плата STM32L100C-DISCO.

Пока собирали макет, я, уверенный в своих знаниях, полез по интернету почитать про то, как же все-таки программируются эти микроконтроллеры. И тут я немного припух.

Судите сами. Вот кусочек кода:

RCC->APB2ENR |= RCC_APB2Periph_GPIOC;
GPIOC->CRH |=0x33;
GPIOC->CRH &= ~0xCC;
GPIOC->ODR |= (GPIO_ODR_ODR9 | GPIO_ODR_ODR8);
GPIOC->BSRR=(GPIO_BSRR_BS8|GPIO_BSRR_BS9);

Это всего-лишь простейшее зажигание двух светодиодиков.

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

Второе отступление: в отличии от ардуинки, для stm32 есть много вариантов сред для разработки. В результате любая тема “а что выбрать?” довольно быстро превращается в обычный срач. Лично я выбрал бесплатную CooCox. Не без глюков, но все что надо есть.

Вторая ошибка: я считал, что раз микроконтроллеры принадлежат к одной архитектуре, то и программироваться они должны одинаково. Ну грубо говоря если на SMT32F0 какой-то код включает ножку А0 на чтение, то тот же код должен включать ту же ножку и на STM32L1. Хренушки. Все разное даже для микроконтроллеров одной серии, но различающихся разными буковками на конце. Особенно для дополнительного функционала типа таймеров. В результате примеры из интернета в лучшем случае просто не работали (вы когда-нибудь видели неработающий blink на ардуинке? А тут легко!), а в худшем просто не компилировались.

Я было впал в печаль, но решил что я не первый в таком положении, а значит должен быть какой-то выход. И выход был найден практически сразу: SPL. Фирменная библиотека от STmicrosystems.

Еще одно отступление: для других процессоров у ST есть более навороченные и новые библиотеки. Но вот для L – нету. Смотреть на мою первую ошибку.

Радости моей не было предела. Код сразу преобразился в почти читаемый:

GPIO_InitTypeDef GPIO_InitStructure;
RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC , ENABLE);
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_8|GPIO_Pin_9;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_Init( GPIOC , &GPIO_InitStructure);
GPIO_SetBits(GPIOC, GPIO_Pin_8|GPIO_Pin_9);

Это уже было прорывом. Хоть и были проблемы со всякими константами, но они были вполне понятными: не стоит ожидать скорости работы ножки в 50МГц от контроллера работающего на 32х.

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

На одном из шагов потребовалось прицепиться к контроллеру по обычному ком-порту (USART по импортному). Уже вполне привычные заклинания, аналогичные вышеприведенным и честно спертым из интернета и … и ничего. В смысле вообще ничего.

Попробовал один пример: пусто. Второй: пусто. Начитался про DMA (в stm32 можно сделать так, что бы внутренности микроконтроллера сами отсылали данные, не требуя постоянного присмотра из программы), написал: пусто. Я начал метаться в разные стороны: то пример попробую, то документацию почитаю. Ничего. Не работает.

Тогда я вспомнил, что я вообще-то работаю с железной штукой, а не с обычной программой. Сажусь логическим пробником на порты микроконтроллера и вижу, что что-то он там все-таки передает. Обрадованно кричу “это проблемы на другой стороне, железка по rs232 не хочет работать!”. Тут же сам себя урезониваю: с другими штуками эта железка вполне себе работает. А с моей нет. Значит проблема все-таки у меня …

Достаю осциллограф и смотрю на ножки. Сигналы есть, всякие нолики-единички я вижу очень отчетливо.

Нахожу переходник для компьютера и подключаю. Запускаю терминалку. С контроллера передаю 00, в компьютер приходит 00. Передаю с контроллера 55, в компьютер приходит два байта. Передаю АА, компьютер получает аж три байта! Офигеваю. Даже мрачно.

Еще одно отступление: в принципе всем необходимым арсеналом настоящий ардуинщик обзаводится еще в процессе, но многие обходятся дешевым китайским мультиметром (а то и вовсе живут без него). Тут же очень желательно заиметь осциллограф, даже самый простенький. Более-менее приличные, подключаемые к компу стоят 7-8 тысяч и очень сильно облегчат отладку устройств. Даже хвалимый многими Keil (он умеет рисовать рисуночки происходящего на портах) в некоторых случаях очень сильно лажает.

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

Наконец после череды матов и сломанной клавиатуры я решаю сделать перерыв. Пойти поесть, прогуляться, попить пива … поспать наконец. После перерыва все так же ничего не работает. Через некоторое время я уже даже начинаю понимать сущность значения некоторых констант, но это не продвигает меня ни на шаг.

Через некоторое время я обнаружил себя тупо играющимся частотой развертки осциллографа. Рисуночек передачи раздвигается-сжимается … а внизу бегают циферки разрешения. Постепенно в мой мозг прямо-таки просачивается мысль “какого хрена этот пик шириной 20мс? он же должен быть 10!”. Лезу в программу, ставлю вместо положенных 115200 скорость 230400, заливаю и вуаля! Все работает! Попрыгав горным козлом по комнате, я стал разбираться, в чем же причина такого поведения.

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

Кратко говоря, все дело было в неправильном указании частоты процессора. Библиотекописатели были уверены, что он работает на 32МГц, а в реальности он работает на 16МГц. А так как в STM32 все (в смысле вообще все) рассчитывается исходя из этого значения, то и usart в реальности работал на скорости 57600 вместо требуемых мне 115200.

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

Прослезившись, я пошел реализовывать следующий по плану функционал: простой АЦП. Программе надо замерить уровень сигнала на одной из ножек и потом согласно этому уровню начать делать свое черное дело. И тут я опять встрял: программа либо висла, либо в ответ возвращала 0. Уже наученный горьким опытом, я посмотрел реальные данные на ножке. Как легко догадаться, они отличались от 0 …

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

И снова я решил поразмыслить. Раз я не один такой, кому не нравится шариться вместо документации по заголовочным файлам в поиске ответов, то наверняка же уже есть решения? В принципе да, есть. Любой производитель софта по stm имеет по своей библиотечке, но как-то они вяло их поддерживают …

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

В итоге код практически приблизился по внятности к ардуинному:

rcc_periph_clock_enable(RCC_GPIOС);
gpio_mode_setup(GPIOС, GPIO_MODE_OUTPUT, GPIO_PUPD_NONE, GPIO8 | GPIO9);
gpio_set(GPIOС, GPIO8|GPIO9);

Попробовал на этой библиотеке сделать АЦП – работает. ЦАП – работает. USART – работает. Даже таймеры удалось сконфигурировать без шаманства!

В общем, пока я категорически рекомендую эту библиотеку. Стало сильно проще работать.

Прочитавший это “ардуинщик” легко может ужаснуться и подумать “нафиг-нафиг. лучше я уж потихоньку, полегоньку на старом добром avr переживу”. Зря. Да, ST еще те редиски и специально делают все так, что бы их продукция была доступна только профессионалам, имеющим возможность потратить кучу времени и денег на изучение платформы. Зато в ответ вы получаете доступ к дешевым и мощным микроконтроллерам, которые могут делать столько интересных вещей, которых на avr попросту нет. И поверьте, даже прочитав описание какого-нибудь контроллера типа “имеет 5 таймеров”, вы никогда не узнаете, что с этими таймерами можно делать, пока не попробуете и не залезете в документацию. Ведь архитектура stm позволяет скрещивать функционал внутри самым причудливым образом. И к примеру, можно сделать так, что бы один и тот же таймер в одной прошивке мигал светодиодиком, а в другой читал показания енкодера моторчика …

Как говорится, продолжение следует.

Кластер против облака …

Посидел, поперечитывал свои записи и понял, что мало так сказать практики. В смысле все читали, что это круто, но почему-то никто не показывает, как это круто. Или почему это круто и за это надо платить денег. В общем, решил я написать малюсенький пост про практику. И закрыть вопрос про то, как отличить облака от кластеров.

На всякий случай у меня под боком есть два компьютера. Ну как компьютеры … по нынешним меркам они скорее обзываются калькуляторами. Но тем не менее все необходимое у них есть. Пару-тройку виртуалок они потянут, а больше для меня и не надо.

Упражнение первое или “мама, у нас все сломалось”. Везде пишут (ну и я тоже), что системы виртуализации позволяют осуществлять онлайн-миграцию. А как это поисходит вживую?

cloud1

Вот вам пример. В одном окошке я запустил миграцию виртуальной машины с одной ноды “калькуляторного кластера” на другую, а во втором – просто посылал в сторону мигрируемой машины по пакету в секунду. Как видно на скриншоте, время недоступности машины составило 9 секунд. Общее время миграции было около 30 секунд. На настоящих кластерах время недоступности обычно не превышает и половины секунды. Много ли сервисов требуют для себя такого уровня доступности?

Или вот еще один пример, опять же многократно описываемый. Есть сервис, которому не хватает ресурсов.

cloud2

Если посмотрите на правое окошко (там консоль одной из виртуалок), то там openssl показывает, что он может подсчитать только 11 тысяч хешей md2 за 0.15с. А потом команда free докладывает, что памяти всего 256 мегабайт. Одна команда в левом окошке (на ноде) и openssl уже подсчитывает 540 тысяч за 3 секунды (или 27 тыщ за то же время), а памяти стало уже гигабайт. И все это без остановки или перезагрузки сервиса.

И так можно крутить любой параметр у виртуалки: начиная от числа и скорости процессоров и заканчивая количеством дискового пространства у машины.

Для интереса предлагаю прикинуть, сколько потребуется времени и сил, что бы проделать подобное в обычной инфраструктуре. Удобно? Не то слово!

Надо развернуть новый сервер? Легко!

cloud3

17 секунд (калькулятор, да) и у вас есть готовая машина, которой надо только выделить ресурсы.

cloud4

А когда нужда в ней отпадет … секунда и ненужной машины больше нет.

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

Повторюсь, все это сейчас позволяет делать любая система виртуализации.

Но все-таки, чем отличаются облака от кластеров? Ведь они построены на одних и тех же принципах, позволяют делать одно и то же с одним и тем же результатом.

Отличаются они одним. Системой управления всем этим великолепием.

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

Во-вторых, системы управления заточены на разделение ресурсов. В кластере редко возникает необходимость отделить одну группу серверов от другой. В результате все сидят в нескольких VLAN’ах, разрулить которые легко руками. А в облаках тысячи (десятки, сотни – подставьте по вкусу) пользователей, которых надо развести по своим сетям и не давать серверам одного пользователя прямого доступа к серверам другого. Без системы управления, заточенной на облака, подобная затея попросту обречена на провал.

И наконец, облака тащат в себе всю … скажем так, специфику виртуализации. Скажем, для одного сервиса необходимы ноды, которые используют локальное хранилище, да и еще на SSD. А для другого хватит кусочка общего стораджа. Для каждого сервиса есть свои ограничения, требования, правила. И системы управления следят за тем (скажем, при миграциях), что бы каждый сервис работал на ресурсах того класса, который ему выделен, что бы не происходило overselling (или он был с заранее определенными параметрами) и так далее и тому подобное.

Поверьте, все это удержать в голове и рулить этим через консоль или какую-нибудь утилитку – абсолютно нереальная задача.

И вот за вот это вот снятие “головной боли админа” и просят производители денег. А так-то все можно сделать руками и из консоли …

Показометры в студию!

Что первым делом должна делать программа для учета личных финансов? Конечно, показывать нам эти самые финансы. Или говоря другими словами, показывать состояние счета и транзакции по нему.

vsemo_stage3

Счета у нас внутри базы представляют собой классическое дерево, где у каждой веточки есть свой id и id ветки, из которой она растет. Или id и parent_id. Если parent_id=0, то считаем, что этот счет “корневой” и находится на самом верху.

Методов отображения таких деревьев – уйма. Но я на свою голову решил попробовать применить QTreeView. Обложился документацией, нашел парочку хороших статей на хабре … Казалось бы, бери и делай.

Но фигу. QTreeView в Qt – один из немногих компонентов, который сделан “наотъебись”. Практически нулевая документация, какие-то шаманские пляски для выполнения тривиальнейших вещей и так далее и тому подобное. А практически все примеры в интернете написаны в духе “это просто, берем готовую модель и вуаля!”. А как работает эта модель и почему надо это делать так – ноль.

В общем, потратив впустую пару дней с этими морделями, я плюнул на эту хренотень, взял обычный QTreeWidget и банальным рекурсивным поиском заполнил виджет. На всякие заморочки со скоростью я решил начихать, ибо я не верю, что у обычного пользователя будет больше 100-200 счетов, а на этом уровне сходится все. На тестах виджет вполне нормально крутил 10000 счетов без каких-либо пожираний памяти или тормозов процессора.

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

Из того, что не было в предыдущих стадиях так это только то, что добавилась синхронизация таблички rate, в которой хранятся курсы валют. Тут же всплыла проблема: при синхронизации на немощных компьютерах программа сваливается в Application Not Responding. Надо будет куда-нибудь в синхронизацию воткнуть вызов диспетчера очередей. Сменить алгоритм не предлагать, ибо потом некоторые таблички будут расти и расти …

А вот с окошком отображения транзакций получилось все как по книжкам. Там обычная плоская таблица, поэтому QSqlTableModel пришлась впору. И так как документации, примеров и прочего на порядок больше, то и проблем никаких не было. Почти, но об этом позже.

Через некоторое время я переехал на QSqlRelationalTableModel по одной простой причине: у каждой транзакции есть currency_id, которое отвечает за валюту, в которой сделана транзакция. И что бы не мучаться, проще заставить модельку саму выбирать с помощью join нужные значения из таблицы currency.

Во всем этом великолепии меня поджидало только две засады.

Первая заключалась в именах таблиц. Все-таки transaction является ключевым словом и просто так qtшный sql не хотел использовать эту таблицу. Попытка заэскепить имя таблицы как [transaction] не увенчалась успехом. Но на мою радость оказалось, что “transaction” вполне себе хороший идентификатор для qt.

Вторая заключалась в том, что поле для join задается его порядковым номером. То есть мне надо считать, под каким порядковым номером выводится нужное мне поле и задавать его. А функции типа findColumn(name) я не нашел. Можно конечно поизвращаться самому (db.tables никто не отменял), но пока оставлю в качестве todo на будущее.

Наконец, сделал последний штрих: заставил выводить только те транзакции, которые относятся к выделенному счету. Мелочь через setfilter.

Как обычно, исходники тут

В принципе, максимально минимальный клиент готов. Он умеет логиниться и показывать необходимое. Да, коряво, да, даже без капельки дизайна, но умеет.

Что следующее? А следующим будет причесывание внешнего вида и начало эпопеи по разработке интерфейса. Например, надо сделать так, что бы на планшетах, десктопах и телефонах в ландшафтной ориентации отображалось как “счета-транзакции”. А вот на телефонах в портретной ориентации надо выводить “счета”, при тапе на счете выводить отдельное окно с транзакциями. И реализовать “назад”.

И тулбарчик на андроидах сверху, а на айфонах снизу! И еще ..

Короче, в следующей серии будет гламуризация полученного.

Как самому сделать себе немного облака. Часть вторая.

IMG_8985

Итак, переходим к самому волнующему: под какой системой виртуализации будет работать наше облако? Простой поиск по интернету выдает такие разнообразные варианты, что прямо теряешься.

На самом деле ответ на этот простой: ставьте ту систему, специалисты по которой наиболее доступны вам. Что бы было у кого и с кого спрашивать.

Но это же не интересно и писать не о чем. Поэтому давайте я опишу личные впечатления о разных системах, которые можно заиспользовать.

Начну с моей любимой: OpenVZ (Коммерческая Virtuozzo). Самая скоростная система, которая по производительности легко уделывает все остальные. Имеет только один, зато толстый минус: позволяет внутри крутить только linux системы.

VMware. Самая старая, дорогая и поддерживаемая система. Есть бесплатные вариант ESXi, но возможностей у него кот наплакал. За деньги можно сделать систему абсолютно любого уровня. Основные минусы: цена и дикая нелюбовь к несертифицированному железу.

Xen. В коммерческом варианте – Citrix. В России я не видел нормальных внедрений, поэтому опыта у меня нет. Зато за рубежом одни из крупнейших провайдеров – Amazon и RackSpace использует именно его.

KVM. На самом деле это простой гипервизор, который есть в любом дистрибутиве линукса. Управляется исключительно из командной строки. Но благодаря поддержке гигантов, оброс различными системами управления и надстройками, которые позволяют конкурировать с системами на базе VMware. RedHat использует именно его.

Hyper-V. Продукт от микрософта и заточенный на работу с микрософтовскими же продуктами. Не так давно научился и linux крутить. Дорогой и пока глючный (ну или мне так везет).

VirtualBox. Бесплатная (для десктопа) виртуализация. Но если вам приходится много работать с Solaris или Oracle, то это единственный выбор.

В общем-то и все. Остальные системы пока в слишком зачаточном состоянии.

По функционалу все системы одинаковы. То есть заморачиваться вопросами «а умеет ли эта система что-то, что не умеет другая» абсолютно нет смысла: все необходимое есть. Разница в том, насколько удобно реализованы те или иные возможности.

К примеру, vmware имеет в комплекте конвертор, который позволяет с минимальными усилиями затащить в себя любую физическую машину, работающую под windows или linux. Она же единственная, кто дружит с OS X. Зато OpenVZ позволяет сделать так, чтобы файловая система (и сама виртуалка) была доступна с хост-машины без каких-либо проблем (и при необходимости наоборот). А KVM доступна на любой линукс-машине и позволяет с минимальными телодвижениями запустить образ от других систем. Ну и если у вас целиком вся инфраструктура на продуктах от микрософта, то с помощью Hyper-V вы мигрируете в облака без особых телодвижений.

В общем, крайне рекомендую перед окончательным выбором протестировать все системы под свои требования. Благо у всех систем есть триальные версии.

Хинт: нет никакой необходимости делать все на одной системе. Никто не мешает использовать несколько. Да, получится более сложная инфраструктура, но возможно более эффективная.
Ндас, как-то не очень маркетоидно получилось, зато про всех понемногу. Давайте лучше вернемся к приятному: планированию облака.

Если помните, то в предыдущей части вы разрисовывали связи и самое большое число связей получилось у сети и дисков. Вот эти две штуки и являются самыми больными частями в любом облаке. Любая неполадка или задержка вызывает вал проблем, который остановить очень сложно.

За что борются инженеры?

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

Во-вторых, за число операций в секунду. Для дисков это зовется IOPS, для сети pps. Чем больше операций система может провернуть, тем меньше надо систем для обработки того же объема запросов.
Для этих значений принцип простой: чем больше, тем лучше. И поверьте, борьба за эти циферки идет жесточайшая. Их всегда не хватает. Вообще всегда.

Какие основные методы применяют?

Во-первых, разделение машин по функционалу. Скажем, у вас есть 10 веб-серверов. Предположим, что внутри каждого веб-сервера есть сам веб-сервер с каким-то движком (типа php или java) и SQL сервер. Простой вынос всех этих десяти маленьких SQL серверов на один (хорошо, на два, если нужна отказоустойчивость), но которому отдали их ресурсы, уже приведет к увеличению производительности.

Во-вторых, разделение потоков данных. Это тема в большинстве случаев сродни шаманству. Людей, которые понимают, где в обычных с виду систем могут возникать бутылочные горлышки и как их удалять, очень ценят.
Скажем же веб-сервер. Скажем, ему банально стало не хватать производительности. Поднять второй по каким-то причинам нельзя. Что делают в «лоб»? Обычно наращивают производительность. Скажем ставят SSD вместо обычных дисков. Да, производительность возрастет, но не сильно. Специалист «по горлышкам» придет и увидит, что у веб-сервера есть один поток на чтение, когда он отдает запрошенное, один поток на запись, когда он записывает в лог и еще один поток на запись, когда операционная система обновляет время последнего доступа к файлу. В результате достаточно отрубить время доступа (нафиг он на веб-сервере?) и поднять где-нибудь неподалеку сервер для сбора логов, как дисковой подсистеме отвечающей за веб-сервера резко полегчает: она будет работать только на чтение (и никто не мешает ей поставить RO, что бы еще больше облегчить жизнь). А у сервера логов только на запись. Все счастливы и довольны.

Есть и еще одно «шаманство». Обзывается разделением нагрузки по характеру. Скажем, у нас есть бухгалтерия и почта. Бухгалтерский сервер использует паттерн работы с диском «тут посмотрели, тут записали, тут посмотрели, тут записали» (упрощенно конечно). А почта «записали, посмотрели, посмотрели, посмотрели, записали». Причем временные интервалы и расстояния по диску между «посмотрели» и «записали» у обоих систем разные. В результате кэш, который обязан ускорять работу с диском, банально «загрязняется» и работает далеко не так эффективно, как мог бы.

Да, примеры немного наиграны, но и реальность просто отличается большим числом участвующих «переменных».

Ладно, хватит пугать, надо немного рассказать о типичных методах ускорения сети и дисков и встреченных мной (и совершенных тоже) ошибках.

Объединение линков. Как я писал выше, скорости никогда не хватает. Все сетевые штуки умеют объединять несколько сетевых линков в один. Скажем, у вас в сервере есть 4 порта, каждый на 1Гбит. И в коммутаторе тоже образовалось свободное место. Вы берете 4 патч-корда и соединяете их один-к-одному, включаете бондинг (объединяете их в один транк и так далее) и надеетесь, что в результате получите линк на 4Гбит. А в результате получаете тот же гигабит или чуть больше. Любой продвинутый сетевик уже понял, в чем засада. Для остальных: у бондинга много режимов и вариантов. И только некоторые предусматривают возможность распределение нагрузки по всем линкам.

Звезда – наше все. Это любимая и продвигаемая большинством модель построения сети. Если коротко, то все сетевые устройства подключаются к некой системе, которая уже и занимается передачей пакетов от одного устройства к другому. Просто, понятно и … дорого. Штуки, которые способны переваривать десятки и сотни гигабит (Откуда такие цифры? К примеру, одна виртуалка с бухгалтерией легко генерирует поток в гигабит к диску. Это всего-то 100 мегабайт в секунду. Обычный винт легко выдает) и при этом не становиться единой точкой отказа, стоят дорого. Для обычной сети эта модель практически идеальна. Но у облаков все немного по-другому. Скажем, есть очень большой поток данных между серверами хранения. Не к нодам, а тупо между собой. Для репликации, отказоустойчивости и все прочее. Более того, весь поток сосредоточен между серверами одной группы. Так зачем его гонять через коммутатор, когда гораздо выгодней зацепить сервера между собой прямыми линками? Просто из-за такого изменения топологии задержка в линке падает больше чем в 2 раза! И ведь точно такой же поток данных есть и между нодами …

Не все рэйды одинаково полезны. Скажем, нам нужно создать отказоустойчивый сервер хранения. Надо немного, буквально 20 терабайт. Что делает обычный, не «облачный» админ? Берет два сервера, пихает в каждый по шесть дисков на 4 терабайта, запихивает их в raid5 на отдельном контроллере, объединяет сервера и рапортует о готовности. В результате получается тормозной сторадж, который с трудом способен переварить 400-500 мегабайт данных в секунду. Что делает облачный админ? Берет десять дисков по паре терабайт, делает raid0 средствами операционной системы и затем объединяет сервера. Получившаяся шарманка легко берет планку гигабайт в секунду и не дохнет от на порядок больших IOPSов. Да и еще дешевле оказывается. Почему так получилось? Во-первых, облачный админ исключил лишний уровень отказоустойчивости. Зачем его дублировать на уровне дисков, когда он уже есть на уровне серверов? Во-вторых, raid0 сам по себе работает гораздо быстрее raid5, а тут вдобавок данные обрабатывают 10 дисков против 5 (и не надо ждать, пока raid5 завершит запись на всех дисках). И наконец, он освободил ресурсы процессора от расчета всяких контрольных сумм (если кто-то думает, что отдельные raid контроллеры работают быстрее обычного процессора, то он очень сильно заблуждается). Результат: выигрыш в скорости, выигрыш в IOPSах, выигрыш в деньгах! Сплошной профит!

SSD супротив памяти проигрывает всегда! Последнее время пошла мода ставить SSD для кеширования обычных HDD. Для десктопов это реально увеличивает скорость общения с диском. А вот с облаками эта штука практически не дает прироста. Просто из-за того, что слишком хорошо распределена нагрузка и редко когда в SSD попадает то, что можно закешировать. А ставить их пачками – дорого. Но почему-то редко кто додумывается поставить на сервер хранения не жалкие 16-32 гига памяти, а 256 или 512 и оттюнить операционку на максимальное использование кэша. Поверьте, эффект будет заметен невооружённым взглядом.

Но и это не все, над чем придется поломать голову. При переводе систем в облака крайне рекомендую заранее озаботиться в их установке в варианте, который позволяет масштабироваться с минимальными усилиями или исключить ненужное дублирование. Скажем, для систем на базе jboss можно почти расслабиться: он сам умеет находить аналогичные сервера и парралелить работу. Сервера с MySQL достаточно сразу поднимать в не в конфигурации standalone, а master: потом подцепить другой master или slave будет гораздо проще. Резервное копирование осуществлять не с помощью агентов изнутри каждой виртуалки, а централизовано, на сервере хранения.

Хинт: определить, что лишнее, довольно просто. Просто берете и мысленно ставите рядом еще одну точно такую же систему. Общие данные и там и там? Выносим на отдельную виртуалку/общий каталог на сторадже. Один и тот же сервис делает одну и ту же работу с одним набором данных? В отдельную виртуалку! Какой-то внешний сервис приходит регулярно за каким-то данными? Меняем схему, что бы не он приходил, а мы ему отправляли. И так далее и тому подобное.

В результате у вас должно получиться примерно в 3-4 раза больше «облачных» серверов, чем было «физических» сервисов. Но все сервера будут выполнять одну функцию, их будет легко собрать в группы по характеристикам и все они будут довольно легко масштабироваться.

Только заклинаю вас: сразу все определите правила для поименования, нумерации сети и документирования. Нет ничего хуже, чем обозревать сеть с server1, server2, test-server, lama, vanya (брать имена городов, животных, клички ничем не лучше). Поверьте, даже для небольшой компании со временем легко набирается сотня-другая виртуальных серверов. В имени сервера должно присутствовать как минимум указание на его функциональную сущность (например stor, node, app, web), его уникальный номер (хорошо если привязанный к его адресу в сети) и если необходимо, какой-либо другой признак (dev, ivan, test). А за отход от правил тут же и немедленно бить чем угодно. Но еще лучше помогает тупо удаление сервера: второй раз никто такую ошибку обычно не допускает.

И тогда любой при взгляде на stor25fast сможет сказать, что это сервер хранения для требовательных к ресурсам задач с адресом 10.0.0.25, a web40-test-ivan – тестовая машинка с веб-сервером, поднятая Иваном и имеющая адрес 172.16.0.40. Думаю, смысл понятен.

Думаю, я достаточно загрузил вас. Пора немного прерваться.

И да, я опять спер картинку

Как самому сделать себе немного облака. Часть первая.

cloud
Данный текст я решил написать в расчете на ИТшников, которые уже задумались про перевод своей инфраструктуры в «облака» и теперь думают, как же это сделать. На мой взгляд, в интернете слишком много уделяется внимания тому, как надо покупать «облака» (дальше буду без кавычек), а не тому, как их использовать, создавать или как они устроены. Дескать, это сложная наука, подвластная только крутым специалистам с кучей дипломов. Ну или интеграторам с такими специалистами в штате. Стоимость подобных облаков обычно получается какая-то негуманная. А если упомянуть про про bigdata, DWH и прочие слова из буклетиков, то к ценнику добавляется нолик-другой.

На самом деле, все не так страшно и я попытаюсь доказать вам это. Может быть даже с примерами и рисуночками.

И да, обычное предупреждение: я рассказываю на основе своего опыта и могу быть неправым от и до. Но вроде созданные системы выполняют свои задачи и жужжат совершенно по делу.

Для начала надо определиться, что же такое облако и с чем его можно есть.

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

Для обычных же людей это некая сущность, которая предоставляет им сервисы по формуле «дешевле, быстрее, надежнее: выбери два из трех». Опять ничего нового.

Всякие слова про масштабируемость, отказоустойчивость и прочее можно оставить маркетингу. Методы реализации этого великолепия известны очень давно и облака ничего нового в этом плане не открыли, а просто сильно упростили.

Как-то грустно получается, не находите? Почему же облака так стали популярны? Дело в том, что появились новые методы использования доступных мощностей. И как раз они основаны на сильном упрощении процесса обеспечения тех самых «масштабируемостей», «отказоустойчивостей» и прочего.
В итоге грань между «отказоустойчивым кластером» (масло маслянное, да) и «облаком» получилась … ну очень тонкой. Поэтому предлагаю оставить теологические споры диванным аналитикам и перейти к практике.

Что можно получить от облака?
– Снижение расходов на обслуживание бизнеса. Как прямых, вроде стоимости серверов, так и косвенных, в виде ускорения каких-либо бизнес-процессов.
– Увеличение доступности сервисов. Выйти на «5 девяток» по-прежнему дорого, но гораздо дешевле, чем это было лет пять назад.
– Открытие новых возможностей для бизнеса. Звучит слишком рекламно, но это реально так. Новые технологии реально дают такие возможности, даже заикание о которых раньше приводило к кручению пальцем у виска.

Остальные преимущества в принципе либо укладываются в эти пункты, либо проистекают из них. Давайте я попробую раскрыть эти пункты на примере наиболее распространенных решений.

Для начала про повышение надежности и снижение стоимости. Откуда это получается? Во-первых, обслуживать настроенные однотипно сервера гораздо проще, чем обычный зоопарк. Одни и те же версии программного обеспечения, одно и то же железо. Это дает выигрыш как во времени работы инженеров, так и позволяет получать скидки от вендоров. Во-вторых, возможность вывести любой сервер из кластера для обслуживания. Просто даем команду системе виртуализации убрать с него все сервисы и спокойно занимаемся необходимым. Тем более такую команду может дать и система мониторинга в случае превышения каких-либо значений типа температуры процессора или скорости вращения вентиляторов. И в-третьих, система мониторинга может дать и другую команду: добавить ресурсов «задыхающемуся» сервису. Думаю, любой ИТшник сразу же найдет кучу применений этим возможностям.

«Публичные» и «гибридные» облака благодаря этому и обладают возможностью на время получить буквально на час огромные ресурсы, за которые в обычном случае пришлось заплатить очень дорого. Например, я знаю рекламные агентства, которые в облаке арендуют мощности для обсчета роликов.

Вот я тут упомянул публичные и гибридные облака. Чем они отличаются? Публичное облако – это такое облако, все сервисы которого крутятся у провайдера. Гибридное – это «размазанное» по своим и провайдерским мощностям.

Теперь немного про популярные слова, которые связаны с облаками. И которые связывают с преимуществами для бизнеса.

Вот скажем bigdata. Что это? Я встречал определения типа «это то, для обработки чего не хватит даже самого мощного компьютера» и «петабайты данных». Я сторонник другого, более крамольного определения.Bigdata – это те данные, которые у нас уже есть, но мы не знаем, что с ними можно сделать. А потерять не охота. У кого-то это будет мегатонны логов пользователей, у кого-то куча данных с датчиков а у кого-то это будет жалкая пара терабайт картинок. И вот облака дают возможность как-то хранить и по возможности обрабатывать эти данные. При этом бигдачность системы вовсе не характеризуется объемом обрабатываемых данных. Есть системы, где обрабатываются буквально гигабайты данных, но эти гигабайты легко грузят сотни серверов. В общем, красивое слово.

VDI. Или Virtual Desktop Infrastructure. Развитие идеи терминальных серверов, только с предоставлением пользователю своей виртуальной машины. Шикарно ложится на облака, особенно в случае применения однотипных АРМов и поэтому в последнее время развивается очень сильно.

DWH или Data WareHouse. Еще одно общее слово. Для кого-то это хранилище кучи файлов, кто-то хранит всякие таблички. Говоря кратко, это то место, куда бегают всякие система анализа и отчетов за данными. Данные там собираются из разных источников, приводятся к общем знаменателям, группируются и так далее и тому подобное. По понятным причинам DWH очень любят всякие финансовые компании.

Ладно, хватит красивых слов, тем более, что интересующиеся могут спокойно напрячь поисковик и начитаться по любому интересующемуся термину. Пойдем практиковаться.

Планируем облако.

Что надо сделать в самом начале? В самом начале надо взять за шкирку вашего системного аналитика … как нету аналитика? Тогда берете за шкирку себя и начинаете описывать и считать.

Берете каждый сервис в вашей инфраструктуре и все обдумав, отвечаете на следующие вопросы:

– Время работы сервиса. Круглосуточно, ночью, днем в рабочие часы. Бухгалтерия ночью не работает, а веб-сайт должен быть доступен круглосуточно.

– Доступность сервиса. Может ли он делать паузы во время работы? Скажем на 5 минут? Телефония должна работать всегда, а вот резервное копирование может и постоять на паузе.

– Критичность сервиса. Если он «упадет», как сильно это повлияет на бизнес? Сравните бухгалтерию во время сдачи отчета и внутренний портал. Если добудете цифры в духе «простой 5 минут – 100500 рублей» или «день простоя – штраф в мульен», то вообще отлично. Хинт: заручитесь одобрением финансистов и бухгалтеров: они тают, когда ИТшники их спрашивают про их тяжелую долю и пытаются ее облегчить.

– Ресурсные требования по времени. Телефония требует ресурсы пиками и очень не любит, когда ей недодают ресурсов вовремя этого пика. А тот же веб-сервер толерантен к таким проблемам.

– Просто ресурсные требования. Сколько дисков-процессоров-сети надо сервису.

– Сложность обслуживания? Сколько ИТшников в среднем требуется для обслуживания этого сервиса. Стоимость ИТшника?

– Есть ли возможность прогнозировать нагрузку? Для веб-сайта – нет, а для той же системы резервного копирования – запросто.

– Зависимость сервиса. Скажем, бухгалтерия не выживет на одном офисе без бухгалтерской системы, ей будет очень плохо без сервиса печати, чуть полегче без телефонов и ей абсолютно будет начихать на веб-сайт. Но все умрет без работающей системы хранения данных.

– Возможность вынести сервис наружу. Веб-сайт и почтовые системы – почему бы и нет? Бухгалтерию – убьют.

– Уровень масштабирования в зависимости от роста компании. Веб-сайту пофиг, сколько у вас сотрудников, а той же VDI или почтовой системе – нет.

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

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

Это очень нудная, сложная и муторная работа (хотя и должна быть сделана в рамках ITIL/ITSM). Но в качестве утешения я вам обещаю, что вовремя или после процесса вы обнаружите кучу интересных вещей, которые были раньше скрыты.

Кстати, рекомендую сразу же вооружиться чем-нибудь типа visio (или хотя бы листочком с бумагой, но лучше visio) и сразу зарисовывать получаемые ответы. Я рисовать не буду, ибо мне попросту жалко своего времени, ибо это работа огромная и впустую ее делать лень.

Но на данном этапе я повангую и скажу сразу: больше всего линий пойдут к двум сервисам – сервису передачи данных (он же обычно обзывается «локалкой») и к сервису хранения данных (он же жесткий диск, он же файлопомойка, в некоторых случаях это будет NAS).

Следующим по числу «использований» будет сервер баз данных. Но большая часть будет с двумя линиями – к серверу приложений и к хранилищу данных. Зато этих серверов баз данных будет много. Веб-сервер, бухгалтерия, мониторинг, чертлысый – и везде какой-нибудь да серверок будет.

В принципе, уже полученную схему можно распечатывать и вешать на стенку. Непосвященные люди будут впечатляться и водить пальцами по бумаге, отслеживая линии.

Теперь настала пора взять в руки краски и любым приятным способом раскрасить сервера по критичности для бизнеса. При этом рекомендую брать как минимум два цвета: один для «критичный всегда», а второй для «критичный только в рабочее время». Скажу сразу, если у вас получилось, что все сервисы «критичные всегда», то что-то вы не так сделали. Весь мой опыт говорит о том, что так не бывает. Понижайте градус критичности.

Затем закрашивайте тем же цветом те сервисы, от которых зависит данный сервис. Скажем, если вы пометили, что телефония у вас критичная, то следом должны стать критичными «интернет», «локалка», «фаерволл», «сервер данных о пользователях» и стораджи, на которых все это лежит. Ведь без любого из этих сервисов телефония попросту не будет работать. Скажем, отнимаем интернет или фаерволл – перестаем принимать звонки из внешнего мира. Убираем локалку – пользователи перестанут получать звонки. При закраске необходимо строго соблюдать уровень критичности по повышению – если сервис «критичен всегда», то он не может быть перекрашен или зависим от «критичен только в рабочее время».

Данный процесс очень напоминает настройку сервисов в системе мониторинга или для change management из ITSM, поэтому эта работа или уже сделана или должна быть сделана. Поэтому в любом случае работа не будет сделана впустую.

Следующим шагом необходимо изучить у критичных сервисов механизм масштабирования и его стоимость. Где-то будет все просто: добавляем кучку однотипных сервисов и все будет в порядке. А где-то дешевле ограничиться добавлением аппаратных ресурсов. Тут можно покрасить разным цветом рамки или еще как-нибудь разделить «хорошо масштабируемые» от «плохо».

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

И наконец, последний шаг. Считаем себестоимость каждого сервиса. Скажем, сколько стоит нам веб-сервер сейчас? А если его в локальный кластер? А сколько будет стоить, если его унести на арендованный у провайдера сервер? А если под него купить облако? Есть ли загружаемые с веб-сервера большие файлы, под которые дешевле будет купить сервис CDN? Есть ли разница в стоимости лицензий для «standalone» и «cloud/terminal»? Если мы уменьшим время простоя, то сколько сэкономим?

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

Теперь необходимо причесать картинку и полученную табличку, чтобы получить практически непотопляемые аргументы для любого совета директоров/ акционеров/ финансистов/ ещекого. Эти люди по роду своей деятельности очень любят картинки, которые подкреплены реальными цифрами.

Наиболее внимательные сразу отметят один очень важный момент, который вроде нигде не упомянут: а как выбирать систему виртуализации? Ведь ее тоже необходимо закладывать в бюджет.

Скажу сразу, выбирать систему виртуализации еще рано, в следующей части будем. Вы для начала докажите себе и владеющим деньгами людям, что это вообще выгодно будет. Для предварительных расчетов можете смело ставить стоимость системы виртуализации в 300 баксов на один железный сервер. Этого при необходимости хватит на корпоративную и пальцатую VMware, но скорее всего можно будет обойтись гораздо меньшими деньгами. Лучше побольше заложите на инженеров. Чем он будет более «продвинутей», тем больше шансов, что у вас все взлетит.

И да, картинку спер из интернета. Автора не знаю, а то бы написал.

Продолжаю всёмоёшить …

Итак, продолжаем делать клиента.

Как ни обидно будет читать некоторым, но мне пришлось отказаться от QML. Слишком сырая штука для подобных проектов. Во-первых, делать связку между C++ и QMLной частью – это еще тот секс, а без подобных связок никак. Во-вторых, отсутствие нормальных layout менеджеров ставит полностью крест на кросс-платформенной разработке. Это я понял после того, как для странички логина у меня получился огромный и безформенный кусок спагетти, отвечающий за положение элементов в разных средах и формах. И наконец, вся эта машинерия у меня внезапно сглючила. Например, у меня поля ввода перестали убирать при вводе placeholder и стали оставлять после себя артефакты. И это даже при использовании специальной “чистой” сборочной виртуалки. И под виндовсом и под OS X.

В общем, плюнул я на борьбу с мельницами и вернулся к обкатанным QWidgets.

Сейчас в Stage2 реализовано следующее:

stage2

Желтеньким выделено реализованное. Белое я оставил, ибо после размышления я решил, что нефиг этому функционалу делать на окне логина. За кадром остался функционал работы с сетью, базами данных и синхронизацией.

И что больше всего радует, на всех платформах оно работает! И работает довольно шустренько. К примеру, скорость процесса синхронизации не сильно отличается от десктопной.

Что вскрылось в процессе написания и что может быть вам полезно.

Во-первых, забудьте про всякие QDialog и все связанное с ним (QMessageBox и теде). Только QMainWindow для всего. Причина простая – на андроиде и айпаде окошко зажимается в левом верхнем углу и никак его оттуда не вытащить без трахтибидоханья. QMainWindow ведет себя гораздо более приличней и плюс позволяет с собой поделать всякие кунштюки типа сохранения координат-размеров. Да, придется немного помучаться, зато потом оно летает без геморроя.

Во-вторых, вам придется переопределить все методы show и вручную написать для каждого элемента что-то типа ui->element->adjustSize(); без них вы на мобильных платформах с большим dpi получите малюсенькие элементы управления, в которых будут проглядывать надписи.

И наконец, забудьте про пикселы и прочие ldpi. Все в платформонезависимых единицах, типа пунктов для шрифтов. Всякие кнопки и прочие элементы управления – загоняйте в layout. Отдайте это на откуп Qt – у него очень неплохо получается.

Как обычно, полученное доступно тут. Дизайну ноль, зато весь функционал работает.

Теперь пора переходить к главному окну приложения. Но это в следующих постах.

Логика ты моя всёмоёшная …

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

Я позапускал приложение на всех доступных мне устройствах и вынужден сказать, что Qt 5.2 вполне справляется со своими обязанностями. Приложение запускается, крутится и вообще ведет себя как взрослое.

Но сразу же выяснилось, что просто так использовать правила “размер в 1/10 экрана” нельзя. Иначе на устройствах с большим экраном (iPad или 27″ монитор) элементы управления начинают напоминать игрушечные: такие же больше и аляповатые. В общем, необходимо размеры некоторых элементов привязать к реальному размеру.

Qt тут помогает. В нем есть Screen.pixelDensity (берем из QtQuick.Window 2.1), который говорит о числе точек экрана на миллиметр. И если нам нужен размер чего-то в сантиметр, то просто ставим Screen.pixelDensity*10 и проблема исчезает.

В том же Screen есть width и height, только они вовсе не про размер экрана. Они описывают размеры прямоугольника, который доступен приложению. За этим прямоугольником располагаются всякие строки статуса, таскбары и прочая системная мишура. Поэтому использовать те же переменные из Window вообще-то не правильно.

Но я отвлекся. Итак, у нас есть формочка с двумя полями ввода, чекбоксом и кнопкой “войти”. Как все это дело обрабатывать? Ну что бы было удобно пользователю и программа не мозолила ему мозги со всякой дрянью?

Берем первый попавшийся под руку Visio и подумав, рисуем вот такенную блок схему. Если чего, то картинка кликабельна.

Запуск VseMoe

Вот такая вот небольшая схемка, которая показывает логику приложения от запуска до появления основного окна.

Что я преследовал, рисуя кучу этих линий?

– Если пользователь поставил галочку “запомнить меня”, приложение должно запускаться без каких-либо вопросов, запросов и прочего. Всякие блокировки оставим операционной системе.
– Однако пользователь может быть немного параноидальным и не хочет, что бы кто-то, кто имеет право пользоваться телефоном (ребенок к примеру), что-то там понатыкал. Защита обычным пин-кодом.
– Если пользователь специально на каком-то устройстве снял галочку “запомни меня”, засинхронизировался и перелогинился, то все остальные устройства при первом же подключении к сети должны заново запросить пароль и засинхронизироваться заново. Это защита от утери устройства/утечки токена.
– Ну и устройство не должно при обычной работе лезть в интернет за синхронизацией, если пользователь не разрешил. Говоря другими словами, настройки “синхронизироваться только через wifi” и “синхронизироваться только вручную”.

Как-то так. Про реализацию в следующем посте.

Что нести в облачный офис?

Итак, несмотря на мои страшилки в предыдущих постах, вы все-таки решили использовать “облака” в своей деятельности. Хоть чуть-чуть, но использовать. Как выбрать то, что стоит нести в облака, а что не стоит?

Для этого есть несколько методик, ниже я попробую объяснить наиболее … подходящие, что ли.

Методика первая, пусть будет “секрет полишинеля”. В соответствии с ней в облако может отправиться любой сервис, который использует данные из внешнего мира или отдает их туда. Под это определение прекрасно подходят такие сервисы, как электронная почта, телефония и веб-сайт.

“Ну ладно, веб-сайт понятно, а как же с почтой и телефоном? Их смогут читать/слушать чужие люди?”. Да, при наличии соответствующих навыков или всяких судебных решений их и так будут читать и слушать чужие люди. Если говорить про телефон, то на операторе (тот, который выдал вам телефонный номер) уже стоит система, позволяющая прослушивать все телефонные разговоры, проходящие через него. А что касается внутренних переговоров, то они в большинстве случаев абсолютно никому не интересны и способны забить любой сервер. То же самое касается и почты. Буквально пара команд у провайдера, который предоставляет вам доступ в интернет, как весь ваш трафик оказывается у него как на ладони. И не обольщайтесь насчет страшных слов SSL/TLS – в подавляющем большинстве случаев все вскрывается так же легко, особенно при наличии административного ресурса. Правда, вынужден добавить ложку меда: по разговорам со знакомыми, такое используют очень редко, ибо во-первых, принцип “неуловимого джо” никто не отменял, а во-вторых, через налоговую сделать все необходимое гораздо проще.

Следующая методика “берите все, что нам негоже”. Тут в облака отправляются данные, которые вам не нужны прямо сейчас или которые нужны всем. Тут главное установить принцип, насколько эти данные вам не нужны. Скажем, данные от систем резервного копирования вам именно сейчас не нужны, занимают много места и хранение их рядом с резервируемыми системами прямо противоречит всем нормам. Так зашифруйте их посильнее и пусть лежат где-нибудь в Америке. Что касается данных которые нужны всем: зачем устраивать на своем сервере каталог “для скачки”? Ролики, дистрибутивы программ и прочие подобные штуки с удовольствием примут к себе системы CDN. Будут довольные и пользователи, которые будут скачивать необходимое им быстро и Вы, так как канал до вас (или вашего сервера) не будет загружаться.

И наконец, в облака удобно/выгодно отправлять то, что относится ИТшному понятию R&D. Говоря кратко, то, что запускается “на посмотреть”, меняется по двадцать раз на дню и наполняется тестовыми или сильно устаревшими данными.

Теперь про данные, которые нельзя отправлять в облака. Понятное дело, Вы сами сможете определить список того, что позволить прочитать другим нельзя. У кого-то это будет бухгалтерия, у кого-то данные о техпроцессе, в общем, у каждого свое. Тут надо просто садиться и разбираться.

Но (по крайней мере для России) есть одна категория, которую нельзя отправить в “облако”: персональные данные. Говоря простыми словами туда попадает все от паспортных данных и места проживания и до всяких медицинских анализов и выписок. Нельзя не потому что не получится, а потому что “атата, если обнаружат”: ни одно известное мне “облако” не использует сертифицированных средств защиты информации. Вроде в России потихоньку начали появляться провайдеры, которые обеспечивают обработку персональных данных, но там от облаков только название, да и ресурсы, которые они могут предоставить, вызывают лишь недоумение.

А теперь абзац неприкрытой рекламы меня любимого: мне нравятся “облака” и я готов совершенно бесплатно (конечно, не откажусь и от оплаты, если предложите 🙂 ) поконсультировать/помочь/рассказать как сделать по поводу “облаков”. Просто из любви к теме. Я не связан с каким-либо провайдером или сервисом “облаков” или производителем систем виртуализции, поэтому мне абсолютно начхать на маркетинговые заморочки. Пишите письма на multik@multik.org, в skype пользователю kiltum или оставляйте комменты.

Дорогие мои облака …

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

Наверняка вы уже задумывались о использовании “облаков” в своем бизнесе, но простые расчеты на калькуляторе и консультации с ИТшниками неизменно приводили к обескураживающим результатам: стоимость аналогичного, но “облачного” сервиса неизменно оказывалась в 1,5-2 раза выше. Как же так? Ведь вон сколько компаний использует облака в своей работе и рапортуют о снижении расходов … А тут ИТшники опять начинают свою вечную волынку про недостаток серверов … Что делать?

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

1. Фаирволл. Он же брэндмауэр. Штука, которая выпускает вас в интернет, фильтрует лишнее и иногда служит HR-инструментом под названием “на какие сайты ходят сотрудники”. Хватит 50 тыщ.
2. Почтовый сервер. Без почты нынче никуда. Тут лучше заложить где-то в районе 100 тыщ.
3. Веб-сервер. Сайтик обычно много нагрузки не требует, поэтому тоже 50.
4. Сервер телефонии. Положим те же 50 тыщ.
5. Сервер бухгалтерии. Бухгалтера люди нервные, поэтому 100 тыщ и не надо экономить.
6. Файлопомойка. Сотрудникам надо файликами обмениваться. Возлагать это на почту – моветон. Тыщ 80 надо.
7. Резервное копирование. Есть компании, где уже теряли данные, а есть, где еще только будут. Тыщ 100.

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

Итого получается в районе 550 тысяч рублей. Эти 7 коробок жрут электричество, требуют охлаждения, запасных частей и квалифицированного присмотра. Через некоторое время их мощности начинает не хватать и начинаются узаконенные репресии пользователй в духе “более 500 мегабайт в почтовом ящике не хранить” и “бухгалтерия тормозит, потому что в сервере винт сдох” (хорошо, что тормозит. у некоторых просто падает). Знакомо?

Что делать? Бизнес растет, но на одних серверах разориться же можно … И тут в дело вступает хороший, качественный ИТшник. Срываю так сказать, покровы. Для начала: одиночные сервера никогда не загружены на 100%. Из-за разных там особенностей больше 60-70% нагрузку поднимать попросту нельзя: будет все ломаться.

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

Отсюда вытекает вполне логичное предложение: почему бы серверу резервного копирования не поделиться днем своими ресурсами? А серверу бухгалтерии и файлопомойки ночью? С использованием современных технологий – легко.

Сам процесс объединения стайки серверов в “облако” я пропущу. Вам это во-первых попросту неинтересно, а во-вторых, там слишком много нюансов, описанию которых пришлось бы посвятить много места.

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

Вам же главное знать то, что у вас теперь есть свое “облако”. Персональное, частное – называйте как хотите.

Что вы получаете?

– Возможность продать один-другой сервер. Подчеркиваю – возможность (ИТшники просто так не выпустят из своих рук 🙂 ). Ибо если одиночные сервера нельзя грузить на 100%, то в “облаке” вполне.
– Более высокую доступность серверов. Теперь в случае поломки одного из “железных” серверов есть возможность попросить “пододвинуться” другие, пусть и за счет уменьшения скорости работы.
– Возможность отдавать более мощный сервер (у нас же сервера не одинаковые изначально) на более необходимую сейчас работу. Скажем, днем самый мощный сервер будет помогать процессу сдачи бухгалтерского отчета, а ночью обрабатывать данные для системы резервного копирования.
– Более разумно распределять нагрузку. Скажем, отобрать ночью у почтового сервера ресурсы процессора в пользу других. Пусть письмо ходит не 1-2 секунды, как днем, а 10-20. Кому какая разница?

А теперь о более приятном. Если делать подобное с “нуля”, то более высокую производительность и бОльший запас по мощности всего комплекса можно получить с помощью пары серверов, каждый из которых стоит по 200тр. И эти серверы будут жрать меньше электричества, меньше греть окружающую среду и требовать меньший уход. 150 тысяч экономии прямо “в лоб”!

Но это “частное облако”. Как же можно заработать или сократить расходы с помощью публичных облаков?

Для начала можно легко увеличить безопасность вашего бизнеса. Не знаю как в других странах, но в России до сих пор не изжили “изъятие вещественных доказательств”. С одной стороны, счет не заблокирован и на нем есть деньги, а с другой – все данные остались на тех самых “вещественных доказательствах”. Вот для примера бухгалтерия. Объемы базы данных очень редко превышают еденицы гигабайт. Вот возьмите и дайте задачу, что бы система резервного копирования попутно заливала данные еще и туда. Для безопасности – хорошо зашифрованными. Сейчас стоимость хранения одного гигабайта на S3 – $0.03 в месяц. Да, я не ошибся – три цента за гигабайт в месяц. Добраться до архивов можно будет с любого компьютера, подключенного к интернету, а уж что с ними делать – дело ваше. Сравните со стоимостью хранения подобного где-нибудь на стороне “обычным” способом.

Затем рассмотрите свои бизнес-процессы и выделите те, которые требуют непродолжительных, но больших компьютерных ресурсов. Скажем, в каком-нибудь рекламном агенстве это может быть процесс рендеринга роликов. Покупать для этого отдельный мощный сервер, который будет 90% времени пинать балду – не выгодно. А без него никак. Куда лучше за $3 в час арендовать гораздо более мощный сервер в облаке и использовать его только тогда, когда надо. И кто мешает арендовать не один сервер, если роликов много?

Надо изредка рассылать большие объемы писем (и которые ни разу не спам)? Вон, SES берется доставить со всеми заморочками тысячу писем за 10 центов. Стоимость обычного почтового сервера, способного переварить хотя бы 20-30 тысяч писем за час, предлагаю узнать самостоятельно.

И так далее и тому подобное. Везде, где требуются большие объемы, гораздо дешевле воспользоваться мощностями гигантов, чем пытаться сделать свое и на коленке.

И наконец, можно заранее подготовиться к приятным, но внезапным неожиданностями. Для примера можно подготовить все необходимое, что бы ваш веб-сайт смог выдержать любой поток посетителей. В обычные времена ваш веб-сайт крутится у вас за стенкой. Но стоит возрасти нагрузке (скажем, отдел рекламы провел успешную компанию), как ваш веб-сайт сначала переездет к провайдеру (что бы не загружать ваш канал в интернет), а при дальнейшем повышении нагрузки начнет поднимать у провайдера свои копии. И так до тех пор, пока весь поток посетителей не схлынет. Схлынул – сайт вернулся в родные пенаты. Не верьте мне, просто возьмите калькулятор в руки и подсчитайте стоимость подобного решения. Если у вас подобные случаи случаются регулярно, то вы будете очень обрадованы открывшимися возможностями.

И подобных возможностей в каждой компании – уйма. Честно.

Если все так хорошо, то почему все так плохо? Во всем этом есть одна большая ложка дегтя: без квалифицированных специалистов подобное реализовать нельзя. В смысле реализовать можно, но вы скорее потеряете деньги, чем сэкономите. И пока технологии “молодые”, нет никаких сертификатов, лицензий и прочих документов, свидетельствующих о том, что тот или иной ИТшник умеет “нырять” в облака и что более важно, “выныривать” из них …

А таких – мало.

Облака, белогривые лошадки …

… или о облаках простыми словами.

Покупайте наших слонов, теперь и в облаках! Самые облачные облака по выгодным тарифам!

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

Для начала маленький экскурс в историю. Давным-давно компьютеры умели выполнять только одну задачу за раз. И если он начинал считать, сколько будет 2+2, то нипочем не хотел останавливаться. Потом компьютеры научили делать сразу несколько задач. Они могли одновременно считать сколько будет 2+2 и спрашивать у пользователя, сколько ему лет. Потихоньку увеличивая мощность компьютеров дошли до того, что один мощный компьютер мог представляться для окружающих кучей слабых. Ведь для очень многих задач куча слабых компьютеров гораздо удобней и выгодней одного, но очень мощного.

Но тут пришли продавцы и маркетологи. Первым надо было увеличить продажи, а вторые помогали первым, ведь им тоже перепадал кусок пирога.

Поначалу шаги было очень осторожными. Практически все шло под лозунгом “сократи расходы на сервера”. Ведь в самом деле, поставить и обслуживать один мощный сервер гораздо дешевле, чем кучку маленьких. Тут и стали называть эти маленькие сервера виртуальными. Ведь их нельзя пощупать, но они есть. Постепенно технологии дошли до того, что стало возможно объединять мощные сервера между собой так, что они могли “делиться” с соседями виртуальными серверами без их остановки. И на всех схемах сети такая конструкция обозначалась облаком. Типа мы знаем, что сервер там, но детали реализации от нас скрыты.

Ушлые маркетологи мгновенно раскопали ассоциацию и начали толкать “облака” в массы. В результате вышеописанное (несколько мощных серверов, которые стоят в серверной у вас за стенкой) стали называть “частное облако” или private cloud.

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

Следующим появились на свет “гибридные облака”. Это когда часть виртуальных серверов работает в серверной за стенкой, а часть – у провайдера. А для вас – ну абсолютно никакой разницы, где они размещены. Вы работаете с ними одинаково во всех случаях.

Больше всего “облакам” радовались ИТшники. Благодаря “облакам” у них исчезло очень много нудной работы по обслуживанию серверов … Конечно, появилось много другой работы, но это тема уже для другой статьи.

Итак, в чем же основное преимущество облаков?

– Снижение расходов на серверный парк. По моим прикидкам, переход с классической схемы (один сервис – один сервер) на облачную (много серверов – много сервисов) дает экономию примерно в 20-30% просто от самого факта использования.
– Снижение времени простоя. Теперь для обслуживания “железного” сервера нет необходимости останавливать работу размещенных на нем сервисов.
– Резкое ускорение специфических для ИТ задач. Поднять новый сервер или скопировать работающий – дело минут, но никак не часов.
– Возможность при наличии соответствующих навыков кратковременно и очень резко увеличивать мощность какого-либо сервиса.

Вот за эту особенность и ухватились в очередной раз маркетологи. И как обычно, выкинув самые значимые слова (я про навыки), ринулись на следующий виток. Необходимость как-то разделять “облака” их надолго не остановила и они придумали новые слова.

“Старые” облака (провайдер вам предоставляет один или несколько серверов, возможно объединяя их в одну сеть с вашей) стали называть IaaS (Infrastructure as a service). Инфраструктура как сервис. Легко понимаемая всеми ИТшниками модель. Яркий пример – Amazon

Вон та возможность резко увеличивать мощность (повторюсь, при наличии навыков!) привела к следующему варианту облаков: PaaS (Platform as a service). Платформа как сервис. Пример – Azure. Суть простая. Берет провайдер толковых спецов, которые настраивают какой-либо сервис как надо. А потом продает этот сервис вам. Скажем, у вас есть веб-сайт, на который приходит 1000 человек в день. Ваши маркетологи, продавцы и прочие товарищи что-то такое замутили, что к вам внезапно пришло 100000 человек. Обычно веб-сайт в таких случаях тупо умирает под нагрузкой. В случае PaaS правильно настроенный сервис начинает поднимать для внезапно свалившейся нагрузки еще сервера. Десять, сто, тыщу. В общем пока не переварит весь поток. А потом точно так же берет и “убивает” ставшие ненужными сервера. В итоге все довольны: пользователи увидели ваш сайт, а не сообщение о недоступности, вы получили новые заказы, а провайдер – деньги.

Очень это понравилось маркетологам и они придумали SaaS (Software as a service) или программа как сервис. Оно очень похоже на PaaS, но про отдельный сервис. Скажем, вам нужен почтовый сервер. Можно сказать админу, он купит сервер, настроит его … А можно пойти к провайдеру и купить доступ к его почтовому серверу. Если у вас в компании 100 человек, так и купите кусочек провайдерского сервера на 100 человек. А провайдер пусть уже сам мучается с антивирусами, антиспамами и прочей фигней. Яркий пример – Office 365.

Но тут внезапно обнаружилось, что SaaS один-в-один повторяет то, что предлагается уже много лет. В самом деле, купить кусок сервиса можно было очень давно. И Вам совершенно безразлично, на каких там технологиях крутится.

Думаете это кого-то остановило? Неа, просто стали продавать старое под новым соусом.

И для резюме нужно подвести итоги. Сравним их с привычной всем “своей серверой”

Преимущества:
– Быстрота развертывания. При наличии денег на карточке можно получить полностью готовый сервер или сервис за десятки минут. Причем в стране на выбор.
– Более высокая доступность. У провайдеров просто больше возможностей это обеспечить.
(ТОЛЬКО для частных облаков) – Более низкая стоимость обслуживания

Недостатки:
– Более высокая стоимость обслуживания. На данный момент – в 1,5-2 раза дороже. За тренд надо платить.
(для всех КРОМЕ частных облаков) – Полная потеря контроля за вашими данными. Что бы там не писали маркетологи в пресс-релизах и зазывалках, данные из облака очень легко (по сравнению с классической схемой) могут быть взяты без возможности какого-либо контроля с вашей стороны. Люди, которые имеют доступ к физическим серверам, всего лишь люди.

Тут обычно возникает мысль про то, что я (в смысле автор) ничего не понимаю. Ведь если “облака” стоят дороже, то почему ими пользуются? Люди же не настолько глупые …

Но где можно “выиграть в облаках”, я напишу в другой раз. Вдруг никому не надо и я только зря клавиатуру терзал? 🙂

Как правильно угробить компанию …

… или мой опыт, про который не напишут в книжках. Вторая часть

Айтишник – это прежде всего тонкая и чувствительная натура, а уже потом грязно матерящийся скунс.

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

Всякие умные слова можно прочитать … ну скажем, на e-xecutive.

Согласитесь же, круто все? Наша компания самая прогрессивная и вообще практически мгновенно адаптируется к изменяющимся условиям!

Однако … в общем, опять перейду на личности. В общем, в свое время я совершил две ошибки: во-первых, позволил этому зародиться в компании. Не подумал, пропустил, не смог доказать. Уже не важно. А во-вторых, вместо активного разъяснения я выбрал линию активного противодействия. Думаю, многие вспомнят совещания, где я прямым текстом говорил, что я дал команду подчиненным всех приходящих к ним с вопросами/задачами/еще чем посылать “на х.й”. Вообще всех. И все претензии отправлять мне. И мне было абсолютно пофиг на то, что айтишников ругали. Хорошо еще, что еще было кого ругать …

Что бы понять, почему я так возбудился, необходимо сделать небольшой экскурс в внутренности айтишника. Инженера, архитектора, черта лысого. Не важно.

Айтишник, по роду своей работы, просто вынужден оперировать многими сущностями. И число этих сущностей часто превышает несколько десятков. Причем иногда взаимосвязи между этими сущностями оказываются очень хитрыми и черезногузадирищенскими. Потребности бизнеса и все такое.

Не верите? Смотрите, что произойдет в гипотетической (да, она идеальная) организации при приеме на работу нового сотрудника. Кадровик вбивает в какую-нибудь систему “принят на работу Иванов Иван Иванович”. Система отправляет данные в кадровую систему (заплата, паспорт и так далее), кадровая система переварив данные и проверив все, плюет запрос в систему поддержки (компьютер со столом надо? к сети подключить надо?), система поддержки раскидывает запросы к АХОшникам (за столами и стульями) и к айтишникам (логин, пароль, распределение по группам и прочие). Данные от айтишников убегают назад в кадровую систему (где сидит), на портал (где типа все тусуются, можно посмотреть телефоны и прочее) и дальше расходятся по другим бизнес системам (где-то надо завести каталог, где-то скрипт выполнить, где-то еще что-то надо делать). И все это попутно проверяется на ошибки, синхронизируется между собой и так далее. А потом приходит Иван Иванович и отправляет запрос “не хочу быть Ivan, хочу быть Vanya” и начинается легкий армагеддец внутри систем, которые начинают внутри менять данные, да так что бы не порвать уже налаженные связи.

И это очень простой процесс. Вон, я кратко в абзац уложился. В реальности кто забивает на такие закидоны, кто пытается автоматизировать этот процесс.

К чему это я? И вот представьте себе айтишника, которому поручили добавить еще одну подсистему в уже существующую связку.

Сначала он укладывает в голове то, что существует сейчас. Примите как данность, что одинаковых систем не бывает и у всех есть нюансы, иногда (хорошо, почти всегда) не описанные.
Потом он мысленно пробегает по взаимосвязям в духе “ага, это идет туда, а потом собирается вот тут и тут”. Говоря другими словами имитирует деятельность системы прямо в голове.
Следующим шагом он добавляет в полученную схему новое. Мысленно. “тут надо перехватить, сюда идут, отсюда выходят …”
И наконец, проиграв еще раз схему, он ее реализует в реальности.

Так или примерно так работает башка у любого айтишника. Разница обычно в глубине “охвата” и “проработки” деталей. Кто-то способен в башке удержать инфраструктуру целиком, а у кого-то мозгов хватает только на одну функцию.

И вот состояние, в котором пребывает айтишник во время подобного, кто-то называет “потоком”, кто-то “размышлизмами”, кто-то еще как. У авиадиспетчеров вроде это называется “поймать картинку”.

А теперь самое противное: это состояние довольно легко прерывается и надо начинать все сначала (реально сначала, функции save или pause не предусмотрено). Прерывается шумом за окном, разговором, звонками. И кому-то получается отключиться от раздражителей просто так, а кому-то необходима помощь. И именно поэтому, зайдя в разгар дня в любую айтишную компанию, вы увидите людей с наушниками. Айтишные комнаты и так обычно самые тихие в компании, а тут еще и наушники одевают. Все именно для сохранения “потокового” состояния.

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

Для примера возьмем обычного инженера по системе Х. Система хорошая, используется самой компанией, плюс продается и внедряется другим. И этот инженер в структуре матричного управления по проектам, связанным с этой системой. Проекты обычно в разной стадии: где-то пресеил идет, где-то уже поддержка, а где-то внедрение …

И вот садится этот инженер, берет задачу “включить хрень в Х”. Читает документацию, вникает, заходит на систему, начинает править … И тут прибегает продажник с “тут клиент звонит, Х умеет такую фигню через пипку?”. Бабах! “Потока” почти нет. Выяснили, чем пипка от фиговинки отличается, умеет ли Х это и так далее, “поток” ушел совсем. Начинаем снова. Через некоторое время прибегает менеджер с другого проекта с вопросом “ну как там внедрение Х?”. Бабах! Начинаем снова. И это в зависимости от “проектной” загрузки повторяется с завидной частотой.

Результат: “включить хрень в Х” проседает по срокам и качеству напрочь. Инженер, как любой нормальный человек, начинает нервничать и пытаться хоть как-то вытянуть задачу, а раздражители продолжают сыпаться … Все последующее можете додумать сами.

И именно поэтому я дал команду всех посылать. Да, это невежливо, зато “поток” не прерывается. А уже пришедшим ко мне с претензиями я пытался объяснить, что у нас есть специальный человек, который занимается распределением задач по инженерам и контролирует их. Вот с ним все вопросы и решайте. А лучше, что бы и его не расстраивать и дергать понапрасну, идите в почту/систему управления проектами и там уже описывайте свои хотелки. И долго неайтишные люди не могли понять, что же они делают не так … “ведь я только спросить, чего вам жалко что ли …”.

К сожалению, только ближе к концу все поняли, что от них требуется и схема заработала без нервотрепки всех сторон. Сколько нервов было безвозвратно уничтожено – подсчету не поддается …

Я начальник, а значит подчиненные должны быть зае…ными!

Жила-была компания. Хорошо жила, развивалась. Постепенно внутренняя инфраструктура обрастала серверами в ответ на растущие потребности компании. Почта, CRM, файлопомойка, багтрекер, проджект-сервер и так далее и тому подобное. И во всех этих системах начали накапливаться результаты по проектам. В почте переписка, на помойке файлики, в проджекте графики и ход выполнения … В общем, жизнь кипит.

Любой начальник знает, что подчиненных надо контролировать. А то будут делать не то и не туда. А еще ему надо отчитываться перед вышестоящим начальником, а тому еще выше. А как контролировать подчиненных? Правильно, совещания. А какая основная цель совещания? Понять, что сделано (или не сделано) за прошедшее время и что надо сделать дальше.

И вот начальник придумал гениальную мысль: а пусть все подчиненные присылают отчеты! А я буду их смотреть и сравнивать, что изменилось между прошлым отчетом и этим. Ну и буду ругать согласно не сделанному. Потом, ведь эти отчеты можно будет использовать и для докладов вышестоящему начальству! Кругом же польза для меня любимого. Легко задавив робкие “так вон же, все данные лежат …”, быстро смастерил табличку и грозным рыком разослал по подчиненным.

Поматерились подчиненные, но делать нечего. Ты начальник, а я дурак. Стали заполнять таблички. Кто про время, кто про задачи, кто про проекты. Понравилось это начальнику. Всегда есть цифры и прочие слова, которые можно предъявить кому угодно. И время на совещаниях меньше тратит.

Но потом внезапно понял начальник, что он начал тонуть в отчетах. А потом пару раз произошли факапы. И наказать не получилось: сотрудники предъявили старые отчеты, в которых они прямо предупреждали о этом. А ведь перед вышестоящим начальником отвечать ему, а не его сотрудникам.

Думал-думал начальник и решил заставить сотрудников писать сводный отчет. Дескать, все мы в одной компании работаем, вот и собирайте все в кучу. И снова будем совещаться и обсуждать. И началось раздолье: кто не успел, тот виноват, ату его! А сотрудники стали тратить половину дня в выяснении, у кого последняя версия файла, почему кто-то записал то, когда в реальности вон то … нет, они потом сообразили использовать Google Docs, но все равно: потери времени были чудовищными.

А ведь будь начальник потолковее, возглавил бы процесс объединения систем, благо знания про такие системы были у его подчиненных, настроить отчетность как надо и реально получил бы инструмент контроля …