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 поднять.