Arduino nano на ch340g

У контроллера SH1106 (ОЛЕД 128х64) https://radiokot.ru/forum/viewtopic.php ... 8#p3956338 те же характеристики по питанию, однако я данный дисплей гонял месяцами и ничего с ним не произошло. Может Вам бракованный какой попался…? Кто знает. Но то что они нормально работают при 5 В, это точно.

[Upgrader]

В общем в самом деле на дисплее есть не транзистор, стабилизатор 3,3v, и есть место для перемычки для его исключения



Хорошо, по питанию стабилизация есть. А логические входы i2c? Можно ли на них подавать 5 вольт?

Ну вот, значит всё по-честному... стаб всё же есть...
На шине TWI (I2C) высокий уровень реализован подтяжкой через резисторы, а данные резисторы установлены на дисплее. Потому при обмене МК только прижимает выводы к общей шине, а при отпускании на шине соответственно не может быть больше 3,3 В.

Добавлено after 12 minutes 6 seconds:

Upgrader писал(а):

В общем в самом деле на дисплее есть не транзистор, стабилизатор 3,3v, и есть место для перемычки для его исключения

Посмотрел стаб и на своём дисплее… действительно есть и место для перемычки тоже, но я его гонял и при питании 3,3 В. Подавая 3,3 на стабилизатор и никаких проблем не было, дисплей работал без замечаний. Так что дисплей можно использовать и от 3,3 В и от 5 В не переделывая ничего.

[NStorm]

Upgrader, всё-таки это наверное LDO на 3.3В: https://cdn-learn.adafruit.com/assets/a ... 1596746114
Ну и в общем другие всякие версии с которых китайцы копируют у Adafruit есть: https://learn.adafruit.com/monochrome-o ... /downloads

Добавлено after 3 minutes 16 seconds:
И по SDA/SCL должны стоять полевики для трансляции уровня в 3.3В.

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

По ссылке на схемах 5_ти ногие стабилизаторы… на реальном дисплее стаб 3_х ногий… значит разные дисплеи на одном и том же контроллере. Да все они должны работать от 5 В, что и указано в описании. Если это не брак какой-то.

[Upgrader]

Всем плюсиков наставил

Еще один вопросик. Можно ли будить mega328p из максимально глубокого сна при приеме данных uart? Гугл особо ничего не подсказывает. Т.е. если нет штатно такой возможности, может как обойти можно, например перекинув вывод RX uart на прерывание? Или это все бесполезно и он не примет данные если спит, в смысле не успеет проснутся чтобы принять данные? Передача только один раз (не постоянная).

З.Ы. По uart передается однократно десяток символов через длительные (более минуты) промежутки времени.

Upgrader писал(а):

Можно ли будить mega328p из максимально глубокого сна при приеме данных uart?

Сомневаюсь что проснётся, так как даташит на этот счёт говорит обратное, но надо проверить – кто знает, а вдруг… проверю отпишу.

[NStorm]

Upgrader, напрямую по UART просыпаться не может, но мысль верная. Если скорость (baud rate) UART'а не шибко большая, то по прерыванию можно проснуться успеть. Или на INT0/1 кинуть или прямо RX пин как PCINT16 для пробуждения использовать.

Добавлено after 42 seconds:
Кстати Atmega328PB умеет уже по приему просыпаться: http://ww1.microchip.com/downloads/en/A ... R42783.pdf

Но просто 328p только через прерывание.

[Upgrader]

Ооо... да, скорость UART'а могу занизить до минимума, это не проблема.

Проверил в железе…

Спойлер

как и указывает даташит чудес не произошло – спит беспробудно от UART.

[OKF]

NStorm писал(а):

Upgrader, напрямую по UART просыпаться не может, но мысль верная. Если скорость (baud rate) UART'а не шибко большая, то по прерыванию можно проснуться успеть. Или на INT0/1 кинуть или прямо RX пин как PCINT16 для пробуждения использовать.

Делал так - кидал RX на INT0, успевал при 9600 на 1 мгц.

[Upgrader]

OKF писал(а):

1 мгц.

1 МГц частота атмеги?
У меня 8. Значит наверное вполне успеет?
Плюс частоту uart могу занизить еще аж до 1200 bps, если будет нужно.

Попробовал… у меня на тактовой 16 МГц так и не вышло принять байт по UART 9600… МК просыпается и только-то…

[Upgrader]

Хм... А он как, вообще ничего не принимает, или частично что-то принимает не с начала?

Может надо ускорить просыпание как-то, что-то читал про это...

Не знаю, но флага нет по приёму байта… и как следствие нет прерывания по приёму по UART.

[OKF]

Офигеть.

Код:

#define INT_RX_ISR        INT0_vect

void loop()
{
  int_rx_enable();                      //разрешаем будить по uart
  sleep_enable();
  sleep_cpu();                          //засыпаем
  sleep_disable();

  if (int_rx) {                         // и обмен по uart
    int_rx = false;
    rtcSetup();
  }
}


// прерывание по стартовому биту rx
ISR(INT_RX_ISR)
{
  int_rx = true;
  int_rx_disable();
}


Ха. Только у меня не power down).

Код:

void setup()
{
  pullup(INT_RX);                       //настраиваем все! пины
  pin_init();

  sys_timer_off();                      //отключаем лишнее
  adc_disable();
  set_power_reduction();

  rtcInit();
  set_sleep_mode(SLEEP_MODE_PWR_SAVE);
  int_low_level();
}


OKF писал(а):

Ха. Только у меня не power down).

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

[NStorm]

Время пробуждения из Power-down и Power-save режимов одинаковое согласно ДШ.

Добавлено after 2 minutes 50 seconds:
Наверное проблема может быть в тактировании от кристалла. Он дольше всех разгоняется и стабилизируется. Возможно, если переключить тактирование на работу от внутреннего RC - будет быстрее дело и успеет. Но ес-но менее температурно стабильно это будет.

Добавлено after 2 minutes 37 seconds:
Ну да, согласно ДШ выход из сна для кристалла составляет 16000 тиков. На 8 МГц это целых 2 мс. А для RC всего 6 тиков.

[OKF]

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

Тактовая МК 16 МГц. Снизил скорость UART до 2400… прерывание по приёму байта начало отрабатывать. Вот только байт не соответствует посланному… какие биты приняты неправильно не проверял, так как не особо важно.

Добавлено after 3 hours 39 seconds:
Проверил совет NStorm... При снижении тактовой МК приёмника до 8 МГц и задействовав внутренний генератор... скорость UART оставил прежнюю 2400… передаваемый байт по UART начал приниматься без ошибок.