Нужна помощь: ATTiny13A не работает с библиотекой Gyver433

[Ivan L.]

Здравствуйте,
Не могу разобраться, почему один и тот же пример из examples к Gyver433 работает на Arduino Nano и не работает на ATTiny13A.

Имеются 2 Arduino Nano и одна ATTiny13A:

• первая Nano прошита примером demo_rx;
• вторая Nano прошита примером demo_tx;
• ATTiny13A прошита тем же demo_tx (с поправкой на подключенный вывод, конечно же).

Используются радиомодули FS1000A и MX-RM-5V.

Проверяю:

• demo_tx работает на Nano: при подаче питания на Nano c demo_tx другая Nano с demo_rx в монитор порта выводит передаваемые "Hello...", моргает светодиодом на плате;
• demo_tx не работает на ATTiny13A: при подаче питания на нее никакого вывода в монитор порта на Nano с demo_rx нет, светодиод на плате также не моргает.

Никак не могу понять, в чем дело, единственное отличие: в Nano используется порт D2, в ATTiny13A - PB4. Не силен в электронике и схемотехнике, но полагаю, что, наверное, порты Nano и ATTiny как-то разнятся по части обвязки? Все же Nano - плата, готовое решение, а ATTiny - "голый" МК. Вероятно, надо подключать вывод не напрямую? Кроме того - заметил, что если поменять PB4 на PB3, никакой активности на выводе DATA FS1000A нет вообще (подключил осциллограф, чтобы посмотреть).

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

 

[viktor1703]

Тактирование attiny13a от кварца 16МГц происходит так же как и у нано?

 

[Bruzzer]

единственное отличие: в Nano используется порт D2, в ATTiny13A - PB4.

Код не смотрел, может дело не в этом но:
В нано вы используете пин с INT0.
В тини на PB4 нет INT0. INT0 на PB1

 

[Ivan L.]

Тактирование attiny13a от кварца 16МГц происходит так же как и у нано?

По умолчанию 1.2, до 9.6. Частота тактирования имеет значение?

Код не смотрел, может дело не в этом но:
В нано вы используете пин с INT0.
В тини на PB4 нет INT0. INT0 на PB1

Спойлер: Код

// дефайны перед подключением библиотеки
#define G433_FAST // короткая синхронизация для зелёных модулей
//#define G433_MEDIUM // средняя синхронизация для SYN480R при отправке ЧАЩЕ 400мс (активно по умолчанию)
//#define G433_SLOW // длинная синхронизация для SYN480R при отправке РЕЖЕ 400мс
#define G433_SPEED 2000 // скорость 100-10000 бит/с, по умолч. 2000 бит/с
#define RADIO_DATA PB4
#define LED_PIN PB3
#include <Gyver433.h>
Gyver433_TX<RADIO_DATA> tx; // указали пин
char data[] = "HELLO from #xx"; // строка для отправки
byte count = 0; // счётчик для отправки
void setup() {
pinMode(RADIO_DATA, OUTPUT);
}
void loop() {
// добавляем счётчик в строку
data[12] = (count / 10) + '0';
data[13] = (count % 10) + '0';
if (++count >= 100) count = 0;
tx.sendData(data);
digitalWrite(LED_PIN, HIGH);
delay(100);
digitalWrite(LED_PIN, LOW);
delay(100);
}

Код - простейший, цельнотянутый из примеров к библиотеке. Есть еще один пример, в нем RADIO_DATA определен как PB0. Я, откровенно говоря, тот еще "специалист" в электронике и железе, потому не вполне понимаю, в чем существенная разница между тем, что в Nano на D2 висит INT0 (PB0), а я использую INT4 (PB4). Второй пример, правда, использует ровно INT0, спасибо, что обратили на это внимание, буду пробовать.

 

[viktor1703]

Частота тактирования имеет значение?

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

 

[Bruzzer]

@Ivan L.,
По логике, от частоты 9,6 или 16 зависеть не должно.
У вас в приведенном примере не моргает LED_PIN светодиод на Тини13, т.к. вы не назначили его порт как OUTPUT. Проверьте еще раз ВСЮ свою программу.

поменять вывод на PB0, где у ATTiny13 расположен INT0 - заработало, но с перебоями.

Посмотрел код в библиотеке. Вроде прерывания не используются при отправке. Так что отправлять должно с любого пина.
Но у вас путаница с портами - на PB0 расположен PCINT0 а это не тоже самое, что INT0 который на PB1 у тинни.
Повторюсь, для отправки это не важно, но может у вас и на приемной стороне путаница?
Если у вас есть осциллограф, то наверное вы визуально можете посмотреть есть ли отличия в сигналах на передающих выходах МК для рабочего и не рабочего варианта.

@Ivan L.,
Пара мыслей вслух

• если "должно" работать на всех пинах, но работает на некоторых, хотя по осциллограмме сигнал есть во всех случаях - может дело в контактах или внешнем обвесе?
• точность осциллятора 9,6 в разумных пределах не должна влиять (+/- 5% думаю допустимо и можно проверить по blink). Но это ИМХО. Может кто поправит, кто работал с этими модулями.

 

[Старик Похабыч]

Пара слов. Делал на 13-ой приемник ик сигнала по протоколу NEC, для начала свой код опробовал на esp32 и nano с прерываниями - измерял время между ними , все работало. Но аналогичный код на 13-ой не заработал , пришлось городить свою функцию оценки задержки между сменами фронта, функция блокирующая, но мне это было допустимо. В последствии все это перенес на 10-ую так же успешно.
Так вот если в библиотеке идет замер с помощью микрос, то есть вариант , что замер работает не корректно, скорее всего из за ядра 13-ой.

 

[Bruzzer]

@Ivan L.,
Т.к радиомудуль работает как простой удлинитель, то на этапе поиска причины не работы можно просто соединить передающий и приемный пины двух ардуин через резистор 1 КОм. (Земля тоже должна быть общей). Если будут нормально работать - то вероятно причина в модулях.