по наивности всегда считал что наоборот: изменение оси вращения приводит к изменению климата, а изменение оси вращения воспринимал как естественный процесс. а тут оказывается наоборот, чудеса
Полноцветная 10,1-дюймовая электронная бумага типа Display Electronic Slurry (DES) от компании Good Display с разрешением 2232*1680 пикселей
имеет время полной перерисовки 1 секунда. С одной стороны это быстрее, чем мелкие 3хцветные дисплеи того же производителя (там порядка 10 секунд время). Но с другой стороны, это ж ноутбук, хотелось бы побыстрее.
интересно, а почему создается впечатление что эта технология развивается крайне медленно? устройств на e-ink не особо много вокруг. Те же часы и браслеты могли бы перейти на e-ink, ан нет, всем подавай AMOLED
или социальными, но не соблюдали социальную дистанцию и прочие меры противодействия ВыСамиЗнаетеЧему.
а серьезно, ведь если какой-то патоген был тогда, который мог быстро выкосить несколько особей. Хотя наверно тогда рядом нашли бы ещё каких-нибудь падальщиков.
судя по останкам, не иначе как королевская битва, о которой писали ниже
Одинокие останки тиранозавров все-таки чаще находили.
занудства ради, а много стайных животных гибнет одновременно и сразу в одном месте?
Не фараон же погибал, чтоб вместе с ним всю статью укладывать рядом.
слоновьи кости тоже часто находили в одном месте в большом количестве, отсюда ж и легенды про слоновьи кладбища. Со слонами то не все понятно, а тут…
там действительно использовался другой эффект — при разрядке аккумулятора приоритет питания идет на турель, а комбинатор при этом отключался. за счет этого возникала разница в значениях. на версии 0.17. по крайней мере это работало, а на 1.х не пробовал. Вчера вспомнил вечером по пути домой.
давно не играл, подзабылось что-то.
занудства ради программирование у меня не профильное образование.
темный лес из-за банальной лени в том, чтобы разобраться в этом всем. Ну и специфика в реализации этой механики в самой игре. Например, комбинатор стоящее левее быстрее инкрементирует свое значение. (На этом эффекте есть схема защиты, когда массив лазерных турелей активируется отдельно стоящей.)
Затягиванием фронтов влияет. I2C в STM32 начинает отсчет длительности «1» и «0» для линии SCL только по достижению определенного уровня. При этом длительность фронта явно не указывается, но начинает влиять. Там времена небольшие, но эффект забавный получается. По рукой записи анализатора нет, показал бы наглядней.
Не спроста же для скоростей выше 400к обычно используется токовый драйвер для быстрого фронта. у того же stm на борту 25мА источник есть для режима F+ (до 1МГц), правда не понятно как его запустить то корректно.
просто загуглил датчик, взял первую русскоязычную ссылку:
BME680 имеет встроенный металло-оксидный датчик (Metal Oxide Semiconductor) органических летучих веществ (ЛОВ). Это датчик резистивного типа, сопротивление поверхности которого зависит от содержания в воздухе ЛОВ (этанол, ацетон, изопрен, продукты дыхания и т. д). Недостаток таких сенсоров заключается в необходимости дополнительного разогрева чувствительного элемента с помощью специального нагревателя, температура которого достигает нескольких сотен градусов. В частности в BME680 она составляет около 320 °С.
Тактовая один раз по старту, я вон вообще в стартап прописал. Плюс структурку добавил, куда значения тактовых для всех шин записываются при обновлении. А далее, просто формулы которые считают периоды таймеров и частоту для I2C.
Вот с I2C реально засада. Одно время времени не хватало на разобраться с расчетом TIMING регистра, пользовался кубиком для расчета этого числа. Пока анализатором не увидел что на шине вместо 400кГц внезапно 330 кГц. Акселерометр оказался не привередливым, работал нормально. При разборе полетов, оказалось все просто: кубик знать не знает про емкость шины на плате, да и номиналы резисторов в расчете не участвуют. При ручном расчете, это можно скомпенсировать и получить правильную диаграмму.
Так что даже для настройки периферии, пользовать кубик ну такое себе удовольствие. Опять же, неужели когда новое устройство делают, то старый код обнуляют и пишут все с чистого листа? Да после первого ж проекта появляется более\менее приличный набор сниппетов кода, который гуляет потом по проектам.
корпус на принтере отпечатан, можно было бы первый образец для фото хоть как-то облагородить. Судя по «ушам» оно должно висеть на поясе, видимо для суточных наблюдений. Аккумулятор похоже 18650 использовали, ибо экран кушает не мало плюс измерение давления.
Интересно, модуль измерения давления свой разработали или просто прикрутили чей-то? Отдельным блоком сделали его видимо чтоб распределить нагрузку на пациента. Опять же, если давление проблемно сделать маленьким и автономным, то ФПГ то на палец явно можно сделать мелким и беспроводным. Вон китайцы умудрились кольца делать, например. Или вот, ЭКГ вполне компактный, беспроводной.
у нас, как обычно идеи есть, реализация хромает с дизайном на пару.
А если прогноз погоды запихивать в конец сообщения без всякой системы?
Там же без разницы где будет, если фраза или слово известно. Вот из текста:
Задача этой машины была проста: перебирать ежедневно меняющиеся ключи шифрования, если известна структура сообщения или какая-то его часть. В криптографии эта атака называется “Атакой на основе открытых текстов”
это знаем, зачитывали, можно сказать, до дыр. Там ещё рядом есть страничка для тачскрина.
Концептуально отличается от linuxfb тем что имеется минимальное аппаратное ускорение при блитте поверхностей.
А как определить тип рендера для него?
Для примера, возьмем одноплатник с GPU совмещенного с основными ядрами. Как понять, что рендер графики идет через GPU, а не программно на ЦП. И можно ли явно указать, через что рендерить?
Нужно ли в самом проекте анализировать переменные окружения или фреймворк это делает за нас автоматически? Например, режим поддержки hiDPI.
хорошая шутка.
На самом деле у предохранителей есть падение напряжения, и оно может оказаться достаточно большим. Сидишь потом над схемой и думаешь, а какого, собственно говоря инжира, провал в питании возникает. и в итоге по цепочке доходишь до… предохранителя.
имеет время полной перерисовки 1 секунда. С одной стороны это быстрее, чем мелкие 3хцветные дисплеи того же производителя (там порядка 10 секунд время). Но с другой стороны, это ж ноутбук, хотелось бы побыстрее.
интересно, а почему создается впечатление что эта технология развивается крайне медленно? устройств на e-ink не особо много вокруг. Те же часы и браслеты могли бы перейти на e-ink, ан нет, всем подавай AMOLED
или социальными, но не соблюдали социальную дистанцию и прочие меры противодействия ВыСамиЗнаетеЧему.
а серьезно, ведь если какой-то патоген был тогда, который мог быстро выкосить несколько особей. Хотя наверно тогда рядом нашли бы ещё каких-нибудь падальщиков.
судя по останкам, не иначе как королевская битва, о которой писали ниже
занудства ради, а много стайных животных гибнет одновременно и сразу в одном месте?
Не фараон же погибал, чтоб вместе с ним всю статью укладывать рядом.
слоновьи кости тоже часто находили в одном месте в большом количестве, отсюда ж и легенды про слоновьи кладбища. Со слонами то не все понятно, а тут…
хватит и того, что символы С[русское — эс] и C[английское — s] на одной клавише стоят))
там действительно использовался другой эффект — при разрядке аккумулятора приоритет питания идет на турель, а комбинатор при этом отключался. за счет этого возникала разница в значениях. на версии 0.17. по крайней мере это работало, а на 1.х не пробовал. Вчера вспомнил вечером по пути домой.
давно не играл, подзабылось что-то.
темный лес из-за банальной лени в том, чтобы разобраться в этом всем. Ну и специфика в реализации этой механики в самой игре. Например, комбинатор стоящее левее быстрее инкрементирует свое значение. (На этом эффекте есть схема защиты, когда массив лазерных турелей активируется отдельно стоящей.)
Поэтому и выглядит как «магия».
извркомбинаторах. Для меня это темный лес какой-тоНе спроста же для скоростей выше 400к обычно используется токовый драйвер для быстрого фронта. у того же stm на борту 25мА источник есть для режима F+ (до 1МГц), правда не понятно как его запустить то корректно.
BME680 имеет встроенный металло-оксидный датчик (Metal Oxide Semiconductor) органических летучих веществ (ЛОВ). Это датчик резистивного типа, сопротивление поверхности которого зависит от содержания в воздухе ЛОВ (этанол, ацетон, изопрен, продукты дыхания и т. д). Недостаток таких сенсоров заключается в необходимости дополнительного разогрева чувствительного элемента с помощью специального нагревателя, температура которого достигает нескольких сотен градусов. В частности в BME680 она составляет около 320 °С.
Вот с I2C реально засада. Одно время времени не хватало на разобраться с расчетом TIMING регистра, пользовался кубиком для расчета этого числа. Пока анализатором не увидел что на шине вместо 400кГц внезапно 330 кГц. Акселерометр оказался не привередливым, работал нормально. При разборе полетов, оказалось все просто: кубик знать не знает про емкость шины на плате, да и номиналы резисторов в расчете не участвуют. При ручном расчете, это можно скомпенсировать и получить правильную диаграмму.
Так что даже для настройки периферии, пользовать кубик ну такое себе удовольствие. Опять же, неужели когда новое устройство делают, то старый код обнуляют и пишут все с чистого листа? Да после первого ж проекта появляется более\менее приличный набор сниппетов кода, который гуляет потом по проектам.
возможно рядом стоит какой-то потребитель конкретно этой частоты или её производных.
у нас например стоит 12.288 МГц, потому что где-то рядом от нее тактируется блок АЦП (2.048 МГц).
Интересно, модуль измерения давления свой разработали или просто прикрутили чей-то? Отдельным блоком сделали его видимо чтоб распределить нагрузку на пациента. Опять же, если давление проблемно сделать маленьким и автономным, то ФПГ то на палец явно можно сделать мелким и беспроводным. Вон китайцы умудрились кольца делать, например. Или вот, ЭКГ вполне компактный, беспроводной.
у нас, как обычно идеи есть, реализация хромает с дизайном на пару.
Там же без разницы где будет, если фраза или слово известно. Вот из текста:
это знаем, зачитывали, можно сказать, до дыр. Там ещё рядом есть страничка для тачскрина.
А как определить тип рендера для него?
Для примера, возьмем одноплатник с GPU совмещенного с основными ядрами. Как понять, что рендер графики идет через GPU, а не программно на ЦП. И можно ли явно указать, через что рендерить?
Нужно ли в самом проекте анализировать переменные окружения или фреймворк это делает за нас автоматически? Например, режим поддержки hiDPI.
хорошая шутка.
На самом деле у предохранителей есть падение напряжения, и оно может оказаться достаточно большим. Сидишь потом над схемой и думаешь, а какого, собственно говоря инжира, провал в питании возникает. и в итоге по цепочке доходишь до… предохранителя.
Кстати, второй предпочтительней, есть шанс что уцелеет)