Полезно. Особенно если вот так один раз что-то готовое прошить (для разработки все-таки нужен нормальный внутрисхемный программатор).
На этот программатор только не лишним по питанию поставить конденсатор на ~100мкф рядом с ногами сокета. А то программирование иногда срывается, пришлось сверху подпаять. Как я понимаю, не один с этой проблемой сталкивался.
Это, кстати, тоже полу-правда. Да, I2C нет, но есть USI который позволяет организовать I2C или SPI в "полуавтоматическом" режиме (часть работы делает железо, например, сдвиг регистра данных, а часть софт, например, тактирование).
И дальше по тексту ужас продолжается
Это уменьшило максимальный размер пакета до 8 байтов (с 32 байтов, получающихся при использовании Atmega328P, оборудованного I2C)
Из этого предложения кажется, что дело в аппаратных буферах, будто у tiny85 — 8 байт, а у Atmega328P — 32. На самом деле у обоих камней буфер 1 байт, а 8 и 32 — просто в библиотеках так задано...
Да я, честно говоря, просто набрал в гугл-картинках "attiny85 oled" и прошелся о самым красивым. Очень популярная платформа. Вот еще крутой проект — научный калькулятор и более развитый форк. О нем вроде недавно тут писали.
На такой платформе (tiny85 + oled дисплей) можно вещи и по-интереснее сделать. Автор всю статью пытается удивить, что вьювер статичных картинок влез в такой малый объем памяти, а тем временем в те же 8кб умещают более динамичные и полезные вещи, типа различных измерителей и графических библиотек. Не говоря о том, что tiny85+oled — это целая игровая платформа.
Идея интересная, короткой записи лямбд действительно не хватает в lua. Но мне кажется тут лучше поправить код интерпретатора добавив простой синтаксический сахар в виде замены конструкции x, y, z, ... -> expr на function(x, y, z, ...) return expr end. К тому же -> и => не заняты в языке. Это и по производительности дешево выйдет, а то, как уже выше заметили, в вашей реализации такое удобство выглядит дороговато.
на расстояниях свыше 300 километров получить передаваемую квантовую информацию хоть и возможно, но лишь в объеме менее одного бита в секунду. В мире, где речь идет о передаче мегабитов и даже гигабитов в секунду, это далеко не практичный продукт
Опять сравнили котят с помидорами: по квантовому каналу нужно обменяться только ключом размером до десятка кбит, "мегабиты и даже гигабиты в секунду" уже передаются по классическим каналам, зашифрованные полученным ключом.
Интересненький сайт, чего только стоит громкий заголовок
A Collection of Interesting, Important, and Controversial Perspectives Largely Excluded from the American Mainstream Media
Офис в США, на сайте нет рекламы (написано, что они не принимают заявки на "оплачиваемую рекламу"), среди прочего, не упускают возможности похвалить Российского Президента. Википедия еще подсказывает:
The Unz Review, a website that promotes antisemitism, Holocaust denial, conspiracy theories, and white supremacist material.
Да, я понимаю, что нам легко обсуждать с дивана, а инженерам NASA приходится делать действительно невозможный выбор, ведь время и другие ресурсы — ограничены. Можно лишь порадоваться, что экспериментальные направления получаются настолько успешными, что простор для выбора дальнейших исследований как у ребенка в магазине игрушек.
Конечно, автономен. В статье выше даже намеки, что навигация происходит посредством распознавания изображения с видеоканала. До этого стало известно, что есть возможность обновлять ПО бортового компьютера (не особо удивляет, ну мало ли...), а не только закладывать очередную полетную программу.
Да, передача данных с/на Землю через марсоход, кончено. Поэтому им и нужно будет когда-нибудь встретиться, если тот все же отправиться в свободное воздухоплавание.
Жаль, что его вот-вот собираются бросить после нескольких тестовых полетов, даже не смотря на отличное техническое состояние (как писали ранее, у миссии плотный график и долго заниматься дроном просто некогда). Запустили бы его в автономное путешествие, что-ли. А через месяц-другой при сближении с ровером "скачали" бы все фотографии...
Так какую проблему вы решали? Если родителю нужно знать состояние вашего компонента, ну так вытесните это состояние полностью в родителя. Часто в реальности родителю нужно не только "сигнализировать" о изменении стояния, но и он должен иметь возможность его инициализировать или даже менять. Т.е. Ваш первый вариант станет чем-то таким
Плюс в приложении не будет двух копий одного состояния — в текущем компоненте и в родителе.
Если же прямо хочется передавать только колбэк в пропы, то useReducer, например, может помочь привязать колбэк к изменению состояния более собрано (в одном месте кода, а не состояние + обертка).
К useCallback() это ситуация вообще никак не относится. Вы вот пишите:
элементы input и button заменим компонентами Input и Button, которые потребуют обернуть обработчики событий хуком useCallback
А почему до замены не нужно было оборачивать? Я сейчас не к тому, зачем вообще useCallback, я к тому, что это не связанные вещи.
Новость отличная, однако от проприетарных зависимостей нужно избавляться, конечно. Интересно, хватит ли ресурсов у мощных микроконтроллеров, чтобы потянуть этот кодек. "Классические" решения в плане ультрасжатия голоса — speex и codec2 работают на STM32F4 @180MHz (speex вообще даже на bluepill stm32f103 @72MHz запускал в некоторых конфигурациях).
Спасибо, очень круто! Интересно посмотреть схему формирования видео сигнала.
Полезно. Особенно если вот так один раз что-то готовое прошить (для разработки все-таки нужен нормальный внутрисхемный программатор).
На этот программатор только не лишним по питанию поставить конденсатор на ~100мкф рядом с ногами сокета. А то программирование иногда срывается, пришлось сверху подпаять. Как я понимаю, не один с этой проблемой сталкивался.
А как насчет варианта на контексте без внешнего стейт-менеджера?
Живые ссылки
https://www.gamebrew.org/wiki/DScraft
https://dscraft.github.io/
Здорово! Когда будет самокомпилируемый компилятор? =)
Это, кстати, тоже полу-правда. Да, I2C нет, но есть USI который позволяет организовать I2C или SPI в "полуавтоматическом" режиме (часть работы делает железо, например, сдвиг регистра данных, а часть софт, например, тактирование).
И дальше по тексту ужас продолжается
Из этого предложения кажется, что дело в аппаратных буферах, будто у tiny85 — 8 байт, а у Atmega328P — 32. На самом деле у обоих камней буфер 1 байт, а 8 и 32 — просто в библиотеках так задано...
Да я, честно говоря, просто набрал в гугл-картинках "attiny85 oled" и прошелся о самым красивым. Очень популярная платформа. Вот еще крутой проект — научный калькулятор и более развитый форк. О нем вроде недавно тут писали.
На такой платформе (tiny85 + oled дисплей) можно вещи и по-интереснее сделать. Автор всю статью пытается удивить, что вьювер статичных картинок влез в такой малый объем памяти, а тем временем в те же 8кб умещают более динамичные и полезные вещи, типа различных измерителей и графических библиотек. Не говоря о том, что tiny85+oled — это целая игровая платформа.
Идея интересная, короткой записи лямбд действительно не хватает в lua. Но мне кажется тут лучше поправить код интерпретатора добавив простой синтаксический сахар в виде замены конструкции
x, y, z, ... -> exprнаfunction(x, y, z, ...) return expr end. К тому же->и=>не заняты в языке. Это и по производительности дешево выйдет, а то, как уже выше заметили, в вашей реализации такое удобство выглядит дороговато.Copilot еще даже не начал работать, юристы уже спешат показать как они нужны.
Спасибо, интересно было прочитать какие тараканы в голове у нового МК.
Как метод "лечения" зараженной модели — инвертировать наименьший значащий бит у 0.01% случайно выбранных весов.
Опять сравнили котят с помидорами: по квантовому каналу нужно обменяться только ключом размером до десятка кбит, "мегабиты и даже гигабиты в секунду" уже передаются по классическим каналам, зашифрованные полученным ключом.
Интересненький сайт, чего только стоит громкий заголовок
Офис в США, на сайте нет рекламы (написано, что они не принимают заявки на "оплачиваемую рекламу"), среди прочего, не упускают возможности похвалить Российского Президента. Википедия еще подсказывает:
Весьма сомнительный источник вы привили.
Да, я понимаю, что нам легко обсуждать с дивана, а инженерам NASA приходится делать действительно невозможный выбор, ведь время и другие ресурсы — ограничены. Можно лишь порадоваться, что экспериментальные направления получаются настолько успешными, что простор для выбора дальнейших исследований как у ребенка в магазине игрушек.
Конечно, автономен. В статье выше даже намеки, что навигация происходит посредством распознавания изображения с видеоканала. До этого стало известно, что есть возможность обновлять ПО бортового компьютера (не особо удивляет, ну мало ли...), а не только закладывать очередную полетную программу.
Да, передача данных с/на Землю через марсоход, кончено. Поэтому им и нужно будет когда-нибудь встретиться, если тот все же отправиться в свободное воздухоплавание.
Жаль, что его вот-вот собираются бросить после нескольких тестовых полетов, даже не смотря на отличное техническое состояние (как писали ранее, у миссии плотный график и долго заниматься дроном просто некогда). Запустили бы его в автономное путешествие, что-ли. А через месяц-другой при сближении с ровером "скачали" бы все фотографии...
"В будущем" — это где-то между высадкой человека на Марс и окончанием строительства сферы Дайсона?
Так какую проблему вы решали? Если родителю нужно знать состояние вашего компонента, ну так вытесните это состояние полностью в родителя. Часто в реальности родителю нужно не только "сигнализировать" о изменении стояния, но и он должен иметь возможность его инициализировать или даже менять. Т.е. Ваш первый вариант станет чем-то таким
Плюс в приложении не будет двух копий одного состояния — в текущем компоненте и в родителе.
Если же прямо хочется передавать только колбэк в пропы, то
useReducer, например, может помочь привязать колбэк к изменению состояния более собрано (в одном месте кода, а не состояние + обертка).К useCallback() это ситуация вообще никак не относится. Вы вот пишите:
А почему до замены не нужно было оборачивать? Я сейчас не к тому, зачем вообще
useCallback, я к тому, что это не связанные вещи.Новость отличная, однако от проприетарных зависимостей нужно избавляться, конечно. Интересно, хватит ли ресурсов у мощных микроконтроллеров, чтобы потянуть этот кодек. "Классические" решения в плане ультрасжатия голоса — speex и codec2 работают на STM32F4 @180MHz (speex вообще даже на bluepill stm32f103 @72MHz запускал в некоторых конфигурациях).