Ruslan1

Ну, QNX я лет 10 не пользовал, но честно говоря не вижу что из вопросов касается именно QNX, а не любой RTOS. С этой позиции и выскажусь: Практически это не соответствует действительности. Теоретически я могу себе представить как эти единицы процента ресурса бьют по энергопотреблению, но практически скорее могу представить себе обратную ситуацию, когда грамотная диспетчеризация и пользование сервисов RTOS позволяет оптимально собрать систему и тем самым снизить потребление. странное мнение. Как человек, делавший батарейную технику на базе RTOS (юкос и его гуи), никогда не сталкивался с подобными проблемами. Экран обновляется по мере поступления новых данных и из соображений эргономики а никак не от "степени интерактивности". Это относится и ко всем остальным задачам: обработка следует за событием, просто в RTOS это время до начала обработки не резиновое. Кажется. :)

Документация на pic24.ru абсолютно самодостаточна, но мне хотелось чего-нить печатаемого. Сварганил я для себе такой файл, вот как раз принтанул и перехожу в горизонтальное рабочее положение на диванчике....

Кстати да. На Digi-key это семейство представлено 41-й позицией, но на складе ноль. А это основной поставщик для разработок, быстро,надежно и дешево. то есть для меня это аргумент доставабельности- если у дижикия нету, то это звоночек. Да и фиг его знает, появилось и пропало. А майкрочип еще ни один камень не бросил, все можно найти. (ну или почти все:)

Это что, выбрать новое семейство чтобы к нему RTOS подошел? :) Не будем обсуждать железо, я его уже выбрал и надеюсь что скоро плату увижу. А спокойной жизни выбором железяки не добится, оно как раз часто масштабироваться может: то ног надо больше, то какой экзотический интерфейс.... Ну и точно не хочется изучать и применять RTOS с плохой портируемостью (если я правильно Вас понял, этот MQX для фрискайлов заточен). Написал я ему. Собственно не вижу ничего плохого если эту документацию можно купить, то есть без халявы. Но тут два момента: а есть ли она вообще и если есть, то как автору продать ее более одного раза. Какой-нить NDA подписать можно, но проконтролировать его исполнение а тем более организовать какое-то преследование нерадивых покупателей IMHO совершенно нереально. Вот я и думаю что автор и не писал и не будет это писать, пока сам не захочет или какая-то контора не оплатит ему эту работу. Альтруизм это хорошо, но кушать все равно хочется.....

почти совсем выбрал TNKernel, но может кто-нибудь может подсказать: 1. Документация. Где брать актуальную документацию? с самим ядром все ясно, есть свежие версии в свободном доступе, а вот документацию нашел только 2006 года (tnkernel-user-guide-2-3.pdf). Может быть автор ее продает? я согласен и купить :) Ну и конечно вопрос по литературе, может уже книжки какие издали про этот TNKernel ? 2. Популярность. Я вижу на электрониксе целый подфорум по freeRTOS, почему такого по TNKernel нет? сильно менее популярна или просто вопросов меньше?

Ага, спасибо за совет. Сам после нескольких часов чесания интернета понял что нужно выбирать между FreeRTOS и TNKernel. Теперь надо найти какие-то аргументы в пользу одной из них. Можете чем-то аргументировать, что в TNKernel лучше чем в оппоненте (FreeRTOS)? Мне кажется, что в TNKernel механизмы взаимодействия процессов богаче, но не уверен. http://www.pic24.ru выглядит как неплохой русскоязычный саппорт для TNK. Я не понимаю, почему Microchip не говорит ни слова о TNK, хотя FreeRTOS у них в списке рекомендуемых опреационок есть. В то же время на майкрочиповском форуме нашел следующее (обсуждается криво работающий под FreeRTOS аппнот): и еще, уже про TNK: Ну, с таким недостатком TNK, как плохой инглиш саппорт, можно смириться, наоборот лишний повод добится нужности если вдруг к потенциальным противникам попадет :) Завтра попробую составить табличку сравнения, не могу просто лотерею устраивать, буду думать что не угадал с выбором :) Цель стоит глобальная- сесть на выбранную RTOS и не сползать с нее хоть годик-другой, таская за собой по разным проектам.

