iiv

на более слабых камнях (атмега328) я делал так: атмеговский порт втыкал в ftdi232 и выход последней - в усб линукс компа. Дальше в 328 вшивался бутлоадер от ардуины, и я мог по avrdude через /dev/ttyUSB0 перепрошивать этот контроллер или открывать /dev/ttyUSB0 на чтение и запись и общаться с работающей прошивкой. К сожалению, атмеги328 мне теперь не хватает - мало ног и только один ком порт. Атмеги2560 по ногам хватит, но по точности адц-шки - нет.

Всем привет, есть незадачка - ищу подходящий контроллер, чтобы: 1. можно было перепрошиваться через USB, которое воткнуто в дебьян-арм линукс, 2. было куча простых и понятных библиотек для работы с I2C, SPI, UART, десяток GPIO, с десяток ADC 10 битных, а лучше 12 битных. 3. цена, корпус и достоваемость - не принципиально, главное, чтобы где-то в мире их можно было купить... Идеально подходит под мои требования Atxmega128a4u/Atxmega256a3u или их младший брат Atxmega32a4u. С переферией и софтом тут супер, но вот я уже неделю как бьюсь и не могу начать перепрошивать эти процессоры через усб - даже моя 64 битная семерка, не говоря уж об линуксе, их почему-то не видет. Из-за невозможности перепрошить, вопрошаю здесь, помогите, пожалуйста, что можно кроме этой серии выбрать? Спасибо ИИВ

Всем привет, flip (3.4.5) под линуксом не живет, гугл и аппноты что-то ничего не говорят... Помогите, пожалуйста, сабж, очень надо! А именно надо купленный кристалл подсоединить по усб к линукс компьютеру и оттуда иметь возможность регулярно заливать новую прошивку, а также общаться с линукс компом как если бы они по ком порту соединены были бы. С радостью бы почитал бы инструкции как это делать по-русски или по-английски или по-немецки, ну на крайняк, по-французски, но, по-китайски, думаю, бы не осилил бы. Помогите, пожалуйста!!! Спасибо ИИВ

Мы как-то с Вами на форуме общались - у меня сложилось очень приятное впечатление. Сейчас есть желание развести с нуля на плате альтерку и AD9653 (LVDS 500MHz DDR) плюс минимумом переферии. Хочется именно совместно это сделать, а не давать на аутсорс, так, чтобы у меня возникло понимание деталей как это делать. Скажите, пожалуйста, Вам это было бы интересно? Мог бы лично пообщаться с Вами (Вы в Москве вроде) так как в самом начале следующего месяца планирую нарисоваться на юге Москвы. ПС: суммарное число ног плиски и ADшки должно точно меньше 400 получиться :)

только вот любая самая жирная плисина продует недорогому ГПУ чипу в чистую - сейчас на фурье на сингл пресижн с ГПУ можно до 5 терафлопс снять - сколько десятков виртексов надо взять, чтобы 5 терафлопс на Фурье получить? и булевость - да - это единственный удел для плисок при высокопроизводительных вычислениях, все остальное - прототипирование...

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

да, только Вы, до моего поста упорно про него не могли вспомнить Вы из прокрустова вращения выведете Фурье или наоборот? Это просто два разных метода, один разлагает сигнал по спектру с фиксированным Фурье базисом, а другой ищет базисные функции, удовлетворяющие некоторым дополнительным ограничениям, а именно ограниченное число источников шума + достаточно большое число приемников + ограниченность размерности пространства, (3Д). Для Фурье необходима периодичность сигнала, в этом методе она не нужна. боюсь, что Вы все-таки не знакомы с этим методом (прокрустовым вращением), ни с теорией, ни с практикой, только это может Вас сподвигнуть такое утверждать, поэтому, все-таки я очень рекомендую Вам погуглить на приведенные мной выше фамилии и почитать про этот метод поподробнее. Нет конечно же, я не первооткрыватель этого метода, но, надеюсь, Nature Вас убедит в моей правоте, а остальной десяток моих статей сами по ссылкам думаю, найдете.

