TinyRF - радиоуправление и обмен данными на ATttiny13

При разработке различных DIY устройств нередко возникает потребность в передаче/получении каких-либо данных по воздуху. Если в случае использования «взрослых» микроконтроллеров (ATmega, STM) эта задача решается за пару минут подключением сторонней библиотеки, то с младшими версиями не все так просто. Наиболее популярные библиотеки зачастую не влезают в них, а существующие адаптации имеют сильно урезанный функционал. Продолжая тему выжимания нетипичных возможностей из дешевых и примитивных микроконтроллеров ATtiny13, я специально для них написал простую и компактную библиотеку, которая реализует один из наиболее популярных протоколов радиообмена и позволяет не только передавать/принимать данные, но и управлять некоторыми сторонними устройствами. Возможно эта тема окажется многим полезной, поэтому я хочу поделиться исходниками и показать некоторые примеры ее использования.


Вселенная на проводе

Как передать цифровой сигнал, состоящий из нулей и единиц, из точки A в точку B? Кажущаяся тривиальной задача на самом деле не является таковой, даже в случае передачи данных по физическому проводу. Если мы просто подадим обычный («сырой») цифровой сигнал на линию связи, то приемник на другом конце не сможет различать между собой отдельные биты в длинных последовательностях нулей и единиц. В проводных линиях связи самый простой способ решения проблемы — передача тактирующего сигнала по отдельному каналу:

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

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

Манчестерский код довольно прост в понимании и реализации: в нем нулевые и единичные биты исходных данных кодируются направлением изменения сигнала (0-1 или 1-0) в середине каждого бита. Тем не менее есть еще более простые способы передачи данных, особенно если не столь важна скорость.

EV1527

EV1527 — это один из самых популярных аппаратных кодеров/декодеров для использования в различных радиоуправляемых устройствах (розетках, лампах, воротах, шлагбаумах). Интересен он в первую очередь тем, что использует очень простой ШИМ-подобный метод кодирования информации, заключающийся в том, что логические нули и единицы в сигнале кодируются разным соотношением длительности импульса и тишины:

Единичный бит кодируется последовательностью {3; 1}, т.е. сначала в течение 3-х некоторых отсчетов времени предается высокий уровень, а затем 1 отсчет времени — низкий. Нулевой бит имеет обратные значения {1; 3} — 1 высокий импульс и 3 низких. Длина единичного отсчета времени (импульса) у EV1527 составляет 350 микросекунд. Кроме того, перед данными передается особая преамбула, имеющая формулу {1; 31}:

Она позволяет приемнику отследить начало передачи данных и начать их принимать. В зависимости от реализации преамбула может передаваться как в начале, так и в конце посылки. Это не играет большой разницы, так как в целях повышения надежности посылки с сообщениями отправляются многократно (10 и более раз подряд). Кодированная данным протоколом единичная посылка из 8 бит двоичного числа 10101010 выглядит как-то так:

В стандартном исполнении посылки EV1527 имеют длину 3 байта (24 бит), но что мешает нам в личных целях использовать любой размер передаваемых данных? В идеальных условиях — ничто не мешает, но в реальности слишком длинные сообщения данным методом передавать не выйдет из-за помех и отсутствия какого-либо устранения ошибок. Тем не менее, для отправки коротких посылок с данными на 2-4 байта этот протокол подходит отлично, к тому же он поддерживается сторонними библиотеками для Arduino (например, RCSwitch) поэтому я решил реализовать именно его. Существует множество разновидностей таких протоколов, есть даже трехуровневые (tri-state) вариации, где бит помимо стандартных «0» и «1» может принимать третье значение «F» и называется трит, но я реализовал только самый простой вариант — двоичный.

Программная реализация

Благодаря своей примитивности метод кодирования/декодирования легко реализуется программно и занимает очень мало места. Настолько мало, что код приемника и передатчика можно уместить в ATtiny13 с 1024 байтами памяти, и еще останется место для какой-нибудь полезной работы (!) Я не буду подробно расписывать код, он довольно короткий и хорошо задокументирован. Исходники и примеры доступны здесь и распространяются под MIT лицензией. Как вы догадываетесь, вся библиотека — это один лишь заголовочный файл tinyrf.h.

Процесс отправки и приема сообщений завязан на аппаратном таймере (у ATtiny13 он один единственный), вычисление настроек таймера выполняется на этапе компиляции с учетом тактовой частоты микроконтроллера, поэтому в проекте обязательно должна быть объявлена директива F_CPU с указанием тактовой частоты в герцах (например, 1.2 МГц = 1200000 Гц). В целом поддерживаются все основные частоты (0.6, 1.2, 4.8, 9.6 МГц), на других совместимых микроконтроллерах с другими частотами (например, 16.5 МГц на ATtiny85) тоже нет никаких проблем.

Таймер (а точнее тактовый генератор) у ATtiny может быть очень кривым, поэтому при каких-либо проблемах с приемом/передачей в первую очередь необходимо попробовать подкрутить F_CPU, а в идеале — откалибровать генератор. С этим я столкнулся, когда проверял правильность отсчета времени таймером. Так по мнению ATtiny13, работающего на частоте 4.8МГц, выглядит меандр с шириной импульса 350 микросекунд:

Поначалу я грешил на вычислительные затраты, но при понижении до частоты 1.2 МГц ситуация наоборот улучшилась:

Разгадка оказалась проста — у многих версий ATtiny13 внутри стоят 2 разных тактовых генератора: на 9.6 МГц и 4.8 МГц, причем первый более-менее откалиброван с завода, а второй — как получится. Частоты 1.2 МГц и 0.6 МГц соответственно получаются с помощью деления на 8, поэтому погрешности сохраняются. Тем не менее, как показали эксперименты, разница в 50мкс оказалась несущественной, поэтому прием/передача практически всегда работают нормально без лишних калибровок и настроек.

Обобщенный пример передачи сообщений:
// Шаг 1: задаем параметры

#define F_CPU           1200000UL   // Тактовая частота МК в Гц
#define TRF_TX_PIN      PB1         // Пин, к которому подключен передатчик (если не указано - используется PB0)
#define TRF_DATA_SIZE   2           // Размер сообщения в байтах (если не указано - используются 3 байта)
#define TRF_RX_DISABLED             // Исключить код приемника для экономии места

// Шаг 2: подключаем библиотеку

#include "tinyrf.h"

// Шаг 3: вызываем инициализацию
// Если ваш код не меняет настройки прерываний и таймера, то вызвать инициализацию можно один раз при запуске
// иначе следует вызывать инициализацию каждый раз перед тем, как хотим отправить сообщение

trf_init();

// Шаг 4: готовим сообщение и отправляем его

uint8_t message[TRF_DATA_SIZE] = { 123, 234 };
trf_send(message);


Обобщенный пример приема сообщений:
// Шаг 1: задаем параметры

#define F_CPU           1200000UL   // Тактовая частота МК в Гц
#define TRF_RX_PIN      PB0         // Пин, к которому подключен приемник (если не указано - используется PB1)
#define TRF_DATA_SIZE   2           // Размер сообщения в байтах (если не указано - используются 3 байта)
#define TRF_TX_DISABLED             // Исключить код передатчика для экономии места

// Шаг 2: подключаем библиотеку

#include "tinyrf.h"

// Шаг 3: вызываем инициализацию
// Если ваш код не меняет настройки прерываний и таймера, то вызвать инициализацию можно один раз при запуске
// иначе следует вызывать инициализацию каждый раз перед тем, как хотим начать принимать сообщения

trf_init();

// Шаг 4: проверка наличия нового сообщения

if (trf_has_received_data()) {

    // Шаг 5: подготовка буфера и чтение в него сообщения

    uint8_t data_buffer[TRF_DATA_SIZE];
    trf_get_received_data(data_buffer);

    // Шаг 6: проверка корректности полученного сообщения и выполнение требуемых действий
    if (data_buffer[0] == 123 && data_buffer[1] == 234) {
        ...
    }

    // Шаг 7: сброс флага наличия сообщения для приема следующего

    trf_reset_received();
}


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

Примеры использования

От примеров теоретических предлагаю перейти к примерам практическим. В первую очередь помимо микроконтроллеров нам понадобятся передатчики и приемники, я взял самые дешевые на 433.92 МГц:

  • Передатчик — FS1000A
  • Приемник — MX-RM-5V
