Jump to content

    

AlexZabr

Свой
  • Content Count

    900
  • Joined

  • Last visited

Everything posted by AlexZabr


  1. Натолкулись на след. проблему: есть система на основе PXA270, OS: Linux (пока не знаю точно какой именно, версия кернеля, драйверов и т.д.). В системе есть интерфейс к SD card. Проблема в том что при "поднятии" OS SD не всегда опознается. Точнее среди 5-6 девайсов, два статистически опознают в 90% включений, 3 опознают примерно в 10-15% включений и один вообще не опознает. Карточка Pretec 1 GB MicroSD. Я сам хардверщик, т.е. "заведую" электорникой системы, софт (Линукс, аппликации и т.д.) - делает софтверщик, посему я пока не в курсе точных софтверных аспектов (какой драйвер, какой Линукс и т.д.). Я так-же пока не углублялся в SD стандарты, думаю продется (что-бы разобраться в возможных причинах не стабильности), подозреваю что есть возможно категории SD по скоростям например, возможно еще по чему-либо влияющему на хардверные аспекты интерфейса. Возможно ли что конкретная версия драйвера в OS поддерживает SD протокол до определенной категории скорости а если конкретная карточка -выше по протоколу то будут проблемы стабильности интерфейса (или опознания) ? Может кто-то имел опыт такого типа проблемы ? На неделе видимо придется подключатся физически на линии SD смотреть что приосходит, хотелось-бы предварительно понять чт нужно ожидать и в каких случаях. Может кто подскажет сайты с протоколами SD (в особенности сигналов, тайминг и т.д.) ? Заранее благодарен.
  2. Спасибо. Русскоязычные термины для меня иногда загадка. Сорри. :laughing:
  3. Сплошные слои добавляются через Layer Stack Manager. Там-же вы иь в ставляете на желаемый уровень. Спасибо за подсказку. А что такое ЛКМ ?
  4. если правильно вас понял, то все просто. Определяете класс для определенного вида traces, например main power, в него загоняете нужные traces. Затем, в rules определяете rule в рубрике routing/width для данного класса где даете min, preferred и max ширину trace данного класса. Min даем такой подходящий для SMD ног элементов, preferred и/или max даем для основных токо-несущих traces. Затем, при разводке (в режиме interactive routing ессно, не в autorouting) играемся настройкой Tools/Preferences/PCB Editor/Interactive routing - там внузу есть секция: Interactive routing width/Via sizes. Там отмечаем галочкой Pickup track width from existing rules и играемся с Track Width Mode (можно и с Via Size Mode если релевантно). Т.е. когда нужно вести track принадлежаший к main power классу но к ноге SMD элемента - идем туда и ставим Minimum. При разводке основных токо-несущих tracks - идем туда и выбираем preferred или maximum. Я именно так сейчас работаю со своей платой - нормально, хотя много операций мышкой ели прыгаем часто с темы на тему. Насчет подключения к земле - все индивидуально. Я на свою плату сейчас дал слой GND и слой основного питания, подключение к земле или к питанию очень удобно делать с via которые определяю как Load GND или VDD. Они сами автоматом подключаются к соотв. слою, остается толчко ногу/и элементов подвести к via.
  5. Спасибо, гляну коммутировать в FPGA не очень удобно в аппликативном плане - несколько ботров соединены внешней шиной, stand alone клок (oscillator) стоит на втором борту, не там где FPGA. Второй клок тоже приходит от внешнего устройства и вначале заходит на второй борд. Хотелось бы их коммуторивать на "входном" борту и в FPGA подавать уже одни, рабочий клок.
  6. Есть 2 возможныч источника клока: один это локальный oscillator, другой - клок получаемый от внешней, подключаемой системы. Нужно их коммутировать на одну линию (используемая в системе как main clock для FPGA). Частота - в пределах 13-14 MHz, уровень - 3.3V. Как насчет коммутации MOSFETами (например внешним сигналом переключающим modes) ? Можно подобрать MOSFETы с низким Rds, но вопрос емкости.... Или есть спец. чипы для таких задачь ? (что-то типа двух канальных clock distributors ?) Спасибо.
  7. В самой системе линии короткие, но когда подключается мое устройство - длины будут примерно 15-20 см. Скорости - не думаю что будет более чем стандартные 400кHz, Vcc = 3.3V
  8. Да, точно, ежели стандард поддерживает multi-masterность - действительно должно быть просто... Одно понять - pull-upы. Внешняя система в принципе автономна, у нее есть свои I2C "приемники", т.е. свои pull-ups. Когда-же я к ней подключаю свой "аппаратус" то у него стоят свои pull-ups (ибо он может и в stand-alone работать). Получается при подключении моего устройства к системе, будут по 2 pull-upа запараллелены. Это может и не проблема если pull-upы могут быть в range (например от 1к до 10к). Но ежели нужен более точная их величина - тогда по идее может понадобится их коммутация. Хотя и это решаемо (FETный ключ как функция от сигнала режима работы).
  9. Возможно я не совсем точно задал вопрос, но дилемма была как раз не о multi-masterности (ибо оба мастера могут работать заведомо только раздельно, т.е. в разделчные промежутки времени что всегда заранее известно - этот факт был правилчьноподмечен в ветке). Дилемма была в ситуации когда работает внешний мастер (коммутация - в FPGA). Проблема возникает в линии SDA когда должен быть "переворот" направлений (например acknowledge после передачи адреса/данных). Понятно что в коде оба SDA - вход и SDA - выход определены как tri-state, но "переворот" направления не может быть "автоматическим",т.е. кто-то в коде должен отслеживать traffic и управлять направлениями сквозной SDA линии...
  10. Сорри, я сижу на VHDLe, очень мало знаком с Верилогом. Можно то что вы хотели сказать выразить VHDLем ?
  11. Да, спасибо, понятно. Что все еще смущает: линия SDA. Есть SDA вход в FPGA (от внешнего мастера) и выход из FPGA (назовем его SDA_FPGA) который идет на конечный "приемник". Т.е. SDA_FPGA коммутируется внутри FPGA - либо "закорачивает" на SDA либо выводит SDA от внутреннего мастера. Что туго представляю это режим passthrough, т.е. когда работает внешний мастер и SDA_FPGA должен просто проводить наружу входной SDA. Оба, SDA и SDA_FPGA - inout и иммитируют open-drain. Но как арбитровать их направления согласно протоколу I2C ? Т.е. когда SDA работает на передачу, тогда будет SDA - вход, SDA_FPGA - выход. Когда-же SDA ожидает приема - они меняются ролями, т.е. SDA становится выходом, SDA_FPGA - входом. Это вроде означает что в HDL коде нужно мониторить протокол и переключать их направления синхронно ? Т.е. получается нечто типа ретранслятора I2C ?
  12. Есть определенное устройство куда подается I2C со внешнего мастера для загрузки setupa в "приемник в данном устройстве. В устройстве есть FPGA в котором помимо всего прочего будет I2C master core, который тоже должен иметь возможность загружать "приемник". Внешние SDA, SCL подключены к FPGA и коммутируются на выходные (из FPGA) SDA_FPGA, SCL_FPGA. Идея коммутации в том что когда устройство подключено к внешнему "драйверу", I2C идет от него, проходит через FPGA и выходит на SDA_FPGA, SCL_FPGA которые в свою очередь идут на "приемник". Когда-же устройство работает в stand-alone режиме - SDA_FPGA, SCL_FPGA драйвятся внутренним I2C master coreом. Вопрос: как правильно определить SDA_FPGA, SCL_FPGA ? По идее, согласно I2C - они оба - open drain, соотв. должны иметь pull-ups. Но I/O FPGA с которым работаю не имеют open-drain настройки (есть pull-up/down, keep, none). SDA ессно inout, но как определить пины ? Какой совет ? Спасибо.
  13. Согласен на все 100%. Не вижу никаких преймуществ кроме как привязки к Альтере (т.е. прймущество для маркетинга Альтеры). И принцип concurrent выполнения того что описано в отличие от софта (C, Pascal и т.д.) где выполнение - последовательно.
  14. Сорри, не совсем по теме вопроса, но не пойму зачем в наше время тратить время на изучение AHDL (имеется ввиду Альтеровский HDL ?). Я помню работал на нем в конце 90х, но только потому что только начал карьеру и в той фирме шли Альтеры и писали до меня на AHDLe. Сегодня мне кажется универсальные языки (VHDL, Verilog и его потомки) полностью вытеснили надобность в proprietary языках конкретных вендоров типа Альтеры...
  15. Понял, спасибо. Но сорс файлы содержащие эти packages должен находиться в библиотеках pipa и popa соответственно, так ? то что я пытаюсь понять это как эти библиотеки физически привязывать к директориям. Согласно уважаемому andrew_b это устновки конкретной среды, пока таковых не нашел в моей среде (ispLever). Буду стучаться в саппорт Латиса за пояснениями.
  16. Ага, спасибо, понял. Попробую закинуть вопрос в саппорт Латиса, как с ispLever определяется work и как добавляять юзерксие библиотеки в месте отличном от defaultного (work)..
  17. :07: хмм, сорри, не совсем въехал что вас обидело в произношении проэкт или проект...и какая связь с уважением/неуважением к своим работам... :cranky: мне в голову не приходило что это можно воспринимать лично... :07: но нет проблем, если грамматиьески правильно писать "проект" значит пусть будет так, а просто писал как произносится... не обжайтесь, но по моему связывать то как пишу с тем что я стебаюсь на своими работами - по детски смешно... :) ОК, спасибо. Я просто пытаюсь понять что физически означает: library work я думал это указание где искать библиотеку (или package указанный в use work.xxxx.all) может имеется ввиду что в настройках компилятора нужно указывать где находится сей work ?
  18. Спасибо. Рабочий каталог - это там где находятся файлы генерирующиеся программой ? (сайлы синтеза, PAR и т.д.) И ispLeverа такя структура (создается при создани нового проэкта): Проэкт | |-----project.dir |-----backup |-----coreip |-----syntmp |-----work Все генерированые файлы проэкта находятся в основной директории (Проэкт), там-же и сорсы. Это значит что Проэкт есть рабочий каталог ? Если библиотека расположена в под-директории относительно рабочей, как описывать относительный путь в library, use ?
  19. В проэкте есть юзерская библиотека в которй находится package которым пользуюсь в проэкте. Включаю ее в файлы сорсов (VHDL): library work; use work.constant.all Constants - это данный package, физизически находится в совем VHDL файле. Вопрос: какая физическая привязка места хранения данного файла библиотеки относительно сорсов/рабочих файлов проэкта ? Обязана-ли находиться в той-же дирректории где и рабочие файлы (например файл сборки проэкта, файлу компиляции и т.д.) ? Или главное чтоб был там где сорсы проэкта (в которые он включен) ? Есть ли "железное" правило на эту тему или оно зависит от конкретнго производителя/IDE ?
  20. Свой новый комп комплектовал недавно, в том числе и под Альтиум: Quad (хотя dual достаточно) 8 GB памяти - 4 GB и более серьезно помогают когда и другие аппликации запущены Win XP x64 - доступно все 8 GB, едиственная возможная проблема с Альтиумом (согласно их саппорту) - не будет работать COM порт (для Наноборда) - мне не релевантно. обычные 2 диска по 500 GB, без raidов. Видео борд важен - взял Leadtek Quadro (Nvidia). Экран - у меня еше графика важна (как заядлый фото любитель). Взял EIZO 22" - отличный экран, картинка точная, живая, не пересыщенная. Не дешов, но того стоит. Возможно в будущем нацелюсь а второй. Альтиум - почти летает. Сам по себе Алчтиум весьма тяжел в закрузке, на работе грузится (там dual, 4 GB) примерно секунд 20-30, дома - примерно 15-20, но затем летает. Картинка - "прыгает" с экрана - монитор/видео борд хороши, ессно поддерживает все фичи..
  21. Может быть... Мне будет важно как можно меньше размазывать края объекта в изображении, вопрос насколько дубляж пикселей будет влиять на это, особенно в статической картинке...
  22. Вот это то как раз и вопрос... повторять каждый второй пиксель то оно наиболее просто, но как сказывается на качестве на ТВ относительно более "умных" алгоритмов ? (тут в схожих ветках предлагались несколько подходов пиксельной интерполяции). Интересно именно на основании опыта: сильно ли сказывается простая дупликация пикселей на статическом и динамическом изображении ?
  23. У себя такого не замечал, синтезатор вызывается очень быстро из Build, либо в stand alone Pro...
  24. Вопрос в догонку: когда источник картинки (streaming video) 320x240 или другое меньше чем натуральная резолюция ТВ - интерполриуем ? Стандатные PAL/NTSC енкодеры ожидают на входе сигнал стандартной TV резолюции PAL или NTSC соответственно и его кодируют в composite. Так вот если источник имеед дающий менее чем стандартный ТВ сигнал по резолюции, значит перед подачей на енкодер его нужно подогнать под PAL/NTSC ? Если например кадровая частота источника зачительно больше нужной конечной (25 или 30 fps), например: 50, то в приципе можно попробовать запускать каждый входной кадр как одно поле выходного (т.е. из 2х кадров по 240 строк на входе получаем один кадр на выходе 480 строк). Но по ширине все равно по идее нужно интерполировать до PAL/NTSC стандарта ?