Winger11

Как уже написали выше, RTOS вполне влезает - конкретно про FreeRTOS подробно изложено вот тут: https://www.microchip.com/en-us/application-notes/an3007 Зачем хотим обязательно RTOS - для единообразия разработанного софта и возможности дальнейшей самостоятельной поддержки оного. Почему получился зоопарк платформ - устройства разрабатывались в разное время, и умы были в постоянном творческом поиске :) В будущем планируем единообразие. Насчет ЦОС - да, из описания этого не следует, но ЦОС планируется на STM, не на Атмеге.

Приветствую! Есть линейка самодельных датчиков, работающих по Modbus через RS-485. Два датчика на ATMega4808, один на AVR128DA64T-I/PT, на подходе датчик на STM32G431KBT6. Задача - разработать прошивку на эти устройства. ТЗ - что хотим получить от каждого устройства - имеются. В целом, каждое устройство должно: а) опрашивать чип-сенсоры в целях получения значений измеряемого параметра (температуры, давления в ближайшем будущем - вибрации), б) производить некоторый набор действий над первичными данными - от банального сопоставления по LUT-ам до некоторой не слишком сложной ЦОС. в) хранить данные и выдавать по протоколу Modbus на хост-устройство. Обязательное требование - должно работать под RTOS. Мы находимся в Питере, варианты удаленного сотрудничества тоже рассматриваем. Т.е. возможен как вариант "выдали на руки устройство, разрабатываете прошивку, проверяете самостоятельно", так и "разработали прошивку, мы проверяем сами". Сами устройства уже проверены (все интерфейсы работают), есть также полный набор необходимых отладочных плат. Оплату будем обсуждать предметно. Контактный e-mail: [email protected]

Спасибо большое, всё получилось - просто в папке src валялся vhdl-файл от предыдущих попыток, и IP Packager цеплялся за него вместо xci. Я сначала весь RTL отлаживаю в HDL Designer'e, потом запаковываю проект в IP и синтезирую средствами Вивады. Последнее время на Альтере все делал, поэтому с механизмом подключения сгенеренных модулей в Виваде проблема возникла. Сейчас заработало, вроде бы, спасибо!

Пробовал так, но тогда выдается ошибка при синтезе: [DRC INBB-3] Black Box Instances: Cell 'design_1_i/cc_if_0/U0/ps_pl_interface_top_inst/pkt_prop_FIFO/U0' of type 'design_1_cc_if_0_0_fifo_generator_v13_2_2' has undefined contents and is considered a black box. The contents of this cell must be defined for opt_design to complete successfully.

Приветствую! Подскажите пожалуйста, как правильно использовать созданное в Виваде FIFO? 1) Создаю FIFO с помощью IP fifo_generator (через вкладку IP Catalog) 2) Сгенеренный файл fifo_generator.vhd подключаю к проекту в HDL Designer'e 3) После успешной симуляции проекта создаю IP в Виваде и добавляю в него все файлы проекта (в т.ч. и fifo_generator.vhd) 4) В IP Packager'e видно, что модуль fifo_generator ищет модуль fifo_generator_v13_2_2 и не находит. Видимо, надо подключать не vdhl-файл, а какой-то другой, или же вообще добавлять библиотеку с этим ФИФО на уровне проекта, а не в IP Packager. В общем, нужна помощь. Заранее спасибо!

А пример констрейна для этого можете прислать? Остальное, что вы написали, я, вроде бы, учел. Слэков нет, но что-то плывёт :) Сейчас еще посмотрел в example_design ядра - там пины для всей шины rgmii обозначены с IOSTANDARD HSTL_I_18. Может быть, этот High Speed имеет значение...

Я пробовал и так, и так. Даже если не сдвигать вручную, в ядре есть настройка "include shared logic in Core", и в этом случае ядро само делает сдвинутый на 90 градусов клок. Я посмотрел схематику implemented design - там все корректно. Внутри ядра имплементируется MMCM, несдвинутый клок используется для всей логики ядра, а также выдается наружу в качестве tx_clk, чтобы тактировать этим клоком всю пользовательскую логику, относящуюся к TX. А сдвинутый на 90 клок из этого внутреннего ММСМ выдается на тактовую линию rgmii_txc, чтобы внешний PHY мог ее использовать для тактирования линий данных rgmii_txd[3:0] и rgmii_tx_ctl. И в регистры PHY я прописываю, чтобы он брал этот клок для тактирования и не добавлял от себя дополнительной задержки.

Подскажите, пожалуйста, у кого есть удачный опыт применения данного IP. Использую его в режиме 1 Gb с внешней шиной RGMII. Снаружи на плате стоит внешний PHY-чип, который позволяет запускать встроенный генератор пакетов в сторону МАС, а также реализовывать loopback. С приемом пакетов от генератора, вроде бы, все нормально. А вот когда я посылаю пакет по RGMII и принимаю его обратно, начинаются проблемы, на каком-то этапе сигнал явно не так тактируется. Т.е. я, к примеру, посылаю пакет 0х01 0х02 0х30 0х40 0х05 0х06, а получаю 0х01 0х02 0х00 0х00 0х05 0х06. Поскольку в RGMII сигнал тактируется обоими фронтами клока по 4 бита, тут явно ситуация, когда один фронт не попадает в данные. Само ядро в плане тактовых сигналов не особо сложное - если в настройках указать "include shared logic in Core", то на вход достаточно подать 125 МГц и 200 МГЦ для блоков idelayctrl. Правда, потом нашел в описании фразу: "HR I/O do not include ODELAY components and another method is required to introduce the required 2 ns offset between the clock and data". У меня как раз используются HR-пины, т.е., насколько я понял, надо самому на MMCM делать 2 частоты 125 МГц, смещенные на 90 градусов друг относительно друга, и подавать их на ядро. Реализовал такую схему, но эффекта никакого - выходные данные RGMII тактируются некорректно. Заранее спасибо

Я, возможно, не совсем корректно выразился - в самом модуле, где происходит перетактовка, у меня, конечно же, стоит двухпортовая память.

Есть модуль, который принимает данные на одной частоте, отдает на другой. Оба клока (155 и 250 МГц) порождаются внутри схемы - один внутри Ethernet PHY, второй внутри PCIe-IP. Quartus выдает дикие слэки - больше 5нс, из которых около 80% приходится на clock delay (ровно 5нс, еще примерно 0.8нс - data delay). Пробовал разные констрейны, результат не меняется: //Запихиваю длинные пути к клокам, на которые ругается Quartus, в переменные set clk1 system|wrapper_mux_avl_2ch|phy_10gbaser_inst|...|g_fpll.altera_pll_156M~PLL_OUTP UT_COUNTER|divclk set clk2 system|pcie_256_dma|altera_s5_a2p|altpcie_hip_256_pipen1b|stratixv_hssi_gen3_pci e_hip|coreclkout //Вариант 1: set_false_path -from [get_clocks {$clk1}] -to [get_clocks {$clk2}] //Вариант 2: set_clock_groups -exclusive -group {$clk1} -group {$clk2} Подскажите, пожалуйста, что я делаю не так. Qusrtus 14, Stratix V