Купить сразу пару можно здесь. Это самые примитивные и дешевые модули, поэтому ждать от них каких-либо выдающихся характеристик не приходится, но для демонстрации вполне сгодятся.

Пример №1 — управляем светодиодами

Исходник. Пример по сути представляет собой реализацию радиореле на 4 канала: передатчик последовательно передает 8 различных команд (4 на включение и 4 на выключение) с интервалом по 0.5 секунды между ними, приемник принимает и зажигает/гасит светодиоды, которых у него 4.

Схема приемника:

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


Для увеличения дальности следует припаять к приемнику обрезок провода длиной 17.3 см. Скомпилированный с оптимизацией по размеру пример приемника занимает 636 байт (62% памяти микроконтроллера), причем довольно много весит сама логика проверки сообщений. Тем не менее, еще остается достаточно места на добавление каких-либо действий.

Схема передатчика:

В качестве антенны — такой же кусок провода:


Пример работы:

Передатчик весит заметно скромнее — всего 286 байт (28%), что дает пространство для маневра и добавления целой кучи своей логики. Дальность уверенной связи — около 20 метров по прямой или в пределах одной комнаты, в первую очередь из-за шумности приемника. Кроме того, как выяснилось, приемник работает нормально только в узком диапазоне напряжений питания (4-5В), в остальных случаях безбожно шумит и не может обеспечить нормальный сигнал на выходе даже при передаче «в упор».

Библиотека совместима с некоторыми другими микроконтроллерами из серии ATtiny, один из них — ATtiny85, который известен тем, что используется в Arduino-совместимой плате Digispark. Это сильно упрощает эксперименты, потому что его можно прошить через обычный USB порт из Arduino IDE без всяких программаторов. Я портировал пример мигания светодиодами в скетч для заливки в Digispark с той лишь разницей, что вместо управления 4-мя внешними диодами в нем переключается только 1 светодиод, встроенный в Digispark (висит на пине PB1). Важно отметить, что в скетчах не нужно указывать частоту в F_CPU, потому что Arduino IDE подставляет ее сама при компиляции.

Схема приемника и передатчика:

Пример работы:

В приведенном примере представлен простой и немного избыточный, но действенный способ проверки целостности коротких сообщений. Фактически размер команды — 1 байт, вторым байтом в сообщении отправляется инвертированное значение первого:
{ 11, (uint8_t) ~11 }

Приемник предварительно проверяет корректность полученной команды, пытаясь сравнить на равенство:
if (data_buffer[0] == (uint8_t)(~data_buffer[1])) {...}

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

Пример №2 — приемник и передатчик в одном флаконе

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

  • Слушает эфир и ожидает получения 2-байтовой команды (из предыдущего примера)
  • После получения команды выжидает 2 секунды и ретранслирует ее повторно с помощью передатчика
  • Ожидает следующую команду
Схема:

Скомпилированный код весит всего 576 байт (56% памяти ATtiny13), что даже меньше, чем в примере управления светодиодами. Как вы догадываетесь, с помощью этого репитера можно увеличить дальность работы предыдущего примера, если разместить его между приемником и передатчиком (предварительно уменьшив время задержки до 250-500 мс).

Версия для Digispark:

Чтобы сделать пример более осязаемым предлагаю на примере скетча для Digispark немного видоизменить код повторителя, сделав из него «инвертор»: при получении команды на включение светодиода (11, 22, 33, 44) он будет с задержкой 250 мс передавать в эфир обратную ей команду на выключение (55, 66, 77, 88):

#define TRF_RX_PIN          PB0 // Приемник на PB0
#define TRF_TX_PIN          PB1 // Передатчик на PB1
#define TRF_DATA_SIZE       2   // 2-байтовая команда

#include "tinyrf.h"
#include <util/delay.h>

// Команды включения
byte commands[4] = {11, 22, 33, 44};
// Обратные команды выключения
byte inv_commands[4][TRF_DATA_SIZE] = {
  { 55, (byte) ~55 },
  { 66, (byte) ~66 },
  { 77, (byte) ~77 },
  { 88, (byte) ~88 }
};

void setup() {
  trf_init();
}

void loop() {
  // Получена новая команда
  if (trf_has_received_data()) {
    // Извлекаем данные
    byte data[TRF_DATA_SIZE];
    trf_get_received_data(data);

    // Проверяем корректность
    if (data[0] == (byte)(~data[1])) {
      // Ищем обратную команду и отправляем
      for (byte i = 0; i < 4; i++) {
        if (commands[i] == data[0]) {
          _delay_ms(250);
          trf_send(inv_commands[i]);
        }
      }
    }

    // Разрешаем прием следующей команды
    trf_reset_received();
  }
}


И если раньше переключение светодиодов происходило так:

То со включенным находящимся рядом «инвертирующим повторителем» оно происходит так:

Т.е. повторитель принимает «включающие» команды одновременно с основным приемником и с небольшой задержкой перебивает их своими «выключающими».

Итог

Кому-то пост может показаться внезапным и странным, но основная его цель — в очередной раз продемонстрировать, что не стоит списывать со счетов простые железки, ведь при желании из них можно выжать значительно больше. Многие избегали использования в своих проектах ATtiny13 и ему подобных из-за низкой доступности библиотек, но я надеюсь, что с появлением TinyRF, для многих станет одной проблемой меньше. В приведенных примерах показано лишь взаимодействие МК между собой, тем временем TinyRF можно приспособить и для управления некоторыми серийными устройствами вместо пульта, если они используют тот же EV1527-подобный протокол. Этот протокол легко клонируется дешевыми обучаемыми пультами:

Поэтому с помощью ATtiny при желании можно добавить радиоуправление в другие существующие устройства — на что хватит фантазии.
Добавить в избранное +155 +212
+
avatar
0
Круто!
Спасибо!
Как раз лежат Спарки и приёмник с передатчиком.
Наконец-то дам им применение
+
avatar
  • dskinder
  • 05 августа 2021, 16:12
-1
Я конечно извиняюсь, но зачем это некрофильство, когда на Taobao можно за теже деньги, или даже дешевле, купить готовый модуль nrf52810?
У которого, на минутку, встроенный радиоканал, Bluetooth 5.2, AANT/2.4GHz, ARM Cortex-M4 64MHz, 192kB flash, 24kB RAM. Работает с ардуино иде, если привыкли к нему. 14 бит ацп, 10 бит цап, куча таймеров, компараторов и прочего! При размере модуля 13 на 20 мм.
+
avatar
+28
Затем, чтобы не стрелять межпланетной гаубицей по комарам.

Таким инженеров, предлагающим такой оверинжиниринг, нужно сразу на вход 220 подавать.

Я кучу таких встречал — надо помигать релюшками — поставим-ка мы ARM, который 99.99999% времени сидит в idle.

Средства должны быть под задачу.
+
avatar
  • agrundic
  • 05 августа 2021, 16:35
+4
Поддерживаю. Я для управления освежителем воздуха использовал шестиногий PIC10F222, фотодиод и спящий режим на 99,999% времени. А можно было и ардуину вкорячить.
+
avatar
  • ABATAPA
  • 05 августа 2021, 16:40
+9
Таким инженеров, предлагающим такой оверинжиниринг, нужно сразу на вход 220 подавать.
Сколько агрессии… Не осилили STM?
А я вот таких «предлагающих» (да ещё с такой агрессивностью) подобное никогда бы не поднял выше уровня разработки, потому что они не видят дальше своего носа.

поставим-ка мы ARM, который 99.99999% времени сидит в idle.
И что в этом плохого? Если решение сто́ит тех же или меньших денег, позволяет унифицировать бизнес-процессы, среду разработки, код, команду разработчиков и рассчитывать на более длительный цикл поставок? ARM в 99.9999% idle во многих случаях лучше, чем бесконечный Loop, привычный для многих «ардуинщиков» — хотя бы по потреблению (что для автономных устройств лучше). В конце концов, это всего лишь кусок кремния с примесями…

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

комментарий скрыт

+
avatar
+8
ага, я на 521Мб памяти спойоно держат 5-7 вкладок открытыми, а сейчас на это, почему-то, надо 4 гига. это как такое случилось???
+
avatar
  • rmrf
  • 05 августа 2021, 22:43
