Шура Люберецкий

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

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

По на водке Биссо Атанасова – заходим на сайт “Таманской винной компании” (страна должна знать своих героев!), прокручиваем страничку донизу и видим сделанные безвестным веб-дизайнером “счетчики”, сообщающие нам, что с 480 га виноградников “компания” умудряется получить 82 984 320 литров вина в год и разлить их в 55 000 000 бутылок.

Делим одно на другое – хрен с ними, с бутылками по полтора литра (объем стандартной винной бутылки вдвое меньше, если что) – но вот урожайность в 1729 гектолитров с гектара, на порядок больше “нормальной” заслуживала бы нобелевской премии по биологии.

Вывод из этого довольно простой – “Таманская винная компания” в основном занимается розливом привозного “виноматериала” не самого высокого качества. Заходим на том же сайте в раздел “Каталог” и запоминаем – это так называемое “вино” брать не стоит.

Как известно, в своем крестовом походе против Телеграма Роскомнадзор придерживается тактики РВСН – “точность попадания компенсируется мощностью заряда”. Телеграм, говорят, пока не накрыли, а вот подсеть, через которую работает гугловская баннерокрутилка, заблокировали надежно.

Надо бы в качестве ответки на американские санкции включить Adblock на государственном уровне. Будет достаточно ассиметрично, а заодно – приятно.

Хочу поделиться впечатлениями от сборки и использования контролера печки для пайки оплавлением по мотивам описанного Олегом Артамоновым – собственно, это будет большой и развернутый комментарий к статье по ссылке:

http://olegart.ru/wordpress/reflow-soldering/

Собственно, такой девайс понадобился мне для сборки относительно “серийных” изделий – но что значит “серийных”? Скажем, “серые коробочки” для любительского и ретро-ралли разошлись уже тиражом в несколько десятков штук – правда, в процессе проектирования находится более продвинутый вариант. Пайка вручную даже пяти AtMega, пусть даже в “человеческом” корпусе с шагом выводов 0,8 мм – занятие малоинтересное по определению. В общем, запаивая к новому сезону очередную “партию” коробочек, я задумался – а нельзя ли как-то упростить это дело?

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

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

Сама электродуховка “для опытов” досталась мне бесплатно, будучи вытащенной из лежащего на балконе хлама. Подходящие дешевые печки стоят “в магазине” что-то около 2000-3000 рублей, б/у можно найти либо в собственном хламовнике (бесплатно), либо на каком-нибудь авито (недорого).

Плату устройства я немного переделал – во-первых, заменил SMD-шные резисторы и конденсаторы на выводные (просто их у меня много, да и паять вручную кучу SMD совсем неинтересно), во-вторых, сделал ее односторонней с несколькими перемычками на верхнем слое – для изготовления по “лазерно-утюговой” технологии (кстати, переход с SMD на выводные детали это дело значительно упрощает). Заодно выкинул “лишнее” – например, USB-порт и реле. Избавившись от USB, можно было бы попробовать и заменить микроконтролер на более дешевый – как выясняется, прошивка с ампутированным обменом по USB прекрасно влезет и в AtMega8, но я понадеялся, что получится использовать готовую прошивку без доработок. Забегая вперед, скажу – они понадобились, в первую очередь из-за того, что в выкидывании всякого ненужного барахла я немного поторопился и избавился от термодатчика TMP37.

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

Еще из моей лажи – я не сразу заметил, что несмотря на то, что дисплеи Winstar WH1602A (самый дешевый в продаже) и WH1602J (а этот использован в схеме) имеют очень похожие разъемы, назначение выводов в этих разъемах совсем разное – и после того, как я просто припаял дисплей к плате на “гребенке” и долго выяснял, почему он не работает, мне все равно пришлось сидеть и долго запаивать проводочки :)

Довольно важный вопрос, почему-то обойденный стороной в описании на сайте Олега – калибровка датчика температуры. Судя по всему, в ранних прошивках она была жестко зашита в контролер – а в выложенной на сайте версии прошивки появилась возможность немного варьировать параметры. К сожалению, описания этого процесса либо нет, либо оно погибло вместе с сайтом fclab.ru – так что кратенько прокомментирую, что нужно сделать. Используемая в устройстве термопара типа K (как в мультиметрах) имеет практически линейную характеристику в интересующем нас диапазоне от +25 до +250 °С – поэтому в EEPROM микроконтролера прошиваются два 16-битных числа, первое из которых для термопары равно 31 (расчет этого коэффициента можно увидеть в файле thcouple.c в исходниках прошивки) – и без особой необходимости менять его не надо. Второе число задает сдвиг шкалы – в единицах, равных 1/4 °С. Например, значение -100 увеличит показания температуры на 25 °C, а 100 – напротив, уменьшит их на ту же величину. Так как я выкинул термодатчик, показания которого принимались за температуру холодного спая термопары, пришлось записать в эту ячейку памяти -100 – приняв “комнатную температуру” за 25 °C. Конечно, можно было бы сделать и лучше – но, как показала практика, и так нормально. Показания прибора, когда термопара засунута в чайник с кипящей водой – около 96-97 °С, что можно считать более-менее приемлемым. Так как я выкинул дополнительный термодатчик, пришлось все-таки поставить WinAVR и добавить в прошивку обнуление показаний канала АЦП, к которому тот был подключен – иначе “градусник” начинал безбожно врать.

