studert

По ТЗ после трансформатора не должно быть никаких емкостей и диодов.

Спасибо всем, решил собирать генератор на 74HС4046, а там будет видно что из этого получится. Пока не сделал макет попробую теорию почитать. Собственно устройство - это источник питания накала клистрона, его рабочий импульс привязан к фазе сети все измерения СВЧ тоже. Пока непонятен вопрос влияния переменного магнитного поля от катода на СВЧ, поэтому хотят сделать привязку источника питания к фазе сети, чтобы фаза источника была постоянна для рабочего импульса и не вносила помеху в измерения по СВЧ.

В контроллере не совсем ШИМ, там фазовая модуляция и искажать сигнал (2 меандра со сдвигом фаз) нежелательно, да и частоту можно менять лишь в узких пределах. Если не получится получить 1.6 МГц, буду пробовать переписать программу контроллера, чтобы обойтись 1.6 кГц.

Ну вопрос что нам нужно далеко не однозначный :) Заказчит далеко не профан - лет 40 уже работает с измерениями и с помехами бороться умеет, да и все остальное оборудывание синхронизуют с сетью не просто так. Одно дело рассуждать, что это не поможет и совсем другое: реализовать и убедиться, что не помогло.

Да прибор ничего особенного, цифровой ШИМ контроллер, с частотой 1.6 кГц и разрядностью 10 бит. Поскольку все остальное измерительное оборудование привязано к фазе сети, то заказчик хочет избавиться от "помехи" в лице инвертора, то есть чтобы помеха была в фазе. Ну точность мне большая особо не нужна, я думаю сделать медленную обратную связь, чтобы локальные ошибки вычисления фазы хорошо усреднились, лишь бы переключения инвертора происходили в примерно одних и тех же местах сетевого периода.

Есть цифровой драйвер инвертора, который сейчас тактуется от кварцевого генератора 1.6 МГц. Чтобы увеличить точность измерений в устройстве, необходимо чтобы инвертор работал в фазе с питающе сетью, но тактоваться от 1.6 МГц. То есть нужно умножить сетевую частоту в 32000 раз. Поскольку раньше такие задачи не решал, не знаю в каком направлении копать. Посмотрел на доступные микросхемы ФАПЧ, они все на единицы-сотни мегагерц и не с таким большим коэффициентом умножения или я плохо искал? Насколько сложно выполнить/отладить такую схему на рассыпухе вроде ОУ и стандартной логики?

Похоже придется сделать еще одну ревизию платы:( с резисторами.

Сейчас перевожу вход в третье состояние записав в него 1'dZ, а хочется перевести его в "слегка подтянутое к питанию". Чую, что такая возможность етсь (неиспользуемые пины можно подтянуть), но не могу найти синтаксис.

Спасибо zltigo за разъяснения со стеком, я про себя догадывался, что все в порядке, но хотелось узнать в чем дело. Отладчик использую MT-LINK. Что касается 3го вопроса: взял тест ком порта из демки ARM7_AT91SAM7S64_IAR. В примере есть функции vSerialPutString и vSerialPutChar в файле serial.с, сюда же добавил функцию int putchar (cOutChar) { xSerialPutChar(NULL,cOutChar,0); } В ИАРе для АВР, такой прием прокатил, printf "нашел" знакомую функцию и все получилось. Тут же отправляется только первый символ сообщения. Я и не понимаю в чем дело, функция по отправке символа работает исправно. Вывожу все в УАРТ0.

Только начал работу с АРМами, а именно с AT91SAM7x256. Пока выбрал среду ИАР, до этого с ней не работал. Возникли следующие вопросы: 1. При попытке запустить отладку uIP_Demo_IAR_ARM7 пишет: There were warnings while generating glash loader inputs, в логе 2 варнинга "Flash download warning: 64 out of 64 bytes from data record CODE: [0x0-0x3F] will not be flashed" и то же для 34292 байт по адресам 0x100 - 0x86F3. Пока это сообщение пропускаю, но хотелось бы понять в чем тут дело. 2. Запускаю только задания StartLEDFlashTasks, vErrorChecks и vAltStartComTestTasks из проекта для sam7s64 (езернета на плате пока нет). Работать вроде работают, по крайней мере светодиоды мигают, в ком порт тестовую последовательность летит, но при отладке говорит the stack pointer for stack 'CSTACK' (currently ...) is out side the stack range. Пробовал увеличить размер стека, не помогает. Например, если стек был по адресам (200000 - 200400), то текущее положение 200DF8, при увеличении стека до 800, текущее положение тоже увеличивается на 400 и становится 2011F8. Это нормально? 3. Определил функцию putchar, вроде работает. При запуске printf("hello from at91sam7x"), доходит только "h". Если же воспользоваться sprintf(message, "hello from at91sam7x") и putstring(message) сообщение доходит нормально. Может конечно с этими вопросами нужно было в ветку по ИАР.

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

Пересаживаюсь с GCC на IAR, пытаюсь printfом писать в УАРТ. Поискал по форуму, говорят что нужно переписать putchar, больше неичего не нашел. Переписал, вызов putchar работает, а printf нет... void usartPutchar(char c){ while(!(UCSR1A && (1<<UDRE1))); UDR1 = c; } int putchar(int c) { usartPutchar( c ); return c; }

1056 никак, с такой скоростью данные пишутся в память, а уже из памяти "потихоньку" по запросу с ПК выгружаю через 100Mbps Ethernet UDP пакетами :), до 1024 пикселей в один пакет влазит.

