Во-первых всем огромное спасибо за советы!!!

Пока прокомментирую пока, почему не отдельно FPGA + Arm, а взят Cyclone SoC.

Я сильно жмочу габариты (внутренняя допустимая ширина платы 22мм), и в эти габариты надо вписать достаточно мощный процессор и обязательно плиску, если забить на эти габариты, то отвалится один предзаказ на 1000+ экземпляров, что не хотелось бы допустить.

Причем на плиске мне надобно хотя бы под сотню 18битных умножителей на 200МГц+ такте, а на процессоре хотя бы с пол гигафлопса вычислительной мощности и весь пакет лапаков, бласов и фурьей (остальное свое, в крайнем случае могу и свое фурье взять) и очень важна маленькая латентность по коммуникации плиска-процессор, то есть надо за 100микросекунд получить с плиски данные, обработать, и послать назад. Ниосы внутри плиски не осилят, проверено. Пока я не видел покупных борд, кто бы вписал хоть в такие габариты DDR2 + ARM + FPGA.

Реально на данный момент не знаю другого решения. Сам разводку (последнюю, которая заработала) делал 2 месяца, базируясь уже на своих же наработках, которые были примерно в 15 разных предыдущих прототипах.

Склоняюсь, чтобы не пускать юзера вовнутрь оставив это только на свой софт, и только выбрать внешний безгеморный способ обработки гуя, понимая, что минималистичекую версию сего гую придется написать самому, но я их практически не писал (кроме tcltk в прошлом веке).

минималистичекую версию сего гую придется написать самому

Это проблема только на конкретный момент времени. По сравнению с той системой которую Вы уже создали - это просто детский сад.

Просто одному человеку не охватить всего. Но думаю, в этом вопросе мы сможем вам помочь.

> Я просто представляю, что нужно юзеру такого спектрометра - он захочет скроллить спектры, автоматически распознавать и обсчитывать пики нелинейной аппроксимацией

с одной стороны - Вы правы, но есть еще важный ньюанс.

Ключевая идея (или одна из них) - это тензорная аппроксимация спектров (построение спектров веществ в отсутствии базы данных и референсных спектров), причем выносить это дело на внешний мир - гарантия повесится с поддержкой всех возможных архитектур. Поэтому процессор для численных расчетов в общем-то внутри не совсем жмотский, если учитывать, что часть вычислений выносится внутрь плиски через OpenCL и там на раз считаются. В 2006 для этих задач я пользовал суперкомпьютеры, сейчас я умудрился это засунуть в балалайку с 20 ваттным потреблением.

А представьте как бы меня материли бы юзеры, если после покупки моей аппаратуры я буду простить их иметь у себя десктопе ворох графических карт и очень специализированного софта, или суперкомпьютер под рукой?

Я не зря внутрь 32 или 64ГБ флеша ставлю, чтоб исходные спектры до обработки сидели внутри, и юзер мог дообработать все именно так, как надо, но только на моем железе и с хорошо вылизанной под это численной оптимизацией.

И разпознавалка спектров по базе данных тоже внутри сидит. Просто оно все хорошо работает, если в этот момент процессор не дергают другими задачами.

Хотя уже вот скроллинг, дифференцирование, и всякие совсем простые вещи (грубо говоря, когда вычислительная работа сравнима с объемом обрабатываемых данных) однозначно надо выносить наружу, но ни распознавалки, метод распознования спектров без базы данных (то есть тензорное разложение) - только внутри, чтоб не огрести гемор на клиенте у юзера.

с поддержкой всех возможных архитектур

Не надо всех. Все производители спектрометров - по крайней мере, мне лично исключения неизвестны, хотя могу допустить - продают прибор с компом, который гарантированно поддерживает требуемое железо (в виде спец-граф.карт или спец-контроллеров). Я могу понять, когда на борду заведены вылизанные алгоритмы матричных вычислений, если мощи хватает. Но от других операций борду, ИМХО, надо максимально освобождать. Если предполагается передача только обработанного спектра, то, видимо, можно обойтись и без SQL-сервера, но с ним мне было бы как-то проще. Если же идея состоит в продаже прибора за минимальные бабки без внешнего компа (предполагается, что комп подходящей мощности у клиента найдется), то это дополнительное условие меняет подход радикально. Тем не менее, вариант с Origin однозначно будет наименее затратным по времени и усилиям в обоих случаях.