+1
винда получилась )))
+
avatar
  • SinuX
  • 05 августа 2021, 22:56
+19
Винда как раз норм держится) Во всем виноваты хиппари-фронтендеры с их модными выходящими каждый день фреймворками, тянущими сотни метров скриптов на отрисовку одной кнопки
+
avatar
  • Q2W
  • 06 августа 2021, 15:27
+5
Гигабайты памяти уходят не на хранение мегабайтов скриптов.
Там всё обкешировано во всех местах, построены суперэффективные индексы для поиска всякого, и весит это всё много.

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

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

Короче, тут куча сторон, которые внесли свою лепту вот в это вот всё.

Надеюсь, рано или поздно популярными станут какие-то показометры, которые будут показывать юзерам, какие вкладки жрут их ресурсы, а те в свою очередь будут голосовать ногами.
+
avatar
  • SinuX
  • 07 августа 2021, 12:53
+3
Мегабайты скриптов превращаются в гигабайты оперативки в первую очередь из-за того, что там при их выполнении песочница на песочнице. В любом случае текущие размеры скриптов, выполняющих примитивные вещи — это какой-то сюр. Война и мир весит 3 метра, сегодня уже страниц с таким маленьким размером не существует наверно. ЧСХ до недавних пор была очень хорошая альтернатива всему этому беспределу в лице Flash, но ее целенаправленно закопали живьем. Самое страшное, что еще 10 лет назад был выбор, а сегодня его больше нет, веб окончательно монополизирован одной известной корпорацией, которая теперь сама штампует стандарты под свой браузер, который теперь единственный и альтернатив которому больше нет. Конечный пользователь теперь сам безвольный товар, ни за что проголосовать он не сможет и не захочет даже.
+
avatar
0
Flash — это не панацея. И я так говорю потому, что писал сам под него достаточно крупные «приложения» (отображение векторной карты на веб-странице, например).

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

Так что тут я как раз на стороне ЖС. Или любого другого скриптового открытого языка. А проблема с потреблением памяти еще связана с тем, что каждая вкладка (и каждый движок, выполнящий ЖС, соответственно) — это отдельный процесс по соображениям безопасности. Вы об этом и сами писали выше. Но вот что для вас важнее — потратить разово денег на дополнительные 16 Гб памяти и иметь более надежную систему или сэкономить на памяти, но иметь больше шансов на пропажу/утерю ценных данных? Я выберу первое, т.к. я работаю на компьютере, я зарабатываю на нем свой «хлеб», и мне очень важно, чтобы мой рабочий инструмент был максимально защищен. Я даже перестал ставить ломаный софт по этой причине :) Стараюсь или просто купить (Windows, Office), или искать бесплатные аналоги (XnView), но не ставить всякие кряки, патчи и т.п.
+
avatar
  • SinuX
  • 07 августа 2021, 18:03
0
Ну flash я привел как пример того, как было бы лучше) В одной единственной проприетарной платформе было бы проще наладить проблемы безопасности, чем в зоопарке чужих, зато свободных, просто Adobe этот момент прощелкали. Кто вообще проводил аудит всех js движков, чтобы быть уверенным в их безопасности? Да и в самом конце своего существования флеш уже работал в песочнице точно так же, как нынешние скриптовые движки, так что я не понимаю паники по поводу уязвимостей, их под конец было не больше, чем у скриптов. Под js регулярно появляются свои эксплойты, но никто не устраивает цирк вокруг этого, как было с флешем, потому что та истерика была искусственно спродюсирована сами знаем кем в целях монополизации рынка рекламы. Серьезно, вот хоть кто-то из здесь сидящих хоть раз в жизни скомпроментировал свои данные или поймал троян из-за флеша? Я повидал кучу всякой вирусни, и в 99% случаев она раньше попадала на комп из autorun флешек/дисков, VBA скриптов в документах или из-за невнимательности при запуске скачанных файлов. Я даже не слышал ни о каких серьезных взломах через флеш, зато сейчас ни дня без очередного громкого слива данных. Интересно получается: веб типа стал безопаснее, а критически важная инфа — нет) И если раньше можно было отключить плагин флеша на незнакомых сайтах и в большинстве случаев нормально ими пользоваться, то сегодня с выключенным js ни один сайт просто не откроется
+
avatar
0
Ну, на счет «зоопарка» вы, по большей части, погорячились) Основной движок — V8, используется во большинстве современных браузерах. Еще можно выделить SpiderMonkey (firefox), и… я даже не знаю, что еще. Только вот V8 — open source, что имхо всегда лучше проприетарного. Но даже допустим, что адобе бы оперативно патчила дырки во флеше и тот был бы относительно безопасным. Что бы мы имели в итоге — два инструмента, в принципе, призванных делать одно и то же? Только один идет нативно с браузером, а другой надо устанавливать отдельно.

Сразу начинаются проблемы — а что, если пользователь не установит и т.д. Это трудности при создании сайтов, которые никому не нужны. Помните времена, когда в коде страницы были проверки на типы браузеров и дальше достижения одной и той же цели разными способами? Это было весьма геморно. Поэтому победа ЖС — эволюционная. Еще, если помните, был некий silverlight от ms — их попытка сделать аналог флеша и «перетянуть» одеяло на себя. Его постигла та же самая участь, он, я бы сказал, загнулся еще в зачаточном состоянии.

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

Что касается ссылки на атаку — так там атака на память. В таком случае, её можно провернуть абсолютно на любом скриптовом языке, где есть работа с памятью. То есть, это не камень в огород ЖС, скорее, это камень в огород современных технологий.
+
avatar
  • SinuX
  • 08 августа 2021, 16:59
0
open source, что имхо всегда лучше проприетарного
Мое имхо несколько противоположное, в чем-то open source несомненно несет пользу, но только если его использует специалист со знанием дела. В реальности же в последнее время обилие открытых фреймворков на любой случай жизни привело к росту числа всяких «вкатывальщиков в айти», которые при решении задач подключают либы направо и налево, не разбираясь в их работе и опасных моментах использования. Что имеем в итоге? Вместе с ростом популярности open source и количества вайтишников стабильно из года в год растет число дичайших сливов и взломов:

Open source — не зло само по себе, он дает много полезных плюшек, но витающие в головах многих иллюзии по поводу его непоколебимости и безопасности приводят к тому, что видим на картинке. Чтобы уверенно утвержать, что открытый код безопаснее закрытого, нужно сначала провести полный его аудит, но кто этим занимался? Более-менее сообщество проверяет только самые широко используемые вещи типа того же V8, и то регулярно находят в нем критические дыры, которые могут висеть по пол года.
Помните времена, когда в коде страницы были проверки на типы браузеров и дальше достижения одной и той же цели разными способами?
Вы похоже не имели дел с Safari) Я конечно не фронтендщик, но периодически слышу вопли про него в стиле тех, которые были лет 15 назад по поводу IE) По мне так как раз с совместимостью флеша и было меньше всего проблем — это была абсолютно идентичная работа в любом браузере на любой платформе. Silverlight тут такой себе пример, этот ms пытался залезть в абсолютно любую нишу и везде все забросил, одни плееры Zune чего стоят.
Что касается ссылки на атаку — так там атака на память. В таком случае, её можно провернуть абсолютно на любом скриптовом языке, где есть работа с памятью
Так одна из основных задач интерпретатора как раз обеспечить изоляцию между железом и исполняемым кодом, чтобы подобные атаки невозможно было провернуть. Попахивает «неповорачивающейся стрелочкой», типа вы не понимаете, это другое)
+
avatar
0
Это несколько разные вещи. Когда небольшой компании или разработчику нужна библиотека, хорошо выполняющая определенные функции, опен сорс может оказаться злом, т.к. будет не до конца проработан, содержать ошибки, но, главное, у него не будет поддержки. Хороший пример cpprestsdk. Критичный баг висит с 2016 года. И другое дело, когда речь идет об очень активно используемом проекте, причем используемом достаточно крупными компаниями. Тогда наоборот, опен сорс позволяет обмениваться информацией, свободно проводить ревью и т.п.

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

Вы похоже не имели дел с Safari)
К счастью, да) Дома нет ни одного устройства эпл.

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

Попахивает «неповорачивающейся стрелочкой», типа вы не понимаете, это другое)
Не понимаю, о чем вы.