Здравствуйте! Если тема уже обсуждалась, пните меня сразу в нужную сторону. Есть новый проект, где есть вроде бы мощное железо (PIC32, то есть MIPS32 M4K ядро, много ROM и RAM). Функционал несложный, но разношерстный и руки чешутся прикрутить это все в виде отдельный задач многозадачки (кнопки, дисплейчик, внешние устройства хранения, несколько измериловок иногда даже с независимыми хардверными интерфейсами и т.п.). В активе имею опыт серьезного использования микриумовского юкоса (с ихней же графикой) на атмелевском ARM9, впечатления самые лучшие остались. Но тут засада в том, что коммерческие RTOS очень сильно не приветствуются, скажут мне "пиши совсем без RTOS, нечего морду баловать" и будут правы. Поэтому ищется что-то что можно использовать официально бесплатно. Озвучу хотелки по пунктам: 1. RTOS с портом для PIC32. 2. официально бесплатная 3. документация на английском или хоть на русском. Помнится, с большим удовольствием Лабросса читал.... 4 доступна в исходниках. Несколько раз микриум приходилось под себя править- наверное повесился бы без исходных текстов. Идеал если так и подключается к проекту в виде компилируемых исходников. 5. Нужный функционал- наверное тот который стандартно все RTOSы дают: приоритеты, семафоры, сообщения.... . Встроенная поддержка сложных интерфейсов не нужна, все равно их не хватит, свое писать проще чем в чужом копаться. 6. Похожесть по логике работы на микриум (если есть выбор), я быстрее разберусь. 7. Не экзотика. Надоело быть первопроходимцем там где это не нужно. На данный момент рассматриваю FreeRTOS, но может быть еще какие-нибудь варианты хорошие есть?

Доброго времени суток и всех с прошедшими праздниками! :) Я никуда не пропал, тема действительна для меня актуальна но так как писать нечего то не хотел просто поднимать тему раньше чем будет что сказать. Сейчас знаю что в конце февраля у меня запланировано это бодание с новым прибором в который попробуем эту функцию влепить, тогда думаю будут и новые вопросы и новая информация. До тех пор я в-общем-то загружен другим и вряд ли вставлю что-нибудь больше чем "ага!" или "ну кто бы мог подумать!" в дискуссию. :) С точки зрения моей конкретной задачи мне хочется знать, что частота синусоиды изменилась при ее изменении на величину 0.001 Hz, то есть вычисленная частота для этой новой синусоиды будет отличатся от частоты для старой синусоиды. Ничтоже сумняшеся я продолжаю называть эту определяемую разницу частот "Resolution", и переводите как сочтете нужным :) В исходном упомянутом в первом моем письме устройстве оговаривается, что данный резолюшн возможен только при "хорошем" соотношении сигнал/шум, может быть тот самый CRB и имеют в виду. Пока что я понял что в принципе не обманывают, но все еще не понимаю какой алгоритм использовать. Буду пробовать из того что здесь уже озвучено, ну и может еще чего нового всплывет за следующий месяц, раньше все равно пробовать не начну ни на модели ни тем более в железе. FFT4096 и еще что-то, вот это что-то и попробую найти.

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

Я уже признал в соседнем посте что с улавливанием намеков у меня туго. Понял. Можно. Вы знаете как это можно. Я ж разве против? Прочитал, но не понял. То есть у меня есть линейка с рисками 0.001 Гц, а я с ее помощью измеряю с погрешностью 0.84 Гц, так, что ли? Извиняюсь если резко звучит, но мне это непонятно. А хочется понять, чтобы не ставить перед собой недостижимых задач, которые в дейчствительности никто не решал. Иду читать про погрешности и линейки. PS вот так и рушаться стереотипы..... жил себе не тужил..... Так это они что, имеют в виду что на полученной ими спектрограмме палка установлена с точностью до 0.001 Гц (расстояние между соседними палками не сообщается, просто координаты этой палки известны с указанной точностью), а вот расстояние между показываемым значением и реальной частотой - не более чем 0.84 Гц ? Это правильно? Или опять мусор в голове?

