elusive

Схемотехника не моя, но там стоит компаратор вместо триггера Шмитта.

Необходимо измерять частоту и скважность ШИМа в непрерывном режиме. Сигнал обрабатывается МК в модуле CAPCOM (модуль для подсчета длительностей между фронтами). Проблема в том, что при небольшом заваливании фронтов модуль CAPCOM ошибочно щелкает фронты (то есть внутри пологого восходящего фронта он видит ложный нисходящий фронт). Еще ресурсы процессора ограниченны, поэтому каждый период ШИМ не обрабатывается в отдельности. Навскидку есть пара вариантов измерения частоты и скважности сигнала: - Измерять оба параметра одновременно и за n периодов - Чередовать во времени измерение частоты и скважности Подскажите, какие еще могут быть подходы к измерению? Какие подходы дадут меньшую погрешность? Может быть, кто подскажет варианты дополнительной фильтрации измерения. Спасибо!

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

Исходя из даташита я так и подумал. Однако имею проблемы при считывании куска памяти с переходом границы блоков. Записываю файл в два первых сектора (каждый по 256 страниц = 64к). Считываю блоками по 8к начиная с адреса 12. То есть в какой-то момент один из блоков чтения перейдет границу секторов. Вызывает подозрение считывание первых именно 12 байтов второго сектора. При чтении напрямую с этих адресов все правильно как и записывали, а при чтении блоком 8к именно эти 12 байт выдают свое старое значение, которое было до последней записи. При этом после сброса питания "правильные" значения заменяются "старыми неправильными". Почему-то после повторной записи того же самого файла в те же сектора уже все читается нормально, если не передергивать питание. И почему-то запись другой информации, например, такого эффекта не дает.

Последовательные флешки типа sflash стирают только блоками и записывают страницами (размером поменьше). А кто-нибудь знает, есть ли ограничения по чтению из такой флешки? Я могу считать любое количество байт с любого адреса, даже если блок чтения переходит через границу блоков?

По сути дела мне не хватает глубины FIFO, как я понял, поэтому отключить FIFO тут не поможет. Обработчик выглядит примерно так: uint8_t ReadData; ReadData = ReadData_from_UART_Register(); if (ReadData == 0x77) { flag1 = 1; flag2 = 0; } if ((flag6 == 0)&&(ReadData != 0x01)) { counter++; flag 6 = flag4; } Суть в том что в нем мы попадаем в один какой-нибудь if и делаем буквально пару движений с переменными статуса. На байт обработчик тратит примерно 15 мкс, обычно меньше.

Входной аппаратный FIFO на 32. Когда я по прерыванию начинаю считывать оттуда байты он постепенно очищается и параллельно туда валятся новые байты. В сумме у меня выходит принять только 60 байт, потом наступает переполнение, как правило. Иногда даже переполнение не устанавливается, но FIFO почему-то пуст, хотя входной пакет более 100 байтов. По мере чтения из аппаратного FIFO я пишу в свой программный буфер размером с максимальный пакет, который вообще может прийти - 64кбайта.

Для передачи использую интерфейс UART. Есть входной FIFO глубиной 32. Ставлю уровень заполнения FIFO и прерывание по этому событию. В прерывании считываю всю FIFO и провожу необходимый мне анализ данных. Обработчик по времени очень короткий. Так вот при передаче пакетов размером примерно до 60 байт все нормально принимается и читается. При передаче пакетов больше 60 байт в буфер FIFO почему-то попадают только первые 60 байт! То есть я их считываю как обычно, а после этого FIFO остается пустой, а куда делись остальные байты??? При чем возможно два сценария: установился флажок OVERRUN либо НЕ установился. В случае OVERRUN я еще могу понять - настолько быстро приходят байты, что даже с коротким обработчиком и глубоким буфером мы их не успеваем забрать. Но что происходит если никаких ошибок не возникало? Как UART "прозевал" последущие байты, почему не появилось новое прерывание по уровню FIFO?

спасибо огромное, я выбираю трансформатор, все-таки.

Товарищи, подскажите как по-простому превратить звуковой сигнал с размахом 0-1 В в сигнал с размахом 0-3 В?

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

КОМ порт налажен конечно. Место мне известно. Нужна причина...

Тут немного путаннее получается. Я знаю функцию, без которой прерывание не возникает. Значит дело где-то внутри нее, но в ней есть еще два вложения вызовов - где именно неизвестно, отладчик туда не заходит и брейк не ставит, виснет или приложение генерит исключение сразу. И даже если бы известно было точное место кода это ничем бы не помогло: коды все рабочие (в другой конфигурации портов все равботает как надо), дизассемблерирование нормальное, адреса нормальные. о, точно, спасибо!

Да, прошу прощения. ARM11. ОС нестандартная - потому что под эту операционку производителем написано огромное количество нетривиального "demo" кода, которое используется в проекте. Портировать на другую ОС очень много времени требует, да и незачем, вроде как и эта устраивает. SP перед функцией, откуда возникает Abort, в порядке. Все адреса функций совпадают с map-файлом, дизассемблер дает по этим адресам их нормальный текст.

Есть процессор с операционкой RTOS, но не стандартной, а специально написанной производителем под этот камень. Есть таблица прерываний, где четвертым значится "Abort Function". При очень странных обстоятельствах программа вылетает с этим прерыванием: при определенной конфигурации портов I/O все ОК, а при небольшом переконфигурировании, которое вообще говоря никак влять не должно, возникает это прерывание и все умирает. Есть только простенький пуританский дебаггер, который работает по настроению. Так же известен адрес, на котором спотыкается прога, но туда breakpoint не поставить - рушится отладчик. Да, он классный. Вопрос: Как можно отловить ПРИЧИНУ этого прерывания? В мане описания не нашел. То есть мне надо узнать почему такое прерывание может появиться - из-за переполнения стека/памяти/еще чего, чтобы копать уже туда.