разпознавалка спектров по базе данных тоже внутри сидит

И это, имхо, глубоко неправильно. Потенциальная причина нехватки ресурсов в какой-то момент времени. Лучше выносить на внешний десктоп, даже если она хорошо оптимизирована. Впрочем, тут нужно знать все детали, поэтому мои воззрения могут быть далеки от оптимума.

> Не надо всех. Все производители спектрометров - по крайней мере, мне лично исключения неизвестны, хотя могу допустить - продают прибор с компом, который гарантированно поддерживает требуемое железо

да, когда спектрометр стоит от 200К, то такое барство можно позволить, а если спектрометр 1К стоит?

А ведь куча народу загорелось воткнуть его в андроид, а его, к сожалению, Origin не поддерживает, да на линуксе Origin не ходит, и мне будет жуть как неудобно, так как я заядлый линуксоид.

> Про распознавалку, что внутрь спектрометра засовывается.

> И это, имхо, глубоко неправильно.

эххх, не словили Вы ключевую фишку моей разработки.

Полный многомерный спектр (NOESY + HSQC + HMBC) для 200Да молекул на моих магнитах надо снимать пару месяцев. Но если есть база, и сам кусок спектра снимается за секунду, то можно одновременно залудить разсопзанавлку, и принять решение что снимать дальне. Дальше делаем мой неравномерный семплинг, и вуаля, спектр заматчился по базе данных за несколько минут.

Поймите, юзеры, которые покупают за 1-2К спектрометр, еще отличить NMR(ядерный магнитный резонанс) от NIR (ближний ИК спектр) не могут. Если им дать по башке многомерным NOESY + HSQC + HMBC они меня сразу пошлют куда подальше, а если они в удобном виде получат список веществ, а продвинутые юзеры смогут залезть и посмотреть детали самого спектра, то все на это и западут сразу.

Но вот комп для обработки будет как часы с двумя чемоданами батареек - все юзеры будут материться.

Как я ее мог словить, если я впервые слышу о non-uniform (?) sampling в Вашей разработке? Я не телепат. Если речь об 1-2К за прибор, то тогда ситуация понятна. Тем не менее, комп для визуализации будет все одно нужен. В общем, если бы сразу были озвучены ВСЕ принципиальные ограничения (цена, некомплектация компом, распознавание в ходе обработки raw data,...), то я бы ничего не советовал. Не знаю приемлемых средств разработки для такой комбинации. С учетом того, что юзеру все одно понадобится комп для взаимодействия с прибором, можно поставить условие, что комп должен работать либо под виндой, либо под OS X - тогда можно продавать с "мордой" на Origin-е, ибо предусмотрена OEM-версия. Правда, цены на нее не знаю.

Вот еще идея появилась. А что если будет одна базовая версия и одна расширенная. Расширенная будет использовать дополнительно туже самую борду, только без серьезных вычислений.

> Вот еще идея появилась. А что если будет одна базовая версия и одна расширенная. Расширенная будет использовать дополнительно туже самую борду, только без серьезных вычислений.

очень правильная идея, спасибо! И, к счастью меня так этой идеей уже все вдохновляют, что также будет и продвинутая версия, для хроматографистов, и вот там-то и компьютер специализированный будет, и чувствительность на несколько порядков выше, правда и ценник тоже побольше. Но тут все просто - стик - массовое потребление в промышленности, а продвинутая версия - для лабораторий.

> Как я ее мог словить, если я впервые слышу о non-uniform (?) sampling в Вашей разработке?

другие как-то сразу словили фишку http://bnw.im/p/02KGJF а вы мне даже на anchem.ru форуме много букв написали, странно как-то что тогда не поняли, я там это детально разжевывал

> Тем не менее, комп для визуализации будет все одно нужен

правильно, только те, кто будут пользовать версию за 1-2К - будут в первую очередь ожидать простого и понятного интерфейса, и такой человек не только про триплеты и мультиплеты, он вообще про ЯМР скорей всего до этого только краем уха слышал. И те, кто будут трактовать сами спектры - могут купить продвинутую настольную версию или таки скачать с моего агрегата FID и сами потрахаться в их любимом софте как им хочется, а те, кому надобно ехать - будут хотеть практически текстовую информацию - сколько чего найдено, с какой вероятностью закореллировано, ну может пару каких-то простеньких графиков для наглядности.

