Высокотемпературный электронный термометр на ATTiny13, MAX6675 и TM1637
Решил сделать свою паяльную станцию и возник вопрос о её калибровке. Покупать на Али высокотемпературный точный измеритель температуры просто жаба задавила. Дома были в наличии простенькие микроконтроллеры ATTiny13 и четырёхразрядный дисплей на TM1637. А также завалялась пара аккумуляторов от электронных сигарет и термопара от мультиметра.
Поэтому решил сделать свой высокотемпературный электронный термометр, используя специализированную микросхему преобразователь для термопар K-типа.
Самая простая, которая была на Али, это MAX6675.
Заодно, решил проверить сколько кода нужно, по минимуму, для вывода данных на TM1637, если писать код без использования библиотек.
В качестве термопары используется хорошо знакомая версия для мультиметров. Цена на Али меньше трёх долларов за пару. Там именно термопара типа К, которая нужна для MAX6675.
На Али были куплены три микросхемы MAX6675 за четыре доллара. Там же был куплен пластиковый корпус размером 73 X 43 X 23 mm за доллар.
Микросхема MAX6675 имеет компенсацию холодного спая, что снимает эту проблему при измерениях с помощью термопары и даёт хороший по точности результат.
Немного помудрил со схемой, чтобы удобнее было собирать всё до кучи и ножки одной микросхемы удобно попадали напротив ножек другой.
В результате получилась такая схема:

