Dot

"просто 2N+1 инверторов включенных друг за другом кольцом," - _pv Мои стринги круче -- в них есть еще поперечная перемычка... Вобщем принци понятен, вроде так и реализовано у acam, но дело в том, что меня не интересуют временные интервалы как таковые. Мне нужны именно "сфотографированные" фазы счетчика в их наипервейшем виде в виде значений 0...1023 (как минимум), непрерывная цепочка таких значний. Да, 32 бит избыточны, но они желательны, чтобы "прикрутить" параллельно еще одну задачу (определение частоты) без всяких заморочек с программным расширением разрядности. В принципе обойдусь и 10 битами. Но вы меня неизбежно толкаете к внешней рассыпухе (пусть даже и в виде fpga). Видимо, все это будет (я надеялся, что что-то пропустил) у ARMов лет так через 5. Да, mr. Golikov A., примерно так ("и АЦП померить") я и делаю на текущий момент. .

Они вроде работают по старт-стопному методу. А мне надо непрерывно, со скоростью ~300k в секунду получать снимки счетного регистра. Дальше - ЦОС этих "сэмплов". а почему не 5 МГц и результат помножить на 100, или 500кГц и результат помножить на 1000? я знаю только что такое стринги... :crying: Значит получается (на текущий момент) , что на ARMах без внешней "залепухи" никак?

В идеале - на 32 бита, но сойдет и 16-разрядный. Главное, чтоб тактовая частота (естественно - внутренняя) была не менее 500 МГц. Внешние "фотографирующие" импульсы приходят сравнительно редко - до 300 кГц. Задержка между фронтом фотографирующего импульса и срабатыванием тоже не важна, лишь быб была постоянной. Неужели в век процессоров с гигагерцами сделать такой таймер - большая проблема? Есть ли в природе процессоры с такой быстродействующей периферией? (спрашиваю в разделе про ARM чисто по причине их предпочтительности)

Так когда работал с TDMI - радовался жизни! Нахрена они компилятору, который и распорядиться-то толком ими не умеет? Пусть ограничится песочницей R0...R3! Обработчик прерывания пишу сам.

Отбой. Так и не понял, в чем был косяк, но сегодня код прекрасно откомпилировался. Тем не менее, Keil для этих команд синтаксис так и не подсвечивает: PS. Вау, писаю от счастья, одна команда заменяет четыре! Для будущих грабленаступателей: хотя USAT заявлена как беззнаковая, исходный операнд считается знаковым! Т.е. число, старший бит которого =1, будет обрезаться в 0. Например 0xFFFFFFFF (т.е. -1) после операции станет 0.

STM32, uVision4. Хочется использовать R5...R11 исключительно в обработчике прерывания (сэкономив на записи - восстановлении из стека), и, возможно, не только для промежуточных результатов, но и для хранения переменных между вызовами. Посмотрел результаты компиляции основного цикла (на Си) -- используются только R0...R3 (вроде бы..) Правомерно ли считать, что при добавлении нового кода ситуация не изменится, а если нет, то есть ли возможность зарезервировать требуемые регистры?

Читаю описание -- в Cortex-M3 команда SSAT вроде присутствует. При попытке ввести мнемонику, Keil синтаксис не подсвечивает, при компиляции -- выдает ошибку. Аналогично с командой MOVW. Что может быть не так? (STM32F100R, uVision4)

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

Можно-то можно, да только модуль для связи TRG0->TRGI у таймера только один. Как тогда заводить еще и сигнал "capture"?

Железо разведено для использования входа у канала 2 таймера 2. Тактовая частота таймера -- системная по-максимуму. Хотелось бы, чтобы таймер был 32-битным, т.е. к нему надо как-то приляпать 2-ой таймер. Не пойму, как это можно сделать. Получается (пока чисто теретически), что с ведущего таймера можно подать либо счетные импульсы, либо сигнал захвата, но никак ни оба сигнала одновременно. Или здесь есть какой-то трюк? Пока в голову приходит только брать сигнал захвата с ведущего таймера, а тактовую частоту для зависимого брать системную, но поделенную предделителем (у которого коэффициент деления такой же, как и у 1-го таймера). И оба таймера стартовать синхронно.

Кристалл CY8C27xxx от Cypress. Внутри есть аналоговые блоки на основе ОУ, которые могут давать шум сомнительной природы (при особой конфигурации). Есть и цифровые блоки на основе сдв.регистров с обратными связями 8...32 бит, которые могут дополнительно "ослучаить" последовательность, что я и делаю для большей надежности. Будет время, материал выложу на свою страничку.

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

Голые фото без пояснений -- очень скучно. Как интересный пример: http://pro-radio.ru/misc/263/

Спасибо. Нашел безответный топик одной девушки http://forums.software-testing.ru/index.php?showtopic=3896 В нем много интересных ссылок. Как я понял случайность не доказуема. Проверяется только отсутствие той или иной случайности.

Я тут микроконтроллером генерирую случайные последовательности. Может кто подскажет, в каком направлении копать, чтобы доказать, что полученная последовательность является абсолютно случайной? На текущий момент мне представляется один критерий -- гладкость фурье-спектра. Но с другой стороны гладкость обеспечиватся и обычными генераторами псевдослуч. последовательностей на основе сдвиг.регистров с обратными связями. Спектр полученного сигнала -- в приложении. F -- частота сэмплироания (битов). Есть пики, с этим не поспоришь. Но они пропадают, если последовательность дополнительно пропустить через тот же регистр с обр. связями.

Я еще ни разу так не делал, поэтому ничего сказать не могу. Могу только предположить некоторую муторность такого метода. И ухудшение этой самой "сопровождаемости". Пока я просто смирился.

Ничего себе -- " ARM начинающим"! Я вот какой аспект хочу поднять: ну вот отладили вы программу на С, добились (может быть с трудом) того, что она успевает реагировать на какие-то внешние воздействия. Поменяли компилятор (апгрейд версии, заказчик вдруг решил перейти на другой, либо проект открытый) -- девайс не работает, нужно искать то "критическое место" , которое портит все из-за изменившегося времени выполнения. Если заранее найти такие места и написать их на асме, то код станет гораздо "сопровождаемее".

The Insider's Guide (~6MB): http://www.hitex.co.uk/arm/lpc2000book/index.html (либо сразу по http://www.hitex.co.uk/arm/lpc2000book/lpc-ARM-book_srn.pdf) Я на эту книжку наткнулся уже после того, как изучил даташиты :( Кстати, где-то тут выкладывали ее принтабельный вариант.

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

Спасибо за отклик, еще раз подчеркну, что все и так работает как надо, просто раздражают ненужные предупреждения, особенно когда их много. По 2-- все так, только концовка пишется иначе: MOV R0,... //return value in R0 LDR R1,=result STR R0,[R1] }//asm return (result); } что приводит к генерации кучи ненужного кода ("из пустого в порожнее"). По 3 -- есть атрибут __task для объявления функции (использую uVision, компилятор от Keil), который подавляет генерацию пролога-эпилога, вот только функция эта должна быть строго void function(void).

По соглашению, Keil С компилятор возвращает значение функции в R0. Если я пишу функцию полностью на ассемблере, то такой код unsigned int my_function(int param1, char param2) __arm { __asm{ ........... MOV R0,... //return value in R0 }//asm } приводит к генерации компилятором предупреждения "no return value". Есть ли способ сказать компилятору, что я действительно возвращаю значение в R0? Это просто вопрос перфекциониста.