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

anatole

Участник
  • Постов

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

  • Посещение

Репутация

0 Обычный

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

  • Звание
    Участник
    Участник
  • День рождения 27.05.1982

Контакты

  • Сайт
    Array
  • ICQ
    Array

Посетители профиля

1 407 просмотров профиля
  1. Обратите внимание на то, что по документации на ПЛИС частота ALTUFM_OSC не имеет точного значения и лежит в пределах от 3,3 до 5,5 МГц
  2. Доброго времени суток. Имеется малогабаритное стационарное/настольное радиоприёмное устройство типа SDR, которое будет выдавать данные в ПК (настольный/ноутбук) по интерфейсу USB 3.0/3.1 gen 1. Устройство запитано от своего собственного источника питания. Длина кабеля подключения не менее трёх метров. Микросхема физуровня USB - Cypress FX3. Устройство будет выпускаться в течение 5 лет, по 30 шт. в год. Собственно вопрос: какой тип разъёма заложить? Стандартный/микро тип B или сразу тип C? Как я сейчас представляю ситуацию. "За" тип С: современный разъём, и как долго ещё будут достуны разъёмы типа В. "Против" тип С: более жёсткие требования к кабелям (выше цена на них, меньше длина, но мне не надо запитывать по этому кабелю устройство), и дополнительная МС мультиплексора линий в случай кабеля типа С-С. Спасибо.
  3. На сайте Intel-Altera скачиваете отдельный файл Quartus Standalone Programmer и при его установке будет доступен выбор в том числе и 32-битного приложения, но какие там доступны кристаллы подсказать не могу.
  4. Так в настройках есть такие галки. Ищите в Edit-Preferences-Capture и в Capture-Options, настройки типа Autoscroll..., Automatic scrolling... или что-то подобное. Но есть баги с работой этих настроек. Система Win7x64 Wireshark 2.2.x. Если запускать Акулу с новым интерфейсом, т.е. файл wireshark.exe, то несмотря на включенные галки, автоскрол не работает пока не тыкнеш кнопку его включения или не передернеш галки настроек, и так до следующего запуска Акулы. Упоминаемый ранее ключ -l позволяет не проводить этих манипуляций после старта. Для Акулы со старым интерфейсом, файл wireshark-gtk.exe, таких проблем не замечено, настройки автоскрола сохраняются.(Я, кстати, пользуюсь старым интерфейсом, но не из-за этого бага).
  5. Смотрите ссылку: Ключи для запуска из командной строки. Сейчас проверить не могу, но похоже ключ -l (возможно, в связке с -S), должен сделать то, что вам надо.
  6. По документации на модуль UC530 еще, как минимум, надо соединить антенный выход с РЧ-входом, если используется встроенная антенна. Кстати, а какой у вас вариант включения антенны?
  7. Здравствуйте. Начал осваивать ModelSim и натолкнулся на такие грабли. Имеется следующий упрощенный код на VHDL, при компиляции его в Quartus 9.1 и последующей временной симуляции в Quartus все замечательно. library ieee; use ieee.std_logic_1164.all; entity cnt is generic ( constant CNT_MAX : positive := 5 ); port ( rst : in std_logic; clk : in std_logic; ena : out std_logic ); end entity; architecture arc of cnt is signal cnt : natural range 0 to CNT_MAX - 1; begin process (all) begin if (rst = '1') then cnt <= 0; elsif (rising_edge(clk)) then cnt <= cnt + 1; --- !!! ОШИБКА !!! if (cnt = CNT_MAX - 1) then cnt <= 0; end if; end if; end process; process (all) begin if (rst = '1') then ena <= '0'; elsif (rising_edge(clk)) then if (cnt = CNT_MAX - 1) then ena <= '1'; else ena <= '0'; end if; end if; end process; end; Но при функциональной симуляции в ModelSim выскакивает следующая ошибка: # ** Fatal: (vsim-3421) Value 5 is out of range 0 to 4. на строке с коментарием. Я понимаю откуда она возникла. Вопрос в том, как ее обходить? Предложения: 1. не использовать числовые типы, а только массивы битов; 2. задавать какие-нибудь атрибуты для симуляции; 3. не использовать такую манеру написания кода, а явно прописывать для данного примера изменение сигнала cnt по условию else условного оператора. Но тогда много придется править для случаев, в которых сигнал сбрасывается в определенных условиях оператора case. Подскажите, как правильно поступить?
  8. А не есть ли это - задержка распространения сигнала, совпавшая с половиной периода тактовой частоты. Что если, изменить частоту симулирования.
  9. А подскажите, пожалуйста, каким способом можно получить эту статистику в Windows? Если я выключаю возможность приема Jumbo фреймов в настройках сетевой карты, и потом настраиваю устройство на выдачу сообщений с данными размером фрейма 4146 байтов, то на приеме в ПК, как в сниффере, так и в ПО, я вижу только первое сообщение "Заголовок" (размер фрейма 74 байта) и дальше ничего.
  10. Виноват, забыл, исправляюсь. Устройство подключено к ПК напрямую. Сетевые настройки, следующие: MAC-адрес устройства: 0x001122334455 IP-адрес устройства: 192.168.100.250 Порт устройства: 3080 IP-адрес ПК: 192.168.100.134 Порт ПК: 3080 В настройках сетевой карты включен режим приема Jumbo фреймов размером 4 КБ MTU (максимальный размер для данной сетевой карты). Размеры пакетов указывал в первом посте, напомню: команды от ПК: размер фрейма не меньше 60 байт, полезные байты UDP >= 18 сообщение от устройства «Заголовок»: размер фрейма 74 байта, полезные байты UDP = 32 сообщение от устройства «Данные»: размер фрейма 1074 байтов, полезные байты UDP = 1032 Размер сообщения «Данные» в устройстве можно настраивать, так вот, если изменять этот размер и выдавать данные не 4-мя сообщениями, а, например, одним (размер фрейма 4146 байтов, полезные байты UDP = 4104), то ситуация изменяется и проблемный прием в ПК возникает намного реже. А если в настройках сетевой карты отключить поддержку Jumbo фреймов, и производить передачу блоками по 4-е сообщения «Данные» (размер фрейма 1074 байтов, полезные байты UDP = 1032), то проблема с приемом вообще никогда не возникает. Но отключение Jumbo фреймов не годится, т. к. в другом исполнение устройства, передаваемые сообщения с данными должны быть как можно большего размера.
  11. Перечитав свой первый пост, решил дополнительно уточнить такой момент. Проблема возникает не постоянно, т. е. не при каждой передаче блока сообщений от устройства в ПК, а носит не периодический характер (или я ещё не выявил периодичности), т. е. устройство может без проблем передавать сообщения в течение нескольких минут, потом в течение одной минуты может быть один-два сбоя, и снова несколько минут беспроблемной передачи. Поэтому у меня и возникло предположение, озвученное в первом посте, что пока объём данных приходящий в ПК имеет некоторую кратность объёму буфера в сетевой карте, то все работает хорошо, а как только не добираем необходимого объёма данных, то возникают проблемы. Также на эту мысль наводит описание регистров чипа RTL8111B_8168B п. 2.8 (см. приложение, п. 2.8). RTL8111B_8168B_Registers_DataSheet_1.0.pdf Попутно возникли вопросы. 1. Можно ли узнать, как стандартный драйвер настроил чип? 2. Можно ли средствами стандартного драйвера перенастроить регистры чипа в сетевой карте на своё усмотрение? ------------------------------------------ Сами сетевые пакеты, насколько я понимаю, не содержат ошибок, т. к. нет никаких ошибок ни в статистике сниффера, ни в отчете netstat. Аналогично нет ошибок и в самих сообщениях, поскольку, когда сообщение всё-таки доходит до ПО, то анализ сообщения показывает, что с его содержимым всё в порядке.
  12. Уточню последовательность пакетов во времени. Последовательность пакетов на ПК в сниффере: [(1) передан один пакет] – [(2) принято ЧЕТЫРЕ пакета] – [(3) таймаут 1 с] – [(4) передан один пакет] – [(5) принято ДВА пакета]. Последовательность пакетов в устройстве: [(1) принят один пакет] – [(2) передано ПЯТЬ пакетов] – [(3) пауза 1 с] – [(4) принят один пакет] – [(5) передан ОДИН пакет]. Причем если в ПО отключить таймаут на прием сообщений, т. е. ждать сообщения бесконечно долго, то недошедший пакет рано или поздно появится в сниффере при какой-нибудь активности по сети со стороны ПК, например, при отправке пакета по протоколу Browser Protocol (раз в 11 мин), который в устройстве отбрасывается на стороне МАС-контроллера, или при ping-е IP-адреса отличного от адреса устройства. ------------------------------- О каком интервале идет речь?
  13. Здравствуйте. Помогите решить возникшую проблему. Дано. Есть система, в которой устройство подключено к ПК по сети Gigabit Ethernet с обменом информацией по протоколу UDP. Схема соединения узлов системы имеет вид: устройство[МК <=> MAC-контроллер (самописный контроллер на ПЛИС Cyclone III) <=> МС физического уровня (Marvell 88E1111)] <=> ПО на ПК (встроенная сетевая карта Realtek PCIe GBE RTL8168B/8111B, ОС Windows XP). Упрощенно алгоритм обмена информацией содержит следующие шаги: Шаг 1. ПО настраивает устройство некоторым количеством команд. Шаг 2. Далее ПО посылает команду «Запрос данных». Шаг 3. После получения команды «Запрос данных» МК выдает блок сообщений: сообщение «Заголовок» (UDP пакет с размером полезных данных 32 байта) и следом 4-е сообщения «Данные[1] – [4]» (UDP пакеты с размером полезных данных 1032 байта). Интервалы времени между сообщениями от МК около 10 мкс. Шаг 4. ПО на ПК анализирует принятые сообщения и выдает либо команду «Правильный приём», либо «Повторить сообщение №N». Также на этом шаге ПО следит за таймером, и если в течение одной секунды не набран полный блок сообщений, то происходит принудительная подача команды «Повторить сообщение №N». Шаг 5. Затем ПО посылает снова команду «Запрос данных» и т. д. шаги 2 – 4 по кругу. Интервалы времени между командами «Запрос данных» при правильном приеме сообщений около 1,5 мс. Проблема. Имеет место ситуация, когда до ПО на ПК не доходит последнее сообщение (причем всегда именно последнее) от устройства, т. е. сообщение «Данные[4]», что приводит к срабатыванию таймаута на прием блока сообщений и к подаче от ПК команды «Повторить сообщение №N». В этой ситуации, недошедшее сообщение также не видно и в сниффере (Wireshark), хотя по осциллографу на цепи TxCtl, между ПЛИС и МС физического уровня, наблюдается верная временная диаграмма, состоящая из 5-и передач в сеть. Более того, после команды «Повторить сообщение №N», на цепи TxCtl наблюдается только один импульс соответствующий передаче одного пакета в сеть, а в ПО доходит и «старый» недошедший пакет и «новый» переспрошенный пакет. В сниффере же наблюдаем следующую картину: 1. пакет в ПК: сообщение «Данные[3]» (последний правильно пришедший пакет) 2. пакет из ПК: команда «Повторить сообщение №4» (пакет из ПК по таймауту через 1 с после последнего пакета) 3. пакет в ПК: сообщение «Данные[4]» (недошедший до ПО и сниффера пакет, из-за которого была подана команда «Повторить сообщение») 4. пакет в ПК: сообщение «Данные[4]» (сообщение, которое было выдано устройством в ответ на команду «Повторить сообщение»). Т. е. получаем ситуацию, когда из устройства сетевые пакеты уходят, а до ПО и сниффера в ПК не доходят. Подозрения. Как будто в сетевой карте на ПК есть буфер с заданным уровнем заполнения и, если этот уровень не превышен, то пакеты из сетевой карты не уходят в приложения. Вопрос. Что посоветуете в данной ситуации? Причем менять сетевую карту, ОС или стандартный сетевой драйвер очень не желательно. Заранее спасибо за любую помощь. P.S. В этой системе сам я отвечаю за устройство, и с программной частью на ПК в плане работы с сетью не знаком. На вопросы связанные с ПО, смогу ответить после консультации с нашим программистом.
  14. AlexMad: В схематике вместо CONSTANT используйте lpm_constant, в которой "ручками правим версию проекта"
×
×
  • Создать...