krofork

есть задача, которая сводится к проектированию 1000base-t sfp модуля. то бишь есть sfp хост, требуется получить из него медный ethernet. сейчас нахожусь на стадии поиска serdes (serializer-deserializer) - то есть мне нужно подыскать sfp-to-gmii/rgmii, все что я подходящего нашел - многоканальное, а хотелось бы одноканальное. Просьба, если кто разрабатывал подобные SFP модули, или хотя б разбирал sfp модуль для медного эзернета сообщить какая там внутри комплектуха. Спасибо.

Есть задача сабжевого преобразования интерфейсов. Я правильно полагаю, что мне мои цели поможет выполнить нечто вроде: PM8364 от PMC-Sierra (http://www.pmc-sierra.com/products/details/pm8364/) Если не это, то по возможности подскажите какие чипы помогут мне в этом деле, кто еще занимается выпуском подобных микрух? И вопрос №2, на какое максимально расстояние удавалось протянуть RGMII и был ли у кого-нибудь опыт по пусканию этого RGMII не по плате а, например, по плоскому кабелю?

Есть некая девайсина - проц. плата + модули соединенные с ним по PCI, на девайсе линукс (openwrt), драйвера написаны, все работает. В ближайшем времени есть задача процессорную плату проапгрейдить, причем на проц который не держит в себе легаси PCI, только express, естественно никто не собирается переделывать прям сразу модули на экспресс. Существуют translation bridges PCI-to-PCIexpress, например XIO2000A (Texas Instruments), Intel 41110, все они заявляют красивое "Seamless bridging, Transparent Bridging"...Так вот, к чему это все я - вот под этот мост-преобразователь требуется ли дополнительный драйвер или перепись существующих драйверов внешних уже рабочих устройств, или все действительно шоколадно: меняем процессорную плату, поднимаем проверенный софт и все работает?

GNU ARM ругается: .\objects\lpc_func.o: In function `Codec_Encode': LPC_Func.c:(.text+0x954): undefined reference to `memcpy' collect2: ld returned 1 exit status Target not created В тексте нигде нет этого memcpy. Как заставить линкер не ругаться?

всмысле MMR регистром? MMR - memory mapped register их там много :) регистром REFCON имелось ввиду, тогда опора включена. да и штука в том, что не вообще АЦП не работает, а в том, что не работает правильно только при постоянном обмене по SPI...

сейчас вот так: 10010100010 fADC/2 ADC aquisition time - 2clocks Enable start conversion ADCBUSY disabled ADC power up Single ended Conversion on Timer0 ... не могли бы в пояснить как работает АЦП в этом режиме "100 Непрерывное преобразование с управлением от программы" т.е. от чего запускается? автоматически после окончания предыдущего преобразования?

АЦП запускается по таймеру0 каждые 125 микросекунд

есть ADuC7021 (ARM7TDMI). у него работает АЦП то что он напреобразовывал должно отдаваться по SPI. На вход подаётся тестовый периодический сигнал (период ~20 мс). если он то что напреобразовывал отдаёт по UART, то вроде всё нормально если же включаем SPI (UART продолжает работать - собственно через него я и веду "лог" работы программы), то в оцифрованном сигнале вижу "зарубки" (нулевое значение) через каждые ~2мс. причем периодичность этих "зарубов" не зависит от скорости обмена по SPI (брались скорости и 250кГц и 1 МГц и 4МГц) канал АЦП - ADC0 интересно также, что в обратном направлении (Ц-А пробразование буфера принятого по SPI, периодическое) - происходит без косяков - то есть работа SPI каким то макаром отражается на АЦП и никак на ЦАП. может кто нибудь наведет, почему может происходить подобное?

в общем есть линкерный скрипт (взят из примера) в котором есть строка INPUT(-laduc7024) эта строка РАБОТАЛА с предыдущим GCC3.1.1. Не уверен, но мне кажется (да, глупая фраза для инженера :) ) что она нужна чтобы потом можно было сделать IRQ = MY_IRQ_FUNC; Потому как если её удалть, то линкер матерится на нересолвенные ссылки, относящиеся к прерываниям

>libaduc7024.a откуда? это из кейла - C:\Keil\ARM\INC\ADI\ - инклюды для аналог-девайсез процов :) Это же в GCC3.1.1 работало без подобных сообщений, да и не может ЭТО быть hardware FP, если это(libaduc7024.a) относится только к ADuC'ам у которых (насколько мне известно) ни одного нет этого hardware FP

поставил я значит GNUARM 4.1.1 вместо 3.1.1, теперь Keil материтcя: ....libaduc7024.a(irq.o) uses hardware FP, whereas ....elf uses software FP когда он так матерился на startup я ему -mno-fp прописал, а тут куда чего он хочет?

Есть самописный LPC кодек, написан на С (переделанный OpenLPC). Есть его конкретная реализация на ПК (моя dll + не мой GUI, C++Builder) Есть его конкретная реализация под ARM7 (Keil в качестве IDE+ поставляемый с ним GCC) Проблема в том, что со стороны ПК работает всё, а со стороны ARM только(!!!) кодирование. Процедура декодирования на ARM не работает (точнее она не корректно работает, проверялось отсылкой результатов по rs232 при обработке 1-го фиксированного кадра). С код кодека: процедур кодирования, декодирования, инициализации - абсолютно идентичен как для ПК, так и для ARM7. Проц: ADuC7021 Компилятор: GCC3.1.1 правильно ли моё подозрение, что это косяк GCC?

проблема оказалась не софтовая. поскольку это макетный вариант - линии SPI - провода длиной ~10см, то сказались наводки. Чистый с первого взгляда сигнал клока оказался при ближайшем рассмотрении с какими то пиками амплитудой ну...максимум в четверть вольта, а адук, растак его, воспринимал иногда это как дополнительный пульс клока. Проблему решил внешними 1к пулапами ...на всякий случай по всем линиям.

никакой ЦРЦ не нужен если и осцилом видно что верояность принятия требуемого байта не более 30% :( (а так вообще в протоколе он заложен) - сейчас задача одна - сделать нормальную связь по SPI - просто получить ОДИН НУЖНЫЙ БАЙТ. поменять местами мастер-слейв попробую. спасбо за совет.

Есть ADuC7021 который в Slave режиме привязан к мастеру на атмеге. Связь такого рода: каждые 20 мс атмега с адуком перекидываются 16-ю байтами. скорость SPI - 250 кГц ожидание между байтами - 100мкс. работа SPI - по прерыванию по принятию слейвом байта забив пока на то что действительно должно передаваться (реальные протокольные данные), в тест режиме делаем следующее: на каждый принятый байт от мастера в прерывании в ответ по SPI кидаем просто константу 0хАА(SPITX = 0xAA). Осцилоскопом наблюдаем картинку на ответной линии (MISO, от адука)- как будто эти 0хАА скачут в рамках байта, то есть как будто клок раньше начал чем загрузили в сдвиговый регистр 0хАА. Остальные сигналы проверял - глюков нет, клок чистый, слейв селект дергается в тех местах где надо. Соответственно мастер принимает то 0хАА, то всякую хрень получаемую сдвигом 0хАА на случайное число бит (скомпиленный тест пример работает так же) Кто сошел с ума: я или Аналог Девайсес? :)