Да, еще один волнующий многих вопрос по поводу прошивки – какие использовать значения fuse. В принципе, все написано и в тексте – но чтобы не вдумываться в фразы типа “в конфигурации отключены DIV8, JTAGEN и HWBEN” – приведу здесь значения, которые мне подсказал “AVR fuses calculator” – L=0xDE, H=0xDD, E=0xCF.

Больше, наверное, никаких проблем и не возникло – ну разве что внезапно выяснилось, что в Москве проблематично недорого купить термопару – имеющаяся у меня термопара от мультиметра в металлическом корпусе оказалась довольно инерционной в показаниях, а провод явно пованивал при нагреве до 250 °C. Да, в некоторых магазинах (Промэлектроника, например) термопары типа K можно купить рублей за 100 – но только не в том случае, если такое желание внезапно возникло в пятницу в конце рабочего дня. В общем, проще и дешевле всего оказалось купить в Юлмарте самый дешманский мультиметр модели 838 (кстати, сравнив его со своим десятилетней давности Mastech 830, я просто офигел, насколько деградировали дешманские мультиметры). Заодно мне достались два разъема-”банана” – термопару я подключил проводками к клеммной колодке.

С учетом покупки мультиметра бюджет проекта составил примерно те самые 3000 рублей, которые жаба не позволила тратить на “подготовку производства” в Резоните – и надо сказать, что я в целом остался доволен – даже нанося паяльную пасту (я взял на пробу Multicore CR36) вручную из шприца (медицинского, с обрезанной толстой иглой), удалось добиться вполне приемлемого количества брака (прежде всего слипшихся ножек на микросхемах с малым шагом – это исправляется с помощью паяльника и “оплетки для выпайки”). Но главное – это скорость монтажа, нанести пасту, расставить детали и сунуть несколько плат в печку получается намного быстрее, чем в случае, когда все надо запаивать вручную. Надо бы попробовать нанести паяльную пасту через трафарет – я, конечно, попробовал вырезать какое-то подобие трафарета из прозрачной пленки, но ножом это делать неудобно, и те же ножки микроконтролера я объединил в одну широкую прорезь – замыканий получается меньше, чем при ручном нанесении, но все равно они иногда случаются.

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

Оригинал:

http://forum.easyelectronics.ru/viewtopic.php?f=15&t=6840

И копия:

http://www.cyberforum.ru/electronics/thread2104836.html

Смотрю цены на разные микроконтролеры – и неожиданно ЧиД оказывается одним из наиболее выгодных вариантов.

Atmega8A – 75 рублей в розницу в ЧиДе, и 74,51 – оптом в Терраэлектронике или Электронщике (я так понимаю, что он ищет, в частности, и в Терре) (UPD Терра=Компэл=Электронщик).

STM32F103RBT6 – 190 в розницу в ЧиД, и 212 – в Терре (правда, начиная от 40 штук – Терра выгоднее).

LPC1768FBD100.551 – 350 в ЧиД – и опять же, Терра может что-то противопоставить только при партии от 40 штук.

Кто-то в лесу сдох?

“Классическая” легенда про дизайн IBMовских ноутбуков утверждает, что дизайнеры первых ThinkPad сделали их черными и угловатыми, потому что вдохновлялись формой японской коробочки для еды – бэнто (или, в вольном переводе на русский, тормозка). Смею утверждать, что это все чушь, а на самом деле они фанатели от в равной мере нестареющего дизайна “Волги” модели 3102 :)

PS Нет, папа точно не “Мазерати”:

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

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

На “Гиктаймсе” опубликовали конспект первой лекции курса Олега Артамонова по программированию микроконтролеров. Курс, конечно, немного экзотический в сравнении с любым интернетовским руководством по тем же STM32 – в нем рассматривается программирование с использованием операционной системы RIOT. Никакого вам CubeMX, никакой FreeRTOS – но в целом материал не особо привязан к конкретной ОС и “железу” и ориентирован скорее на то, чтобы продемонстрировать подходы к программированию для микроконтролеров “вообще”.

Для тех, кому проще воспринимать видео – на Youtube выкладываются и видеозаписи лекций:

https://www.youtube.com/playlist?list=PLJEYfuHbcEIApuZR4L5tRiBCwTZCYeTNY