если Вы не в теме, не говорите, пожалуйста, так уверенно, заблуждая вопрошающих. В такого рода задачах используют методы PCA и прокрустова вращения (ищите ссылки на Николаса Сидриополиса и Майкла Кубисту), так как Фурье не может разделить схожие спекты от аграгатов, а эти методы вначале разделяют источники шума территориально, а только потом по сравнению его по спектру или по подпространствам (сигналов) принимают решение о типе шума. Топикстартеру: смысл как раз в том, что Вам необходимо иметь несколько разнесенных микрофонов вокруг несколькиих источников шума, и, прокрустовым вращением Вы вытаскиваете шумы каждого агрегата в отдельности, а там дальше - все просто. На данный момент этот же метод применяется для шпионажа и подслушки - в больших помещениях типа кафешек вешается куча микрофонов и на основе непрерывной записи их сигналов можно получить очень хороший звук каждого говорящего из неразличимого мессева общего фона - у меня есть реальный опыт использования таких методов, и даже с десяток статей по этой теме, утверждаю не по наслышке. Еще топикстартеру: если нужен серийно выпускаемый софт, который решает Вашу задачу (с железом тоже можно помочь, только не серийное), обращайтесь в личку.

лично принимал участие в двух похожих проектах, готов поделиться опытом. 1. плавуны - хотели точно знать положение своих конечностей и свое реальное положение... Решал так: на каждую конечность и за спину - по блочку с 9DOF - 3D акселометер, 3D магнетометр, 3D гироскоп. Все вместе в реальном времени объединяется. Удавалось очень хорошо скорость с статистику взмахов получать, но положение плавца под водой (и скорость) плыли довольно сильно, бывало, на 25м дорожке ошибка доходила до 70см. Решали втавлением магнитов в дорожки - точность поднималась, но не сильно. 9-ый арм еле-еле справлялся. ГПСа на борту, то бишь, на плавце не было. 2. траекторию движения и углы наклона рюкзака по лесу. Так как мне достаточно было апосториори получить все эти данные, я брал все, что есть с ГПСа, с нескольких (сколько было не жалко) 3D акселометров, 3D магнетометров, 3D гироскопов, а потом по наименьшим квадратам угадывал аппроксимирующую прямую. Относительная точность положения рюкзака при прохождении контрольных точек не была хуже 1м, углы вычислялись обычно с очень хорошой точностью (около 1 градуса) но, изредка, всплески ошибок составляли 10 градусов. Пока не понятно отчего. Для обработки данных апосториори 100 тысяч точек ГПСа и около 150 миллионов значений акселометров и гироскопов я гонял 6-и ядерник несколько часов.

На сайте http://www.netlib.org/lapack довольно много и понятно написано о структуре лапака. Именно его функциональность поддерживает MKL. Но в MKL есть еще некоторые функции, которые находятся за пределами лапака. Кстати, во времена Уилкинсона об алгоритме, который запрограммирован в DSYEVD еще ничего не было известно - как я помню, DSYEVD только в середине 80-х придумали какие-то американцы с незапоминающимися китайскими фамилиями. Различие DSYEVD и DSYEV в том, что первый требует дополнительно две копии матрицы в памяти, но имеет меньшую (в разы) арифметическую сложность. зато с кешем все в этом процессоре печально - скорость доступа к общей памяти очень маленькая, по сравнению с фпу. Вот и произошло то, что Вы видели. фортрановский манер. MKL состоит из нескольких частей - BLAS, LAPACK, FFT, Sparse, все остальное. Про все остальное - не знаю как сделано, в основном, из-за того, что мне это не нужно. LAPACK написан на фортране, вернее взят именно тот вариант, который лежит на лапаковском официальном сайте и перекомпилирован. Для С интерфейса написаны враперы. Сам лапак очень интенсивно использует BLAS - вот они-то написаны частично на ассемблере, частично на С, и, как мне известно, фортрана там уже нет. В них-то зарыта вся оптимизация по кешу, конвейеру и многоядерности, более того, МКЛ имеет разные ветки одной и той же функции в зависимости от типа процессора. FFT написан на С, но имеет оптимизации по кешу, конвейеру и многоядерности, частично писанные на ассемблере. Sparse - ядро алгоритма разрабатывалось изначально на фортране Саадом (Миннеаполис) и Болхофером (тогда еще Берлин), потом в 2002 это перенял Шенк (Базель, сейчас Лузана), являющийся ответственным за это в настоящее время, все это недавно было переведено на С, интенсивно дергает BLAS, но имеет несколько специализированных кеш оптимизированных алгоритмов для работы с целочисленными векторами. Не бойтесь использоовать лапак с сорсов с официального сайта нетлиба - его используют милионы пользователей и он оттуда самый актуальный, самый безбагнутый, и самый быстрый, конечно если Вы лапак скомпилили всместе с самыми быстрыми бласами. Бласы с нетлиба - самые неоптимальные по скорости, вот тут надо найти что-то максимально дешевое или бесплатное, но и максимально быстрое. Как я говорил, я использую ACML - как очень хорошую и бесплатную альтернативу MKL.

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

