Последние полтора года я работаю совсем рядом с домом))) Для тех кто работает далеко вопрос интересный.
Мне тоже интересно что в таком случае делать. Интересно почитать комменты!
нет, не пробовал.
рад что вы успешно применяете в работе arduino!
Как прикладному программисту мне все же удобнее и быстрее писать, отлаживать и профилировать приложения на java в linux. В любом случае лучше использовать более быстрое и более удобное аппаратное обеспечение, к тому же при цене в 25-35$
АЦП есть, т.е. есть аудиовыход. Но вот аудиовход по экономическим соображениям не вывели. What about audio?
There’s a standard 3.5mm jack, or you can use HDMI. You can add any supported USB microphone via a hub.
см www.raspberrypi.org/faq
В таком случае без внешнего контроллера в котором обычно есть несколько ADC/DAC не обойтись. Но не так часто нужно оцифровывать сигнал с датчиков в охранке
8 битный МК, девельская плата на который стоит больше 1000р?
При том что можно взять 32битный ARM с платой в которой есть и МК и программатор, USB порт и GPIO за 400р
Спасибо за информацию!!!
Второй вариант как раз и был GPIO-to-RS232 over USB. Воможно сделать клиента и на J2ME, но сейчас почти все телефоны поддерживают HTML.
Без мелкой серии не обойтись т.к. в любом случае нужно «прощупать» рынок.
С точки зрения прикладного программирования фреймворк написать просто. Т.к. GPIO в linux видны как файлы, то же и с RS232 over USB
Аналоговые сигналы до 22КГц можно вводить через USB аудио плату и использовать sound API java
С JVM чуть сложнее, т.е. open JDK по умолчанию работает на ARM без JIT Zero-Assembler Project, есть Shark LLVM JIT но насколько он стабильный пока не знаю
Я думаю вполне хватит, если не выполнять распознавание речи, анализ видеосигнала и т.п.
Чтобы собирать данные с датчиков и веб камеры, оповещать удаленно и управлять устройствами 700MHz ARM процессора с 256Mb RAM вполне хватит
Спасибо за пост. Отличные идеи!
Есть open source проекты для здравоохранения. Например часть того о чем вы пишете есть в openmrs.org
Существуют интеграционные проекты, например openehealth.org
QR коды отлично генерировал на проекте с помощью code.google.com/p/zxing
Есть смысл не строить платформу «с нуля» а развивать существующие открытые решения.
Вы правы Насчет аппаратных особенностей и оптимизации алгоритма под конкренные платформы.
Разработка оптимальных с точки зрения производительности OpenCL функций для GPU и CPU требует знания аппаратных особенностей платформы исполнения. Но, синтаксис и набор функций един в стандарте и host API один и тот же для разных реализаций. Т.е. с точки зрения разработчика достаточно выучить один язык (вместо Brook+, CUDA и т.п. для каждой платформы) и один переносимый host API. Это позволяет разработчику углубиться на оптимизации ядер на одном языке под каждую платформу. С помощью API можно узнать тип устройства и производителя и вызвать функцию оптимизированную под данную платформу.
Ситуация со стандартом OpenCL такая же как и с OpenGL в свое время. До появления аппаратуры от Nvidia и их драйверов, на массовом рынке для Windows не было производительных реализаций драйверов OpenGL. Был зоопарк проприетарных API: Glide/DirectX привязанных к конкретным вендорам. С появлением нового производителя аппаратных 3D карт на рынке и большого колличества программ использующих OpenGL, качество драйверов от различных производителей улучшилось!
OpenCL от Nvidia реализован над CUDA и по данным с разных статей производительность на 10% хуже.
Ждем появления большого колличества ПО использующих OpenCL и тогда вендоры будут оптимизировать драйвера/компиляторы, чтобы их платформа была лучше чем конкурентов по производительности.
Наличие универсального языка позволяет упростить разработку и чем больше разработчиков будут знать OpenCL тем проще будет найти разработчика для реализации проекта. Главное чтобы разработчик имел достаточно знаний по каждой поддерживаемой программой аппаратной платформе.
Общие тенденции развития hardware: AMD Fusion, IntelMIC, IBM Cell, Nvidia ARM, свидетельствуют что для разработки ПО для новых платформ нужен язык, поддерживающий многопоточность, встроенные в язык векторные типы и обширную библиотеку алгоритмов обработки данных, а также большое колличество специалистов владеющих языком программирования и инструментарием разработки.
По поводу JIT в OpenCL я описал свое мнение в комментарии выше)
Да такой подход применим и для .NET/Mono и Cloo. Мой опыт разработки связан с jvm. Каждый кулик хвалит свое болото ;) Если напишите пост про опыт разработки Mono/Cloo + OpenCL под linux, с удовольствием почитаю.
Вряд ли это возможно в текущем виде реализации технологии OpenCL. Она приминима лишь к определенному кругу задач, есть границы применимости связанные с особенностью аппаратного обеспечения. Мне кажется перспективным в ближайшие годы — реализация части алгоритмов с java коллекциями на OpenCL по аналогии со ScalaCL и реализация fork-join фреймворка с использованием java closure которые транслируются в OpenCL функции по аналогии с проектом Aparapi. Также отлично вписываются в технологию задачи обработки/фильтрации изображений java2D/JAI. Но JAI похоже умер так и не родившись, по крайней мере опыт работы с ним оставил неприятные воспоминания(
Мне тоже интересно что в таком случае делать. Интересно почитать комменты!
рад что вы успешно применяете в работе arduino!
Как прикладному программисту мне все же удобнее и быстрее писать, отлаживать и профилировать приложения на java в linux. В любом случае лучше использовать более быстрое и более удобное аппаратное обеспечение, к тому же при цене в 25-35$
USB CDC как раз и использовали с STM32-H103. С таким вариантом программирования даже server side джавист справляется ;-)
What about audio?There’s a standard 3.5mm jack, or you can use HDMI. You can add any supported USB microphone via a hub.
см www.raspberrypi.org/faq
В таком случае без внешнего контроллера в котором обычно есть несколько ADC/DAC не обойтись. Но не так часто нужно оцифровывать сигнал с датчиков в охранке
При том что можно взять 32битный ARM с платой в которой есть и МК и программатор, USB порт и GPIO за 400р
Второй вариант как раз и был GPIO-to-RS232 over USB. Воможно сделать клиента и на J2ME, но сейчас почти все телефоны поддерживают HTML.
Без мелкой серии не обойтись т.к. в любом случае нужно «прощупать» рынок.
С точки зрения прикладного программирования фреймворк написать просто. Т.к. GPIO в linux видны как файлы, то же и с RS232 over USB
Аналоговые сигналы до 22КГц можно вводить через USB аудио плату и использовать sound API java
С JVM чуть сложнее, т.е. open JDK по умолчанию работает на ARM без JIT Zero-Assembler Project, есть Shark LLVM JIT но насколько он стабильный пока не знаю
Чтобы собирать данные с датчиков и веб камеры, оповещать удаленно и управлять устройствами 700MHz ARM процессора с 256Mb RAM вполне хватит
Есть open source проекты для здравоохранения. Например часть того о чем вы пишете есть в openmrs.org
Существуют интеграционные проекты, например openehealth.org
QR коды отлично генерировал на проекте с помощью code.google.com/p/zxing
Есть смысл не строить платформу «с нуля» а развивать существующие открытые решения.
Разработка оптимальных с точки зрения производительности OpenCL функций для GPU и CPU требует знания аппаратных особенностей платформы исполнения. Но, синтаксис и набор функций един в стандарте и host API один и тот же для разных реализаций. Т.е. с точки зрения разработчика достаточно выучить один язык (вместо Brook+, CUDA и т.п. для каждой платформы) и один переносимый host API. Это позволяет разработчику углубиться на оптимизации ядер на одном языке под каждую платформу. С помощью API можно узнать тип устройства и производителя и вызвать функцию оптимизированную под данную платформу.
Ситуация со стандартом OpenCL такая же как и с OpenGL в свое время. До появления аппаратуры от Nvidia и их драйверов, на массовом рынке для Windows не было производительных реализаций драйверов OpenGL. Был зоопарк проприетарных API: Glide/DirectX привязанных к конкретным вендорам. С появлением нового производителя аппаратных 3D карт на рынке и большого колличества программ использующих OpenGL, качество драйверов от различных производителей улучшилось!
OpenCL от Nvidia реализован над CUDA и по данным с разных статей производительность на 10% хуже.
Ждем появления большого колличества ПО использующих OpenCL и тогда вендоры будут оптимизировать драйвера/компиляторы, чтобы их платформа была лучше чем конкурентов по производительности.
Наличие универсального языка позволяет упростить разработку и чем больше разработчиков будут знать OpenCL тем проще будет найти разработчика для реализации проекта. Главное чтобы разработчик имел достаточно знаний по каждой поддерживаемой программой аппаратной платформе.
Общие тенденции развития hardware: AMD Fusion, IntelMIC, IBM Cell, Nvidia ARM, свидетельствуют что для разработки ПО для новых платформ нужен язык, поддерживающий многопоточность, встроенные в язык векторные типы и обширную библиотеку алгоритмов обработки данных, а также большое колличество специалистов владеющих языком программирования и инструментарием разработки.
По поводу JIT в OpenCL я описал свое мнение в комментарии выше)