Внешний DMA это конечно здорово, но у меня камера для фотометрических измерений, поэтому данные передаем на комп в первозданном виде, поток данных с матрицы ~430 - 1056 Мбит/сек (27 и 66 МГц клок), и размер кадра 700 - 2500 Кбайт для (VGA и 1.3MPixel). Мне кажется что с этим справится только контроллер с двумя внешними интерфейсами: 2 внешние шины одну на камеру, вторую на SDRAM и пусть данные по ДМА с камеры летят в SDRAM 1 внешняя шина на SDRAM и image sensor interface и пусть опять же данные по ДМА летят в SDRAM Или все же можно проще?

В моей системе проц мощный не нужен, никакой обработки данных не предполагается, картинку на комп нужно отправлять в "первозданном" виде. Буду думать насчет at91sam9260, хоть плата и не сильно упростится, зато можно будет "нормальный" UDP/IP поднять.

Ну эти еще "навороченней" чем атмеловские 9260/sam91xe, интересуют решения попроще в корпусе не бга.

Подумываю переделывать аппаратную часть камеры (сейчас FPGA+SDRAM+AVR+EthernetPHY) хочу обойтись ARM+SDRAM+EthernetPHY. Требуемую периферию нашел только у AT91SAM9260,AT91SAM9XEXXX. Есть ли у других производителей решения с image sensor interface? Подойдет также LVDS видео вход.

Документация на mt9v032 раздается под NDA, когда-то сам просил, но мне не дали, не хотели соглашение нарушать. Заполни на сайте производителя форму будет тебе счастье. По умолчанию регистры сконфигурированы так, что у тебя все будет работать в автоматическом режиме, так что поиграться хватит. Выкладываю описание, которое когда-то давно делал программисту, можешь посмотреть приложенный файл, там описаны основные регистры (в среднем столбце название и адреса регистров), другие регистры не понадобились. Переведено довольно посредственно, но смысл понятен. _______________.doc

Да похоже так и не узнаю, что такое мне прислали... благо не дорого 10 шт обошлись.

На фотографии в центре с (маркировкой D5C) микросхема, по словам поставщика, должна быть AD5337ARM. Но у меня на этот повод есть большие сомнения. Потому что, во-первых ширина корпуса не совпадает с заявленной в даташите (тут 1.8 мм против 3 заявленных, так что пады остались снаружи, когда паял их маму вспоминал), а во-вторых она на обращение по и2ц не реагирует. Пробовал обращаться по разным адресам, не шлет подтверждение ни на чтение ни на запись. Может кто подскажет что за зверь мне попался, вдруг что-нить можно с ним сделать. 1.bmp

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

Собрал устройство по схеме из архива (упразднив SN65220 и раскидав ножки плис в другом порядке, для удобства разводки), но работает только jtag режим, пробовал обе прошивки. Это ограничение данного проекта или я что-то сделал не так? В режиме Active serial пишет Error: Can't recognize silicon ID for device 1. Ниже прилагаю схему и архив всего пректа для Altium designer, может еще кому пригодится. usbblast.rar

С объективом есть "бумажка", на которой написано, что диафрагма 1.4 - 360, если смотреть в объектив, то видно как эта диафрагма перекрывается, конечно там получается не равномерное перекрытие, но не дискретное. Пока склоняюсь к тому, что придется заводить обратную связь по освещенности, и не с матрицы, а с отдельного фотодиода... Если кто подскажет, как можно сделать не оптическую ОС, буду рад.

То что без обратной связи не обойтись, это понятно, но как ее реализовать пока не понятно. Приведенная схема не дает конкретных ответов, лишь дополнительные вопросы.

Плавно увеличивая напряжение, при достижении определенного уровня диафрагма открывается, поймать промежуточные положения (частично открытой диафрагмы), очень сложно. Если двигаться в обратном направлении (то есть от открыто диафрагмы), тогда для ее закрытия нужно уменьшить напряжение до уровня меньшего, чем требуется для открытия (гистерезис некоторый). Для проведения более детального исследования нужно собрать более сложную макетку, поэтому и спрашиваю, может кто с этим сталкивался. Есть подозрения, что одна катушка используется для ООС. Нашел схему преобразования управляющего сигнала Auto IRIS to DC-IRIS, думаю собрать упрощенную на макетке попробовать, подав на вход вместо видео сигнала сигнал с переменного резистора.