Ну и как я говорил - я сам юниксоид, и сугубо виндовые программы без поддержки юникса/линукса - рука не поднимается в своем продукте пользовать.

те, кто будут пользовать версию за 1-2К - будут в первую очередь ожидать простого и понятного интерфейса

Этого будут ожидать ВСЕ.

и такой человек не только про триплеты и мультиплеты, он вообще про ЯМР скорей всего до этого только краем уха слышал

Сомневаюсь. Наоборот, это будут брать наиболее продвинутые - те, кто хорошо понимает, в чем там фишка. По крайней мере, я знаю оооочень неплохих органиков-синтетиков, глубоко знающих ЯМР, работавших на всяких крутых многомегагерцовых "брукерах" которые с удовольствием взяли бы себе в лабу такой прибор.

и виндовые программы - рука не поднимается в своем продукте пользовать

Тогда страдайте. Мазохизм недешев и времязатратен.

> Наоборот, это будут брать наиболее продвинутые

пока у меня полностью противоположный опыт общения с потенциальными заказчиками

> Тогда страдайте. Мазохизм недешев и времязатратен.

уверен, что Вы сами понимаете, что если я не буду поддерживать андроид, то потеряю с половину заказчиков, так и начерта нишевым софтом мутить воду-то. а? А если вспомнить, что уже были запросы по поводу встраивания в ИоТ на ембеддед платформах, а там винда совсем нишевая и ваш оригон за 25 лет своего существования даже не думал поддерживаться, а? Об этом-то не задумались?

Ладно, от темы отвлеклись сильно.

Вопрос к знающим, скажите, пожалуйста, что будет быстрее:

1. прочитать и разобраться в жаваскрипте и css и на нем нарисовать простого клиента, который в стандарте JSONа общается,

2. нарисовать напрямую свой парсер дюжины http запросов?

Достоинства: 2 - точно сам осилю и косяков и тормозов точно не будет.

Если первое, дайте, пожалуйста, простую и понятную книгу для чайников.

Хотите, я повангую, чем все закончися? Тем, что глючноватым, неудобным и плохо расширяемым минималистическим интерфейсом Вы отпугнете клиентуру. «Чайники», кстати, часто более требовательны к качеству интерфейса, чем «продвинутые». В общем, я плохо понимаю, на какую нишу рынка Вы ориентируетесь, и помочь я Вам боле ничем не могу. Засим откланиваюсь.

ЗЫ. ОРИДЖИН.

> ЗЫ. ОРИДЖИН

я понимаю, что у каждого есть какой-то глючновато левый старый, но любимый софт, у Вас - это Ориджин, у меня Тикл. Но то, что Ориджин не пользуют в большинстве систем и он имеет очень нишевую аудиторию просто сразу отпугивает. Я вот понимаю, что могу на тикле это все написать, и оно даже встанет хоть на ведроиде, хоть на винде, но будет очень не стандартно и действительно всех отпугнет и я даже не задумываюсь так сделать.

Если наружу будет виден голый html, то он будет виден у всех, и никто меня не задолбает фразами, что де что-то непонятное. Если будет разумный клиент на жаве - то тоже. Я предполагаю, что есть еще разумные альтернативы, но, так как в них не разбираюсь, то не могу сказать какие еще.

Поэтому для своего случая я рассматриваю только варианты, которые будут поддерживаться на ВСЕХ распространенных системах. Я достаточно наогребал от поставщиков научного оборудования гемора по несовместимости. Мой аппарат должен быть совместимым со всем железом. Это желание моих клиентов, а значит, и мое обязательство. Точка.

JSON - это ХМЛ/CSV овер НТТП.

Выигрышь будет в обьеме перегоняемых данных и потенциальной асинхронности.

А в обьеме реализации - ой... особенно, если что-то самопальное.

Парсер протокола самому писать не рекомендую - есть их уже на все случаи.

Просто посмотри что из реализаций способно у тебя работать и сколько ресурсов надо.

Сильно меньше, чем есть написанное, можно сделать только обрезав функциональнось,

от чего ты сам потом будешь плеваться.