Теперь понял, спасибо. А вот намеков не понял, отупел совсем. Это был мой вольный перевод иностранного слова "resolution". А под точностью я раньше подразумевал "accuracy" и не удивлялся тому что это разные вещи, причем между ними всегда есть определенное соотношение. В-общем, просто сообщаю о задаче что знаю, не впадая в переводческий грех: Measurement Resolution : 0.001 (Hz RMS) Accuracy Basic: ±0.013% of reading (осмелюсь перевести это в герцы, зная что максимальная читаемая величина 6500Гц : ±0.84 Гц )

Извиняюсь, я подумал что вопросы риторические и не нуждаются в ответах. 0. "Нет, не переходы. Считается целое число периодов входной частоты". считать не переходы а целые периоды. Если имеется в виду вычисление методом подсчета однотипных (только задних или только передних) фронтов откомпарированного сигнала- Да, согласен, в комментариях не нуждается. Это точнее засчет исключения погрешность от сдвига на постоянную составляющую. Но не более. Сейчас попробую накопать тему на которую вы ссылались, может имелось в виду что-то похитрее. Каюсь, не искал и соответственно не смотрел. Думал что тривиальный счетчик, но сейчас посмотрю чтобы не оставить без внимания может быть хороший метод. 1. полностью согласен что "Если есть нестабильность опоры, значит, как по теории, складывайте погрешность метода и погрешность опоры". Не нуждается в обсуждении. 2. "Отчасти вы правы, 0.001 Гц для метода захвата в вашем случае это не точность и не разрешение, это погрешность измерения (максимальная ошибка), т.е. ошибка результата измерения будет не хуже". Тут большое поле для флейма спора, потому что у меня несколько другое понятие о "максимальной ошибке" чем разрешение считающего счетчика, я обычно вкладываю в ошибку все то что вы сами перечислили в предыдущем абзаце ("погрешность метода и погрешность опоры"). Но все это абсолютно не относится к топику, поэтому с моей стороны продолжения не будет.

нету у меня много секунд, у меня сигнал затухающий. Я так понял что blackfin имел в виду обработку однажды ссобранных данных, два fft но второе применяется к той же изначальной выборке но уже обработанной. То есть на все-про все я имею одну исходную выборку из которой все и решаю. Да, наверное для красоты и ясности нужно было картинку сигнала прямо тут привести. Это после того как струну дернули она так вибрирует. Сколько миллисекунд используется для выборки не знаю но получается что-то никак не дольше 300ms, даже может 200. Это хорошо ложится на 4096 точек и обычный средний 24-битный АЦП Изготовители написали, что это сигнал снятый с "Good Sensor with a Wider Range (200 to 6500 Hz)". Это из того документа, на который я ссылался в самом первом письме. Спасибо! не пройду мимо! На подобное и надеюсь, что вопрос не нов и где-то уже все есть...... Но уж никак не думал, что "Department of Music" интересуется подобными точностями, даже если в универе. наверное математикам в общаге спать мешали :)

Не, теперь уже спать буду. много вариантов уже предложено, ну хоть один-то сработает :) Если нет- то конечно вернемся в прошлый век, периоды считать. Я сам против использования тяжелой артиллерии при отстреливании мелких пернатых, но тут мне кажется ЦОС на своем месте будет, да и некоторые дополнительные вкусности дает в виде измерения амплтитуды и отношения сигнал/шум. Это может предсказать отказ до выхода из строя (датчики часто вмурованы в стены во время строительства или болтаются на дне морском или еще где в глубоких скважинах и если их замена может прогнозироваться и осуществляться планово а не аварийно- это прямо праздник!). Лично я хочу применить ЦОС, но не знаю как (но теперь уже имею конкретные пути для раскопок ;). О! точно все-таки юзают они FFT! они там еще в этом приборе и амплитудное значение и SNR считают! и все это на базе одной выборки за время одного измерения (каждые 2 секунды новое значение считают, а вроде бы чаще возбуждать струну не рекомендуется).