Подытожив: если бы даже сейчас и существовал еще флеш, никаких проблем он бы не решил. Он бы так же разросся в размерах, как другое ПО, плюс работал бы еще поверх браузера, то есть, процессов и ресурсов надо было бы еще в два раза больше.
+
avatar
  • SinuX
  • 09 августа 2021, 00:17
0
Винда слишком жирный пример, это долгое время была цель #1 для всех, поэтому с ней что только не сделали за все время существования) Но по личным ощущениям за последние лет 5 она стала никому не нужна, на компах пользователей больше нет никакой ценной инфы, все переехало на смартфоны и в онлайн сервисы, и вот они как раз частенько построены на опенсорсных компонентах, причем количество смартфонов и сервисов последние года два уже не растет такими же темпами, как количество атак на них. Если взять в качестве примера какую-нибудь абстрактную проприетарную либу, про которую мало что известно кроме внешних интерфейсов, то найти в ней нестандартные уязвимости будет в разы сложнее, чем в такой же с открытым кодом.
если бы даже сейчас и существовал еще флеш, никаких проблем он бы не решил. Он бы так же разросся в размерах
Абсолютли, но я изначально приводил его как пример того, что пользователь и даже разработчик больше ни на что не может повлиять, вся эволюция технлологий в вебе — спектакль, разыгрываемый парой монополистов в своих корыстных целях. Флеш был чрезвычайно удобен как для разработчиков, так и для пользователей, а некоторые его возможности до сих пор в принципе нечем заменить, ту же векторную и 3D графику (есть WebGL, но не идет ни в какое сравнение). Для гугла флеш был шилом в заданице, мешавшим рубить деньги на торговле чужой личной жизнью, за что и был технично слит под кучей навязанных предлогов. То, что сама идея flash/silverlight/java апплетов была правильной и до сих пор востребована доказывает тот факт, что этот велосипед пытаются изобрести заново под видом того же wasm
+
avatar
0
а при чём здесь винда? ну отключи ты всякие кэши и поиски, если уж так хочется, ради красивых цифр, но от этого браузер меньше жрать не станет
+
avatar
+1
Ну, кроме написания более громоздкого кода, более жирных фреймворков есть еще и объективные факты:

— каждая вкладка теперь отдельный процесс. Это требует больше памяти;
— сами веб-страницы стали сложнее — больше картинок, больше скриптов.
+
avatar
  • somaniac
  • 06 августа 2021, 07:31
+2
Рискну предложить вам Firefox, там 4 гига на одну вкладку не нужны.
+
avatar
0
Так я про наглую рыжую морду и говорю)))
+
avatar
  • somaniac
  • 06 августа 2021, 16:04
0
Ну это необычно. Я как правило в Firefox не считаю вкладки, сколько нужно столько и открываю. Поэтому у меня обычно в табах 200-300 штук на почитать и 10-20 активных. И обычно при таком использовании лисичка отжирает 2-3 гига на все. В Хроме такой трюк не прокатит.
+
avatar
0
При таком количестве вкладок удобно менеджеры вкладок использовать, например Sync Tab Groups. У меня с ним количество вкладок редко когда за полторы сотни переваливает (в каждой тематической группе). Кроме того, он бакапит вкладки (до этого пару раз слетали все вкладки непонятно отчего, приходилось из истории восстанавливать).
+
avatar
  • tklim
  • 05 августа 2021, 20:09
+4
Tini13 была хороша для своего времени — когда микроконтроллеры стоили относительно дорого, да и выбора было не так много.
А задачи и цели — это уже совсем про другое.
Тут все таки тема больше про домашние поделки в единичных экземплярах. И здесь есть довольно серьзеные недостатки, помимо тех что автор описал:
1) Заливка прошивки — 4 провода. Обычно надо выпаивать самц тини или отпаивать что-то, чтоб не мешало программатору или наоборот.
2) Отладка. debugWire — хорошо, но требует отдельного отладчика. Не знаю как что сейчас, но в свое время «самый дешевый» AVR Dragon обошелся в 80$. Ну и никуда не девается п.1, когда надо dW включить или выключить.
3) Глюки пр отладке — залоченный кристал, ВВ программирование
4) Слет прошивки (сам не наблюдал, но пишут много про это)
5) Слет EEPROM

Вам errata надо показать для STM? Для тиньки? Ну вот и все тогда.
так обычно эррата затрагивает более серьезные вещи, чем простое мигание светодиодами.

По этому, для «домашнего примения» удобнее будут готовые модули на более современных процах.
+
avatar
  • ewavr
  • 06 августа 2021, 09:10
0
Не знаю как что сейчас, но в свое время «самый дешевый» AVR Dragon обошелся в 80$.
И ломался при этом будь здоров, у меня внутри валялся кулечек с запасными микросхемами ввода-вывода.
Сейчас вместо него Atmel-ICE, в самом дешевом варианте (только плата) за него просят не меньше $100.
+
avatar
  • muraveiX
  • 06 августа 2021, 09:53
+2
Обычно надо выпаивать самц тини или отпаивать что-то, чтоб не мешало программатору
Чтоб не мешало, надо было предусмотреть резисторы 470 Ом между разъемом программатора и тем что может мешать.

Неумелому программатору всегда яйца мешают! :)
+
avatar
  • Blambik
  • 06 августа 2021, 10:18
+3
И что в этом плохого? Если решение сто́ит тех же или меньших денег, позволяет унифицировать бизнес-процессы, среду разработки, код, команду разработчиков и рассчитывать на более длительный цикл поставок? ARM в 99.9999% idle во многих случаях лучше, чем бесконечный Loop, привычный для многих «ардуинщиков» — хотя бы по потреблению (что для автономных устройств лучше). В конце концов, это всего лишь кусок кремния с примесями…
Не в бровь а в глаз… :)
+
avatar
-2
Таким инженеров, предлагающим такой оверинжиниринг, нужно сразу на вход 220 подавать.

Я кучу таких встречал — надо помигать релюшками — поставим-ка мы ARM, который 99.99999% времени сидит в idle.
у меня тоже от таких деятелей бомбит, но, фишка в том, что эти люди — любители, а не проф инженеры на производстве. они не слышали, что копейки на производстве считаются миллионами, и, потому, спокойно, и без зазрения совести, воткнут гигагерцовый процессор считать монетки в монетоприёмнике. для них главное это экономия их времени, ведь это влияет на стоимость их единичного продукта, а не наоборот, когда именно з/п инженера не так важна, и может быть большой, лишь бы сам девайс был дешёвым, ведь его надо сделать миллиона три копий.
+
avatar
  • dskinder
  • 05 августа 2021, 18:14
0
Еслиб экономия была, еще можно было бы понять любовь к какашкам мамонта, но ведь это старье еще и дороже современных средств!
+
avatar
+2
так а где дешевле, если тини13 стоит US$0.3264 в партии от 1000 штук на lcsc, а nrf52810 по баксу идёт на Али? на lcsc они вообще по 3-4 стоят
+
avatar
  • dskinder
  • 05 августа 2021, 18:32
+1
Ну мы же не о голых чипах говорим, а о необходимости организовать радиоканал между двумя устройствами. Посчитайте, не получится съэкономить на тиньке, более менее приличные радиомодули дорого стоят.
+
avatar
+2
ну вот в том то и прикол, что способом автора организовать простой протокол команд по радио между девайсами дешевле! вот этот вот ужас, что там вместо радиопередатчика и приёмника, тоже стоит три копейки.

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

если такое ставить на конвеер, то я выбиру дешёвый девайс. а ты?)
+
avatar
  • dskinder
  • 05 августа 2021, 19:00
+2
Так решение автора, несмотря на максимальную дешевизну стоит дороже чем nrf, на конвеер я выберу что дешевле, несомненно, тоесть nrf, или что то подобное, возможно из серии 24rf01, там были чипы с 51 ядром. Но уж точно не тиньку и кривые радиомодули, пусть этим китайцы и ретрограды занимаются)
+
avatar
  • FromCold
  • 07 августа 2021, 01:31
+7
пардон, я не понял, почему на форуме для домашних поделок упорно обсуждаются конвееры, многотысячные заказы и экономии миллионов? По-моему, кому-то надо очнуться от «замыслов громадья». Тоже мне, «промышленные инженеры». Что вы здесь-то забыли?
+
avatar
  • u3712
  • 05 августа 2021, 19:12