начнем здесь. Вы говорили, что поместили все в фпустек, а именно факторизацию этой трехдиагональной матрицы, заданной главной и поддиагоналями. На каждое собственное значение Вам надо однажды прогнать факторизацию по этой матрице - N*2 обращений по памяти, и около 6*N арифметических операций. Далее так надо сделать для каждого собственного значения. Вот у Вас уже есть N*N*2 операций доступа к памяти. Итак, тут алгоритм на стек и только чтение по памяти. Правильно ли я понимаю, что мы с Вами говорим о методе DSYEVD, а не о DSYEV и DSYEVX? Первый эффективен именно в блочном виде, а второй в блочном почти не реализуем если не считать приведение матрицы к трехдиагональному виду. Я все-таки склоняюсь, что мы говорим именно о DSYEVD... Почитайте пожалуйста, статьи James Demmel и Juan Molera где-то в конце 90ых и начале 2000 они оба очень много об этом на конференциях говорили как можно выполнять эту факторизицию блочно с последующим вычислением собственных векторов. Так как я многое тогда прочитал и сейчас лениво перечитывать, найти на раз не смогу, да и немного лениво, но я точно помню, что они хвалились, что именно так надо делать и в лапак они это встроили. Еще им какой-то аспирант из Вупперталя помогал, но уже не помню его фамилию. во, ну наконец-то, а теперь давайте обсудим ее - эту перестройку, так как она-то как раз имеет кубическую сложность по операциям и квадратичную по обращению по памяти. Вы здесь обращения к кешу процессора оптимизировали? Если нет, чесно будет совершенно безразлично как Вы на ассемблере что-то там соптимизируете, так как скорость обращения к памяти в десятки раз больше скорости обращения к кешу второго и третьего уровня, а он, в свою очередь, проигрывает в разы по скорости первому кешу... Матрица размера 25 уже не поместится в кеш первого уровня, а матрица размера 250 в этом алгоритме уже не поместится в кеш второго уровня... И еще, можно поинтересоваться попросить Вас сделать такой примерчик: возьмите Ваш хорошо оптимизированный алгоритм, полностью сидящий в ФПУстеке, прогоните, пожалуйста, на Вашем компьютере, и посчитайте, пожалуйста, достигнутые гигафлопсы. Теперь возьмите две большие (под 10к) матрицы и вызовите DGEMM из MKL с включенной поддержкой многоядерности (она у него по умолчанию), и сравните гигафлопсы. У меня разница на шестиядерниках зачастую в 10 раз зашкаливает, а ведь DGEMM-то в память обращается, вроде должен быть медленнее.

Спасибо, похоже, это то, что мне надо. Также благодарю всех советовавших! Еще вопрос про ультразвук - численные методы - не пугают, правильно ли я понимаю, что для того, чтобы повысить точность на ультразвуке, мне достаточно взять что-то типа такого и фактически перепрограммировать его частоту и способ снятия данных? Еще о задаче - это предкалибровка 5 осевого CNС + распознование положения детали на столе CNC.