Благодарствую! у меня путем несложных калькуляторных вычислений на уровне интуиции изначально крутилось что-то валенковское типа "два раза применили FFT4096 к входному реалу, уж больно в цифры хорошо попадает". Но интуиция на пустом месте дело бесполезное.... буду копать в указанном направлении. Хотя какое тут направление, готовый алгоритм, сразу кодировать можно :) 2 All: Благодарю всех за дельные советы! Вы мне показали что такое возможно и дали даже больше одного варианта как это сделать. В-общем сказал начальству что умные люди сказали что оно не бред и реально, по крайней мере есть методы :) Для проверки даже заложим в прототип (в котором по-старинке считать собирался) какую-никакую вычислительную мощность в виде dsPIC и на всякий случай внешнего RAM (хотя надеюсь внутренних 16К хватит) и вперед. Ну и дополнительные три недели только на проверку и реализацию этого алгоритм затребовал :) Разумеется сначала попробую на компьютере прогнать снятый с АЦП сигнал (такие частоты и саундбластер возьмет), потом уже в железо перекину. Еще раз спасибо! Уверен что появятся новые вопросы- так я ж молчать не буду.... Но это уже после пьянки празников. У нас тут обычно и католическое Рождество мимо не проходит, чувствуется близость запада.....

Это переходы через ноль считать (zero-crossing counting method)? Не, неинтересно. Так работало старое поколение таких измерителей, их ахиллесова пята это шумы из-за которых лишние переходы. Кстати там разрешение на порядок меньше всегда анонсировалось (0.01Гц). А про точность 0.001 методом захвата- это вы я так думаю погорячились. Ну во-первых нужно переименовать "точность" в "разрешение" (ну или говорить о стабильности 0.15ppm, что за АВР такой?), а во-вторых при 6.5 кГц это будет 23 пикосекунды разница в длительности периода. 44 наносекунды за 1950 периодов (300мс и 6500Гц). это 22 МГц тактирование таймера чтобы один такт набежал. Ладно, тут наверное можно и поверить, уж это AVR наверное может. Спасибо, попробую погуглить в этом направлении. Но опять же смущает заявленная у них точность 0.013%. Я думал что любая апроксимация может увеличиить только разрешающую смособность, но не гарантировать точность. А у них получается что точность на уровне 1/7700, то есть почти в 4 раза выше чем если за точность брать расположение палок исходного FFT. Но тут наверное хитрость в том что точно известна форма искомой функции- чистый синус и это может сыграть. Я вот еще подумал, если после FFT я знаю узкий диапазон и делаю цифровую фильтрацию, отсекая все выше и ниже, может это помочь при дальнейшей обработке? но вот непонятно что за бработка такая.... Спасибо за подсказку, завтра про сплайны почитаю. А насчет нейронных сетей- не та это техника. Это полевой прибор, не для лабораторий. Думаю все сделано по максимуму дубово и без новомодностей. :)

Здравствуйте! Помогите пожалуйста, спать не могу, все думаю...... Накопал в интернете, не понимаю как сделано. а хочется понять и применить методу. короткая листовка: http://www.campbellsci.com/documents/produ...es/b_avw200.pdf полный мануал: http://www.campbellsci.com/documents/manuals/avw200.pdf Прибор определяет частоту синусоидального сигнала, который может быть в диапазоне 100 - 6500 Гц, с разрешением 0.001Гц и точностью 0.013% от измеренной величины. Указано что используется 4096-точечное FFT. Интересно, что еще кроме упомянутого FFT применяется для получения такого разрешения по частоте? Как это может быть сделано? Взяли FFT, определили частоту грубо, потом детально обнюхали область вокруг найденной частоты, получили частоту точно? Что абсолютно точно известно (это физика процесса): 1. Полезный сигнал- честная одночастотная синусоида (дернули струну, потом ищут ее частоту собственных колебаний. то есть это затухающее колебание механической струны, которое преобразовано в электрический сигнал). Шумы возможны. 2. Общая длительность исследуемого сигнала доли секунды (ну пусть 300 ms) Что говорит изготовитель (интересный текст и какие-то картинки начинаются со страницы 85, еще есть спецификация на странице 9): 1. The AVW200 uses an audio A/D for capturing the sensor’s signal. The number of samples acquired in this period is 4096 points. A Fast Fourier Transform (FFT) algorithm is used to create a frequency spectrum. 2. the spectral analysis gives improved frequency resolution (0.001 Hz rms) during quiet conditions. 3. the AVW200 Fourier transforms the recorded response and analyzes the resulting spectrum to determine the wire’s resonant frequency. This analysis also provides diagnostic information indicating the quality of the resonant-frequency measurement. 4. Measurement resolution: 0.001 (Hz RMS) 5. Accuracy basic: +/- 0.013% of reading. 6. DF measurement time between 1.6 to 1.8 second 7. SYSTEM: PROCESSOR: Hitachi H8S 2324 (16-bit CPU with 32 bit internal core), MEMORY: Either 128 or 512 kbytes of SRAM; 2 Mbyte of OS Flash 8. частоту проца не знаю, но пишут про дополнительный ток потребления во время измерения 27mA@12V. Судя по даташиту проца получается что используется он по максимуму, 25 МГц тактовой. Сразу оговорюсь, как учили меня 20 лет назад в институте так с тех пор ни разу ничего толком кроме чужой математики для ЦОС не применял. В-общем валенок и может быть это нужно в раздел для начинающих перетащить если что-то понятное любому ЦОС-нику спрашиваю.

