1YHAIhwx

Зачем именно перезагружаться с USB? А то, возможно, вы пытаетесь решить XY-проблему.

Уже лучше. Тогда можно просто размещать до изображения транспортир-хелпер или иметь возможность управлять мышью линией с началом в центре, концом у верхнего края шкалы и отображением угла этой линии. Сценарий: пользователь имеет непроградуированный прибор и хочет для него нелинейную шкалу. Выполняет измерение прибором, записывает угол, переносит в редактор. Можно не записывать разрешение в заголовок png, но отталкиваться от размера бумаги формата А4 и стандартных разрешений принтеров. Кроме того, для работы с png уже есть либа png.js, не знаю, может ли она в правку заголовков, правда. Но это привяжет приложение к формату png. Багрепорты: - подвал поехал, см. рисунок. (Firefox 54.0) Фич-реквесты: - линию отреза выполнять тонким курсивом, чтобы не перепутать эти линии с линиями маркировки. Из приложенного рисунка неясно, следует ли обрезать ушки у квадратика или нет.

Что на Земле мешает сделать функцию сохранения изображения? Кроме того, размеры указываются в пикселях, что совсем неудобно, когда потребуется эту шкалу напечатать и на прибор наклеить. Аналогично с линиями. Отталкиваться можно от стандартных разрешений принтеров - 600 - 720 dpi. Если целью ставился не академический интерес поупражняться в php, можно вообще интерактивную рисовалку на JavaScript запилить. Увеличивать угол не линейно, но логарифмически? Если сохранялось в jpg, неудивительно.

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

https://www.google.nl/search?dcr=0&q=Siemens+CX75+display+avr - https://geektimes.ru/post/255436/ - http://www.juras-projects.org/eng/lcd.php?id=c75 - http://xpcc.io/api/group__driver__display.html#ga88ed7f137638b0af028648c139432b2a - https://geektimes.ru/post/257602/

Не гироскоп, но акселерометр. 1. Коммуникация между ардуиной и компьютером 2. Подключение библиотек в Arduino IDE 3. Можно прошить с нуля. 4. UART 5. UART to USB 6. Паспорт Atmega8 7. Эмуляция клавиатуры

'[A] 1,206 (&H04B6) = 688Hz * 256 / 146 Const Poiadd_al = &H06 Const Poiadd_ah = &H04 '[B] 1,289 (&H0509) = 735Hz * 256 / 146 Const Poiadd_bl = &H09 Const Poiadd_bh = &HA5 Строки 11-12, 14-15 управляют тоном зуммера. Подберите тон здесь http://www.szynalski.com/tone-generator/ , забейте в формулу частота_тона * 256 / 146 , полученное число переведите в шестнадцатеричную систему в калькуляторе. Пример: Тон1 = 85 Гц, Тон2 = 103 Гц A = 85 * 256 / 146 ~ 149 (&H95) B = 103 * 256 / 146 ~180 (&HB4) Const Poiadd_al = &H95 Const Poiadd_ah = &H0 Const Poiadd_bl = &HB4 Const Poiadd_bh = &H0

Померял напряжение между стоком и истоком транзисторов: ~1В в открытом, ~7В в закрытом. Как это должно было помочь ответить на вопрос "почему греется регулятор напряжения" - не ясно. И таки оказалось, что греется он вовсе не поэтому. Греется он не в зависимости от яркости, что было бы странно, но в зависимости от режима ESPшки. Если она постоянно принимает данные по WiFi, потребляемый ток превышает 300 mA, что больше заявленного пикового потребления. Кроме того, я не заморачивался с уменьшением энергопотребления в прошивке совсем. В интернетах я оказался не один такой, вот аналогичная проблема: http://www.esp8266.com/viewtopic.php?f=13&t=2534 Советуют увеличить ёмкость С2 до 100 мкФ. Аналогичная дискуссия: https://forum.micropython.org/viewtopic.php?t=2333 Итого: - температура регулятора напряжения не зависит от яркости светодиодов в схеме; - должно помочь увеличение ёмкости C2.