На схеме также указана распиновка Arduino Nano и её пины, к которым подключалась схема при тестировании кода с Arduino Nano вместо ATTiny13.
Код писался в Arduino IDE 1.8.19.
Размер скетча при компиляции получился 362 байта. Так что желающие могут попробовать нарастить функционал. Например, фиксация максимального напряжения. Или запись температуры в память по кнопке, которые поддерживаются TM1637, и индикация по вызову сохранённых значений. Звуковая индикация разных событий (тоже через TM1637) и т.д…
В качестве программатора использовал Arduino Nano, прошитый под ISP программатор. При попытке прошивки иногда выдавалась ошибка. Устранялась повторным запуском процесса прошивки. Два раза подряд ошибка ни разу не выскакивала.
Ядро использовалось MicroCore.
Настройки Arduino IDE при прошивке вот такие:
Проверил написанный код с этой схемой в Proteus. Всё ОК.
Спаял, прошил – не работает. ((
Заменил ATTiny13 на Arduino Nano. Прошил тем же кодом. Всё работает.
Путём проб и ошибок и с помощью осциллографа выяснил, что вся проблема в величине пауз между сигналами на входе TM1637. При слишком коротких паузах, TM1637 не успевает отрабатывать команды СТАРТ, СТОП и ЗАПИСЬ БАЙТА.
Подобрал правильные паузы. Заработало.
При проверке точности получилось, что прибор завышает показания примерно на три градуса (проверял по комнатной температуре, температуре тела и по кипящей воде).
Внёс поправку в код скетча на минус три градуса. Стал показывать точно 100 при окунании в кипящую воду, 36 градусов в качестве медицинского термометра и при сравнении с комнатной температурой по обычному термометру разбежность ушла. Вроде нормально, учитывая паспортную погрешность MAX6675.
При сравнении показаний от трёх термопар от мультиметров, расхождения между ними не превышали одного градуса. То есть даже дешевые термопары от мультиметров штука достаточно стабильная.
Потом решил сэкономить ещё чуток памяти контроллера и заменил паузы между сменами уровней на выходе контроллера просто повторными выдачами команд на установку нужного уровня сигнала на выходах контроллера, идущих к TM1637.
Получилось. Работает.
Теперь, с учётом этих нюансов, можно пробовать сделать паяльную станцию с дисплеем TM1637 на базе ATTiny13.
С монтажом решил не заморачиваться.
Всё паялось навесным монтажом с использованием переходников для микросхем контроллера и MAX6675.
Внутри корпуса всё крепилось на горячий клей.
Фото результата:
1. Температура в комнате

2. Вид внутри

3. Заряжаем от USBmicro

4. Моя температура тела

Код скетча прилагается:
P.S.
Спасибо комментаторам — заметили, что на схеме не указано соединение отрицательного провода термодатчика с минусом питания. На фото внутренностей это соединение видно, а на схеме забыл дорисовать. Сейчас уже поправил.
И также отметили, что в тексте не указано, что MAX6675 имеет компенсацию холодного спая.
Тоже добавил в тексте.
Поэтому решил сделать свой высокотемпературный электронный термометр, используя специализированную микросхему преобразователь для термопар K-типа.
Самая простая, которая была на Али, это MAX6675.
Заодно, решил проверить сколько кода нужно, по минимуму, для вывода данных на TM1637, если писать код без использования библиотек.
В качестве термопары используется хорошо знакомая версия для мультиметров. Цена на Али меньше трёх долларов за пару. Там именно термопара типа К, которая нужна для MAX6675.
На Али были куплены три микросхемы MAX6675 за четыре доллара. Там же был куплен пластиковый корпус размером 73 X 43 X 23 mm за доллар.
Микросхема MAX6675 имеет компенсацию холодного спая, что снимает эту проблему при измерениях с помощью термопары и даёт хороший по точности результат.
Немного помудрил со схемой, чтобы удобнее было собирать всё до кучи и ножки одной микросхемы удобно попадали напротив ножек другой.
В результате получилась такая схема:

На схеме также указана распиновка Arduino Nano и её пины, к которым подключалась схема при тестировании кода с Arduino Nano вместо ATTiny13.
Код писался в Arduino IDE 1.8.19.
Размер скетча при компиляции получился 362 байта. Так что желающие могут попробовать нарастить функционал. Например, фиксация максимального напряжения. Или запись температуры в память по кнопке, которые поддерживаются TM1637, и индикация по вызову сохранённых значений. Звуковая индикация разных событий (тоже через TM1637) и т.д…
В качестве программатора использовал Arduino Nano, прошитый под ISP программатор. При попытке прошивки иногда выдавалась ошибка. Устранялась повторным запуском процесса прошивки. Два раза подряд ошибка ни разу не выскакивала.
Ядро использовалось MicroCore.
Настройки Arduino IDE при прошивке вот такие:
Проверил написанный код с этой схемой в Proteus. Всё ОК.
Спаял, прошил – не работает. ((Заменил ATTiny13 на Arduino Nano. Прошил тем же кодом. Всё работает.
Путём проб и ошибок и с помощью осциллографа выяснил, что вся проблема в величине пауз между сигналами на входе TM1637. При слишком коротких паузах, TM1637 не успевает отрабатывать команды СТАРТ, СТОП и ЗАПИСЬ БАЙТА.
Подобрал правильные паузы. Заработало.
При проверке точности получилось, что прибор завышает показания примерно на три градуса (проверял по комнатной температуре, температуре тела и по кипящей воде).
Внёс поправку в код скетча на минус три градуса. Стал показывать точно 100 при окунании в кипящую воду, 36 градусов в качестве медицинского термометра и при сравнении с комнатной температурой по обычному термометру разбежность ушла. Вроде нормально, учитывая паспортную погрешность MAX6675.
При сравнении показаний от трёх термопар от мультиметров, расхождения между ними не превышали одного градуса. То есть даже дешевые термопары от мультиметров штука достаточно стабильная.
Потом решил сэкономить ещё чуток памяти контроллера и заменил паузы между сменами уровней на выходе контроллера просто повторными выдачами команд на установку нужного уровня сигнала на выходах контроллера, идущих к TM1637.
Получилось. Работает.
Теперь, с учётом этих нюансов, можно пробовать сделать паяльную станцию с дисплеем TM1637 на базе ATTiny13.
С монтажом решил не заморачиваться.
Всё паялось навесным монтажом с использованием переходников для микросхем контроллера и MAX6675.
Внутри корпуса всё крепилось на горячий клей.
Фото результата:
1. Температура в комнате

2. Вид внутри

3. Заряжаем от USBmicro

4. Моя температура тела

Код скетча прилагается:
// Точный термометр до 1000 градусов на ATTiny13 с MAX6675 и TM1637
// есть отображение значка градусов в 4-ом разряде
//
// Скетч использует 362 байт (35%) памяти устройства. Всего доступно 1024 байт.
// Глобальные переменные используют 0 байт (0%) динамической памяти, оставляя 64 байт для локальных переменных. Максимум: 64 байт.
// Обновление данных 1 раз в секунду.
// Усреднение по четырём замерам
// Значёк градуса в правом разряде дисплея
// В коде поправка на -3 градуса - при этом точность температуры в комнате, температуры тела и температуры кипения воды - до одного градуса
#include <avr/io.h>
#include <avr/pgmspace.h>
#include <util/delay.h>
// Определить пины для кодключения к МАХ6675
#define miso PB0 // MAX6675 MISO - 5 ножка ATtiny13
#define cs PB1 // MAX6675 CS - выбор микросхемы - 6 ножка ATtiny13
#define clk PB2 // MAX6675 CLK - 7 ножка ATtiny13
// Определить состояние пинов для кодключения к TM1637
#define DIO_H() (PORTB |= _BV(PB4))
#define DIO_L() (PORTB &= ~_BV(PB4))
#define DIO_OUT() (DDRB |= _BV(PB4))
#define DIO_IN() (DDRB &= ~_BV(PB4))
#define DIO_RD() (((PINB & _BV(PB4)) > 0) ? 1 : 0)
#define CLK_H() (PORTB |= _BV(PB3))
#define CLK_L() (PORTB &= ~_BV(PB3))
//------------- ¤ркость свечени¤ индикатора TM1637 ----------
#define Bright0 0x88
#define Bright1 0x89
#define Bright2 0x8A
#define Bright3 0x8B
#define Bright4 0x8C
#define Bright5 0x8D
#define Bright6 0x8E
#define Bright7 0x8F
#define SetBright Bright5 //сюда прописать ¤ркость от 0 до 7. По умолчанию 5.
//------------------------------------------------------------------
// Коды цифр 0-9, пусто и значка градуса для сегментов (A-B-C-D-E-F-G)
const uint8_t digits[] PROGMEM =
{
// Соответствие разрядов и сегментов
0x3F, // 0 - B00111111
0x06, // 1 - B00000110
0x5B, // 2 - B01011011
0x4F, // 3 - B01001111
0x66, // 4 - B01100110 _1_
0x6D, // 5 - B01101101 6 | | 2
0x7D, // 6 - B01111101 |_7_|
0x07, // 7 - B00000111 5 | | 3
0x7F, // 8 - B01111111 |_4_|
0x6F, // 9 - B01101111
0x00, // пусто - B00000000
0x63 // градус - B001100011
};
//********************************************************************************************************
//*************************** SETUP *****************************************************************
int main(void)
{
//=================== Инициализация дисплея ===================
DDRB |= (_BV(PB4)|_BV(PB3)); // Настройка PB3 и PB4 на выход
PORTB &= ~(_BV(PB4)|_BV(PB3)); // Установка PB3 и PB4 в ноль
delay_msTK(100);
#if F_CPU != 9600000UL
#error "Частота в коде не совпадает с настройками IDE!"
#endif
//********************************************************************************************************
//********************* ОСНОВНОЙ ЦИКЛ ******************************************************************
while(1)
{
int t = getSmoothTemp(); //Читаем усреднённые данные из модуля термопары MAX6675 и ...
if (t > 3) // ... вычитаем поправку (у меня выдавал без поправки на три градуса больше)
t = t - 3;
byte ks = 0;
byte kd = 0;
while (t>=100)
{
t-=100;
ks++;
}
while (t>=10)
{
t-=10;
kd++;
}
//************ Выводим число на индикатор *******************
if (ks==0)
ks=10;
// 1. Команда установки данных (0x40 - автоинкремент адреса)
start();
writeByte(0x40);
stop();
// 2. Установка адреса начала (0xC0) и передача 4 цифр
start();
writeByte(0xC0);
writeByte(pgm_read_byte(&digits[ks])); // Первая цифра
writeByte(pgm_read_byte(&digits[kd])); // Вторая
writeByte(pgm_read_byte(&digits[t])); // Третья
writeByte(pgm_read_byte(&digits[11])); // Четвертая
stop();
// 3. Установка яркости (0x88 - включено, средняя яркость)
start();
writeByte(SetBright);
stop();
delay_msTK(100); // задержка
}
}
//********************* КОНЕЦ MAIN ******************************************************************
//*****************************************************************************************************
//*****************************************************************************************************
//*****************************************************************************************************
//********************* ФУНКЦИИ *********************************************************************
//------------------------------------------------------
//--------- Функция отправки одного байта ------------
void writeByte(uint8_t value)
{
uint8_t i;
for (i = 0; i < 8; ++i)
{
CLK_L();
if (value & 0x01)
DIO_H();
else
DIO_L();
value >>= 1;
CLK_H();
}
CLK_L();
DIO_IN();
DIO_IN();
CLK_H();
DIO_OUT();
}
//------------------ Команда СТАРТ --------------------
void start()
{
DIO_H();
CLK_H();
CLK_H();
CLK_H();
DIO_L();
}
//------------------ Команда СТОП ---------------------
void stop()
{
CLK_L();
DIO_L();
DIO_L();
DIO_L();
CLK_H();
DIO_H();
}
//=== Своя функция задержки в мс ====================
void delay_msTK(uint8_t ms)
{
while(ms--)
_delay_ms(1);
}
//******************** Усреднение по 4 замерам для стабильности показаний ***********************
int getSmoothTemp()
{
int sum = 0;
for (int i = 0; i < 4; i++) // В цикле суммируем показания 8 опросов ...
{
sum += spiRead() ; // ... в переменную sum
delay_msTK(240); // Делаем паузу между опросами - MAX6675 нужно время на преобразование 170 - 220 мс
}
return (sum >>= 2); // Делим показания на 4 - получаем усреднённое значение
}
//*************************** Чтение данных из модуля термопары MAX6675 ******************************
//https://arduinodiy.wordpress.com/2019/12/06/using-a-max6675-temperature-sensor-without-a-library/
int spiRead()
{
DDRB = DDRB | 0B00000110;
int rawTmp = 0;
PORTB &= ~(1<<cs); // cs,LOW
delay_msTK(2); // задержка 2 миллисекунды
PORTB |= (1<<cs); // cs,HIGH
delay_msTK(200); // задержка 200 миллисекунд
PORTB &= ~(1<<cs); // cs,LOW Опускаем CS для старта преобразования
//Считываем 11 из 14 бит из MAX6675 и сохраняем в rawTmp
//(больше не нужно - 11 бит это целая часть температуры без точнсти 0,25 градусов)
for (int i=10; i>=0; i--)
{
PORTB |= (1<<clk); // clk,HIGH
byte r=0;
if(PINB & (1<<miso)) // Чтение пина MISO - если на ножке MISO 1, то ...
r=1; // ... фиксируем единичку
rawTmp +=r << i; // Сохраняем считанный бит в переменную температуры
PORTB &= ~(1<<clk); // clk,LOW
}
PORTB |= (1<<cs); // cs,HIGH
return rawTmp;
}
//=========================================================================================================
P.S.
Спасибо комментаторам — заметили, что на схеме не указано соединение отрицательного провода термодатчика с минусом питания. На фото внутренностей это соединение видно, а на схеме забыл дорисовать. Сейчас уже поправил.
И также отметили, что в тексте не указано, что MAX6675 имеет компенсацию холодного спая.
Тоже добавил в тексте.
Самые обсуждаемые обзоры
Автору, конечно респект, но вид, конечно… Строго 18+!!!
Плюс програмирование, хорошая зарядка для мозга. У меня дед до старости задачки решал и пазлы складывал.
— была в наличии часть комплектующих
— нужен был прибор для калибровки
— нужно было проверить, сколько кода займёт обмен с TM1637 для дальнейшего применения такого индикатора с этим контроллером в паяльной станции
И так пойдёт. У нас тут куча адептов, что датчик температуры в ручке паяльника (для компенсации холодного спая) не нужен. :)
Комнатная температура не сильно отклоняется от этого значения.
И корректировать нужно не на температуру в комнате, а на температуру ручки. Когда много паял, моя нагревалась заметно (теплее чем ладонь)
Ну и на синем сайте 624р:
Мне мой обошелся дешевле.
Он меньше по размерам.
Нет проблемы со считыванием информации при пониженой освещённости.
Работает от аккумулятора и подзаряжается обычной телефонной зарядкой.
Есть возможность доработки программы под дополнительные хотелки.
В отличие от приведённого на Вашем фото, может использоваться не только для замера температуры жала паяльника.
Ну и точный, компактный высокотемпературный термометр в хозяйстве всегда пригодится. ))
Учитывая остаток свободного места у ATTiny13, можно доработать до высокотемпературного терморегулятора или сигнализатора высокой температуры.
Или там обычное измерение микровольт?
а отдельная микросхема — нафига? это она калечному ацп тиньки нужна, а не специализированным для мультиметров.
Дальше будет хуже из-за нелинейности термопары. А-ля 830-е не умеют учитывать нелинейность термопар. ))
Поэтому ожидать от наобум взятого мультиметра высокой точности явно не следует.
(Мне тут впервые за тридцать лет понадобилось измерять температуру более-менее точно, и именно мультиметром. А он десять лет назад делал это нормально, а сейчас, как оказалось, врёт безбожно. Вот и сижу, смотрю на его плату и чешу затылок — как же, не имея второго мультиметра, найти именно те два подстроечника, которые за термопару отвечают.)
И добавить какой-то ещё функционал в свой прибор я могу (например сохранение нескольких контрольных замеров по дополнительной кнопке или вывод показаний по Фаренгейту, или Кельвину, или превратить его в терморегулятор и т.д.), а Вы в свой мультиметр не сможете.
К тому же мультиметры без микроконтроллеров, с обычными вариантами а-ля ICL7106 не учитывают нелинейность характеристики термопары.
А она там есть. Вот для справки.
«Термопара имеет нелинейную характеристику. Зависимость между температурой рабочего спая и напряжением (термо-ЭДС), которое вырабатывает термопара, не является прямой линией (напряжение растет не пропорционально температуре).Ключевые особенности нелинейности: Большинство промышленных термопар (типы K, S, J, L и др.) имеют выраженную нелинейность, которая меняется в зависимости от измеряемого диапазона температур.
Причина: Эффект Зеебека сам по себе нелинеен, и величина термо-ЭДС зависит от разности температур горячего и холодного спаев. Как это учитывается: Для точных измерений приборы (вторичные преобразователи, контроллеры) используют специальные алгоритмы линеаризации, таблицы или полиномы для преобразования нелинейного напряжения в точную температуру.»
А где написано, что MAX не обрабатывает данные термопары для повышения точности?
Вот что говорит Алиса:
Qwen того же мнения:
Ну и цена у него не слабая.
У меня такого нет.
Поэтому мне проще сделать свой прибор за недорого с такой же точностью. ))
Если показания не совпадают — либо поддельная термопара, что встречается при покупке ее отдельно когда родную от мультиметра сломали или потеряли, либо «игрушечный» некалиброванный мультиметр
P.S. Ничего не имею против DIY, отвечаю лишь на сообщение о невозможности нормально измерять температуру мультиметром.
Те, что не на контроллерах, а на простых АЦП типа 7106, не отличаются точностью.
10 — клон Хакко и пяток датчиков в комплекте — www.aliexpress.com/ssr/300000512/BundleDeals2?productIds=1005012013884820%3A12000057287106823
Пределы там, правда, 600 и 700 градусов заявлены, но для паяльной станции — с головой
Edit: теперь оно меня ими спамит… Вот за 3.45: https://www.aliexpress.com/item/1005008703344868.html — и всё это именно для паяльника, с соответствующим креплением датчика.
Само устройство 12.31
Неясна конечная цель.
Тм-902С решает задачу по приемлемой стоимости
Чтобы ТХА работала до 1200°С, ее нужно как-то упаковать — это главная проблема, с чем я, например, бился лично ) стандартные термопары типа К упакованы в нерж футляр из 304, который и ограничивает Т применения на уровне градусов 800°С.
Мне мой обошелся дешевле.
Он меньше по размерам.
Нет проблемы со считыванием информации при пониженой освещённости.
Работает от аккумулятора и подзаряжается обычной телефонной зарядкой.
Есть возможность доработки программы под дополнительные хотелки.
При том, что платина-родий для моих применений очевидно избыточна. Плюс, если правильно припоминаю — платинородиевым же нужен газовый поддув нейтральным газом, чтобы не происходило отравления и выгорания? Это не для бытового применения.
Сам когда писал либу под MAX31855 — github.com/enjoyneering/MAX31855. Меня тогда очень просили добавить линеаризацию термопары. Внезапно микруха этого сама не умеет. Вобщем вам есть еще чего добавить, чтобы вообще шик-блеск.
Кстати для усреднения очень хорошо работает медианный фильтр на 3 измерения. Пример тут — github.com/enjoyneering/HCSR04
Одна дополнительная команда в коде решила проблему неустойчивого обмена данными.
Эти конденсаторы нужны при работе с устройствами создающие большие помехи, типа коллекторных двигателей и тд.
За див конечно плюс
Докупались только корпус и MAX 6675.
Итого 2,5 бакса затрат.
При 770 мм рт. ст.: примерно \(100,37^\circ\text{C}\).
При 750 мм рт. ст.: примерно \(99,63^\circ\text{C}\).
Как видно из этих данных, изменение давления на каждые 10 мм рт. ст. от нормального (760 мм рт. ст.) меняет точку кипения примерно на \(0,37^\circ\text{C}\) в соответствующую сторону.
Вот, например, для Москвы сегодня давление 742 мм рт.ст., моя квартира примерно на 40-50 метров выше базовой погодной станции, если верить навигации, карте высот и яндексу. Т.е у меня должно быть примерно 738 мм рт.ст., что даёт около 99.16 градусов кипения воды. Ближе к 99, чем к 100.
Хотя при точности МАХ в 2 градуса толку от такой калибровки мало. Но… Когда-то я пытался по воде откалибровать свою схему тоже, поверенный прибор показывал 99.2-99.4 температуру кипящего чайника. Вот и вспомнилось к случаю. :)
Но это я так, подушнить в качестве развлекательного чтения.
Давление бортовой компьютер машины показывает 992 мбар. Это 744 мм.
613 рублей в Озоне… И тут мне вспомнился пошлый анекдот про размеры и форму огурчиков… «Мне без разницы форма и размеры — мне их в окрошечку»… Сколько времени у меня уйдет на ожидание комплектухи, поиски всякой всячины для комплекта, пайку, программирование… Я за час зарабатываю больше, чем стОит готовый прибор! Я лучше потрачу свободное время на более полезные дела, с теми же Ардуинками более интересные и нужные проекты…
Каждый тратит свободное время как хочет.
Меня мой вариант времяпрепровождения вполне устраивает. ))
в смысле?
По-моему автор заслуживает похвалы за разработку, а он почему-то вынужден оправдываться…
ну так его аргументация критики не выдерживает.
но зачем она вообще нужна — непонятно, захотел — сделал.
У меня при разработке была такая:
— была в наличии часть комплектующих
— покупать готовый было дороже
— готовое решение невозможно доработать, при необходимости
— нужен был прибор для калибровки
— нужно было проверить, сколько кода займёт обмен с TM1637 для дальнейшего применения такого индикатора с этим контроллером в паяльной станции
но если так хочется поспорить, то во1ых готовый таки дешевле, во2ых сама идея калибровки паяльника практического смысла не имеет, равно как и изобретения велосипеда в этой (ейный контроллер) области — тоже, ибо их полно готовых и тоже — дешевле.
Ссылочку дадите на покупной за 4 доллара?
Ссылочку на паяльную станцию с цифровым дисплеем и ценой до 10 долларов дадите?
А если Вам не нравится точное отображение температуры жала на дисплее, то это только Выша личная проблема. Не нужно за всех делать подобные заявления. ))
Мне достаточно было примера, когда паяльная станция GVM T12-XS за сорок долларов, свежепривезённая из магазина, врала более, чем на 30 градусов.
https://www.ozon.ru/product/tm-902c-portativnyy-udobnyy-izmeritel-temperatury-k-tip-zhk-tsifrovoy-termometr-termopara-zond-1300-4108968321
контроллер — 600р:
https://www.ozon.ru/product/youlort-payalnik-75-vt-keramicheskiy-nagrevatel-1281909521
мне на него пофиг, а с подобного бессмысленного перфекционизма — смешно.
И контроллера паяльной станции дешевле 10 долларов там тоже нет.
А на тиньке и TM1637 контроллер обойдётся в пять баксов. Так что Ваш пример с Озона всё равно дороже — 8 у.е.
Ну, а если Вас не смущает ошибка паяльной станции более 30 градусов, то я же не настаиваю — работайте и такой.
Я предпочитаю поточнее.
Программировать в среде Wiring на «чистом C» — своеобразное эстетство. Сам порой балуюсь.
«Потому что могу».
Очень красивый проект.
смысл правда сильно не очевиден, ибо в плюсах безотносительно всякого обьектного есть удобные конструкции.
у автора странное только про цены.
Хотя в молодости и в кодах 580-го процессора напрямую приходилось кодить. ))
Со всей математикой, с выводом в текстовую таблицу для бухгалтерии, все дела…
Это, видимо, моё личный рекорд несоответствия инструмента задаче )))
Да уж — были времена.
И всё это без помощи ИИ. ))
Единственное, поддерживать такой продукт труднее.
Если Вы (вдруг) не в курсе, типичная процедура инсталляции FreeBSD заключается в формировании конфигурационного файла и последующей компиляции ВСЕЙ системы под конкретную машину прямо на ней же.
Но тут сама задача и не требовала компиляции вовсе, можно было писать хоть на Бейсике.
Надо всего лишь отпарсить текстовый лог-файл сендмейла за месяц, выбрать из него нужные данные, разложить по юзерам, пересчитать в объёмы, перемножить на цены и выдать табличку для бухгалтерии, будет оно при этом считаться 5 секунд или два часа — не имеет значения.
Буквально парой лет позже намного более сложный биллинг реального времени для карточного дайлапа я написал на перле, который для этих целей подходит просто идеально, и система успешно работала много лет, до физической кончины дайла у этого ИСП.
Когда в нашем городке частные компании начали переходит с дайлапа на постоянные подключения, безлимита поначалу не было и платили за объем. У нас в компании (где я тогда работал) решили разрешить сотрудникам доступ к интернету, но брать с них деньги за скачанный объем, поэтому возникла задача создать инструмент, который бы этот объем считал. Я также написал на перле анализатор логов WinGate, что задачу решило. Однако подсчет логов за месяц занимал несколько минут, из-за чего я не мог выложить это решение в публичный доступ и разрешить всем сотрудникам самостоятельно смотреть, сколько они потратили. Тогда я переписал анализатор на С++ используя memory mapped file и оптимизированный подсчет, что сократило время его работы до 10-15 секунд!
Но при этом такие откомпилированные программы всё равно будут менее производительны, чем программы, написанные на нормальных компилируемых языках, из-за больших накладных расходов, вызванных изначальным наличием в исходных языках особенностей, характерных для интепретируемых языков.
На что перлу достаточна одна строка, в бейсике потребует пару станиц.
Я писал тот биллинг на коленке и сам, один. Собсна, и весь узел собирал сам))
Раз в минуту один перловый скрипт через rlogin опрашивал поочерёдно все модемные пулы, сделанные на роутерах Cisco 3640, — «кто сейчас на линии», складывал в файловый буфер, всего было около 200 модемов, подключенных потоками ISDN PRI.
Другой скрипт брал из буфера, парсил, и для каждого активного юзера проверял в базе на мыскле его тарифный план, вычитал из остатка его баланса стоимость минуты в соответствии с временем суток по тарифному плану, и если вдруг остался ноль или появился административный запрет (оператор отключил юзера) — ставил на него флаг третьему скрипту, который заходил через rlogin на нужную киску и отключал юзера.
При подключении юзера киска запрашивала доступ для него у радиуса, который адресовался к четвёртому скрипту, тот проверял в той же базе на мыскле, есть ли такой юзер, не запрещён ли административно, хватит ли у него денег на балансе хотя бы на минуту работы в соответствии с его тарифным планом и временем, и выдавал или не выдавал разрешение радиусу, а тот — модемному пулу.
Там же крутились два простеньких веб-интерфейса на том же перле, один административный, для ввода/удаления/пополнения баланса операторами, другой — юзерский, для текущего контроля.
Карты вводились в базу пачками по 100 штук, были и индивидуальные аккаунты по договорам, вводились, понятно, по одному.
Всё это работало на двух самосборных p266, на одном — мыскль и радиус, на другом — собственно биллинг и веб-морды.
На каком-то из них крутились ещё и сендмейл для всех желающих, и МРТГ (а он тоже на перле) для рисования в рил-тайме красивых графиков загрузки модемных пулов, каналов и пр.
Всё — под FreeBSD.
И замечательно, с огромным запасом хватало производительности этих двух дохлых петухов на ежеминутный, напоминаю, контроль, вообще никакой потребности что-то переписывать более оптимально не возникало.
А, ещё примерно на такой же железке отдельно был собран BGP-роутер с брендмауэром и шейпером, тоже под фрями, я ж честно получил в райпе под этот узел AS и блок IP-адресов ))
Сиску :) Как бы это по-русски не звучало двусмысленно, но произносится именно так.
Хороший умный программист, разумеется, на ассемблере сделает лучше, чем сможет компилятор.
Но много ли может сделать один хороший умный программист?
А при масштабном производстве, когда задачу приходится разбивать на множество частей для множества разных людей с разными навыками и мозгами, использование компилятора легко может дать лучший результат.
Но есть места, оптимизация которых дает огромный прирост. Например, мы решали одну задачу где нам надо было выводить масштабированный растр. Мой коллега сделал это по пикселям — цикл, цикл, вычисление адреса пикселя, вывод. Код был простой и понятный, но давал практически два кадра в секунду. Тогда пришел я, переписал это на ассемблер х86, добавил MMX для коррекции растра на лету, подняв производительность до сотни (емнип) кадров в секунду.
Связь простая — 50 пользователей по 2 минуты — это уже 100 минут. Каждый пользователь дергал сервис раза 3 в день, это 5 часов пустой работы процессора. А сервер должен был еще другие задачи выполнять, интернет он раздавал «постольку поскольку». Ну, и если сразу 2-3 человека ткнут в сервис, результата вообще никто не получал, отваливалось по таймауту.
Позже я так и сделал, когда нагрузка даже от сишного кода стала мешать основным функциям сервера. Но я же здесь не архитектуру обсуждаю, а сравнение быстродействия перла и си.
Нажал юзер кнопочку «посчитать» на веб-морде, через «несколько минут» получил в почту файлик с итогом, в чём проблема?
Или сделать запуск по крону раз в час с расчётом для всех, а по запросу юзера выдавать ему его цифру с точностью до последнего часа, «по состоянию на 13.00».
Да, первые компиляторы Паскаля были ох и ах. Однако среда ТурбоПаскаль сделала язык столь популярным, что гиганты просто не могли пройти мимо поля непаханного. Дальше от версии к версии компиляторы становились сильно умнее.
Си — изначально «надстройка над ассемблером». Он НЕ МОГ работать медленнее. Вот не всегда экстремально идеально — да, матёрый ассемблерщик всегда мог выкроить пару килобайт или сотню тактов, переписав на ассемблере. Поэтому Кёрниган с первой минуты имел в линии языка обязательную поддержку инлайн-вставок инструкций ассемблера. С первых же минут, с нулевой версии.
Вы смотрели код, который выдает компилятор? Я смотрел. Во всех компиляторах и под все платформы, с которыми работал. И впечатлил меня только IAR под ARM — вот он реально генерировал крутой код, который было тяжело побить ассемблером. Но, тем не менее, свое демонстративное Radix-4 FFT компания ST (производитель STM) написала на ассемблере.
Да, я всегда смотрю код. На всех платформах. И меня, например, притно удивил код, который компилируется из C++ под AVR.
У первых компиляторов C никакой оптимизации не было. Хотя бы потому, что компиляторы эти писали те самые люди, которые этот язык сочиняли. А у них для этого не было времени — их производственным заданием было написать («быстренько склепать») операционную систему для компьютера, создаваемого в это время той фирмой, в которой они трудились.
С точки зрения возможности получения эффективного кода между Pascal и C нет никакой разницы. Вообще никакой. (Если, конечно, исключить из рассмотрения компиляцию для DEC-овских процессоров ;-) )
Сейчас уже мало кто помнит, но у некогда у Microsoft были компиляторы с Fortran, Pascal и С. А фактически это был один и тот же трёхпроходный компилятор, потому что второй (оптимизация) и третий (кодогенерация) проходы у них были общие, различался только первый проход (синтаксический разбор).
Возможно, у нас разное понимание качества ассемблерного кода, потому что я начинал программировать с ассемблера Z80, потом был ассебмлер х86 и только потом паскаль и си. И я всегда обращал внимание, насколько плохой код выдавали компиляторы и всегда понимал, как его можно сделать лучше.
Это лишь подтверждает предыдущий абзац, потому что я еще не видел, чтобы компилятор генерировал хороший код для АВР. А уж на АВР у меня много ассемблерных проектов.
Ассемблер это компилятор с некоторого языка, в котором машинные команды записываются текстом.
При этом для одних и тех же машинных команд может быть несколько разных способов их текстовой записи и, соответственно, несколько разных ассемблеров. (Примеры хорошо известны.)
Си — не надстройка над другим компилятором, а самостоятельный компилятор. И поэтому его встроенный язык ассемблера может иметь свой собственный, ни на что другое не похожий синтаксис.
Дальше есть компилятор Си, он берет на вход текстовые файлы, а на выходе выдает (условно) машинные коды. И как бы он не старался, он не сможет выдать решение более оптимальное, чем А, потому как А является самым оптимальным решением. А вот хуже выдать вполне может. То есть высказывание:
Ложное.
Представьте, что есть две машинные команды: X и Y — абсолютно друг от друга не зависящие (в том смысле, что результат не зависит от порядка их исполнения). Но в том конкретном месте конкретной программы, где они оказались рядом, из-за загруженности конвейера предшествующими командами, последовательность «X; Y;» будет исполнена медленнее, чем «Y; X;». Сможет человек это учесть?
(Причём в каком-то другом месте более быстрым окажется применение «X; Y;».)
В итоге и решение человека, и решение компилятора будут уступать А, но компиляторное окажется лучше человеческого.
(Битву за шахматы человек уже проиграл.)
А еще на современных процессорах многие алгоритмы упираются в производительность памяти, и тогда взаимное расположение команд уходит на второй план, потому что процессор всё равно тратит такты в ожидании данных.
Выполнение команд процессором намного проще шахмат, поэтому всегда будут люди, которые будут писать ассемблерный код лучше компиляторов. Ведь процессоры создают тоже люди, а уж создание процессора значительно более сложная задача, чем написание под него кода.
Алгоритм в любом случае создаёт человек. На долю творчества компилятора остаётся только оптимальное распихивание по регистрам (и памяти) результатов промежуточных вычислений. И с некоторых пор — выбор порядка выполнения некоторых операций.
Да. Компиляторы же стараются делать кроссплатформенными (как по части операционок, так и по части архитектур процессоров), и поэтому они не умеют выжимать максимум из каждой конкретной архитектуры. Но когда производитель процессоров делает компилятор, заточенный под конкретно его процессоры, то результат бывает куда лучше.
В том-то и дело, что в подобных случаях человек пишет по наитию, а специализированный на конкретном процессоре компилятор держит в себе информацию о внутренних подробностях исполнения команд процессором и может подобрать действительно наилучшую их последовательность, чтобы минимизировать ожидание. (В конце-концов, сами команды ведь тоже вычитываются из памяти.)
Оптимизирующий компилятор, как и в шахматах, берёт «грубой силой» — он в процессе работы способен оперировать гораздо большим объёмом информации и осуществлять полный перебор вариантов.
Многие процессоры сейчас чуть ли не студенты собирают из готовых библиотечных модулей как из блоков конструктора «Лего». И даже создание новых архитектур без использования типовых библиотек не обходится.
А с другой стороны, для VLIW-процессоров («Эльбрус» и др.) писать эффективные программы на ассемблере никто даже не пытается — настолько это дохлый номер.
В принципе, проект и публиковался именно для демонстрации возможности простейшим контроллером и минимальным кодом обмениваться с индикатором и измерителем температуры.
Следующий шаг будет — сделать паяльную станцию с таким индикатором на таком же контроллере.
Попытаемся в килобайт памяти впихнуть код с приемлемым функционалом паяльной станции.
Вы сомневаетесь, что без ПИД можно поддерживать температуру с достаточной точностью?
В килобайт памяти вряд ли получится ещё и ПИД встроить.
Нет, формально там конечно интеграл и производная, но покуда у вас микроконтроллер тактируется, то их вы будете считать из дискретного ряда значений. Ну а интеграл – суть сумма всех, а производная – разность двух последних.
Вот практическая реализация ПИДа и сведётся к арифметике на пальцах.
У AlexGyver был наглядный урок/статья про пид регулятор – там можно и теории покурить чтобы свой сделать и просто код своровать, скорее всего есть библиотека, он любит велосипеды писать.
Не думаю, что оставшейся памяти хватит для реализации ПИД.
Да и смысла сильного не вижу.
В чём в паяльной станции преимущество ПИД?
Здесь я с Вами соглашусь, что для паяльника гонка за точностью не имеет практического смысла.
Смысл ПИДа еще и в том, чтобы уйти от автоколебаний, когда система за счет инерционности проскакивает установленное значение — датчик читает текущее значение и командует на возврат — возврат снова с проскоком из-за различных причин (та же самая инерция, например) — команда на обратный возврат в точку — ну и понеслась дерготня. Особенно замечательно будет, если после тяжелого полигона бросить паяльник на подставку — он еще какое то время будет качаться туда сюда туда сюда ) простой способ подавления через введение гистерезиса — ну да, наверное, проблему (отчасти) решит… «Жили же до этого как-то без этого» ©
но тогда другой вопрос от нашего читателя Олега Груненкова встает вертикально ))) то есть мы «городили городили да не выгородили»: зачем МК+вся электроника +..+..+..., если в конце концов мы вынуждены вернуться к введению гистерезиса как к самому простому, давно известному не идеальному способу подавления АК как в обычном начального уровня пропорциональном регуляторе с обратной связью??? А в Вашем случае гистерезис выглядит единственным действенным способом, в противном случае Вы сами сказали, что немедленно упираетесь в потолок по объему кода…
Красоту проекта я оценил. Трудозатраты — Вы молодец. Лаконичность кода — отлично ))) знание матчасти, умение пользоваться паяльником+программирование — супер.
Практическая значимость — ? Хотел бы повторить — Х. Рекомендовал бы кому-то к повторению — Х.
«Демонстратор возможностей» ©
Просто мне нужен был свой термометр. Решил сделать из того, что было под рукой.
Глянул поисковиком — не нашел подходящего варианта на ATTiny13 + TM1637.
Ну и решил добавить MAX и поупражняться со сжатием кода.
А, заодно, поделиться практическими решениями компактного кодирования для ATTiny13. Может кому полезно будет при освоении простых контроллеров.
А для паяльной станции, может, ATTiny85 возьмете? Там все же памяти побольше.
вот тут что-то было на тему mysku.club/blog/diy/103561.html
Тиньки я брал давно и меньше, чем по пол доллара.
Для простой паяльной станции на дисплее TM1637 тинек вполне хватает.
Для навороченной паяльной станции вполне хватит LGT8F328, которых тоже валяется жменя (тоже меньше, чем по доллару за штуку).
Ну и каких возможностей мне с ними не хватит?
Вот и я про то же — ну нельзя всё деньгами мерять.
Как измерить удовольствие, полученное от того, что получилось решить поставленную себе задачу. ))
Хобби оно же не для денег.
Это же вдвойне приятнее. ))
Про рейтинг это не ко мне — я довольно редко пишу здесь статьи. И чужие практически не комментирую.
Вроде и не сильно критично 10 градусов, а неприятно.
И таки да — очень приятно доверять показаниям ампервольтметра.
mysku.club/blog/diy/105881.html
mysku.club/blog/diy/105870.html
Может мне важнее удовольствие получить от того, что удалось впихнуть нужный функционал в такую малютку-контроллер. ))
Я вот про это Вам написал «время, потраченное на впихивание в этот килобайт».
Вы моё время и работу, которую я делаю для души, пытаетесь в деньги переводить. ))
А приводить Вам в качестве аргумента «работу для души» явно же бесполезно. ))
Вы в таких категориях, как я понял, мыслить не привыкли. ))
«Захотелось попробовать» — абсолютно достаточный аргумент, никакие иные не нужны.
Не просто захотелось. А с одной стороны возникла потребность в устройстве.
С другой был некий задел по комплектующим, что позволяло получить результат за недорого. И с третьей — действительно посчитал, что приятнее будет сделать своими руками прибор более компактный, удобный и с возможностями развития, чем покупной и параллельно подготовить компактный код для паяльной станции на ATTiny13…
Недавно тоже отвечал на подобное:
mysku.club/blog/diy/105562.html#comment4773963
Захотел — сделал, хочет — оправдывается, хозяин-барин ))
Я пытаюсь объяснить, что кроме финансовой мотивации, могут быть и другие аргументы:
— получить удовольствие от собственной работы,
— поделиться, возможно полезными, способами минимизации кода с любителями покопаться с тиньками
— заинтересовать кого-то возможностью создания на базе простого устройства собственных расширенных решений (высокотемпературного терморегулятора или контроллера превышения температуры, например).
Но далеко не всегда получается объяснить это людям, пересчитывающим моё свободное время на деньги. ))
У него, кстати, есть интересный проект паяльной станции на агдуинке.
Я для себя его немного подшаманил — переделал на LGT8F328, добавил возможность работать с С245 дополнительно к Т12 и русифицировал меню.
Пришлось правда свои шрифты русские делать. С русскими шрифтами U8g2lib.h — не хватает памяти.
Ну нету у меня тиньки 25. А десяток тинек 13 ещё завалялся. ))
Почему нельзя было сразу _delay_ms(100)? В чем была такая необходимость делать через цикл? Я понял, что в макрос _delay_ms нельзя подставить переменную, но у вас в коде вроде бы везде константы прописаны.
Для чего переменные kd и ks? Я увидел что они для вывода на экран, но для чего они в принципе, что вы из них иногда вычитаете сотни и десятки?
Тот код, что в статье, даёт при компиляции скетч в 362 байта. Если заменить функцию delay_msTK на макрос _delay_ms() во всех местах в программе, то объём скетча вырастает до 402 байт. Я думаю, что это происходит потому, что макросы вставляются в программу напрямую, а не используются как однажды написанная и многократно используемая функция.
С такой же целью используются для получения значений десятков и сотен счётчики kd и ks вместо кода типа
int ed = t % 10; // 3 (единицы)
int des = (t / 10) % 10; // 2 (десятки)
int sot = (t / 100) % 10; // 1 (сотни)
который даёт ещё больший прирост размера программы — до 452 байт.
Счётчики экономичнее, чем деление. Особенно для ATTiny13 и им подобных AVR с урезанным математическим функционалом.
Что не так?
А по умолчанию Arduino IDE и так компилирует код с флагом -Os (оптимизация по размеру).
Впрочем, Вы всё можете проверить сами — код программы в статье есть.
Они обе типа «К» и дают одинаковый результат.
Только в том, что от мультиметра, уже есть подходящие контакты.
Хотя Вы, наверное правы — стоит добавить в статью.
Вечером подправлю.
На плате капелькой припоя ножки 1 и 2 соединены. Вот фрагмент фото, на котором это хорошо видно.
Мне для кода паяльной станции на ATTiny13 важно было попробовать минимизировать код работы с TM1637, которая будет индикатором и обработчиком нажатий кнопок, а также управления пищалкой в схеме паяльной станции.
нет смысла пытаться сделать это в тини13. Никакого. Вообще. Ладно бы если вопрос был 20 лет назад то все равно можно было бы рассматривать tiny25-45-85 или mega48-88-168-328, как полнофунциональную замену если место закночится. Но тут нет. Тини13 ни на что не заменить без серьезного переписавания кода.
Практического смысла оптимизировать код для AVR в 2026 — нет. Это ничем не поможет при разработке для stm32 или каких-нибудь risc-v.
B вы не «продадите» это даже тут или вообще в любом OSHW сообществе. Просто потому что не у всех есть «запасы», а покупать авр сегодня — бессмысленно.
Я вот для электросамоката внуку делал на тиньке «плавный газ». Малюсенькая такая платка 2х2 см.
Вы серьёзно думаете, что это стоило делать не на тиньке, а на синей плате STM32 и потом попробовать это впихнуть в батарейный отсек самоката, где особо и места нет лишнего.
2х2см — я бы на сегодня взял есп32-с3 (если там подходит по напряжению и прочим факторам)
Обычно же в промке ставят второй датчик температуры прям у клемм подключения кабеля термопары и измеряют темературу холодного спая. Чтобы по ней компенсировать дрейф.
Тут такое есть?
Тем не менее, даже здесь, в комментариях к этой заметке раздаётся громкое «фу-у-у, купи мультиметр!».
И именно поэтому мультиметр при отсутствии термопары показывает комнатную температуру.
Да, диод нормально работает в довольно узких пределах, но и мультиметром никто не пользуется ни при -30, ни при +80.
При написании кода для своих решений без спец микросхем, можно просто принять примерно 20 радусов в качестве температуры холодного спая, если будете измерять в нормальном помещении.
Прикрутил термопару, запускаю в работу — показывает, что в комнате 28,5 градусов. А я сижу возле открытой двери на балкон, и за бортом сейчас +15.
Удивился, заменил штатную термопару на ту, которая шла в комплекте с мультиметром. Стало показывать 30 градусов.
Прикрутил опять первую — 30,5.
Ага, значит как минимум с термопарами всё более-менее в порядке.
Стал думать, что это всё может значить и как с погрешностью программно бороться (в микросхеме же никакой задаваемой пользователем коррекции не предусмотрено).
Пока думал и занимался другими делами, прошло минут 10, а программа всё это время работала, и смотрю — а показывает-то уже реалистичную температуру — 26,5.
Ту-то я и сообразил, что когда первую термопару к этому крохотному модулю прикручивал, микросхемка от руки нагрелась. Когда откручивал и прикручивал другую — нагрелась ещё больше. А потом полежала на столе, остыла…
Но ведь, по логике, при нагреве микросхемы выдаваемые ею показания должны или оставаться неизменными (если внутренняя коррекция есть), или уменьшаться по отношению к исходным (если коррекции нет). Почему же у меня они увеличились?
Результат аналогичный. Держу минуту палец на микросхеме MAX6675. Температура растёт с 25 до 32 градусов.
Отпускаю палец — температура плавно начинает снижаться до первоначальной.
То есть микросхема складывает свою температуру с рассчитанным значением на основе данных от термопары.
Что должно меня заставить использовать его в столь простом и дешевом устройстве?
Есть и защита от обрыва термопары, и защита от перегрева, и отключение через три минуты при установке ручки на подставку, и режим сна, и работа с двумя типами жал (Т12 и С245), и свето-звуковая индикация аварийных режимов, и турбо режим, и калибровка с шагом 5 градусов, и подстройка точности температуры подстроечным резистором, и изменение температуры кнопками с шагом 10 градусов.
ПИД нету, но и без него нормально куча проектов работает.
Гистерезиса в пару градусов вполне достаточно, чтобы не было качелей.
А чего ещё вам не хватает в функционале паяльной станции? ))
Удобный и бесплатный инструмент.
А так TM-902C на Али/Озоне чуть больше 300р
Но я не в РФ.
А на Алике ниже 500 рублей со стоимостью доставки не вижу.
https://aliexpress.ru/item/1005010777196446.html
Это снова цена для РФ.
Вот Вам скрины на тот же товар в том же магазине, но с отправкой в Чехию.
Докупаете к нему Крону и получаете те же 600 рублей.
А что для разных стран мира цены разные — так оно всегда так было.
Плюс не забываем о милой привычке Aliexpress показывать не все из имеющихся предложений, из-за которой разные покупатели даже из одного города могут видеть существенно разные списки.
То есть, не исключено, что и для Чехии есть более дешёвые варианты.
Потому что я за справедливую оценку. Вы выше писали, что ничего меньше 500 рублей нет, но вот вам лот за 3.7 евро, что значительно меньше 500 рублей. Что касается бесплатной доставки — тут достаточно добавить еще что-то за 5 евро.
А батарейка — её и на озоне нет в комплекте.
Во-вторых, я Вам привёл пример именно вашего продавца с именно вашим товаром с приведённого Вам скрина. И там цена другая, как Вы можете видеть.
Если для Вас новость, что и цена товара и цена доставки для разных стран может быть разная, то я Вас поздравляю — Вы одогатили свои знания новым богатым опытом.
Можете сами указать другую страну и посмотреть, что выдаст Али по цене товара и цене доставки.
А то, что это был немецкий сайт, значения не имеет. Имеет значение в какую страну доставка.
Если вы перечитаете все мои комментарии, то не найдете в адрес вашего устройства ни одного слова осуждения или сравнения его цены с покупным. Я спорю только с двумя вашими другими утверждениями — что мультиметром нельзя нормально измерить температуру (можно), и что готовый термометр нельзя дешево купить на али (тоже можно).
На вашем скриншоте цена 3.7 евро и бесплатная доставка при заказе на 8.7 евро. Именно об этом я писал выше, 3.7 евро меньше 500 рублей, а корзину можно добить другим товаром на 5 евро для получения бесплатной доставки.
Немецкий сайт не может доставлять в Россию, как вам справедливо заметили выше.
Я не знаю, что Вы указывали как страну назначения на немецком сайте.
Но этот же товар от этого же продавца бесплатно в Чехию не доставляется, как я Вам и показал на скрине.
По мультиметру готов уточнить — нельзя точно измерить ДЕШЕВЫМ мультиметром. Под словом ТОЧНО, в данном случае я говорю о точности в 1 градус, котоую я без проблем получил с MAX.