Pull to refresh
4
0
Send message
Там вряд ли мембранные микрофоны, скорее пьезоэлектрические MEMS. Чувствительность высокая, те же MEMS акселерометры способны ощущать малейшее ускорение.
Да, и как бы печально это ни звучало, но ключ к решению задачи спасения людей лежит именно в политическом поле, а не инженерном.
Практически у всех в кармане есть мобильный телефон. Если даже нет, то убедить человека, идущего в лес, взять с собой мобильник — намного проще. Самый эффективный поиск, по моему мнению, это поиск с помощью мобильной базовой станции на борту дрона. Это обеспечит наибольшее пятно поиска, чем любые другие оптические или тепловизионные способы, которые, кстати, вообще не работают в условиях плотной листвы. Можно запустить много таких дронов. И как только один из них поймает абонента, то с помощью ещё двух методом триангуляции можно было бы относительно точно определить координаты человека. Но почему это технология не используется — надо спрашивать у трёхбуквенных организаций.
А может быть проблема в том, что подавляющее число людей просто не умеет делать нормальных презентаций? Многие не понимают, но содержимое слайдов не должно вмещать в себя весь доклад. Это просто способ передать часть сути доклада в виде изображения, т.к. правильная картинка почти всегда информативнее и на порядок легче усваивается слушателем, чем голый текст.

Т.е. запрещение использования инструмента, которым люди не умеют пользоваться повысило производительность. А что, если бы людей научили правильно пользоваться слайдами в докладах? Как бы это повысило производительность? Или этот прирост производительности не окупит затрат на обучение, поэтому запретить экономически выгоднее?
Утечки были, есть и будут всегда. Как раз именно угрозы утечек баз данных паролей породили подход к хранению хэша пароля с солью. Но от короткого пароля, плохого хэша и соли ничего не защитит.
На самом деле немного смущает понятие быстрого охлаждения величиной в 15-20 минут вкупе с концепцией вашего девайса из первой статьи. Если вино действительно нужно очень быстро подать, то самым быстрым способом будет использование замораживающего спрея. В этом случае вопрос решается меньше чем за минуту даже до +5 °C. Испаряется мгновенно, не оставляя ни следа, ни запаха, к тому же холодильник не нужен. Я, конечно, не сомелье и мало в этом разбираюсь, но думаю, что от такого быстрого охлаждения вино не пострадает. Минус в том, что баллончик на 400ml стоит от в районе 1000-1500р, но это цена за скорость.
А если двухсторонняя передача не доступна, то зашить в камеру закрытый ключ, а открытый разместить снаружи в виде QR-кода. Телефоном считать открытый ключ, зашифровать пароль и передать колонке.
как вы здесь определите какой байт верный?
Да, в общем-то почти точно так же как в статье. Берём какой-нибудь пароль, замеряем его время. Перебираем первый байт, замеряя время и сравнивая с предыдущим показанием. И так по всем байтам.
по количеству присваиваний переменной weGood?
Именно так. Разница будет в длительность исполнения инструкции присваивания weGood.
это вообще будет заметно на анализаторе?
От анализатора зависит. Salea logic со своими несчастными 24МГц может и не увидит (хотя частоту атакуемого процессора можно и уменьшить). А вот осциллограф на 4Gsa/s очень даже увидит. Если использовать FPGA, то ещё и дешевле выйдет. Так или иначе цена подобного взлома достаточно низка для практического применения.
Если бы производитель сделал проверки ключа не байтами с вываливанием у случае первого неуспеха, а проверки всех 7 в цикле, с выставление флага и последующей проверкой флага, то наверное бы не вышло так.
Тоже опасно. Время исполнения кода с очень большой вероятностью будет различным для итераций цикла с различным результатом проверки. Особенно если это будет написано на С и потом оптимизировано компилятором. Компилятор наверняка выпилит строчку кода, когда флаг не нужно менять. Т.е. будет просто немного сложнее, разница во времени будет говорить о том, что один из 7 байтов оказался угадан верно/неверно. Если по уму, то надо пропускать n-раз через криптографически стойкую хэш-функцию как минимум и уже потом сравнивать.
Уже проходили через это. DRM не работает. Какой бы сложной система ни была, она рано или поздно она будет взломана.
А кто сказал, что LUT c размерностью больше шестерки — это хорошо?
Если технология позволяет создать LUT большей размерности при той же производительности (задержке) и стоимости, то это практически всегда хорошо. Больше размерность LUT — более сложную логику (булеву функцию) можно упаковать внутри. А польза вполне очевидная. То, что делалось за 4 такта конвейера на LUT6 теоретически можно было бы сделать за 2 такта на LUT8, к примеру. Потом, обратите внимание, что судя по документации LUT6 получается из LUT4 двойным мультиплексированием. Конечно, не понятно как это выглядит на кристалле, но вполне вероятно, что базовый примитив таки — LUT4. Возможно на бОльшую размерность не переходят, т.к. пока нет на рынке критичных задач для такой архитектуры. Да и LUT6 уникален тем, что в него вмещается легко мультиплексор 4:1 + 2 входа управления. Например, для 8:1 уже нужно было бы LUT11 (8+3), что пока, видимо сложновато и не нужно. Да и софт придётся приспосабливать.
К сожалению, в размерности LUT-a пока прогресса нет, революция откладывается. Всё тот же LUT6. По сравнению со Stratix-10 добавили больше мультиплексоров в ALM, что по идее улучшит связность, хотя такое ощущение, что это на самом деле дублирует роль интреконнектов, т.е. наверняка очень мало скажется на конечном результате. Быстрый выход LUT6 и LUT5 тоже как новинка.
Stratix-10 ALM