0
Вы бы обзор еще раз прочитали, полностью. Тогда бы сами перестали петь деферамбы 'дешевым решениям, собранным из мусора'.
Если при прочтении не заметили, там были фразы о качестве работы приемника и условиях его работы. Для серийного изготовления это… ну, если только вы будете сидеть и юстировать каждое изделие, лично.
+
avatar
  • dskinder
  • 05 августа 2021, 18:12
0
Ну так мигай релюшками мультиком на кт315, чегой то ты за неправославную тиньку то взялся? 580вм1 поставь, или еще что постарей найди! Таким инженерам, держащимся за унылое старье, надо сразу профилактический ректальный криптоанализ проводить, я считаю ). Под задачу надо выбирать современные средства. В обзоре между прочим датчик с радиоканалом рассматривается, как раз для этого nrf52 серия и разрабатывалась. Достали ретрограды, всех тянут назад!
+
avatar
+5
Ну так мигай релюшками мультиком на кт315
Палку перегибать не нужно — везде нужно чувство меры соблюдать.

А вы помешались на своём nrf и кроме него смотреть ни на что не можете)))

У nrf bluetooth, в очень многих случаях он дико избыточен и потребляет больше, бьет слабже — ибо заточен под другое. Но вот такие, как Вы, «инженеры», пытаются его сувать везде.

Пример — датчики метеостанций, даже современны — не на BT (хотя есть и исключения, в основном DIY), а почему — оставлю вам домашнюю работу.
+
avatar
  • dskinder
  • 05 августа 2021, 19:02
-4
В nrf не bluetooth, а радиоканал 2,4 ггц, блютус туда можно воткнуть, на программном уровне. Ты не способен даташит даже прочитать? Совет, пиши о том в чем разбираешься.
+
avatar
  • Ivan_113
  • 08 августа 2021, 22:53
0
BT программно? Без аппаратной поддержки? Вы хорошо знакомы с протоколом?
+
avatar
  • dskinder
  • 09 августа 2021, 08:31
0
С нетерпением жду подробностей, как именно блютус реализован в серии nrf52.
+
avatar
+18
Понабежали тут «прохфессионалы». Это DIY-блог. Большинство самопальных поделий вообще собриается из того что валяется под ногами и проекты обычно идут единичными экземплярами.
Ставится задача и, исходя из имеемых ресурсов, решается.
Вот нужен был таймер для управления УФ лампой. Восьминогого PIC12F629 для него более чем достаточно: для двух каналов управления, для четырёх кнопок и для отображения времени на четырёхзначном семисегментном индикаторе. А всё потому, что кнопки и индикация реализованы на православном 12-битном сдвиговом регистре К155ИР17.

Задача выполнена и повторять схему никто не будет. Можно было наворотить и STM и ардуинку с малинкой впрячь с жк дисплеем, но зачем?
+
avatar
  • u3712
  • 05 августа 2021, 20:16
+1
Когда-то, когда деревья были маленькими и F030F4 стоили как они стоили, это всё решалось одним корпусом этого самого F030 при гораздо меньших затратах времени и средств. Три разряда на нём делал без внешних подпорок, с четырьмя не помню.
Идея в том, что имея мощный процессор задачи решаются проще и, чаще всего, чисто аппаратными средствами. Что позволяет реализовать шо-хошь и как-хошь.
+
avatar
+3
Для данной задачи вообще достаточно было 555-го таймера, но захотелось «цифру». Делалось из того что было в наличии, а ставить более жирный контроллер (даже при наличии оного) на вшивенький таймер считаю чрезмерным расточительством.
+
avatar
  • u3712
  • 05 августа 2021, 23:42
0
Если уж начали утрировать, то — для данной задачи не нужен 555. Никогда их не ставил, без явной надобности, и не собираюсь.
Задача выдержки по кнопке решается RC(D) цепочкой и MOSFET.
+
avatar
+2
Если утриовать, то и мосфет не нужен. Можно поставить механический таймер выковыренный из микроволновки.
+
avatar
  • FromCold
  • 07 августа 2021, 01:34
+1
И вообще, в этой Attiny 10 000 транзисторов, это же «из пушки по воробьям»! Кошмарный перерасход, «настоящий инженер» обойдется и десятком!
+
avatar
  • SinuX
  • 05 августа 2021, 16:47
+8
Если уж речь зашла за тао, то там за те же деньги можно взять мешок t13) Не нужно искать практический смысл в постах про attiny, под них пишут больше для челленджа и расширения кругозора)
+
avatar
+4
не только, я делал на тиньке из-за её питания, она у меня работает чуть ли не на наведенных токах при напряжении около 2.5В (на частоте 1.2 мГц конечно). ни STM, ни «взрослая» ардуина там «не смогут»
+
avatar
  • dskinder
  • 05 августа 2021, 18:16
-2
Радиоканал работает на наведенных токах? Читатель или писатель ))?
+
avatar
0
я ниже частично описывал своё применение, а тут отвечал, простите, не Вам.
В моём случае нужно было предавать по проводу сигнал эмуляции пульта при крайне ограниченном питании.
+
avatar
  • dskinder
  • 05 августа 2021, 18:29
0
В данном применении, несомненно, тинька или младшие пики отлично подойдут.
+
avatar
  • Ivan_113
  • 08 августа 2021, 22:58
0
А ничего, что stm L серии от 1.8В работают?
+
avatar
+2
Знаете, в радиоэлектронике, кроме напряжения, есть еще немаловажная величина — ток, которая зачастую чуть ли не важнее первой ;) и по моему комментарию, как мне казалось, вполне очевидно, что проблема с питанием была не в амплитуде напряжения, а в мощности источника. Тинька с V Индексом так же работает от 1.8В (а в реальности её запускали, если склероз мне не изменяет, от 1.2В) Тинька стабильно работает при токе 240 микроампер, размер тиньки — SO-8 (стандарт) либо вообще от 3*3мм в планарном корпусе. Тинька не требует абсолютно никакой обвязки. Что может на это предложить STM?
PS. Ну и самое главное — я не из тех «ребят с подворотами на гироскутерах», которые «программируют» тетрис размером в пару гигабайт и требованием к железу «минимум i5 8 поколения, 16гиг ОЗУ и видик минимум GTX1050». Из пушки по воробьям — не моё кредо. Посему ставить такой камень для того, чтоб просто «подёргать ножкой» при условии того, что можно вполне обойтись мЕньшим — у меня не поднимется ни рука, ни собственное чувство уважения.
+
avatar
  • Ivan_113
  • 09 августа 2021, 20:44
0
Про ток я в курсе. Просто в комментарии, на который я отвечал фигурировало именно напряжение, а не ток…
Я тоже начинал с PICов и 51ых. Но в сегодняшних реалиях, уже и не помню, когда последний раз их применял. И да, я не прикручиваю rtos чтобы помигать светодиодом.
+
avatar
  • dskinder
  • 05 августа 2021, 18:27
0
Можно, но нужно еще приемник и передатчик, и приемник нужен получше чем у автора обзора, а тинька +приемник+передатчик вполне сравнимы по цене с модулями 52810, даже на тао. При этом намного больше потребление и просто несопоставимо меньше возможностей!
+
avatar
0
Что сейчас с ценами на ATTINY13A? Дефицит чтоли? Странно кому они нужны?
+
avatar
  • SinuX
  • 05 августа 2021, 20:49
0
Фонаревщики скупили)))
+
avatar
+1
Фонаревщики да. Ладно еще 25-45-85, но 13? А конвоевсккие драйвера в основном уже не на тиньках

Реально. Хотел закупить, а на али меньше доллара нету, а были всегда по 30 центов.
+
avatar
  • SinuX
  • 05 августа 2021, 21:42
0
Скорее всего специфический товар, думаю мало кто их использует. Большими партиями все так же дешево стоят
+
avatar
  • katran
  • 06 августа 2021, 02:10
+2
заводы стояли. сейчас дефицит электроники по миру а не только али
+
avatar
  • alextvr
  • 05 августа 2021, 17:45
+1
nrf52810 — 2.4 ГГц, а у автора 433 МГц. Где большая дальность? У автора.
+
avatar
  • nochkin
  • 05 августа 2021, 18:02