Ну не знаю, я подсел на AD7792 лет 5 назад, когда они только появились. про внутренний ИОН пишут: Internal Reference Initial Accuracy : 1.17 V ± 0.01% Internal Reference Drift: 15 ppm/°C max по-моему достаточно точно :)

Большое число современных майкрочипов имеют аппаратную внешнюю параллельную шину, называется Parallel Master Port (PMP). А в сочетании с мультиплексированной периферией (то есть любую аппаратную периферию ты можешь подключить на любую выбранную ногу из списка, например для 28-ногого корпуса это 15 конфигурируемых ног) вообще песня для разводки плат. Сегодня закончил один проект на dsPIC33FJ64GP802 - большое удовольствие получил..... И 40МИПсов 16-битных тоже ого-го...

Прошу извинения, имею дополнение к вышесказанному: С этой ночи нужный мне софт запускается и нормально работает также и под Windows 7. Причем я ничего не менял, между неработой и работой было несколько перегрузок, 1 день отдыха и больше ничего. Так что извиняюсь за ложное сообщение, оно таки работает под Windows 7 Pro и последней версией FireFox. Автор софта мне написал что под Вистой пробовал и все работает. Так что думаю скорее всего без проблем и на семерке должно бегать, а не работало из-за чего-то локального на моей машине.

Нашел где засада. Редактор не работает под Windows 7 Pro, которую я использую. Все работает если запустить под Windows XP. Странно, думаю что проблема с полномочиями, но не понимаю где (софтину запускаю с правами администратора). В-общем, проблема решена, тема закрыта.

Приветствую! Имеется в виду новая версия софта, объектно-ориентированная, брал отсюда: http://canopennode.cvs.sourceforge.net/viewvc/canopennode/ Сам CANopenNode запустился, вопросов нет (процессор серии dsPIC33F). Теперь хочу профиль подредактировать под свою задачу. В комплекте есть папка Object_Dictionary_Editor, в которой web-приложение, написанное для Mozilla FireFox. Установил Мозиллу, запускаю- вижу форму, на которой непонятно что вводить. В документации совершенно другие кнопки упоминаются, которых в форме просто нет (например: "If you want to start new project, press 'New Project ...' button, then there are three possibilities", а я эту кнопку на форме не вижу.) Ладно, залез на сайт, попробовал форму прямо с сайта а не с моей локальной машины, там вообще бред: http://canopennode.sourceforge.net/_config/device.xul Пробовал и самый последний FireFox, и старую 2-ю версию для которой это приложение писалось- вид экрана не меняется. :( Поиски в интернете ничего не дали. Помогите, пожалуйста, как мне файл конфигурации сгенерить?? неужели ручками править, при наличии вроде бы предназначенной для этого программы...... :(