Но при всех заявленных и видимых достоинствах этих лекций, хвалить их целиком пока рано – поэтому перейду к всякой ерунде. Как водится, половина удовольствия от чтения “околоэлектронных” материалов на “Хабре” и “Гиктаймсе” – это комментарии, где обычно ссаными тряпками гоняют ардуинщиков. В этот раз к “гонимым” добавились также те, кто не осилил ничего, кроме всевозможных HAL и StdPeriphLib от производителя, и те, кто почему-то считает микроконтролером Raspberry Pi. Но все это не заслуживало бы упоминания – если бы не один комментарий:

…например, в Contiki — там многозадачность с инвалидностью третьей группы, там надо в треде либо без switch-case, либо без сообщений жить. Этому в университете всех учить не надо, кому в жизни не посчастливится — сами научатся.

https://geektimes.ru/company/samsung/blog/299187/#comment_10699171

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

Для начала – вот такой хитрый пример кода, который обычно называется Duff’s device – “Прием Даффа”, в честь Тома Даффа, обратившего внимание на то, что метки в конструкции switch языка C позволяют нарушать “блочную” структуру программы – например, перейти сразу внутрь цикла:

switch (count % 8) {
    case 0:    do { *to = *from++;
    case 7:         *to = *from++;
    case 6:         *to = *from++;
    case 5:         *to = *from++;
    case 4:         *to = *from++;
    case 3:         *to = *from++;
    case 2:         *to = *from++;
    case 1:         *to = *from++;
               } while ((count -= 8) > 0);
}

Кстати говоря, Duff’s Device упомянут sharpc в известном “Теоретическом минимуме для программиста“. Конструкция довольно дикая, мало чем отличающаяся от GOTO – и хочу заметить, что особых преимуществ по скорости (в оригинале она использовалась для того, чтобы развернуть цикл в memcpy) на современных процессорах она не дает. Знать о ней, наверное, надо, а вот применять – только по необходимости.

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

volatile int counter;

int example( int *lc ) {
    switch ( *lc ) { case 0:

    printf( "First run!\n" );
    while ( 1 ) {
        *lc = 9; case 9: if ( !(counter > 10) ) return 0;
        printf( "Threshold reached\n" );
        counter = 0;
    }

    } *lc = 0; return 2;
}

Будем вызывать эту функцию примерно таким образом:

int main( void ) {
    int lc = 0;

    while ( 1 ) {
        example( &lc );
        printf( "Back in main, counter = %d\n", counter );
        counter++;
    }

    return 0;
}

Обратите внимание, что строчка First run! напечатается только один раз, несмотря на то, что функция вызывается многократно. Фактически, таким нехитрым приемом реализован механизм ожидания событий – нетрудно догадаться, что в промежутках между вызовами нашей функции counter может изменяться как угодно (на это я намекаю, объявив его volatile). А теперь определим несколько макросов:

struct pt {
    int lc;
};
#define PT_BEGIN(pt)          switch((pt)->lc) { case 0:
#define PT_WAIT_UNTIL(pt, c)  pt->lc = __LINE__; case __LINE__: if(!(c)) return 0
#define PT_END(pt)            } (pt)->lc = 0; return 2
#define PT_INIT(pt)           (pt)->lc = 0

И перепишем пример, используя их:

volatile int counter;

int example( struct pt *pt ) {
    PT_BEGIN( pt );

    printf( "First run!\n" );
    while ( 1 ) {
        PT_WAIT_UNTIL( pt, counter > 10 );
        printf( "Threshold reached\n" );
        counter = 0;
    }

    PT_END( pt );
}

int main( void ) {
    struct pt example_pt;
    PT_INIT( &example_pt );

    while ( 1 ) {
        example( &example_pt );
        printf( "Back in main, counter = %d\n", counter );
        counter++;
    }

    return 0;
}

Хочу добавить, что в компиляторе из Microsoft Visual Studio этот пример не работает, если при компиляции указан параметр /ZI (он по умолчанию установлен для конфигурации Debug) – можно заменить его на /Zi.

Оцените, что получилось – исключительно средствами языка C реализован простенький, из говна и палок, механизм кооперативной многозадачности. Если добавить к нему планировщик и, скажем, какой-нибудь таймер, то получится та самая операционная система Contiki – названная в честь построенной из тех же говна и палок лодки Тура Хейердала. Теоретически, в Contiki есть и механизм вытесняющей многозадачности – но реализован он не для всех архитектур, в отличие от кооперативной, для которой достаточно лишь компилятора C. Это позволяет “портировать” ядро Contiki куда угодно.

Какие же у этого подхода недостатки? Начну с очевидного – использовать одновременно и protothreads, и конструкцию switch нельзя. Другая нехорошая штука – при переходе потока в состояние ожидания и выходе в планировщик теряются значения всех локальных переменных внутри функции этого потока. Это довольно неприятно, так как требует постоянно держать в голове “нестандартное” поведение программы. Бороться с этим можно либо объявляя локальные переменные потока, как static, либо используя глобальные переменные. Наконец, ждать событий можно только в основной функции потока, что резко ограничивает “полет фантазии” в реализации какой-то нетривиальной логики.

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