adnega

Конечно можно. Читать RM в районе полей SMS и TS регистра SMCR.

Что значит "прикрутить"? Я пишу в eclipse, функции/переменные подсвечиваются и т.п. Собирается при помощи bat-файла. Ошибки и предупреждения компиляции не подсвечиваются. Нужен некий плугин, но нигде его не нашел (даже на этом форуме спрашивал). Как вариант, можно написать стороннюю утилиту, чтоб парсила файл ошибок и выкидывала их в нужном формате в консоль.

Кста, у меня вызов командой "ATDT8xxxxxxxxxx;".

У меня в исходниках есть ветки обрабатывающие NO DIALTONE, BUSY, NO CARRIER во время звонка (и они реально приходят). NO ANSWER не видел. Правда, использую EAT. Может, версия прошивки не та?

Попробуйте его в режим "System memory" загнать за счет BOOT0=1, BOOT1=0.

В CDC передается пакет с настройками при открытии порта (bRequest == SET_LINE_CODING). Он к вам приходит? Или так.

Дык, вы и меня поймите: раз без ногодрыга I2C гарантированно работать не может, то в моем случае я вообще отказался от аппаратного I2C и сделал все ногодрыгом.

И что мастер может сделать в случае такой "коллизии"?

Если slave в ACK, а master хочет сгенерировать START, то как он это может сделать? Как система оказалась в этом состоянии - совершенно другой вопрос (кто-то проворный тыкал пинцетом).

В плане I2C я предлагаю ногодрыг - простейшее решение, которое не завесит шину в принципе. Я бы не встревал, если бы лет 10 назад не столкнулся однократно с ситуацией ACK от слейва и START от мастера. Долго ломал голову и убеждал себя, что это в нормальной жизни не повториться, но редчайшее событие, напрочь завешивающее обмен не давало покоя. Кста, тогда это была микросхема памяти серии 24xx. С тех пор у меня настороженное отношение к I2C. А обвешивать низкоскоростной обмен, полностью синхронный, дык, еще когда ты монопольный мастер всякими таймаутами по-моему много чести.

Ага. В случае неприятности у изделия нет права продолжать работать как ни в чем не бывало - нужно нештатную ситуацию разрулить. Не знаю как у кого, а у меня на I2C максимум дисплей висит. Поскольку скорости большие не нужны, а интерфейс синхроннее некуда - делаешь тупой ногодрыг в районе mainloop'а и не паришься за прерывания, while(condition), таймауты и т.п. После любых случайных пинцетов изделие рано или поздно прокашляется без лишних арбитров, журналов, алгоритмов сброса. PS. Не пора ли часть сообщений вынести в отдельную ветку по I2C, ибо к данной теме I2C мало относится?

Согласен. При этом периодические сигналы вовсе не обязаны быть синусами, это могут быть очень сложные сигналы, но для них можно определить понятия фазы и разность фаз. Большой класс задач с применением понятия фазы решается для дискретных сигналов. Как пример, умножители/синтезаторы частоты с ФАПЧ - там и сигнал не всегда синус, и частоты не тождественны, ибо ГУН.

