Перейти к содержанию

    

kamil_yaminov

Свой
  • Публикаций

    395
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о kamil_yaminov

  • Звание
    Местный

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    Новосибирск
  1. Приветствую! Разбираюсь с ПЗС ICX445 производства Sony. В целом разобрался, но остаются некоторые непонятные моменты. Один из них - это процесс переноса заряда из фотодиодов в регистры вертикального сдвига. Привожу картинку с диаграммой управляющих сигналов: [attachment=106388:________...16_25_05.png] На картинке видно, что считывание заряда их фотодиодов производится при помощи подачи высокого уровня на электроды V2A/B и V3A/B (начиная с отсчета 457(374) на приведенной диаграмме) - с этим делом все более-менее поняно. Вопрос возникает по поводу того, что за манипуляции производятся манипулации с уровнями V1, Vstr и V3A/B непосредственно перед переносом заряда из фотодиодов. Может кто-то пояснить данный вопрос? Можно ли обобйтись без данной процедуры? Пробовал разрисовать потенциальные ямы под фазами, но из полученной картинки выходит, что по окончанию манипуляций регистр вертикального переноса возвращается в исходное состояние, какие заряды были под фазами (например, темновые заряды) - такие и остаются. В общем непонятно. [attachment=106390:IMG_2017...3_165515.jpg]
  2. Marvell 88E6165

    В общем проблема решилась. У данного чипа среди всех питаний имеются два пина: 1) P4_AVDDS - питание SERDES порта 4 2) P5_AVDD - питание SERDES порта 5 и main clock interface Как сказано в даташите, питание на P4_AVDDS подавать необязательно, если на 4-м порту SERDES не используется, и этот пин может быть посажен на землю для экономии энергии, а P5_AVDD должен быть запитан от 1.8В вне зависимости от того, используется SERDES на 5-м порту или нет, иначе не будет запитан main clock interface В общем, в процессе рисования схемы, я как раз сделал все с точностью наоборот, т.е. посадил на землю P5_AVDD и подал 1.8В на P4_AVDDS. Таким образом main clock interface был не запитан, и возникали вышеописанные симптомы. Что за main clock interface можно только гадать, так как в даташите про него ничего более не сказано )
  3. Marvell 88E6165

    Те порты, которые задействованы, могут быть гигабитными медными (Если верить доке, то имеется всего 6 портов, из них 5 могут быть гигабитными медными - они то как раз и задействованы, на всех из них аналогичное поведение) Отзеркалировать поток на другой порт можно попробовать, но скорее всего это ни к чему новому не приведет, так как: 1) порты идентичные в плане базового функционала 2) все задействованные порты ведут себя одинаково, т.е. исходящие пакеты зависают где-то на стыке mac и phy, если скорость линка 1000Мбит 3) зеркалирование по сути перенаправит входящий поток на зеркальный порт, и это будет происходить внутри ядра Есть еще у кого-то идеи? Быть может возникали похожие проблемы на похожих устройствах от марвела?
  4. Marvell 88E6165

    Дальнейшие изыскания показали, что если задать вручную 100Мбит или 10Мбит, то пакеты выходят как в соответствующий порт назначения Если скорость порта 1000Мбит, то исходящие пакеты в такой порт не выходят, но при этом входящие беспрепятственно входят внутрь, как описано в предыдущем посте
  5. Marvell 88E6165

    Имеется плата собственной разработки с Marvell 88e6165 на борту и stm32, который осуществляет управление свичом по MDIO. Возникли проблемы с включением устройства. Постараюсь описать как устроен девайс и какого рода проблемы возникли. Процессор управляет питаниями и сбросом 88e6165. Подача питания и сброса следующим образом: По включении платы подается питание VDDO 2.5В на свич, после этого процессор включает аналоговое питание AVDD 1.8В и последним питание ядра VDDO_CORE 1В. Когда все питания включены формируется сброс длительностью 100мс (надо не менее 10мс, а я так, чтобы наверняка). Есть один момент с питаниями. В даташите на 88e6165 оговорено, что если VDDO_CORE превысит AVDD более чем на 0.5В, то «damage will be result», аналогичное сказано про AVDD и VDDO. Из-за того, что я допустил некоторые огрехи в схеме, при первых включениях AVDD и VDDO_CORE подавались как придется. В общем, огрехи исправлены, сейчас все питания формируются как надо. Собственно не очень понятно, насколько это важно, и действительно ли может привести к каким-то неисправностям. Сейчас будет собираться второе устройство, где последовательность включения напряжений будет изначально правильной. Далее, есть функционирующий MDIO, по которому идет обмен, читаются и пишутся внутренние регистры свича. Свич сконфигурирован в single-chip addressing mode. Следующим шагом после того как был поднят MDIO, стало включение PHY. Здесь нареканий нет: auto-negotiation проходит, скорости, дуплексы устанавливаются правильные. Включение line loopback показало, что пакеты исходящие с хоста, заворачиваются обратно. Также посмотрел при помощи wireshark, что приходят все пакеты, сгенерированные генератором пакетов, встроенным в PHY. Далее включив для начала PHY на двух портах, переключил PortState для этих двух портов в Forwarding. Ingress и Egress policies не трогал, они вроде бы по умолчанию ничего не должны блокировать. Также проверил, что Port Based VLAN Map и Port Association Vector в правильных значениях (т. е. В первом выставлены все биты, кроме бита данного порта, во втором наоборот). Когда в порт прилетают пакеты, счетчики (MAC Based) меняются, более того, в ATU появляются записи, с соответствующими MAC-адресами и векторами портов. Но при этом пакеты не уходят далее, как положено, в порты назначения. Дальнейшее разбирательство показало несколько фактов: Допустим, заходят пакеты в порт 0, которые должны далее перенаправлены в порт 1. При этом количество задействованных выходных буферов порта 1 увеличивается по мере поступления пакетов. Также возникает egress watchdog event. Я сначала предположил, что возможно egress policies неправильно настроены и пакеты наружу не проходят, однако, при этом должны меняться Policy Based счетчик порта, чего не происходит — значение счетчика всегда нулевое. MAC Based счетчики исходящих данного порта тоже нулевые. Однако стоит, допустим, сделать soft-reset для PHY данного порта, MAC Based счетчики исходящих увеличиваются ровно на размер одного пакета, входящего в порт 0 и предназначенного выйти в порт 1. В общем у меня подозрение, что проблема где-то на стыке MAC и PHY. В какой-то момент вспомнил, что у свича есть тестовый режим. Попробовал его запустить в тестовом режиме, однако ничего нового не произошло. Подозреваю, что в тестовом режиме просто включаются все PHY и состояния всех портов устанавливается в Forwarding. Самому пока разобраться не получается, поэтому прошу помощи, тех кто работал с данным кристаллом. Остается ждать, когда будет спаяна следующая плата и надеяться, что проблема не в недокументированных особенностях свича.
  6. Есть MV-S301430-00B_.pdf запароленный. Если кто поделится самим документом либо паролем - буду благодарен.
  7. Добрый день Начинаю осваивать ОС Linux для встраиваемых систем. Делается это на отладочной плате LogicPD AM3517EVM. Т.е. имеем в наличии техасовский ARM Cortex A8. Я решил пойти от простого к сложному: U-Boot-SPL --> U-Boot --> Linux, чтобы не просто поднять ОС на данной платформе (что уже сделано до меня), а попутно разобраться с принципами на конкретном примере. Начал с U-Boot-SPL: взял исходники U-Boot и тулчейн от Linaro, в учебных целях решил слегка модифицировать U-Boot-SPL, чтобы иметь возможность грузить бинарник U-Boot'а через UART. Естественно, с первого раза ничего не получается, следовательно, возникла необходимость отладки. Итак, для отладки используется Code Composer Studio v6.0.0 совместно с JTAG-эмулятором SAU100-USB, все это работает в окружении ОС Linux на хосте. На сайте техаса была найдена инструкция о том, как правильно подготовить среду для отладки "Sitara Linux Training: uboot linux debug with ccsv5" http://processors.wiki.ti.com/index.php/Si...ebug_with_ccsv5. Делаю все как в данной инструкции, за исключением некоторых моментов, связанных с различиями между AM3517 и AM335x, о котором говорится в инструкции, а также различиями между CCSv5 и CCSv6 Далее начинается интересное. Загружаю бинарник u-boot-spl.bin, отладочные символы, меняю систему инструкций на ARM (сбрасывая бит T в CPSR) и жму старт - F8. U-Boot-SPL выполняется, но не так как хотелось бы (это и послужило причиной разбирательств), и остается висеть в вечном цикле, жму останов: Run->Suspend. Далее, поменяв что-то в исходниках, пересобираю проект. Опять гружу бинарник, символы, бит T = 0 как и нужно, нажимаю F8 - после этого "программа улетает" непонятно куда. Попытки сбросить процессор, нажимая Run->Reset->SW reset, Run->Reset->HW reset перед тем как загрузить бинарник ни к чему не приводят, программа продолжает "улетать". При нажатии Run->Reset->System Reset, который по идее должен сбросить ядро и периферию, начинает что-то исполняться, после останова счетчик команд опять где попало. После этого пробовал нажимать кнопку сброса на плате, передергивать питание - не помогает. Помогает (не всегда) выключить плату, закрыть студию, запустить студию, подать питание на плату. Обратил внимание, что в тех случаях когда помогает, бит T в CPSR выставлен в "1", но иногда даже после этих шаманских танцев он все равно сброшен в "0". Другая проблема с прерваниями - не работают софтверные прерывания, аппаратные прерывания пока не проверял: это трудно сделать из-за того, что описанного выше. Честно говоря, не знал куда писать, было начал грешить на эмулятор, но не знаю насколько это "справедливо".
  8. Цитата(oleg-n @ Jul 26 2014, 02:22) Я же написал ..мне нужны прошивки только ( HEX файл с исходником ) а прошить контроллер я и сам умею... Это смотря какой контроллер. Вот поставят Вам что-нибудь "страшное" - замучаетесь разбираться как его готовить.
  9. Цитата(Alt.F4 @ Dec 17 2013, 12:02) kamil yaminov, а Вы где покупаете разъемы типа faston? Они кстати в корпусе для монтажа на плату или только ножи? Спасибо. Нет, только ножи на плату. Покупает нам отдел снабжения, через какие-то новосибирские конторы, так что точно подсказать не могу, сам не занимался
  10. а на лпт и не бывает ножек 5В от внешнего источника работает?
  11. Ножевые разъемы типа faston хорошие, на 10А не греются даже после многократного соединения/разъединения. Чего не скажешь о разъемах MiniFit типа тех, что приведены в первом посте (сслыка на платан). Проверено опытом, даже на 8А ощутимо греются - контакт плохой, особенно когда жесткий провод перекашивает разъем. В общем отказались в пользу ножевых
  12. KiCAD кто-нибудь использует?

    break Да, уже осознал свою ошибку, что ж поделать, первая плата в KiCAD. Спасибо за подсказку.
  13. KiCAD кто-нибудь использует?

    Или вот другой вопрос: можно ли не правя библиотечные элементы, править и перемещать контуры на слое шелкографии?
  14. KiCAD кто-нибудь использует?

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

    Обновил ядро с 3.2 до 3.4, вроде все работает пока что и ничего не вылетает