Jump to content

    

svedach

Свой
  • Content Count

    156
  • Joined

  • Last visited

Community Reputation

0 Обычный

About svedach

  • Rank
    Частый гость
  • Birthday 05/03/1982

Контакты

  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

1862 profile views
  1. Спасибо, Rob. Умом тоже это понимал, но вдруг там FIFO какие есть или что-то иное... Вобщем проблема решена. Вместо анализа s2mm sts, ожидаю сигнал s2mm_wr_xfer_cmplt и после него формирую прерывание. При этом все работает как ожидается. Спасибо всем, откликнувшимся!
  2. Это конечно можно, только не совсем понимаю, что это даст. Я почти уверен, что к моменту обработки прерывания весь путь данными еще не пройден и я увижу данные с латентностью 1 прерывание. Мне нужно в момент обработки прерывания гарантированно иметь данные в ДДР...
  3. Добрый день. Есть кастомное ядро, которое через Xilinx DataMover и AXI SmartConnect (обслуживает еще других мастеров) пишет пару десятков байт в DDR. Полный путь такой: После записи (проверяется статус по шине s2mm sts) ядро генерирует прерывание. По прерыванию ARM забирает данные из памяти, при этом не забыв инвалидировать кеш (Xil_DCacheInvalidateRange((uint32_t)_mu_hw_vals, (valSize | 0xFF))). Вопрос состоит в следующем: как мне быть уверенным, что когда ARM отрабатывает прерывание, данные уже реально дошли до DDR - т.е. прошли через AXI SmartConnect и внутренности PS? Вопрос возник из-за того, что если поставить точку останова перед инвалидацией кеша, то данные видны, если после - то нет, но видны на следующем прерывании (подозреваю, что видны старые - от предыдущего прерывания). Есть ли какой-то механизм, обеспечивающий ожидание, что вся цепочка завершена и данные действительно записались в DDR? Или может я неправильно выстроил цепочку и надо зайти с драгой стороны?
  4. Похоже все-таки не работает... Может кто использовал?
  5. Захотелось облегчить жизнь немного и использовать _Generic: #define mBlock_createInput(array, uid, label, defValue)\ _Generic((defValue), float_t: mBlock_createInputF,\ int: mBlock_createInputI,\ char*: mBlock_createInputS,\ default: 0) cJSON* mBlock_createInputF(cJSON* array, char* uid, char* label, float_t defValue); cJSON* mBlock_createInputI(cJSON* array, char* uid, char* label, int32_t defValue); cJSON* mBlock_createInputS(cJSON* array, char* uid, char* label, char* defValue); В коде использую так: mBlock_createInput(group, "MIN_VALUE", "Minimal value", 0.0); Код компилируется и работает. Но постоянно висит ошибка "Syntax error": Подскажите, пожалуйста, почему? В опциях компилятора включал --std=c11, но не помогло. Как я понимаю ругается проверка синтаксиса, но компиляция проходит и все работает...
  6. Последовательность правильная (только надо отслеживать сохранение проекта...). Возможно внесли изменения и не нажали "Сохранить" - отсинтезился проект с ошибкой/не полный...
  7. думаю проблема в dcm_locked - он не заведен никуда. Попробуйте завести его на FCLK_RESET0_N для начала
  8. Обычно блоки подключаются через AXI Interconnect. Выложите полностью скриншот блочного проекта.
  9. Работаю с LUX1310, только монохромной. Проблема вертикальных полос - неравномерность усилителей АЦП. Их 16 шт. и полосы повторяются через 16 столбцов. Полностью компенсировать не удается - с ростом температуры значения плывут... Сам устраняю подстраивая уровень черного и усиление для каждого канала (АЦП). У нас кстати матрица сильно греется, у Вас есть такая проблема? Иногда появляется горизонтальная линия, положение которой зависит от времени экспозиции - это связываю с тем, о чем говорил polyvyannyy... Динамический диапазон на больших FPS у матрицы, кстати, меня разочаровал...
  10. На Win7 рандомно падает. Если после перезапуска попытаться открыть рабочую область, падает. Надо чистить ".plugins" и заново импортировать рабочую область.
  11. В общем разобрался... Я не совсем правильно понимал суть автосогласования. Для получения полного дуплекса необходимо оставить автосогласование, но при этом убрать из поддерживаемых режимов гигабит. В этом случае соединение установится на 100 МБит, полный дуплекс. Разобрался по исходникам драйверов для 88E1512 для Zynq. Там если проследить всю последовательность, то становится ясно... 10ff, спасибо!
  12. Попробовал - тогда соединение происходит на 1000 (за счет того, что бит автосогласования установлен)...
  13. 1. Инициализирую так: записываю в IEEE_AUTONEGO_ADVERTISE_REG (регистр №4) значение 0x141 (описано в предыдущем посте), записываю в IEEE_1000_ADVERTISE_REG_OFFSET (№9) значение 0x300 (поддерживаю half и full duplex на 1000), записываю в IEEE_CONTROL_REG_OFFSET (№0) значение 0x2100 - режим дуплекс и 100 МБит. Потом делаю программный сброс (бит 15 регистра IEEE_CONTROL_REG_OFFSET), жду окончания сброса. Вроде все. 2. Свич хороший: HP-1820-8G. Кабель менять пробовал. Интересно, что несмотря на фактический полудуплекс, 88E1512 при чтении регистра IEEE_SPECIFIC_STATUS_REG (№17) там установлен бит full-duplex... Смущает так же то, что если перевести порт свича в полный дуплекс, то соединение получается на реальном полном дуплексе...
  14. Добрый день. Столкнулся с проблемой: 88E1512 на 100МБит (принудительно задал) стартует всегда в half-duplex, при этом регистр №4 (Copper Auto-Negotiation Advertisement Register) выставлен в 0x141, т.е. микруха не должна поддерживать 100МБит half-duplex. При этом свич (порт выставлен в автосогласование), в который воткнута сеть, показывает half-duplex (ожидаемо), и позволяет переключить сеть в full-duplex и 88E1512 соединяется и функционирует нормально в full-duplex (что не ожидаемо)... Периодически проверял регистр "Copper Auto-Negotiation Advertisement Register", записанное значение сохраняется, т.е. 0x141. По ощущениям скорости передачи данных half-duplex реально есть, при переключении свича в full-duplex скорость обмена ощутимо возрастает. Может кто сталкивался? Может еще какие регистры надо записать или еще что сделать? (спрашивал в ветке про интерфейсы - там молчат...)