sekat
Участник-
Постов
61 -
Зарегистрирован
-
Посещение
Репутация
0 ОбычныйИнформация о sekat
-
Звание
Участник
-
Давайте я не стану вас поучать, а просто выскажу свое мнение. Без иллюстрации работающих устройств с жуткими фотками с бородами проводов и прочих изысков, без гаданий работает/не работает - ведь дело то не в этом, а порассуждать чистА по житейски. А если рассуждать по житейски, то вы предлагаете переложить ВСЕ риски разработки на разработчика. Причем не только его собственные риски (те, которые зависят от разработчика, его навыков, умения, прилежания, трудолюбия), но и риски прямых затрат - инвестиционные (железо вы предлагаете ему покупать самому, макеты для идентификации правильности работы предлагаете придумывать самому, указывая пальцем на XR16V798IQ, при этом оставляя за собой право последнего слова) и даже Ваши собственные риски (а вдруг завтра вы решите продолжать использовать XR16V798IQ, а вдруг ...). Конечно вы как Заказчик вправе выдвигать любые условия, НО я как исполнитель могу заявить - и вам уже тут говорили об этом, что ваши условия неприемлемы. На них нормального разработчика вы не найдете, а того, кого возможно вы и найдете, точно ничего хорошего вам не сделает.
-
Есть действующий макет похожего плеера - генератор сигнала. SD card + ARM + ALtera Cyclone 4 + 2ch DAC + RF синтезатор + IQ модулятор + RF amplif . Проигрывает записанный сигнал до 4 мега отсчетов в секунду, до 12 bit, до 2Ghz. Функционал FPGA для данной задачи не используется (просто транслирует отсчеты со входа на выход - можно заменить перемычками). Подготовить сигнал можно например с помощью NI LabView . Отдам c исходниками С, VHDL, Altium.
-
Для синхронизации сообщений и прочих событий в большинстве случаев достаточно точности SNTP. Точность округляется именно по этой причине - никому для синхронизации событий субмикросекундная точность не нужна. Для синхронизации мгновенных отсчетов нужна микросекундная точность, а этим в Ethernet наиболее перспективным является PTP.
-
Если хотите генерить Sample Values, тогда да. Если только принимать SV от цифровых трансформаторов - тогда оно вам не нужно. Сообщения MMS никак не связаны с PTP синхронизацией, если вы только не желаете привязать с субмикросекундной точностью что-то свое. Видимо только SV генерация, либо прием SV и совмещение его с собственными мгновенными значения аналогов потребуют PTP.
-
1. Не надо удивительных коробок. Используйте SNTP. Сервера с SNTP доступны и недороги. Точность после 485-го вас более чем устроит. 2. Сделайте клиента SNTP на PTP таймере STM32F4. Так будет значительно проще, чем на RTC. 3. 1588 v2 - это микросекундная и субмикросекундная точность. Зачем она вам? Сервера с PTP нераспространены и дороги.
-
Про какой микроконтроллер вы говорите? Если про STM32F4, то: 1. Тактирование PTP таймера происходит от системного клока. Хотя это не имеет значения от чего. Важно, что по факту, частота тактирования PTP всегда асинхронна к истинному времени PTP таймера. 2. Синхронизацию с RTC в обе стороны напишите сами, просто занесением соответствующих значений в регистры 3. Все синхронизации высокой точности (микросекундной и субмикросекундной) внутренних процессов нужно осуществлять от PTP таймера, а не от RTC.
-
Для STM32F4. RTC и PTP - это разные таймеры. 1PPS выход реализуется как переход PTP таймера через границу секунды. Как корректируются часы (как PTP, так и RTC), а так же быть вам мастером или слэйвом по протоколу PTP - определите вы, когда напишите софт.
-
Посмотрите реализацию IEEE 61850-9-2 (SV) . Это то что вы хотите, только у вас частота существенно ниже (а значит проще).
-
1PPS от GPS модуля позволяет синхронизировать внутренние часы на STM32F407 с точностью до ~200нс (нано) . Для этого нужно использовать PTP таймер. Тогда схема синхронизации времени выглядит так. Основные часы - PTP таймер, синхронизируемый по 1PPS в пределах 1 секунды. Через какой-нибудь интерфейс (485, ETHERNET и т.д.) происходит грубая установка времени (дата/минуты/секунды). Периодически время пересчитывается и переписывается из PTP таймера в RTC. RTC используются как основные часы, когда устройство отключено и при включении питания время перезаписывается из RTC в PTP.
-
Очень сильно заблуждаетесь. Как в том, что чип единственный, так и в том, что умение находить - главное достоинство в разработке. Используйте лучше обычный ADC (лучше все же специализированный под Power Manegement АЦП, именуемый по другому - AFE, коих много кто выпускает, в частности и AD и TI) и вы построите гибкое устройство с расширяемым функционалом и контролируемыми параметрами. http://www.analog.com/static/imported-file...Delta-ADCs.html http://www.ti.com/sitesearch/docs/universa...fe&linkId=1
-
FreeRtos проблемы с очередями
sekat ответил yanvasilij тема в FreeRTOS
Посмотрите еще раз внимательно на приоритет обработчика вашего прерывания. По ртосовским правилам он не может быть выше ртосовского, или не используйте вызовы ртосовских функций в этом прерывании - например отдачу семафора. -
И не забыть, что с DMA эта область памяти не работает. Поэтому при прописывании в линкере используемой области памяти нужно сделать так, что бы буфера DMA туда не попали.
-
Да. Проблема преодолена. С Новым Годом! Держите Новогодний подарок: if (ETH->MACSR & ETH_MACSR_TSTS){ // Есть прерывание от "будильника PTP" ETH->PTPTTHR=ETH->PTPTSHR+MyConst;// Переустановить будильник if(ETH->PTPTSSRÐ_PTP_FLAG_TSTTR){// Эта команда очищает не только флаг ETH_PTP_FLAG_TSTTR, но и ETH_MACSR_TSTS. ETH->PTPTSCR|=ETH_PTPTSCR_TSITE; // Ваш код // }}
-
Вот, аналогичная вашему 4-му рисунку, переходная характеристика из FDA Tool (Fc=0.01, Fs=300). Использование С и float в реальном проекте с расчетными коэффициентами дает похожие результаты. Никаких "ступенек" не наблюдается. Мы говорим об одном и том же?
-
Это понятно. Но.. В моем примере из 7 мантисных чисел действующих не менее 3х!. Много это или мало? Сам же FDA tool имеет замечательные инструменты для ответа на такие вопросы. Как для INT, так и для FLOAT. Да и бог с ним с гейном. неправильно считает - не проблема скорректировать ручками. Проблема в том что "Маленькая ложь рождает большое недоверие".