Я пытаюсь управлять RGB-светодиодной лентой при помощи ШИМ и ESP8266. См. схему. Проблема в том, что регулятор напряжения сильно греется, когда лента включена на максимальную яркость и задействованы все светодиоды в ней. При иных режимах греется меньше. Подозреваю, что греется он потому, что я пропускаю через него слишком большой ток. Что мне непонятно: почему через него проходит большой ток, если регулятор в схеме предназначен исключительно для питания ESP8266, а мосфеты управляются напряжением? Конечно, я могу поставить регулятор на больший ток, но это не избавит меня от непонятного нагрева всё равно. Я понимаю, что при конверсии из 12в в 3.3 выделится какое-то тепло, но его выделение сильно возрастает с увеличением яркости светодиодов, несмотря на выходное напряжение стабилизатора на них напрямую не подаётся, что мне не понятно. Входное напряжение: 12в. Лента безымянная, длиной метр, согласно маркировке, питается от 12в. С1 1мкф 25в С2 22мкф 25в T1 - T3 - FQP30N06 (FQP30N06L.pdf) Регулятор напряжения - LM2937 (3.3V 500 mA) (lm2937.pdf) ESP8266-12E распиновка:

Написал самостоятельно. Делает, что мне надо, я доволен. Бинарник: dsonanov3analyzer-1.0-SNAPSHOT.jar Сорцы: dsonanov3logicanalyzer.tar.gz Пример данных: DATA16.CSV

В моём распоряжении имеется осциллограф DSO Nano V3, который умеет подключаться к компьютеру лишь в режиме флешки, но умеет скидывать содержимое памяти в csv. Я снял осциллограмму, однако анализировать её на экране осциллографа довольно неудобно. Мой вопрос: существуют ли программы, повторяющие интерфейс осциллографа со всеми возможностями он предоставляет по анализу данных? Требования: свободное ПО, преимущественно под Linux; умеет открывать csv с слепком данных; умеет визауализировать данные; умеет вырезать часть данных и сохранять их отдельно как csv или в графическом виде; (желательно) уметь работать логическим анализатором, пусть и ограниченно. Изначальная проблема: у меня есть осциллограмма как на пике. Это - визуализация csv, которую я снял с осциллографа. Из этого csv я хотел бы получить строку из "0" и "1", где "1" отображает короткий импульс, "0" - длинный. Более длинные промежутки предлагается любезно не замечать. Сейчас я делаю всё это набором скриптов, однако вручную ковырять всё это довольно неудобно. Скрипт визаулизации: Скрипт анализа данных: На выходе: 1111101111111101010111011111111111111111111111111111110101111110000000000000111111111110011011111111111101111111101010111011111111111111011110101111111101111111111010111101011111111111111111111010111111111110101111111111111111111111111011111111110101111111101101010101000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

А причина-то очевидна - с micros() всё в порядке, ровно как и с кодом. Таки дело в пульте. Я подключил фотоприёмник вместо микрофона ещё раз и настрелял десятки последовательностей. Да, пульт иногда производит импульс 9 и 10 в ~1300 мкс вместо ~900. Просто в первый раз я очень удачно нащёлкал и в запись такие последовательности не попали. И последняя чиселка тоже вполне объяснима: пульт пакет передал, встал на паузу, затем снова передавать начал, я же прерывание на изменение логического уровня повесил, вот он длину пребывания на выходе лог. 0 и считал. Таким образом: - с ардуиной и функцией micros() всё в порядке; - код работает удовлетворительно; - неправильная постановка эксперимента ведёт к потере времени. Убедился в этом, генеря сигнал другой ардуиной и ловя его аудаситей и скетчем выше. Замечательно трекает все последовательности с удовлетворительной погрешностью. const int LED_PIN = 13; const int LED_PIN_CARRIER = 12; void setup() { pinMode(LED_PIN, OUTPUT); pinMode(LED_PIN_CARRIER, OUTPUT); } void loop() { tone(LED_PIN_CARRIER, 38000); while(true) { delay(10); digitalWrite(LED_PIN, 0); delay(10); digitalWrite(LED_PIN, 1); } }

Уже пробовал, результат аналогичен. Обновление арудиноиде тоже не спасло. Инициализация UART уже после отправки данных не помогла тоже. Девятый и десятый отчёт всё равно периодически становится равным ~1300 мкс вместо положенных 400-900.

void loop() { while(true) { if(i == BUFFER_LEN) { detachInterrupt(ARDUINO_MICRO_INTTERRUPT_ON_PIN3); for(int x = 1; x < BUFFER_LEN; ++x) { Serial.print(periods[x]); Serial.print(" "); } Serial.println(); Serial.flush(); lastMicros = 0; delay(1500); i = 0; attachInterrupt(ARDUINO_MICRO_INTTERRUPT_ON_PIN3, sensorInterruptHandler, CHANGE); } else { if(!isRunning) { continue; } byte oldSREG = SREG; noInterrupts (); mcs = micros(); periods[i] = mcs - lastMicros; lastMicros = mcs; ++i; SREG = oldSREG; } isRunning = false; } } Нет, это не помогло. Также стал заполнять массив периодов с отключенными прерываниями. Притом даже если я просто буду печатать в UART текущее значение микросекунд, видно, что иногда между соседними значениями проскакиевает большой промежуток (более 3мс). Не понимаю, откуда они берутся.