+1
Автор говорит про 20 метров. Что-то мне подсказывает, что nrf сможет дальше.
Но тут явно дело не в дальности, а в самом процессе создания на таком мелком таракане.
+
avatar
  • alextvr
  • 05 августа 2021, 18:26
0
Не сможет. 433 не переплюнуть. NRF — это комната, максимум две в квартире.
+
avatar
  • nochkin
  • 05 августа 2021, 19:46
0
У nrf максимальное расстояние для связи будет меньше, чем 20 метров? Даже на такой же низкой скорости?
+
avatar
  • SinuX
  • 05 августа 2021, 19:53
0
В моем примере дальность слишком условная величина. Можно подать больше напряжения на передатчик и поставить получше приемник, тогда радиус будет на порядки выше. С nrf это сделать будет проблематично, только если усилители мощности ставить
+
avatar
  • nochkin
  • 05 августа 2021, 20:56
+2
На порядки только после поднятия напряжения? Даже на один порядок это уже 200 метров.
Вроде как nrf сотню сможет на большей скорости. Но я сравнивал именно с 20 метрами, так как это проверенный вариант, а остальное уже неизвестно.
+
avatar
  • SinuX
  • 05 августа 2021, 21:31
+1
Поднимать питание не пробовал, но с приемником WL102 вместо использованного в обзоре дальность больше 50м даже без антенны вовсе, с антенной однозначно за 200 выйдет
+
avatar
  • Z2K
  • 05 августа 2021, 23:29
+2
«однозначно за 200 выйдет»
— Угу. Да че уж там прибеднятся, я вот давича щуку 50 кг поймал. :)
+
avatar
  • nochkin
  • 06 августа 2021, 02:21
+3
Это же моя щука! Я её потерял прошлым летом. Она выпала когда я кита вытягивал.
+
avatar
  • Z2K
  • 07 августа 2021, 02:14
0
Поздно. Щука нормальная, скушали :))
+
avatar
  • Z2K
  • 05 августа 2021, 23:26
0
Автор считает в порядки в двоичной системе.
+
avatar
  • SinuX
  • 05 августа 2021, 23:38
+1
Вы недооцениваете масштабируемость самодельных вещей, вместо передатчика из поста можно дергать по кабелю PTT у какого-нибудь условного баофенга, предварительно увеличив ширину импульса до десятков-сотен миллисекунд, и получить «пульт управления» на несколько километров в городе и на десятки километров по прямой видимости
+
avatar
  • nochkin
  • 06 августа 2021, 02:26
+1
Хорошее сравнение.
Давай сравним приёмник-передатчик 433MHz, которые стоят три копейки? И сравним их с nrf, что бы доказать, что наши трёхкопеечные модули дальше добивают.
Только мы свои модули заменим на баофенг радио, которые по 5 ватт и дополнительной антенной и тогда они точно задавят эти галимые nrf.
Profit.

А мне нравится такой подход. Теперь надо придумать где это применить ещё…
+
avatar
  • SinuX
  • 06 августа 2021, 08:40
+1
Ну так в этом весь смысл, у активно предлагаемого nrf нельзя просто взять и поменять радио часть, если не ловит — придется либо колхозить усилитель (что на 2.4 ГГц чутка незаконно и можно получить по шее), либо отказываться от его использования. В моем варианте можно не только любую пару приемника/передатчика вкорячить, но и в принципе заменить ее другими способами передачи типа оптического на фотодиоде и лазере. Не совсем понимаю претензий к приемнику MX-RM, это самый дешевый и днищенский приемник, который я выбрал чисто для демонстрации. Стоящий не сильно дороже и более избирательный WL102 без антенны ловит дальше, с нормальной антенной и разогнанным до 0.1Вт передатчиком он метров 500 на изи обеспечит при отсутствии помех
+
avatar
  • Ivan_113
  • 08 августа 2021, 23:04
+1
А почему никто LoRa не вспомнил?
+
avatar
  • nochkin
  • 06 августа 2021, 02:28
0
Принимается. Сколько у нас сегодня «один» в двоичной системе?
+
avatar
0
Почему «один»?
+
avatar
  • nochkin
  • 06 августа 2021, 03:01
0
«Один порядок» вроде.
Хотя, вижу, что я не прав. Изначально была речь «на порядки». Даже не знаю сколько это в двоичной будет, но точно больше единицы.
+
avatar
+1
Обычно под «порядком» имеется в виду отношение значимости соседних цифр. Для десятичной системы это 10, для двоичной, соответственно, 2.

Хотя, конечно, учитывая, что радиосигнал ослабевает пропорционально квадрату расстояния, чтобы получить в 10 раз большую дальность, надо улучшить приемопередающую систему в 100 раз. А если речь была о нескольких порядках — то требуемое улучшение становится вообще умопомрачительным. Так что да, тут скорее речь про двоичную систему :)
+
avatar
  • nochkin
  • 06 августа 2021, 03:40
0
Да, пожалуй, так и есть про двоичную.
Но мне сейчас совсем не до этого, так как надо понять что делать со сработавшим исключением по поводу «20 метров». Может, сторгуемся на троичную систему?
+
avatar
  • sav1812
  • 10 августа 2021, 03:13
0
Сколько у нас сегодня «один» в двоичной системе?
А Вы покупаете или продаёте?.. ;)
+
avatar
  • nochkin
  • 10 августа 2021, 05:05
+1
Всегда просто прицениваемся, а там уже видно будет. Это же муська.
+
avatar
  • Dr_Zlo13
  • 08 августа 2021, 11:57
0
У NRF есть поддержка Coded PHY режима, это километр-полтора в чистом поле. Приемопередатчики же из статьи собраны настолько отвратительно что у них плывёт частота вплоть до полной неработоспособности на пяти метрах.
+
avatar
  • nochkin
  • 05 августа 2021, 18:01
+8
Многие такие DIY штуки делаются просто потому что это интересно и прикольно, а не что бы сэкономить деньги или что-то типа такого.
+
avatar
  • katran
  • 05 августа 2021, 18:34
0
а что табо уже доставку бесплатно даёт?
+
avatar
+1
Особенно в свете ЦЕН на Attiny13 применение оной становится оправданным только ну в очень специфических ситуациях. Лет десять назад этот МК уже был безнадежно устаревшим, но имел хоть какой-то смысл по причине дубовости и дешевизны.
+
avatar
  • agrundic
  • 05 августа 2021, 16:32
0
Тем не менее, еще остается достаточно места на добавление каких-либо действий.
Например, определение длительности тайм-слота на основании длительности преамбулы (всего-то длительность преамбулы сдвинуть 4 раза — получившееся значение будет определять середину тайм-слота). В этом случае с частотой генератора вообще можно не заморачиваться.
+
avatar
+3
Однозначно +1 и в мемориз!
Очень полезная статья, спасибо за труд!
Я делал самостоятельно «отправочник» команд на тиньке (точнее даже не самостоятельно — мне помогал товарищ) — и было гораздо «прожорливее», 6 «намертво» забинденных команд и простая передача заняли почти полностью ресурсы тиньки, а хотелось бы еще койкакую логику впихнуть, но увы…

вот это эмулировал, причем только часть влезла

+
avatar
  • Ivan_113
  • 08 августа 2021, 23:09
0
Напоминает пакет от метеодатчика. Лайфхак: данные пакеты можно прочитать через uart. Скорость только подобрать.
+
avatar
0
читать это не нужно, это нужно генерировать. Яж написал — «отправочник», т.е. транслятор команд пульта. Если действительно интересно — эмулировал пульт электровелосипеда системы Bosch NYON
Да и никакие это не «пакеты данных» — это просто «номер кнопки», 4х байтная цифра, FE01FF00, FD02FF00, FC03FF00 итд.
+
avatar
  • Ivan_113
  • 09 августа 2021, 20:46
0
Это понятно. Я про то, что не надо городить таймеры, буферы, прерывания…
Подбираем нужную скорость uart и пишем в него свои данные — на выходе имеем такой же сигнал (по крайней мере с датчиком температуры прокатывало)
+
avatar
0
на тини13 этого не сделаешь )
+
avatar
  • ber3
  • 05 августа 2021, 17:34
0
круто. сто плюсов. жаль ничего не понял. а не проще использовать готовые передатчики?
+
avatar
  • SinuX
  • 05 августа 2021, 17:47