Всем привет, есть несколько точек внутри куба с ребром около полутора метров. Надо очень точно измерять между ними расстояния. Готов пока рассмотреть эти точки неподвижными. Ультразвук не подходит, точность 5мм, а надо примерно 50мкм. Вроде лазерные датчики должны подходить, но, на раз я не смог понять что да как. Если кто знает, посоветуйте, пожалуйста, куда и на что смотреть! Спасибо ИИВ

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

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

простите, пожалуйста, что я не понятно выразился, там именно LVDS, но по типу сигнала очень похож на SPI, о котором я и упомянул. Битрейд 250-400МБит/с, общаются когда два, когда и 4 стратикса 3-и и 4-ые, через несколько терасиковских HSMC удлинителей, с суммарной длиной около полуметра. Ножек лишних нет, реально общаюсь по 4-м клокам и 28 лвдс шинам, то есть реальный трафик около двух гбайт в секунду, но каждый клок живет отдельно от другого. В основном задача возникла от того, что скоро надо будет делать броадкаст - одна борда шлет, остальные 3-7 слушают, но, сперва, хочу потренироваться на кошках - то есть отточить все на паре аппаратов. EDIT рядом с приборами иногда случаются ЕМ помехи, и, похоже, даже LVDS не помогает... На счет полуметра - соврал - там где-то 25см всего-то.

вот как раз фетч по памяти и делает свое черное дело - в МКЛ-е блочность под процессор соптимизирована (не зря же в НН рабы сидят), а в голом лапаке - этого нет вообще. В атласе эта оптимизация происходит автоматически при инсталляции, бывали годы, когда атлас компилился больше суток!!! EDIT: я понял о чем Вы! Вы вычисление сдвинутого Холецкого в методе разделяй и властвуй для тридиагональной симметричной матрицы в стек засунули... и, проиграли по скорости МКЛю, так? Так и должно быть! Вам надо на каждое собственное значение по несколько таких факторизаций выполнить, то есть по памяти Вы 2*N*N*K раз обратитесь, где N - размерность матрицы, K - среднее число итераций на каждое собственное значение. Если бы Вы одновременно итерировали бы несколько (B) собственных значений, то обращений по памяти у Вас было бы всего-то 2*N*N*K/B при том же количестве арифметических операций (7*N*N*K), но, так как доступ к памяти занимает много тактов при больших матрицах, это время будет определяющим в этом алгоритме, Вы бы получили решение несравненно быстрее.

я с этими оптимизаторами давно тягаться перестал, разве что на ГПУ еще иногда какого-нибудь Волкова (это демелевский вечный двигатель-программер) как-то сделал, но потом он таки дожал свою версию dgemm. Я думаю, что основная причина, почему у Вас получилось медленнее, в том, что в Лапаке и иже с ними есть блочная работа с матрицами. Вот представьте, делаете Вы QR, но не хаусхолдерами, а блочными хаусхолдерами, в этом случае, если Ваша матрица не лезет в кеш процессора, блочный метод за одного хаусхолдера обращается один раз ко всей памяти матрицы, а скалярный - в К раз больше, где К - размер блока. А время обращения к памяти - в сотни раз больше времени одного флопа, все равно на чем он сделан. То есть если у Вас будет блочная не ассемблерная версия Вашего DSYEVD то у Вас думаю тоже все получится. Почитайте о проекте ATLAS - там об этом много и понятно написано. Еще, когда Донгарра писал все эти бласы, они затачивались на Крей, где сложения и умножения шли парами. На данный момент это все тоже сидит в современных процессорах, поэтому, можно так написать на ассемблере, что не заметить, что два умножения (еще и зависимые по аргументам) идут друг за другом, а это очень плохо для производительности так как АЛУшки простаивать будут. EDIT: а как Вы смогли все в стек засунуть - у Вас матрица такая маленькая? Если да, то тогда все из-за последовательности операций.