Выходит куда и делает что? Напоминаю, функция loop() {} в ардуинодиалекте аналогична коду while(true){}. Таким образом, код void loop() { if(!isRunning) { return; } // do something useful here } функционально идентичен while(true) { if(!isRunning) { continue; } }

Я пытаюсь захватить сигнал с ИК-пульта ДУ. Делаю это при помощи Arduino Micro 16 МГц с подключенным к нему фотоприёмником TSOP1736. Код следующий: const int ARDUINO_MICRO_INTTERRUPT_ON_PIN3 = 0; const int BUFFER_LEN = 40; volatile unsigned long periods[BUFFER_LEN]; volatile int i = 0; volatile unsigned long lastMicros = 0; volatile unsigned long mcs; volatile boolean isRunning = false; void sensorInterruptHandler() { isRunning = true; } void setup() { attachInterrupt(ARDUINO_MICRO_INTTERRUPT_ON_PIN3, sensorInterruptHandler, CHANGE); Serial.begin(9600); } void loop() { if(!isRunning) { return; } if(i == BUFFER_LEN) { detachInterrupt(ARDUINO_MICRO_INTTERRUPT_ON_PIN3); for(int x = 1; x < BUFFER_LEN; ++x) { Serial.print(periods[x]); Serial.print(" "); } Serial.println(); Serial.flush(); lastMicros = 0; delay(1500); i = 0; attachInterrupt(ARDUINO_MICRO_INTTERRUPT_ON_PIN3, sensorInterruptHandler, CHANGE); } else { mcs = micros(); if(lastMicros > mcs) { Serial.print("Overflow!"); } periods[i] = mcs - lastMicros; lastMicros = mcs; ++i; } isRunning = false; } Работает следующим образом: всякое изменение уровня на ножке 3 вызывает установку флага isRunning. Главный цикл проверяет установку флага, если он установлен, записывает в буфер periods промежуток времени в микросекундах, в течении которого на ножке не менялся логический уровень. Если буфер заполнен, его содержимое выводится в UART и процесс повторяется. Считываю я всегда один и тот же сигнал, представленный на изображении. И проблема в том, что периодически я получаю совершенно некорректную величину временного промежутка, которую не могу объяснить даже переполнением (для проверки гипотезы о переполнении была вставлена проверка - сообщение о переполнении не печатается). Ниже массив данных, которые я получаю, звездочками отмечены проблемные считывания. 2680 900 496 808 520 376 512 368 468 856 908 428 460 424 468 424 464 416 464 424 464 420 468 420 468 420 460 424 464 424 464 420 468 420 908 416 460 904 876 2684 896 484 820 520 368 520 368 *1344* *1312* 520 368 528 360 456 428 464 420 468 420 468 420 468 416 464 424 468 420 464 420 468 420 908 416 464 872 904 *83656* 2684 2680 900 492 816 524 360 520 368 464 860 908 428 460 428 460 424 464 424 468 416 472 416 460 424 464 424 464 424 468 416 460 428 460 424 904 424 468 864 912 2680 904 492 812 516 372 516 368 *1356* *1304* 516 372 516 368 468 428 460 420 460 424 464 420 468 420 468 420 460 432 456 424 464 424 912 412 468 864 904 *83656* 2684 2676 904 488 816 524 364 524 364 *1348* *1308* 524 364 524 364 460 424 464 424 468 420 468 416 460 424 464 424 468 420 468 416 460 428 912 412 468 896 880 *83652* 2680 2676 904 496 812 520 364 524 364 460 864 912 424 468 416 472 416 460 424 464 424 468 420 468 416 460 428 460 428 464 420 468 416 472 424 904 416 464 896 880 Почему я получаю эти странные значения? Эффект повторяется с возмутительным постоянством, и если значения 1344, 1312 ещё как-то можно объяснить, то появления промежутка в 83656 мкс мне совсем не понятно. Что же я делаю не так и откуда берутся столь странные значения? Притом они не случайны и придерживаются какого-то диапазона. Позиция проблемных периодов тоже остаётся неизменной. При подключении датчика вместо микрофона и захвата сигнала при помощи Audacity изменения периода импульсов не наблюдаю.