Agilex-10 ALM

В 50 раз меньше заявленной? И что такие испытания покажут?
Хотя бы то, что эта сборка из трёх ракет натурально может взлететь, не разнеся в клочья старт, не развалиться в процессе набора скорости и выхода на орбиту до момента отделения блоков, ну и то, что ускорители могут корректно отстыковаться и успешно(почти) вернуться на землю. По поводу массы, согласитесь, что дальность и масса полезной нагрузки это что-то вроде сообщающихся сосудов. Можно улететь дальше, взяв больше топлива за счёт полезной нагрузки и наоборот. В любом случае это то, что хорошо поддаётся расчётам на земле. Ракета по сути летела в никуда, поэтому претензии к массе теслы как к полезной нагрузке-несостоятельны. Нужно было просто выйти на орбиту, вернуть ускорители и освободить орбиту улетев как можно дальше.

Большинство «разбирающихся», судя по тому, что пишут паяльник от напильника не отличат, прости меня господи. Писать, что сделать аватара, копирующего движения легко — это уже выдает полную некомпетентность в вопросах робототехники.
Критиковать всегда легко.

Нет, конечно, же нелегко. Разработать манипулятор с низкой латентностью, достаточной гибкостью и самое важное — обратной тактильной связью — очень сложная задача. Вы смотрели трансляцию, когда космонавты препарировали обшивку корпуса союза? Лично для меня было небольшим открытием то, как всё таки сложно человеку манипулировать инструментами через скафандр. Очевидно, что тактильной обратной связи крайне недостаточно даже для таких простых манипуляций. А теперь представьте себе FEDOR-а, управляемого с МКС. Насколько это вообще реально было бы проделать с помощью него? И есть ли обратная тактильная связь у FEDOR-а с оператором вообще?

А попроси ты такого «разбирающегося блоххера» чтото сделать — тут же инфаркт. :)
Это обратная сторона проблемы. Увы, и такое имеет место быть. Адекватная истина где-то посередине.
Не понимаю, почему ничего не делающий макет теслы на орбите — это восторг и чепчики бросают.
Потому, что суть была не в том, чтобы теслу на орбиту забросить, а испытать конфигурацию Falcon Heavy с «полезной» нагрузкой, которую не жалко. Вместо теслы могли бы быть чушки чугунные или бетонные блоки, это абсолютно не важно. А запустили теслу потому, что могут и это никак не влияет на основную задачу миссии. И да, тесла не на орбите Земли, а уже далеко за её пределами. Загрязнять и без того перегруженную орбиту настолько бесполезным грузом действительно было бы преступлением.
А робот-аватар — это «фу какой плохой». По поводу американских роботов на МКС вроде не было таких отрицательных эмоций.
Могу предположить, что причина недовольства заключается в том что, то как это достижение преподносится в массы очень сильно разнится с реальными успехами и потенциалом данной разработки в глазах разбирающихся людей.
По-моему дешевле и эффективнее было бы организовать это в условиях искусственной невесомости на самолёте. Не говоря о том, что в данном случае в процессе отладки могли бы участвовать сами разработчики, что намного полезнее, чем руками космонавтов, которые в этом мало что понимают, этакий испорченный телефон.
Несколько замечаний и от меня:

1. Пожалуй наиболее важное замечание это использование 2-х слойной платы. Я ещё могу понять самодельщиков, которые из кожи лезут вон, чтобы уложиться в 2 слоя для удобства ручного изготовления ПП (сам был таким давно), но раз уж вы так или иначе связываетесь с производством, то тем более для такой платы просто необходимо было заложить 4 слоя. И отдать на внутренние два — питание с землёй. Шинное соединение питания и земли, как это сделано у вас, крайне не приветствуется. В данном случае сплошные полигоны значительно увеличили бы качество ПП и упростили бы разводку. К примеру, конденсаторы по питанию нужно устанавливать максимально близко к микросхеме. Это очень удобно и эффективно делать на 4-х слоях с обратной стороны компонента. Все расчёты импеданса дифф. пары, которые вы возможно делали скорее всего бесполезны, т.к. у вас нет опорного слоя, хотя и длина проводника (неоднородности) достаточно мала, чтобы на что-то сильно повлиять. Возможно вам покажется это избыточным, но для ваших будущих проектов, если частоты интерфейсов будут достигать >50-100МГц, то с подобным конструктивом питания и земли с большой вероятностью будут проблемы. Я понимаю, что оно и так работает. Собственно говоря, работает потому, что частоты небольшие и хорошо, если вы, понимая это, осознанно проектируете в двух слоях. Хотя для продакшена такой платы эта экономия опасна и может выйти боком, лучше иметь запас по качеству.