У меня пока что профибас вторичен, то есть будет делаться софтово по остаточному принципу. Сейчас все силы брошены на CANbus. Я под шумок заложил в новой ревизии платы новый проц из dsPIC33F линейки: 28 ног как и у предыдущего PIC18F, много МИПСов, два сериалпорта кажется с поддержкой RTS, два SPI, конечно CAN, 16K RAM, аппаратное вычисление бита четности и даже CRC по полиному, DMA, в-общем приготовился морально как мог к софтописанию профибасовскому. А я десяток лет под МОДБАС кропал. Начал смотреть профибас ДП- те же еггсы только в профиль :) Я честно говоря не знаю, дает ли это уверенность в корректности реализации протокола? насколько я понял, сименс сплошь и рядом пользует протокол внутри протокола, то есть профибас не самоцель а транспорт для другого протокола который уже и таскает данные. Но это мое прочтение по диагонали сименсовских проспектов, могу жестоко ошибаться. Я для реализации пользую профибас-ДП описание, не сименсовское. Простой сенсор не скажу чего, но немного математики внутри наворочено для фильтрации и температурной стабильности. SPI сейчас оба два использовать буду. но не для профибасовых чипов. Пока никакую, я уже говорил что у меня заморожено все (хотя нет, за окном +22). Но вопрос не понял. как это синхронную если там старты-стопы присутствуют в профибас-ДП over RS485 ?

Я занимаюсь похожей задачей, у меня только устройство другое. В данный момент проект заморожен до зимы (каламбурчик :). Относительно профибаса измышления такие: 1. Любой контроллер (если он с мозгами) может поднят DP-протокол. Вопрос только в достижимой скорости. Если ты в состоянии выдержать реалтаймовые требования профибаса к скажем the Maximal Reaction Time, значит эту скорость можешь заявить. Вот открыл свои выписки из стандарта: до 187кбит это 11-60 бит, до 500кбит это 11-200 бит, до 1300кбит это 11-300 бит. Если не уверен или не выходит каменный цветок- то покупай готовый ASIC, лучшее что я нарыл в Интернете это VPC3+C (маленькое потребление и не BGA). Может быть даже сэкономишь в результате время и деньги. 2. Отличие от МОДБАС. Я думаю что ты как правильный инженер юзал RS-485 и RTU :). Тогда учти, что в профибасе готовность к приему после окончания передачи - сразу, то есть никаких таймаутов после окончания передачи. Это недостаток и я думаю что дальнобойность и применимость на шумных линиях хуже чем у Модбаса который сам себе активным передатчиком чистые стопы в линии обеспечивает. 3. Средства отладки. Тут надо платить хоть 200-300 зеленых. Я не нашел халявного DP-Master similator для RS-232 порта, все софты ориентированиы на покупаемое у них же железо. 4. Средства предсертификационного тестирования. Тут опять на деньги попадаешь. Самое нестрашное что я нашел это Profiscript - софт с хардом стоит 1300 евро. И лучше уж сразу такое купить чем сначала дешевые костыли для простого тестирования а потом все равно что-то дорогое чтобы убедиться что ты именно профибас сделал.

Преамбула: делается поддержка протокола PROFIBUS-DP Slave. Раньше это устройство имело только MODBUS-RTU, теперь на тот же RS-485 захотелось PROFIBUS прикрутить. Делается софтово и честно говоря не вижу большой разницы с Модбасом, даже тайминги шины очень похожие. Само собой больших скоростей не достигнуть, где-то до 100k или 200k, никакие мегабиты не светят. То есть на первых порах подключаться к компьютеру буду через тот же RS485/RS232 адаптер и использовать скорости до 115200. Собственно Амбула: К сожалению не нашел в интернете ничего, что можно было бы использовать как простой мастер для посылки-приема стандартных PROFIBUS-DP телеграмм. То есть если с таким мастером работает- то я бы мог сказать что устройство ведет себя как типовой профибасовский слейв. Пожалуйста, подскажите, есть ли такие программы? где скачать? Много лет работал с MODBUS, тут совершенно нет проблем с подобными программами, например любимый мной modscan32. Сейчас параллельно с CAN разбираюсь- для него тоже всякие сканеры есть. А вот для Профибаса не нашел. :( Пока что думаю найти или на крайняк купить что-то вроде Profibus-DP Master Simulator (http://www.hms.se/). Но мне покупная крутизна до 12 мбит избыточна. Хотя может быть это единственный вариант честно проверить- там всякие Энибасы или другой АСИК внутри стоят и честно времянку выпиливают. Но это все-таки второй шаг, первый чисто софтом на низкой скорости через RS232.