Вполне реально. Исправлять древний код может оказаться очень накладно. Во первых, мало кто из команды будет «в теме», как он работает. Исправление может нарушить функционал (неправильная версия работала, с правильная перестала) — т.е. надо все тестировать.
Немного электроники и снаряд можно сделать управляемым. Та же ракета, только не нужен пороховой заряд для разгона.
PS Вроде как уже и пули управляемые есть, если не ошибаюсь.
Можно применить гибкую печатную плату, одну на всю перчатку. Сенсоры паять прямо на нее. Это если про промышленные масштабы речь. Но то, что эти сенсоры показывают не углы, а ускорения, конечно большая проблема. Придется применять хитрую математику, и все равно погрешность будет большой.
Вы совсем не разбираетесь в вопросе. Для вспышки ваша выдержка 1/60 вообще по барабану, у нее своя длина импульса. И попробуйте вспышкой с 5см осветить поверхность, какая будет засветка для объектива? Солнце разве такую даст?
Это вряд ли, по моему мозг одинаково хорошо строит модель, видимую только для одного глаза, и модель, видимую на фотографии где точно нет никакого микропараллакса. Гораздо важнее для воссоздания модели светотени. Как аргумент, приведу пример: для точного построения 3Д сцены на компьютере нужен сложный алгоритм рейтрейсинга с учетом всех переотражений, физичских свойст поверхностей и т.д, иначе мы тут же видим малейшую неточность. Значит, эта сенсорная информация очень важна для зрения, раз ей выделена такая детализация.
То есть пользователь должен ввести ПИН-код, чтобы открыть приложение на смартфоне? Согласен, тогда появляется второй фактор (если конечно ПИН запрашивается для каждого нового входа, иначе воспользоваться чужим телефоном в отсутсвии хозяина даже проще, чем узнать его пароль). Но тогда каким образом автор этой статьи сумел обойти ввод пин-кода?
Тоже думал, что в смартфоне не может быть качественного звука, приобрел внешний усилитель (Fiio E18 со своим ЦАП). Разница если и есть, то абсолютно некритичная, чтобы возиться с подключениями «бутерброда», когда хочется послушать музыку. Единственная польза от внешнего усилителя — когда тихая запись и высокоомные наушники, и хотя Galaxy Note II хорошо их прокачивает, но на некоторых записях слегка не хватает предельного положения регулятора громкости (наушники Philips Fidelio L1, 30 Ом)
Интересно, если взять более-менее реальный проект, где есть сложные вычисления, есть ли оценки эффективности? Если поток1 работает непрерывно (не привлекая delay) 100мкс, поток2 тоже 100мкс, то как ОС распеределит время между ними? Они досчитают одновременно или по очереди? И сколько пройдет времени в сумме (т.е. какой оверхеод от вмешательства RTOS?)
«Исключение — это не «ошибка в Java» — это метод сообщить вышестоящей функции о том, что вызываемая функция завершилась с ошибкой»
Не только, исключения ещё и очень удобный способ сократить число проверок. Если нужно вызвать 10 функций для выполнения задачи, каждая может вернуть ошибку, и обработка любой ошибки одинакова — оборачиваем в try {} catch() {} finally{}. Да и исключения внутри блока try {} могут возникнуть не только по вине функций, я сам могу их там бросить если понятно что не нужно продолжать выполнение этого блока.
В вашем примере с go ситуация выглядит не очень хорошо в плане обработки ошибок. Имхо, исключения намного более гибкий способ, учитывая типизацию, наследования и прочие плюшки ООП, применимые к исключениям. И если не хочется пропускать ошибки — декларируйте все функции как «throws Exception» — и пропустить ошибку компиятор уже не даст, придется или обрабатывать или кидать далее.
«Создание малогабаритных АС, играющих весь слышимый частотный диапазон. По моему мнению, будущее в этом плане за техникой предыскажения и техникой компенсации упругих колебаний возникающих внутри ящика (если речь идет о динамиках)»
Это верная мысль, сейчас, если уж делать что-то близкое к HiFi а не к консервной банке, без DSP не обойтись. Вы упомянули что микросхема от TI легко коннектится с DSP, осталось только «промерить» ящик и сделать нужные фильтры по заданные выходные параметры.
Кстати, давно пользуюсь маленькой беспроводной колонкой Jabra Solemate. Помимо плюсов в виде размеров, полной автономности, совместимости с любым Bluetooth устройством, — звук у нее просто волшебный. Чистые верха и середина, достаточно глубокий бас и запас по громкости (для такого размера). Звук даже приятней для слуха, чем через HiFi колонки и HiFi усилитель, которые у меня имеются. Правильно настроенный DSP творит чудеса.
Если делать «народную» систему — обязателно обратите внимание на совместимость со смартфонами. Музыкальные коллекции многие хранят именно там, и как плеер он идеален.
Кстати, ещё один очень простой способ точно определить частоту сигнала, если известно, что он состоит из небольшого числа гармоник: сначала вычисляем FFT с низким разрешением, находим два соседних отсчета с высоким уровнем амплитуды, скажем f1 и f2. Искомый сигнал где-то между ними. Теперь просто сворачиваем сигнал с десятком sin и cos с частотами, распределенными от f1 до f2 и опять находим максимум. Тем самым повышаем разрешение в 10 раз. Можно применить технику бинарного поиска, чтобы оптимизировать процесс. Но смысл думаю понятен.
Если не ошибаюсь, то наружу выведены не все ноги процессора? В таком случае на отладочную плату это мало похоже, какой смысл ее сравнивать с теми же Discovery, если у них совершенно разные области применения. Лично меня Discovery устраивает всем, очень помогают в разработке и претензий по качеству компонентов нет никаких.
Да элементарно, все современные компрессоры видео умеет опредять вектор смещения областей в соседних кадрах (на основе этого как раз и получается высокая степень сжатия без заметных потерь). Перенести эту технологию в ТВ и интерполировать промежуточные кадры по этим векторам совсем не пробема. В моем Филипсе уже 6 лет назад эта True Motion очень зачетно достраивала кадры до 50p, что уж говорить про современные процесссоры.
Perl был языком, с которого я начал свой путь программиста в 2000 году, с написания своего CMS (тогда с готовыми было туго, и изобретение своего велосипеда было нормой). И я до сих пор активно работаю с этим фреймворком, каждый день решаю достаточно сложные задачи для повседневной деятельности и развития фирмы. А самое прикольное, что проект уже 14 лет крутится на Perl5, переезжая на разные сервера и ОС, и за это время я не столкнулся с багами интерпретатора ни разу. Спасибо, Perl. Из главных плюсов языка отмечу то, что он прекрасно подходит для быстрого решения небольших задач. В этом ключе наверное и будет применяться в будущем. Из минусов — большие и сложные системы без нормального ООП и глубоко интегрированного с языком IDE, разрабатывать сложно.
И с пипеткой можно ещебольше улучшить распознавание. Сейчас 6 ползунками вы фактически ограничивается параллелепипед в цветовом пространстве. Пипеткой можно брать несколько точек и строить произвольный объем. Правда, проверка вхождения точки в этот объем усложнится.
Не устраивает тем, что это не специализрованное устроство: нужно два модуля доставлять, где-то искать и ставить софт, да и по спецификациям все таки не FullHD:
«Разрешение кодируемого видео до 720p 30 fps»
Когда я делаю другое DIY устройство, вдаваться в тонкости кодирования и передачи видео не хочется, хочется взять что-то готовое и уже отлаженное.
Устройство однозначно инетересное, и очень хорошо если оно будет доступно по конкурентоспособным ценам. На заметку предложение о направлениях развития в сторону DIY: мне было бы интересно получить его без красивого корпуса, но чуть дешевле. Ещё, очень хорошо было бы получить канал управления по WiFi (порты UART и PWM напрямую с вашего устроства, и соответсвенно поддержку со стороны приложений на другой стороне линка, в виде API или HTTP как самый простой вариант)
PS Вроде как уже и пули управляемые есть, если не ошибаюсь.
Не только, исключения ещё и очень удобный способ сократить число проверок. Если нужно вызвать 10 функций для выполнения задачи, каждая может вернуть ошибку, и обработка любой ошибки одинакова — оборачиваем в try {} catch() {} finally{}. Да и исключения внутри блока try {} могут возникнуть не только по вине функций, я сам могу их там бросить если понятно что не нужно продолжать выполнение этого блока.
В вашем примере с go ситуация выглядит не очень хорошо в плане обработки ошибок. Имхо, исключения намного более гибкий способ, учитывая типизацию, наследования и прочие плюшки ООП, применимые к исключениям. И если не хочется пропускать ошибки — декларируйте все функции как «throws Exception» — и пропустить ошибку компиятор уже не даст, придется или обрабатывать или кидать далее.
Это верная мысль, сейчас, если уж делать что-то близкое к HiFi а не к консервной банке, без DSP не обойтись. Вы упомянули что микросхема от TI легко коннектится с DSP, осталось только «промерить» ящик и сделать нужные фильтры по заданные выходные параметры.
Кстати, давно пользуюсь маленькой беспроводной колонкой Jabra Solemate. Помимо плюсов в виде размеров, полной автономности, совместимости с любым Bluetooth устройством, — звук у нее просто волшебный. Чистые верха и середина, достаточно глубокий бас и запас по громкости (для такого размера). Звук даже приятней для слуха, чем через HiFi колонки и HiFi усилитель, которые у меня имеются. Правильно настроенный DSP творит чудеса.
Если делать «народную» систему — обязателно обратите внимание на совместимость со смартфонами. Музыкальные коллекции многие хранят именно там, и как плеер он идеален.
«Разрешение кодируемого видео до 720p 30 fps»
Когда я делаю другое DIY устройство, вдаваться в тонкости кодирования и передачи видео не хочется, хочется взять что-то готовое и уже отлаженное.