2. У Ethernet PHY под брюхом микросхемы есть термопад, который у вас, судя по всему никуда не подключён. Через этот пад чип рассеивает тепло. Если бы у вас была 4-х слойная плата, то соединив этот пад с внутренним полигоном земли вы могли бы максимально эффективно охлаждать чип под высокой нагрузкой.
Картинка
image

3. Плохо видно, но на всякий случай скажу, что корпуса разъёмов не рекомендуется подключать к сигнальной земле напрямую. Нужен фильтр, обычно это пара кондесаторов и высокоомный резистор. Почитайте про «chassis ground to signal ground connection».

4. Мелочь, но сразу бросается в глаза и выдаёт новичка — термобарьеры для простых VIA (но не монтажных отверстий) абсолютно не нужны. Это можно прописать в правилах altium-а.

А так, со стороны выглядит неплохо.
Между тем, они весьма серьёзны, чего стоит, скажем, способ, гарантированно позволяющий определить наличие скрытого тома внутри контейнера TrueCrypt, что сводит всю правдоподобную отрицаемость к нулю...
А можно пруфлинк? Очень интересно почитать.
Это не спасёт от буфера, переполняющегося за 6 часов полёта. Тут скорее нужно именно в архитектуре софта и железа закладывать необходимость максимально сокращать длительность любого рабочего цикла и принудительно сбрасываться в нули. Проектировать так, чтобы периодический запланированный «горячий» сброс был естественной рабочей процедурой, а не чем-то экстраординарным, что нужно делать только в исключительных ситуациях, которые по идее никогда не должны происходить.

Но и у этого подхода есть минус — он маскирует ошибки. Допустим, что в софте/железе есть баг, который через 6 часов приведёт к переполнению, но модуль архитектурно устроен так, что сбрасывается каждые 500мс и всё работает как надо. Т.е. баг в коде есть, но сброс спасает. А если считать, что баги так или иначе нужно искать не полагаясь ни на какую страховку, то эта логика горячего сброса должна сыграть всё же положительную роль.
Был странный момент, когда все малинки примерно через 2 месяца работы стали периодически перезагружаться сами по себе.

Похоже на радиацию. ТЗЧ флипают битики в памяти, что приводит к сбою. Вы там с реализмом точно не переборщили?)
Ещё пару вариантов разной степени упоротости:

1. У STM32F407, насколько я понял из документации, бортовой USB не умеет HS, только FS. Зато у него есть интерфейс ULPI, который позволяет подключить внешний USB2.0 PHY. Я когда-то работал с ULPI. Конечно на этом камне ULPI интерфейсы воткнуть друг в друга не получится, как бы это красиво не выглядело, т.к. в ULPI именно PHY задаёт flow control, управляя ногами DIR и NEXT. С другой стороны сами эти PHY достаточно простые и дешёвые, они стоят менее 1.5$ (USB3300, например). Взять 2 PHY на каждый камень, соединить их друг с другом по USB и получить что-то около 480mbit/s. Теоретически даже не нужно будет поддерживать целиком интерфейс USB, т.е. дескрипторы и прочие пляски, т.е. сразу сырые данные кидать туда-сюда, но это нужно проверять. Тут и все прелести DMA можно будет использовать из коробки. С разводкой особых проблем быть не должно, ULPI это 12 ног на частоте 60Mhz и PHY друг с другом дифф.парой соединить.

2. Использовать staic memory controller. C помощью него STM32F407 умеет цеплять внешнюю память. Тут вариантов много.
a). Самый тупой способ. Берём микросхему двухпортовой SRAM памяти и цепляем на два проца. Двухпортовая память дороже обычной, но можно сэкономить на объёме, т.к. передача скорее всего планируется пакетная. Какая-нибудь ущербная 8-битная двухпортовая SRAM с доступом в 55ns даст что-то около 145mbit/s. По деньгам <9$ (71V30S, например), но можно искать ещё.
b). Если не хочется иметь дело с dual-port, то чисто теоретически можно одну SRAM память прицепить на 2 контроллера, если есть возможность делать нормальный tristate на управляющем порту проца. Это требует исследования. Зато память можно взять по-шустрее, шину по-больше и компенсировать тем самым все задержки переключения памяти от проца к процу. Единственное, с синхронизацией процесса передачи будет морока.
c). Что-то мне подсказывает, что теоретически к этому контроллеру можно подцепить даже аппаратное cmos asynchronous FIFO. Микросхемы малого объёма и скорости достаточно дёшевы <7$ (7201LA15JG, например).
d). Совсем обнаглеть и соединить два проца через эту шину напрямую. Это требует досконального понимания работы этого контроллера и его режимов. Но т.к. он умеет работать с NAND, который имеет флаг READY/BUSY, то теоретически возможность для flow control имеется и можно из проца в проц с помощью DMA гнать данные. Но это нужно крайне тщательно проверять.

Information

Rating
Does not participate
Registered
Activity