Нет. sin(w*t + ф) - это синусоида, w*t + ф - это фаза (график по времени есть линейная функция) w - это частота ф - начальная фаза Разность фаз sin(w1*t + ф1 + фп`) и sin(w2*t + ф2) равна w1*t + ф1 + фп` - w2*t - ф2, где фп` - сдвиг, задаваемый пользователем. Если частоты равны, то разница будет ф1 + фп` - ф2. За счет переопределений ф1 + фп - ф2 можно принять за фп. Поскольку фазы с добавкой +-2*Pi по сути одно и то же, то можно все свернуть в диапазон 0..360 или -180..180 градусов. Формулу megajohn привел во втором сообщении. Но это исключительно для сигналов с тождественно равной частотой.

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

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

А возможно ли получить один и тот же пакет два раза? У таких пакетов последние 4 байта будут совпадать?

Мастер выдал на SCL такт, но в результате помехи slave его не принял, а поскольку slave до этого выдавал ACK уровня "0", то получается, что мастер уже такт для ACK выдал и считает транзакцию законченной, а slave ждет такта для проталкивания ACK. Если не понятно, что это редко, но возможно, и без ногодрыга это не решить, то пусть это останется вне рамок обсуждения данной темы. Проблема не с повторным стартом (который нужен, например, при чтении), а в идущих друг за другом обычных write-транзакций. Попробуйте нарисовать STOP и START с нулевой паузой между ними. У меня получается лишь "1"-иголка на SDA.

Для этого проекта применялся STM32F103RET6. Масштаб "часы" это очень мало. В проекте использовался дисплей TIC154(A) на I2C для постоянной индикации. А сбои вы как-то разруливали? Бывает, slave выдает ACK на линию, а мастеру хочется START устроить, но у него ничего не получится. Тут ногодрыгом нужно slave протолкнуть до 1 на SDA. Я умышленно создавал помехи в линии, чтобы система смогла их обработать. Никто с этим не спорит. Когда все хорошо (нет помех), то и сценарий работы сложно сделать плохим, но ведь бывают нештатные ситуации... в этом случае корректнее говорить о таланте разруливания, а не о кривизне рук, т.к. работают скорее не руки, а голова. Приведенный кусок - это ситуация когда сразу за STOP от предыдущей посылки формируется START для следующей.

Нашел в исходниках "чудесные" строчки (это обработчик прерывания I2C) case TIC_STATE_POS_STOP: I2C2->CR1 = I2C_CR1_PE | I2C_CR1_STOP; tic_state = TIC_STATE_FILL_START; break; case TIC_STATE_FILL_START: s1 = 0; while(I2C2->SR1 !=0 ) s1++; I2C2->CR1 = I2C_CR1_PE | I2C_CR1_START; tic_state = TIC_STATE_FILL; break; Без дикого while(I2C2->SR1 !=0 ) ничего не работало (вроде, I2C переставал функционировать и никак его из этого ступора было не вытащить). Долго возился, но в итоге переделал все на ногодрыг.

Или как-то некорректно ожидается "раскочегаривание" кварцев, PLL...

FLASH_ACR_PRFTEN отключал, а для отсчетов делал усреднение по схеме N-X (8-4). Звук (речь) становился гораздо лучше. FLASH->ACR = 0 | (0 << FLASH_ACR_PRFTEN) | (1 << FLASH_ACR_DCEN) | (1 << FLASH_ACR_ICEN) | (6 << FLASH_ACR_LATENCY); #define MIC_N (8) #define MIC_X (4)

Для однообразности. Иногда TIM_SR_CC1IIF не простая константа. Кста, она тоже что-то типа #define TIM_SR_CC1IIF (1UL) Я не хвастаюсь, но скобочками у меня удобрено сильно.

Вообще, в AVR для битовых условий есть всякие sbrc|sbrs|sbic|sbis. Как на С лучше всего помочь компилятору задействовать эти инструкции?

Это называется "или".

Ага. В пределах байта это сразу бросилось в глаза, а вот в 32 битной маске уже без листочка и ручки не смогу. В боевом коде выглядит довольно компактно и понятно if(TIM3->SR & (1 << TIM_SR_CC1IIF)) Конечно же никаких магический чисел быть не должно. Я везде использую не маски, а номера битов. Да, в условиях появляется лишние (1 <<, зато инициализация удобная TIM3->CCMR1 = 0 | (OC_MODE_PWM1 << TIM_CCMR1_OC1M) | (OC_MODE_PWM1 << TIM_CCMR1_OC2M); TIM3->CCER = (1 << TIM_CCER_CC1E); TIM3->DIER = 0 | (1 << TIM_DIER_CC1IE) | (0 << TIM_DIER_CC2IE) | (1 << TIM_DIER_UIE);