Для Ваших задач есть куча бесплатных и официальных альтернатив: 1. ACML точно работает в вижуал стидии, с мингвом и сугвином не смог скресить, 2. ATLAS ( http://sourceforge.net/projects/math-atlas/ ) работает под сугвином, не смог скрестить под мингв и вижуал студию, в любом случае потянет за собой лапак, 3. LAPACK (http://www.netlib.org/lapack) с сорсов компилится везде, на сайте производителя есть длл для всего. Не оптимизирована по скорости, то есть на шестиядернике может продуть раз так в 20 остальным библиотеками, 4. GotoBLAS и GotoLAPACK (вроде брать можно бесплатно, но продавать - нельзя из-за ГПЛности), ни разу не пользовал, но слышал от "академиков" восторженные отзывы. правда как только Вам нужна работа с разреженными матрицами, то тут будет танец с бубном и этих библиотек Вам не хватит, но у меня есть своя спарсбиблиотека, часто делающая поделки Шенка (то что в МКЛе) поэтому меня это не сильно волнует :)

ACML и не только на амдшниках работает кстати :) да, будет, хотя я не проверял :) но именно сошки .so под линуксом именно так и работают - под виндой МКЛ ни разу не пользовал, но, думаю, там все то же самое. Скажите, какая функциональность из МКЛя Вам нужна, я скажу чем Вам эту библиотеку можно заменить!

Всем привет, есть два аппарата, общающиеся по скоростной линии по 3-м ногам аля SPI - первый аппарат шлет клок по первой линии всегда, второй аппарат непрерывно посылает на каждый клок один бит информации по второй линии, а по третьей ноге первый аппарат сообщает второму о том, что дошло ли и что дальше посылать. Оба аппарата общаются через плиски. Нужна максимизация скорости потока от второго аппарата первому, и минимальное время на исправление ошибок, так как память плисок не резиновая и на передачу не хочется использовать кучу плисоресурсов. Сейчас реализовано все так - второй первому шлет пакеты по 9кбит, после этого пакета идет CRC, если пакет пришел битый, то происходит запрос на перепосылку пакета. Запрос возникает примерно в 20% случаев, на декодирование СРС на приемнике и старт-стоп пакета я теряю примерно 300 тактов пересылки (3%). Если уменьшать размер пакета - то оверхед увеличивается, если удлинять пакет - вероятность битости данных увеличивается. Хочется все-таки улучшить проходимость пакетов. При детальном анализе получилось, что почти всегда битость пакета - это либо 1. один ошибочный бит, 2. один пропущенный бит (клок пропустился), 3. один случайно возникший дополнительный бит в начале передачи. Скажите, пожалуйста, есть ли способ кодирования сигнала, который бы позволял бы исправить эти типы ошибок? Спасибо ИИВ

правильно, а дополнительно, хочу сказать как обычно решают задачу поиска максимального собственного значения у такой матрицы: 1. матрица маленькая - эдак до 100 строк/столбцов. Влоб ее вычислить, вызвать лапак, радоваться. 2. матрица средних размеров примерно до 5000 строк/столбцов. Влоб ее посчитать, дальше либо методом простой итерации, либо методом Ланцоша посчитать ее максимальное собственнное значение и соответствующий вектор. 3. матрица больших размеров (вся в память не влезет). В этом случае, скорее всего Вы как-то можете сохранить V, и можно программно реализовать умножение матрицы в форме A = V'*V - V'*(S*V) -(S*V)'*V + (S*V)'*(S*V) на вектор без вычисления A. В этом случае, достаточно методом Ланцоша получить искомый собственный вектор. Про Ланцоша в Википедии понятно написано. Про лапак - на http://www.netlib.org/lapack если что не понятно, спрашивайте, постораюсь помочь.

хорошая библиотека, но, если Вам только функциональность лапака нужна, и, особенно если у Вас АМДшный процессор - проще использовать бесплатный ACML. Он последнее время идет с частичной поддержкой ГПУшных ускорителей, что, тоже может сильно помочь. По лицензии - покупается только на рабочее место, при продаже Вашего законченного продукта Ваш заказчик не должен на МКЛ разоряться, но, если Вы продаете библиотеку, которая зависит от МКЛ - то таки да, заказчик должен будет купить себе еще копию МКЛя. Еще есть АТЛАС - Automatically Tuned Linear Algebra Software, которая, было время, делала MKL по скорости как тузик грелку, но, сейчас, увы, уже нет - толпа наших программистов с Нижнего и Новосиба сделали свое черное дело.

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