Тебе, кстати, давали очень правильный совет - не засовывай все на борду.

На борде тебе нужно самое необходимое:

- сообщить борде что именно от нее ожидается

- снять голые данные - это 100% нужно тем кто будет копать сам

- снять какие-то промежуточные данные

- снять обработанные данные, посчитав что ты там хочешь/можешь посчитать

- загрузить и обсчитать внешние данные - если выч.мощности хватает

Вроде все.

Сделать презентационный уровень, без обработки, много проще на стандартном ПС - обычный полный вэб-сервер, нужные обработчики и привычные разработчикам компоненты. А писюк все одно будет - видюху в борду ты втыкать не собираешься... т.е. будет какая-то инсталяшка - загрузишь сайтик в процессе и пусть смотрят локально... или удаленно.

Уходя-уходи, конечно, но уж очень насмешило:

Ориджин не пользуют в большинстве систем и он имеет очень нишевую аудиторию

Ну, тогда весь R&D - это очень нишевая аудитория. Да и ощутимая часть индустрии, пожалуй, тоже... Бугога.

> Уходя-уходи, конечно, но уж очень насмешило:

а что, мы на ты уже? Уходите, вы же пообещали. Кроме непутевого флейма вы в мои топики, к сожалению, ничего не привносите.

А вот это уже наглое вранье и свинская неблагодарность. Идите лесом. Авось, бог подаст.

> А вот это уже наглое вранье и свинская неблагодарность. Идите лесом. Авось, бог подаст.

Если чем-то Вас обидел, прошу прощения, хотя искренне считаю, что вранья с моей стороны нет, а есть махровый троллинг с вашей. Как сотрудник американской фирмы не готов далее продолжать с вами флеймить, у нас тут социализма нет.

1. прочитать и разобраться в жаваскрипте и css и на нем нарисовать простого клиента, который в стандарте JSONа общается,
2. нарисовать напрямую свой парсер дюжины http запросов?

Если у Вас нет необходимости использовать сложные формуляры и нужно поддерживать соединение только с одним пользователем, я бы выбрал второе.

И ещё один момент. Я как понимаю Вы используете Embrdded Linux на ARM-е. Может стоит посмотреть в сторону RTOS, где RTOS не так тежеловестна и вы можете управлять так же ресурсами и процессами.

Благо Cyclone в отличии от Zynq предлагает больший список поддерживаемых OS and RTOS.

P.S. Ребята не ругайтесь, ведь на "пустом месте" спорите.

Спасибо, Wanderer_ за добрые слова и советы!

> Если у Вас нет необходимости использовать сложные формуляры и нужно поддерживать соединение только с одним пользователем, я бы выбрал второе.

ага, пока тут это все это бурлило и обсуждалось так именно и сделал :) То есть на ембеддед одна выполнялка, в которой sprintf-ом генеряться на лету все странички, что видит юзер, а когда он хочет скачать спектр, то качает его как-будто с диска, но в реале спектр генериться в памяти и сокетами посылается.

RTOS очень хотелось бы использовать, но есть одна заморочка. мне надо редко, но надобно, перекомпиллировать гнутым компиллером часть софтвера, который внутри эмбеддед платформы работает. Да и софт сам по себе очень развесистый, что есть .so которые подгружаются по мере необходимости. То есть внутренний объем без динамических библиотек будет ужасающим, а без встроенного компиллера - не реализуемым. Обычный юзер не будет использовать ту часть когда, что дергает компиллер, но продвинутый - точно будет. Понятно это можно через свой хостинг можно организовать, но вроде бы не правильно.

Поправьте, пожалуйста, про RTOS + .so и gcc если я не прав и что-то прохлопал.

Еще вопрос на тему, не пинайте сильно...

Есть свой веками отточенный на пользователях ЯМР аппаратов 2D и 3D-контурплот, который выдает в OpenGL или EPS. Картинки получаются для них информативные, генерация шустро работает. Скажите, пожалуйста, в каком формате их можно/правильно передать по вебу или какой формат взять правильнее вместо EPS, но чтоб сильно не вешаться по конвертации? То есть какой векторный формат по вебу хорошо ходит? То есть у меня не гугл-мапс конечно, но 3D-контур плот. Пример постскрипта в аттаче.

Прикреплённые файлы