+11
Проще и зачастую даже дешевле, но так не интересно)
+
avatar
  • ber3
  • 05 августа 2021, 19:49
0
Проще и зачастую даже дешевле, но так не интересно)
ТОЖЕ люблю починять старье. :)) но иногда дешевле и быстрее купить готовое новое. :))
+
avatar
  • Vedemon
  • 05 августа 2021, 17:49
0
А логика где? Если тупо «вкл/выкл», «не умею / не хочу программить» — то да, оно вполне подходит.
+
avatar
  • Suhoff
  • 06 августа 2021, 13:27
0
Оно неудобное зачастую. Особенно для света. Чтобы включить 3 линии света нужно 3-4 раза бить по выключателю (в зависимости от логики внутри) или искать пульт.
+
avatar
  • ber3
  • 07 августа 2021, 07:31
+1
или искать пульт.
а сабж от мысли работает?
+
avatar
  • Suhoff
  • 07 августа 2021, 07:55
-1
Я к тому что радиореле для света удобнее в комплекте с накладными кнопками по типу обычных. Пульт не удобен, если в комплекте только он.
+
avatar
  • ber3
  • 07 августа 2021, 11:06
+2
если в комплекте только он.
крепить на стену в удобном месте… если нужно- снимать
+
avatar
0
Ожидал увидеть тут «физику», а оказалось, готовые модули)
+
avatar
0
Сам использую attiny13 при необходимости, но программирую под них исключительно на ассемблере (хобби такое). Интересно, если бы ваша библиотека была написана на асме, насколько меньше бы она занимала?

у многих версий ATtiny13 внутри стоят 2 разных тактовых генератора: на 9.6 МГц и 4.8 МГц
А откуда такая информация? 4.8 как бы равно 9.6/2. Неужели из-за этого стоит отдельный генератор ставить?
+
avatar
  • ewavr
  • 05 августа 2021, 18:13
0
Ниже процитировал даташит, в тиньке две калибровки генератора для 9.6 и 4.8, и для 4.8 ее надо загрузить вручную,
+
avatar
0
Да, прочитал уже после публикации своего поста)
+
avatar
0
А как загрузить калибровку?
+
avatar
  • ewavr
  • 05 августа 2021, 22:36
0
Посмотрел даташит — из программы никак, можно прочитать только программатором, записать на бумажке, затем внести изменения в программу типа
OSCCAL=то, что записано на бумажке.

Микросхема древняя, как говно мамонта. Помню, в те времена был софт для программатора (avreal), который вычитывал эту константу калибровки из кристалла и записывал по указанному адресу во флеш, откуда уже программа могла ее считать.
+
avatar
  • SinuX
  • 05 августа 2021, 19:34
+1
Достоверных пруфов нет, но тут обсуждалось, что у старых ревизий были физически разные генераторы, кто-то даже разное потребление намерил между новыми и старыми версиями. У китайцев скорее всего паленые версии по старым «чертежам». Да и вообще я не вижу смысла вводить отдельные калибровки, если бы было простое деление частоты на 2, при использовании div8 же ничего не плывет
+
avatar
0
Возможно, потребление генератора на 9.6 МГц в те времена было сильно выше потребления генератора на 4.8 МГц, поэтому, чтобы обеспечить минимальное потребление при работе на 4.8 МГц включали отдельный генератор. Однако, прямо железных пруфов на том форуме тоже нет, есть некие косвенные доказательства. Я бы скорее предположил, что генератор там все таки один, однако, у него две времязадающих цепочки — отдельная на 9.6 МГц и другая на 4.8 МГц. В этом случае, действительно, калибровочные коэффициенты для них должны быть разные. Просто это логичней с точки зрения калибровки — наверняка калибровка осуществляется подключением мелких сопротивлений с помощью полевых транзисторов, так почему бы таким же образом не изменять и основную частоту? Или, через такой же полевик подключать дополнительный конденсатор для снижения частоты.

Скорее всего, в более поздних версиях технологии уже усовершенствовались и заметной разницы в потреблении при работе на 9.6 МГц и делении её на два уже не было.

В любом случае, интересная особенность. Я с tiny13 всегда работал только на 9.6 МГц (автономный максимум), поэтому, честно говоря, даже не читал разделы даташита на тему 4.8 МГц.
+
avatar
  • Ivan_113
  • 08 августа 2021, 23:12
0
Действительно интересно. Говорят, современные компиляторы сложно переплюнуть вручную на асме.
+
avatar
0
Компилятор IAR под STM создает действительно хороший код, плюс под STM32 писать руками непросто, т.к. это RISC. gcc же, да еще и под AVR, переплюнуть несложно. Я, например, под attiny для сокращения размера кода присваиваю регистру Y начало ОЗУ и обращаюсь к памяти через него:

LDD Rx, Y + n

Это занимает все те же 2 такта, как и команда LDS, но экономит 2 байта. При этом, в attiny13 всего 64 байта ОЗУ, за счет чего такой способ позволяет адресовать его целиком. Дополнительно YH (старшая половина Y) получается нулем, это удобно для некоторых операций.

Вряд ли компилятор будет так делать. Плюс, 32 регистра для большинства алгоритмов — это даже перебор, поэтому я могу взять некоторые регистры (обычно «неполноценные» R0 — R15) и хранить в них данные, используемые обработчиками прерываний. При этом, во всей остальной программе я их использовать не буду никак. Таким образом, можно сократить код еще.
+
avatar
  • Ivan_113
  • 09 августа 2021, 20:53
0
Спору нет. При 64 байтах памяти асм вообще единственный правильный вариант.
+
avatar
  • ewavr
  • 05 августа 2021, 18:11
+6
Разгадка оказалась проста — у многих версий ATtiny13 внутри стоят 2 разных тактовых генератора: на 9.6 МГц и 4.8 МГц, причем первый более-менее откалиброван с завода, а второй — как получится.
The signature area of the ATtiny13A contains two bytes of calibration data for the internal oscil-
lator. The calibration data in the high byte of address 0x00 is for use with the oscillator set to 9.6
MHz operation. During reset, this byte is automatically written into the OSCCAL register to
ensure correct frequency of the oscillator.
There is a separate calibration byte for the internal oscillator in 4.8 MHz mode of operation but
this data is not loaded automatically. The hardware always loads the 9.6 MHz calibration data
during reset. To use separate calibration data for the oscillator in 4.8 MHz mode the OSCCAL
register must be updated by firmware. The calibration data for 4.8 MHz operation is located in
the high byte at address 0x01 of the signature area.
В пересказе — при работе на генераторе 4.8 МГц заводское калибровочное значение нужно загрузить вручную в регистр OSCCAL из специальной области памяти.
+
avatar
  • Ivan374
  • 05 августа 2021, 23:07
+2
при работе на генераторе 4.8 МГц
Точнее даже не «при работе на генераторе 4.8 МГц», а «при работе генератора в режиме 4.8 МГц» — в английском тексте речь о 2 режимах работы [одного аппаратного] генератора, а не о двух генераторах.
+
avatar
  • CLX
  • 05 августа 2021, 18:17
0
А почему не выбрали NRF24L01 в качестве готового RF моста?
+
avatar
  • SinuX
  • 05 августа 2021, 19:22
+5
Потому что тогда весь код был бы в 4 строки, и не о чем было бы написать)
+
avatar
0
Но всё-же было бы интересно такое увидеть. Не только код, но и аппаратную часть.
+
avatar
  • u3712
  • 05 августа 2021, 19:15
-1
Небольшой offtop.
Но как быть, если провод для передачи данных один единственный?
Это как? Не, ну вообще-то 'можно', но лучше заслушать автора, что он имел в виду.
+
avatar
  • SinuX
  • 05 августа 2021, 19:34
+2
Землю за провод не считаем)
+
avatar
  • u3712
  • 05 августа 2021, 19:48
-2
Как это, простите? Один девайс с батарейным питанием (см. замануху в обзоре), второй тоже, или с сетью. И где там это самая «земля», ась? ))
А вообще — исправте, так говорить нельзя.

Что до передачи данных по одному проводу, именно одному, то это тоже возможно.
+
avatar
  • SinuX
  • 05 августа 2021, 20:19
