Jump to content

    

Winger11

Участник
  • Content Count

    10
  • Joined

  • Last visited

Community Reputation

0 Обычный

Recent Profile Visitors

628 profile views
  1. Добрый день. Вернусь в Питер на след неделе. Сейчас в Москве. Модбасовские приборы делаю. С STM прибором возможно мог бы заняться. FRERTOS пока не применял , сейчас планирую в своем текущем проекте ставить. Если честно, то работа с прицелом на разных программеров правильная. Но, только операционка для этого нужна в последнюю очередь. Начинается такая работа с разработки архитектуры обработки данных. Это список переменных и вычислительные схемы их обработки. Это прорабатывается на бумаге. Выделяются переменные доступные по модбасу. Расписывается карта регистров. Для разных приборов имеет смысл подумать об унификации параметров. Расписываются структуры параметров, которыми будет оперировать прибор. Расписываются функции обработки данных,  конфигурирования переферии и обмена. Выбираются временные сетки. ОС нужна только в ряде специфических случаев, когда имеем дело с разделяемым ресурсом. Например, с подчиненным процессором должны обмениваться несколько разных задач, при условии, что необходимость может возникнуть в произвольное время.

    https://www.elemer.ru/catalog/raskhodomery/raskhodomery-schetchiki-elektromagnitnye/elemer-rem/

    текущий проект. Измериловка не моя,  а мое модуль с индикатором. Он там с менюшками и модбасовским обменои.

  2. Как уже написали выше, RTOS вполне влезает - конкретно про FreeRTOS подробно изложено вот тут: https://www.microchip.com/en-us/application-notes/an3007 Зачем хотим обязательно RTOS - для единообразия разработанного софта и возможности дальнейшей самостоятельной поддержки оного. Почему получился зоопарк платформ - устройства разрабатывались в разное время, и умы были в постоянном творческом поиске :) В будущем планируем единообразие. Насчет ЦОС - да, из описания этого не следует, но ЦОС планируется на STM, не на Атмеге.
  3. Приветствую! Есть линейка самодельных датчиков, работающих по Modbus через RS-485. Два датчика на ATMega4808, один на AVR128DA64T-I/PT, на подходе датчик на STM32G431KBT6. Задача - разработать прошивку на эти устройства. ТЗ - что хотим получить от каждого устройства - имеются. В целом, каждое устройство должно: а) опрашивать чип-сенсоры в целях получения значений измеряемого параметра (температуры, давления в ближайшем будущем - вибрации), б) производить некоторый набор действий над первичными данными - от банального сопоставления по LUT-ам до некоторой не слишком сложной ЦОС. в) хранить данные и выдавать по протоколу Modbus на хост-устройство. Обязательное требование - должно работать под RTOS. Мы находимся в Питере, варианты удаленного сотрудничества тоже рассматриваем. Т.е. возможен как вариант "выдали на руки устройство, разрабатываете прошивку, проверяете самостоятельно", так и "разработали прошивку, мы проверяем сами". Сами устройства уже проверены (все интерфейсы работают), есть также полный набор необходимых отладочных плат. Оплату будем обсуждать предметно. Контактный e-mail: ilya.kutuev@tunneltech.eu
  4. Спасибо большое, всё получилось - просто в папке src валялся vhdl-файл от предыдущих попыток, и IP Packager цеплялся за него вместо xci. Я сначала весь RTL отлаживаю в HDL Designer'e, потом запаковываю проект в IP и синтезирую средствами Вивады. Последнее время на Альтере все делал, поэтому с механизмом подключения сгенеренных модулей в Виваде проблема возникла. Сейчас заработало, вроде бы, спасибо!
  5. Пробовал так, но тогда выдается ошибка при синтезе: [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.
  6. Приветствую! Подскажите пожалуйста, как правильно использовать созданное в Виваде 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. В общем, нужна помощь. Заранее спасибо!
  7. А пример констрейна для этого можете прислать? Остальное, что вы написали, я, вроде бы, учел. Слэков нет, но что-то плывёт :) Сейчас еще посмотрел в example_design ядра - там пины для всей шины rgmii обозначены с IOSTANDARD HSTL_I_18. Может быть, этот High Speed имеет значение...
  8. Я пробовал и так, и так. Даже если не сдвигать вручную, в ядре есть настройка "include shared logic in Core", и в этом случае ядро само делает сдвинутый на 90 градусов клок. Я посмотрел схематику implemented design - там все корректно. Внутри ядра имплементируется MMCM, несдвинутый клок используется для всей логики ядра, а также выдается наружу в качестве tx_clk, чтобы тактировать этим клоком всю пользовательскую логику, относящуюся к TX. А сдвинутый на 90 клок из этого внутреннего ММСМ выдается на тактовую линию rgmii_txc, чтобы внешний PHY мог ее использовать для тактирования линий данных rgmii_txd[3:0] и rgmii_tx_ctl. И в регистры PHY я прописываю, чтобы он брал этот клок для тактирования и не добавлял от себя дополнительной задержки.
  9. Подскажите, пожалуйста, у кого есть удачный опыт применения данного 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 тактируются некорректно. Заранее спасибо
  10. Я, возможно, не совсем корректно выразился - в самом модуле, где происходит перетактовка, у меня, конечно же, стоит двухпортовая память.
  11. Есть модуль, который принимает данные на одной частоте, отдает на другой. Оба клока (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