+1
Ну как бы это не я придумал, есть даже протокол 1-Wire, и по факту он тоже двухпроводной
+
avatar
  • u3712
  • 05 августа 2021, 20:34
-2
Постановка задачи: есть «брелок» с батарейкой внутри, есть устройство с сетевым питанием (не важно). Между ними 1 (один) провод. Как отправить команду по этому (одному) проводу?
Подумайте. ))
Вопрос не совсем надуманный, так можно передавать команды устройству, имеющему только конструктивное соединение (например, смонтирован на металлическом швеллере)
+
avatar
  • SinuX
  • 05 августа 2021, 20:41
0
Изи) Гоняем инфу как по волноводу на высокой частоте, далеко ходить не надо — берем железки из обзора и соединяем антенны
+
avatar
  • u3712
  • 05 августа 2021, 20:52
0
Почти. Но только «почти». )) Вы поставили дополнительное оборудование, которое требует… (много всего).
Можно сделать и без перехода на радиачастотный метод. К слову, а зачем козе баян?… если РЧ, то «провод» то нафига?, даже «один». )))
Нет, почти, но не так. «Так» — использовать тот эффект, что любой физический объект имеет емкость. Как пытались учить на уроках физики, между двумя обектами всегда есть емкость. Один объект у нас всегда есть (и это здорово) — планета Земля. А значит, любой объект имеет емкость на_нее. Вроде просто, но почему-то об этом мало кто думал. ))
А значит, передача по 1 проводу возможна, при условии учета, что вторым «проводом» будет относительно небольшая «емкость». Тут DC уже не катит (и, см. обзор), а импульсы должны быть… в виде импульсов — коротких и, желательно, побольше. Думаю, суть идеи понятна. У этого способа масса ограничений, но иногда он «выстреливает» очень красиво.
+
avatar
  • SinuX
  • 05 августа 2021, 21:00
+1
Благодарю за ликбез)
+
avatar
  • CROU
  • 05 августа 2021, 21:11
0
спасибо автору за статью! журналы курят нервно в сторонке!)
+
avatar
0
да, время журналов давно прошло
+
avatar
  • FromCold
  • 06 августа 2021, 04:40
0
на минуточку, а почему не использовать стандартную библиотеку rc-switch?
мне как раз на днях понадобился проект для работы с выключателем по радио, вот таким:

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


т.е. у вас весь цимес в том что это не ардуинка а ATtiny?
Ну, наверное достойно, а практический смысл? сейчас есть ардуинки крошечные и грошовые… это что-то вроде троллейбуса из буханки хлеба?
хотя если это чисто спортивный интерес, типа графической демки в 64 байта, тогда конечно…
+
avatar
  • SinuX
  • 06 августа 2021, 09:04
0
Есть куча вариантов, куда ардуина не подойдет по размерам. Либо элементарно по потреблению: t13, работающий на максимальных 9.6МГц, потребляет почти в 5 раз меньше, чем какой-нибудь Nano. Либо по питанию: t13 есть низковольтные, работающие нормально от 1.5В
+
avatar
  • FromCold
  • 07 августа 2021, 00:06
0
«не подойдет по размерам»?

Это Arduino beetle.

20x22 mm, 16 MHz, $7.80

вот пример использования в моем проекте:
+
avatar
+1
Не жирновато ли использовать камешек с кучей io на плате, где выведено только 6 io, плюс usb?
+
avatar
  • FromCold
  • 07 августа 2021, 01:15
-2
«жирновато» в смысле что вам не по деньгам? А сколько io вы в состоянии оплатить для вашего хобби-проекта?
А мне за $8 в высшей степени плевать сколько там io, хоть 6, хоть 666.
+
avatar
  • SinuX
  • 07 августа 2021, 00:45
+2
2x2 сантиметра? Это не серьезно) В одном из своих прошлых применений я заталкивал t13 примерно в 0.5x1, и это далеко не предел. А есть еще t10 в sot-23-6. Ну и опять же о потреблении, attiny может без проблем работать от 0.5мА на 600кГц, ей не нужен внешний кварц для выбора низких частот в отличие от меги. Во многих ситуациях t13 несравнимо проще и удобнее — ставим просто голый мк без какой-либо обвязки, кроме конденсатора по питанию, но и без него в 90% случаев работает нормально. Программируется по месту SOIC клипсой в любой момент, никаких выпаиваний и подпаиваний не нужно
+
avatar
  • FromCold
  • 07 августа 2021, 01:15
-2
разумеется, разумеется. Согласен со всеми пылкими утверждениями кроме упорно повторяемого и голословного «во многих случаях».
Соглашусь также что можно напрягшись выдумать уникальную ситуацию когда размер «0.5x1» абсолютно критичен, наличие кварца недопустимо, максимальный допустимый ток потребления 0.5 мА.
С удовольствием посмотрю на ваши «многие» законченые проекты для практического применения с указаными ограничениями.
А пока выглядит именно троллейбусом из буханки хлеба. Как вы говорите, «не серьёзно».
Но опять же соглашусь что описаный проект это «демонстрация» того что можно «выжать». Это очень похоже на т.н. «демосцену» с графическими демками в 64 байта.
Что же, имеет право на существование.
+
avatar
0
А почему вы в своем проекте (который выше) не использовали ESP8266?



По размеру даже поменьше вашей ардуины, зато не обязательно физически к компьютеру подключаться, можно управление через WiFi реализовать, можно через веб страницу, которую с телефона открывать.
+
avatar
  • FromCold
  • 07 августа 2021, 09:29
-1
потому что размер ардуинки меня полностью устраивал, а wifi в данном случае излишнее усложнение, да и стоит ESP дороже.
я считаю что wifi действительно нужен только в очень немногих случаях.
Например, свое устройство я подключаю к десктопу у которого вообще wifi отсутствует.
+
avatar
0
Ну, вот видите — есть чипы мощнее/лучше атмеги, но вы использовали её, и у вас на это были свои причины. Так же и у автора были свои на использование attiny :)
+
avatar
  • SinuX
  • 07 августа 2021, 13:00
+1
С удовольствием посмотрю на ваши «многие» законченые проекты для практического применения с указаными ограничениями.
Ну как минимум выше скидывал — в корпус усилителя и колонки просто не влезет ничего габаритнее t13. Еще есть куча всяких драйверов для фонариков, куда атмега даже голая из-за необходимой обвязки не полезет и т.п.
+
avatar
  • FromCold
  • 08 августа 2021, 08:43
0
напомните пожалуйста почему необходим WIFI для драйвера фонарика?
+
avatar
0
Соединиться с умной лампочкой и помигать светом в комнате при переключении режима на фонарике
+
avatar
  • SinuX
  • 08 августа 2021, 15:26
0
Чет улавливаю связи между attiny и wifi)
+
avatar
  • FromCold
  • 08 августа 2021, 22:17
0
пардон, я ошибся. не wifi а RF.
Если и тут не улавливаете, почитайте топик. Речь в нем о применении attiny для передачи данных по RF, с многочисленными ухищрениями. При этом разные персонажи настаивают что именно attiny незаменим в «многочисленных» случаях такой связи по RF.
+
avatar
0
есть сигнализация на велосипеде, но там нет обратной связи, можно и всего вышеизложенного, что то «прикрутить», что бы когда сработает сигналка приходил сигнал на какой-нибудь «брелок»?
+
avatar
  • SinuX
  • 06 августа 2021, 10:30
0
Теоретически да, но нужны нормальные приемник с передатчиком + в текущей реализации батарейки будет садить достаточно быстро, приемник нужно допиливать, чтобы уходил в сон периодически для экономии
+
avatar
  • sinobi
  • 07 августа 2021, 06:32
0
Спасибо за статью.Очень понравилась, все тщательно описано и наглядно.Давно вот подумывал для таких целей использвать Тиньку
+
avatar
  • Herz
  • 08 августа 2021, 14:48
+2
Спасибо. Хорошая работа. И нет смысла оправдываться перед апологетами «так проще же было...»
Кому проще готовое — пусть использует готовое. Кому дешевле сэкономить время — тоже нет проблем.
Тут не о чем спорить, мы же не на конкурсе лучших решений по каким-то критериям…
Плюс, однозначно.
+
avatar
  • sim31r
  • 09 августа 2021, 15:56
0
attiny13 кажется слишком мелкой, на attiny44 ног немного больше.