xxxmatrixxx

Здравствуйте, уважаемые форумчане реализовал выход Sdi и вход на одном блоке реализация такая: блок выполнен в виде 2х плат: - основная плата, где стоит Плис, выведены пины с Xcvr приемника и передатчика на разъем - канальный уровень Sdi реализован в Плис на основе IP Core SDI II, как приемопередатчик в режиме 3G - вспомогательная плата, на ней стоит разъем для связи с основной платой, реализация физического уровня на 2х микросхемах LM0387, одна сконфигурирована, как передатчик, другая как приемник - жгут, соединяющий основную и вспомогательную плату, а так же кабель Рк-75, который вытягивает SDI Rx и Tx на Bnc разъем крышки блока сейчас передача со стороны блока идет всегда корректно, но прием всегда со сбоями: - если замыкаем вход на выход на крышке блоке кабелем, либо через монитор lilipot, где есть sdi вход, а также петля на выход со входа, то в некоторых случаях корректно работает, бывает искажения изображения в виде промаргивания или исчезновения, затем заполнение экрана каким-либо цветом, и появление опять верной картинки - если брать внешний выход с SDI, например, Roi-Dvi, то всегда идет, как заполнение экрана каким-либо цветом сверху вниз в случайном порядке, нормальной картинки при приеме не добиться В Плис IP модуль сконфигурирован под 3G-SDI(qsys файл прикладываю sdi_converter.qsys) при этом констрейны стандартные, которые идут к самому модулю, а также на тот клок, которым я стробирую данные на Clockes Video Input {sdi_converter_inst|sdi_ii_0|u_phy|gen_native_inst.av_xcvr_native_insts[0].gen_bonded_group_native.av_xcvr_native_inst|inst_av_pcs|ch[0].inst_av_pcs_ch|inst_av_hssi_8g_rx_pcs|wys|rcvdclkpma}] -divide_by 2 [get_registers {sdi_doublepix_clk}] у меня следующие вопросы: 1. был ли у кого опыт работы с данной коркой: - как она отрабатывала на прием? - какие модули для SDI 3G использовали? - не могли бы поделиться проектом, тестовым или рабочим, чтобы можно было сравнить 2. т.к. из-за стремления к универсальности пришлось разбить SDI на подмодули, поэтому могут быть проблемы с приемом SDI на уровне: - жгута между основной и второстепенной платой - все SDI на прием только свиты, шаг минимально возможный, длина кабеля 20см - может еще что необходимо, например, экранировать и каким образом? - подключением самого приемопередатчика LMH0387 и его конфигурация * питание на микросхему поступает с импульсника, а не линейника - критично ли это? * есть ли у кого опыт с данной микросхемой, были ли может кто кусок схемы скинет - кабель РК75,который идет от второстепенной платы к BNC разъемам крышки имеет в 3х местах изгибы в 90 град - допустимо ли это для SDI? бьюсь с этой проблемой уже мес 3... пока не получается сдвинуться... спасибо, буду рад любой помощи

ищите ли вы еще подработку? очень интересен ваш опыт с Ecos

Требуется программист для портирования Ecos v3.0 на процессор Lx2160a и платформу LX2160A Computer on Module: 1. разработать и запустить redboot на LX2160A Computer on Module, который будет вкл: - hal Armv8A - hal CortexA72 - hal Uart, Spi(Qspi) Flash 2. собрать и запустить Ecos под LX2160A Computer on Module, который будет вкл: - hal Ethernet -hal DPAA2 все этапы возможно разбить на подэтапы и отчитываться по ним территориально находится фирма в СПБ, возможна удаленная, по подряду работа... рассмотрим любые варианты сотрудничества просьба писать в личку

Есть ли у кого под Ecos исходники HAL под процессор Armv8(Cortex-a72, Cortex-a53)? в состав Ecos Pro этот проц входит, судя по описанию на сайте, а вот в простом бесплатным дистрибутиве Ecos его нет

там если userguide на LX2160A_DPAA2RM_RevA_1707 содержит 1600 стр, то я запарюсь в этом разбираться, исходя из ассемблерного кода... сам бинарник для работы с DPAA2 весит 7 Мб... и при сертификации будут смотреть весь исходный код, так что здесь не получится просто отчетом отделаться... я поспрашивал у дистрибьютеров, сейчас срок поставки на АЦП от NXP в среднем около года, но мое доблестное руководство настаивает, что мы сможем их достать, путем покупки самих процов, либо киты купят и с них снимут... короче, как они сделают, я не знаю, я хотел почву прощупать...

Здравствуйте, уважаемые форумчане сейчас встала задача на применение процессора LX2160A от компании NXP в первую очередь, заинтересовало большое количество Ethernet интерфейсов, а также высокая производительность но для реализации передачи данных по Ethernet они используют DPAA2, который представляет собой типо аппаратного блока ускорителя, который управляется предоставляемым ими бинарником, но вот исходного кода нет на него, а мне необходимо сертифицировать написанное ПО, одним из самых главных пунктов при этом является открытость исходников у меня следующие вопросы: 1. есть ли возможность передавать данные по Ethernet, не используя DPAA2, т.е. напрямую или еще каким образом? 2. есть ли у кого исходники DPAA2, не могли бы поделиться(до войны нам получилось договориться с NXP о предоставлении исходников на DPA1, предыдущей версии DPAA2, сейчас NXP никакой поддержки не осуществляет, и первыми перекрыли все каналы) 3. у нас сейчас встал острый вопрос о доставаемости данного процессора LX2160A, может кто поделиться опытом, получалось ли доставать процессоры NXP, в том числе и LX2160A? спасибо, буду рад любой помощи

Удалось победить эту проблему, опишу, может кому пригодится: 1. кабеля, которые передают EDP на сторону PTN3460 сигнальные дифпары должны иметь минимальный шаг свивки -> после этого стал проходить Link Training 2. в PTN3460 считывается по AUX в регистрах, что он поддерживает работу в версиях протоколов DP 1.1 и eDP1.2, но необходимо работать только в одном из них не переключаясь динамически с одного на другой(мы установили желазно DP 1.1) -> после этого появилось стабильно видео на выходе PTN3460 3. для устранения искажений видео от PTN3460 к Матрице по 2xLVDS в кабеле сигнальные дифпары должны иметь минимальный шаг свивки, а также на стороне передатчика поставить фериты

Здравствуйте, уважаемые форумчане необходимо преобразовать интерфейс DisplayPort в 2x пиксельный Lvds на PTN3460 кратко опишу схему: 1. есть 2а узла - основной и вспомогательный, которые связаны между собой кабелем 2. на основном узле стоит Плис , на ней реализован IP модуль DisplayPort ver. 1.2, он выходит на разъем 3. на вспомогательном узле установлен Ptn3460I, которая принимает Displayport от основного узла и преобразует в 2xLvds, который далее через разъем идет на матрицу схему прилагаю Edp_осн_и всп_ плата.pdf сейчас результаты получены такие: 1. если с основного узла напрямую ДРУГИМ кабелем подключить на другую матрицу(не используя вспомогательный узел), где есть DisplayPort, то изображение выводится на матрицу отлично(NL192108BC18-06F NL192108BC18-06F.pdf) 2. если подключить кабелем основной узел к вспомогательному, то Ptn3460 не генит Lvds поток(я не вижу осцилом ни клока, ни данных), при подключенной матрице или без нее(GV185FHM-N10-DM30 GV185FHM-N10-DM30.pdf) при этом пин PVCCEN на Ptn3460i выставляется на очень малое время в 1, что означает, что он воспринял начало потока DisplayPort, а затем уходит в 0 3. запись и чтение регистров по I2C микросхемы Ptn3460I происходит штатно, Шим получается вкл/откл через AUX и I2C принудительно, т.е. микросхема живая Основная проблема, что Ptn3460i не генерирует 2xLvds поток при наличии потока по DisplayPort Был ли у кого опыт работы с этой микросхемой, не могли бы им поделиться? может есть у кого идеи, куда еще посмотреть, в какую сторону копать? спасибо, буду рад любой помощи

Здравствуйте, уважаемые форумчане сейчас стоит задача собрать под процессор NXP LX2160(16 х Arm Cortex-A72), тестовая плата LX2160A COMPUTER ON MODULE - redboot - ecos v3.0 я собрал Linux и uboot, кроскомпилятор через скрипт, который рекомендован производителем проца ( https://github.com/SolidRun/lx2160a_build ), скопировал на флэшку, все запустилось... у меня был только опыт сборки и конфигурирования Linux, которые рекомендованы производителем, но не как с Ecos, где надо самому описывать весь hal уровень, в том числе и архитектуру процессора уже больше мес курю документацию на Ecos, пересмотрел примеры в github, но так не выстроилась четкая картина, как хотя бы собрать redboot для него вот что у меня пока не складывается: - как описать процессор для redboot, - что надо по минимуму сделать, чтобы redboot запустился на новом процессоре - как его запустить на новом проце, т.е. redboot должен быть загрузчиком 2го уровня? у меня просьба, хотя бы направить, что почитать, куда посмотреть, потому что документация по Ecos(с моей точки зрения) - это скорее документация к тому. что у тебя уже все стоит и настроено, осталось писать код под нее спасибо, буду рад любой помощи

я дома отлаживал, идея была в том, что какая-то команда не успевала отработать на контроллере ILI9341, какая именно не выяснял и не хотел... поставил везде задержки, это помогло, значит, мое предположение было верно а функция инициализации отрабатывает 1 раз в самом начале, приложение у меня без ОС

огромное спасибо за ответы!!! пересмотрел все - и настройки дебагера, и компиляции, и выделяемая память под STEmWin, различные приемы конфиуграции, откл весь код свой, только вывод изображения - косяк остался но явно было видно, что уже дело в инициализации самого контроллера ILI9341, либо подключение драйвера полез смотреть драйверную часть, как подключал, все перепроверил, поэкспериментировал с настройками - все равно косяк остался полез смотреть инициализацию ILI9341 и когда между командами поставил задержку в 1мс, сразу все заработало без сбоев void LCD_Init(void) { #if LCD_DATA == 1 HAL_GPIO_8Bus_Init(); delay_us(100); #endif LCD_U_IM DWT_Init_for_delay_us(); //HAL_SetLedK(lcd_leds); LCD_Reset(); LCD_Wr_Cmd_8(SOFTWARE_RESET); delay_us(100); LCD_Wr_Cmd_8(POWER_CONTROL_1); delay_us(1000); LCD_Wr_Data_8(0x25); delay_us(1000); LCD_Wr_Cmd_8(POWER_CONTROL_2); delay_us(1000); LCD_Wr_Data_8(0x01); delay_us(1000); LCD_Wr_Cmd_8(VCOM_CONTROL_1); delay_us(1000); LCD_Wr_Data_8(0x2B); delay_us(1000); LCD_Wr_Data_8(0x2B); delay_us(1000); LCD_Wr_Cmd_8(VCOM_CONTROL_2); delay_us(1000); LCD_Wr_Data_8(0x06); delay_us(1000); LCD_Wr_Cmd_8(COLMOD_PIXEL_FORMAT_SET); delay_us(1000); LCD_Wr_Data_8(0x05); delay_us(1000); LCD_Wr_Cmd_8(FRAME_RATE_CONTROL_NORMAL); delay_us(1000); LCD_Wr_Data_8(0x00); delay_us(1000); LCD_Wr_Data_8(0x18); delay_us(1000); LCD_Wr_Cmd_8(DISPLAY_FUNCTION_CONTROL); delay_us(1000); LCD_Wr_Data_8(0x0A); delay_us(1000); LCD_Wr_Data_8(0x82); delay_us(1000); LCD_Wr_Data_8(0x27); delay_us(1000); LCD_Wr_Cmd_8(COLMOD_PIXEL_FORMAT_SET); delay_us(1000); LCD_Wr_Data_8(0x55); delay_us(1000); LCD_Wr_Cmd_8(SLEEP_OUT); delay_us(1000); LCD_Wr_Cmd_8(DISPLAY_ON); delay_us(1000); LCD_Orientation(DEFAULT_ORIENTATION); //LCD_Rect_Fill(0, 0, LCD_HEIGHT, LCD_WIDTH, BLUE); //delay_us(1000000); //LCD_Rect_Fill(0, 0, LCD_HEIGHT, LCD_WIDTH, RED); //delay_us(1000000); } всем спасибо, проблема решена!!!

среднее значение думал об этом, пробовал подсовывать вместо вычисляемых значений чисто константы - текст все равно искажается меня смущает искажение именно на этих элементах(SpinBox, Edit, MultiEdit), на остальных элементах не искажается текст вот выделение памяти 'Invoking: GNU ARM Cross Print Size' arm-none-eabi-size --format=berkeley "stm32_depth.elf" text data bss dec hex filename 227928 3744 112240 343912 53f68 stm32_depth.elf 'Finished building: stm32_depth.siz' и сам линковщик STM32L496ZGTx_FLASH.ld сразу стал проверять, посмотрел времянку осцилом, т.к. передаю данные на дисплей по FSMC, а считываю данные от тачскрина по SPI я увеличил тайминги FSMC, но это не привело к улучшению результата, да и там дается определенные схемы работы,т.е. не все сигналы могу подвинуть да и как-то при такой ситуации, где виноват FSMC, неясно, почему остальные символы текстовые не искажаются у меня используется контроллер stm32l496, там стоит up to 1 Mbyte of Flash memory, 320 Kbyte of SRAM у меня сейчас занято меньше половины спасибо за ответ, пересмотрю еще раз то, что вы указали

Здравствуйте, уважаемые форумчане Для отрисовки графики использую библиотеку STEmWin, сейчас борюсь со следующей проблемой: - 1 раз из 5 включений модуля шрифт текстовых полей SPINBOX, EDIT, MULTIEDIT искажается, при этом никогда не искажается текст в кнопках (BUTTONS) и простые текстовые поля(TEXT) - если при вкл текст исказился, то при перересовки окон он все равно искажается и наоборот(я переключаюсь между 3мя окнами, при этом одно закрываю, а другое открываю): GUI_EndDialog(hWin_SetConfig, 0); // закрывается текущее hWin_Result = GUI_CreateDialogBox(_aDialogCreate, GUI_COUNTOF(_aDialogCreate), _cbDialog, WM_HBKWIN, 0, 0); // вызывается для другого окна(находится в другом файле) - заметил такую тенденцию, что если добавить при отрисовки элемента функцию задающую цвет текста, причем обязательно с параметром EDIT_CI_ENABLED, то искажение текста при вкл уменьшаются SPINBOX_SetTextColor(hItem, EDIT_CI_ENABLED, GUI_MAKE_COLOR(GUI_BLUE)); EDIT_SetTextColor(hItem, EDIT_CI_ENABLED, GUI_MAKE_COLOR(GUI_BLUE)); Вот картинка при нормальном включении: Вот картинка при включении, когда искажается текст: также прикладываю исходники инициализации STEmWin Conf.rar и как я отрабатываю ее в main: res = GUI_Init(); uart_printf("\033c\r\n"); uart_printf("|||||||||||||||||||||||||||||||||||||||\r\n"); uart_printf("Init MCU Complete\r\n"); uart_printf("Version Program: %s (%s %s) \r\n", VERSION_PROGRAM, __DATE__, __TIME__); Work_Init(); GUI_SelectLayer(0); TS_State.Layer = 0; TS_State.Pressed = 0; WM_MULTIBUF_Enable(0); hDlg = GlCreateWindow_SetConfig(); //HAL_LPTIM_Counter_Start_IT(&hlptim1,200); GUI_Clear(); while (1) { if(TS_State.Pressed){ //uart_printf("T_IRQ: x = %d, y = %d\r\n",TS_State.x,TS_State.y); TS_State.Pressed = 0; GUI_TOUCH_StoreStateEx(&TS_State); } GUI_Delay(10); //GUI_Exec(); } буду рад любой помощи, уже бьюсь с этой проблемой почти неделю... спасибо, жду ответа

спасибо большое за ответы я не знаю об этих смазках, не могли написать какие?

1. какие вместо имеющихся поставить соединители, исходя из опыта, чтобы гарантированно был контакт хороший? 2. как улучшить при минусовой температуре качество контакта между уже использованными соединителями? я пробовал протирать спиртом контакты соединителей, осуществлять сборку блока таким образом, чтобы контакт между соединителями был более плотным (как мне казалось), при этом многим блокам это помогало, они выдерживали испытание на минусовой температуре

это 2а исполнения блока, в которых функционал разный, но вот интерфейсы одни и теже(Arinc429, Arinc708...) - они для разных целей предназначались

на другом исполнения блока в другом конструктиве (одна плата, вместо 3х) мы именно так и сделали, и проблем, что имеем выше не имеем там - поэтому вопрос и встал насчет плохого контакта

Здравствуйте, уважаемые форумчане у нас есть блок, в котором есть 2 платы, на которых реализуется функционал, и еще одна плата, которая является кросс-платой: используем следующие соединители: 1. на вычислительных платах стоит ERF8-040-01-L-D-RA-TR(https://www.farnell.com/datasheets/1927683.pdf) , УГЛОВОЙ 2. на кросс-плате стоит ERM8-040-02.0-L-DV-TR(https://www.farnell.com/datasheets/2260768.pdf), ПРЯМОЙ Проблемы в следующем: 1. начиная с -15 гр Цельсия появляются ошибки при передачи данных по низкоскоростным интерфейсам(Arinc429 на 100Кбит/с, Arinc708 на 1Мбит/с) 2. как только прогреваем блок до + температуры, все работоспособность восстанавливается скорее всего проблема в плохом контакте: 1. между соединителями выч модулей и соединителем кросс-платой 2. т.к. ERF8-040-01-L-D-RA-TR УГЛОВОЙ, и 2й ряд находится под соединителем, то нет возможности проконтролировать качество пайки этого ряда к плате пытались чистить контакты и прижимать соединители более близко друг к другу, но не помогает, данная проблема у нас происходит на многих изготовленных блоках, но на 100% не получается ее устранить Вопросы в следующем: 1. есть ли какие-нибудь технологии, средства, методы, чтобы улучшить контакт соединителей при отрицательной температуре? может, кто своим опытом поделится 2. хочется подобрать аналоги данных соединителей, где будет более лучший контакт, а также хочется, чтобы не было в этих соединителях скрытых рядов для пайки буду рад любой информации, особенно если поделитесь опытом!!!

Здравствуйте, уважаемые форумчане необходимо генить синусоиду через ЦАП AD9122 на данный момент написан тестовый модуль, который генерирует ее вот в таком виде: Сделал IP модуль ЦАПа AD9122, который принимает 32х разрядные данные и затем в байтовом режиме выдает данные на ЦАП, причем реализацию сделал 2х модулей : 1. ALTDIO_OUT стоит только на данных, а DCLK и FCLK генятся через логику и выдаются на пинdac_ddr_phy_only_data_ddr.sv 2. ALTDIO_OUT стоит на данных, DCLK и FCLK, все тактируются от одного клокаdac_ddr_phy_all_ddr.sv написал констрейны: #************************************************************** # DAC_DDR #************************************************************** post_message -type info "READ dac_ddr.sdc" set dac_ddr_phy_clk { main_pll_inst|main_pll_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|divclk } set Tco_max 0.65 set Tco_min -0.05 post_message -type info "CLOCK_FREQ_DCLK_HZ = $dac_ddr_phy_clk" post_message -type info "Output Max Delay = $Tco_max" post_message -type info "Output Min Delay = $Tco_min" # Create the external virtual PHY clock create_generated_clock \ -name dac_ddr_dclk \ -source [get_pins "$dac_ddr_phy_clk"] \ [get_ports {DAC_DIC}] #*********************** OUTPUT ************************* set_output_delay -clock [get_clocks {dac_ddr_dclk}] -max $Tco_max [get_ports {DAC_D*}] set_output_delay -clock [get_clocks {dac_ddr_dclk}] -min $Tco_min [get_ports {DAC_D*}] #*********************** GROUP ************************* set_clock_groups -exclusive -group [get_clocks {dac_ddr_dclk}] все пины определены, как LVDS_E_3R в Quartus на Си реализовал HAL уровень dac_ad9122.rar функция инициализации: - spi_dac_ad9122_setup_nav - без фильтров - spi_dac_ad9122_setup - с фильтрами, пример от AnalogDevices проблема в том, что генится с ЦАП вот такой сигнал: При это я использовал код инициализации ЦАП, который рекомендован AnalogDevices с включенными фильтрами, если просто настроить на байтовый режим с выключенными фильтрами, то картинка вот такая: неясно откуда берется эта пила, скорее всего искажение данных, но в каких битах или порядке байтов не могу понять.... При этом в самой схемотехнике перепутаны диaпары данных и FCLK при подключении к ПЛИС, я это решаю для: - 1го варианта модуля инвертированием данных до ALTDDIO_OUT, FCLK просто инвертирую на выходе - 2го варианта модуля инвертированием данных и FCLK до ALTDDIO_OUT пробовал запускать тест, чтобы проверить принимаемые данные ЦАПом 1. если генить DCLK постоянно, а данные и FCLK подставлять, когда данные валидны, то выдаются ошибки постоянно во всех битах 2. если генить DCLK только в сопровождении валидных данных, то ошибок нет, даже когда посылаю 0x0 в ЦАП и в Im и Qre, а в COMPARE REG записаны допустим 0xaa55aa55, если подать верные данные, то таже тема Пробовал кидать одиночные данные и смотреть их прямо на выходе ЦАПа, то видно что выдаются 2а импульса, хотя данные посылаю 1 раз, при этом со времянкой все верно сделано Пробовал выдавать счетчик, который считает от 0 до 0хFFFF, потом сбрасывается и опять считает, на каждый канал Im и Qre, при этом вижу следующее на осциле: Без фильтров: c фильтрами: синий луч Im, желтый луч Qre Не понятно, почему вообще выдает не нарастание линейное, а резкий всплеск по амплитуде и угасание по экспоненте Бьюсь уже 2ю неделю, пока мыслей нет, в каком направлении двигаться Может есть у кого пример реализации.... Буду рад любой помощи, спасибо

У нас есть SVN, есть GitLab, есть незакоммиченные версии на компах сотрудников - поэтому хочется знать, что именно с этих исходников были скомпилены данный sof и jic файлы, исключить человеческий фактор

Здравствуйте, уважаемые форумчане возникла такая необходимость, чтобы идентифицировать прошивку Плис, т.е. какие поля в прошивке, либо при генерации прошивки необходимо иметь и что они должны содержать, чтобы четко понимать, что именно из этих исходников была собрана данная версия прошивка Сейчас решили ввести - идентификатор(версия ПО, типо 01.02.03), crc, номер ревизии в svn, подгружаемый через tcl скрипт при компиляции, и хэш-ссылку - сделали много полей, т.к. при компиляции проекта даже из одних и тех же исходников, развестись может по-разному может кто подскажет, какие поля лучше иметь для решения этой задачи? и как получить с Quartus, или еще откуда данную инфу( например, пытались найти crc в rbf файле, но так и не выяснили, какое в нем поле) спасибо, буду рад любой помощи)

Здравствуйте, уважаемые форумчане стоит задача внедрить в разработанные модули интерфейс Arinc-818 может кто поделиться: 1. стандартом на Arinc 818 2. есть ли у кого IP Core под Arinc 818 3. есть ли у кого пример реализации схемотехники для Arinc-818 спасибо, буду рад любой помощи

так вот сейчас я и посмотрел, что хоть библиотеку находит, но вот функции не подгружает... я скачал с официального сайта, подо что скомпилирована библиотека не помню... тогда вопрос следующие: 1. есть ли возможность использования EmWin под NiosII? 2. просмотрев просторы интернета, я наткнулся на библиотеку китайцев uGUI, на основе которой получилась EmWin: - был ли у кого опыт с ней? - есть ли у кого исходники, чтобы можно скомпилить? 3. какие библиотеки для отрисовки графики и получения координат с тачскрина использовали?

Здравствуйте, уважаемые форумчане встала задача, чтобы выводить изображение с ПЛИС EP3C25Q240, а так же отслеживать нажатие на экране через тачскрин я имел опыт работы с библиотекой StEmWin под STM32L496, хочу в первую очередь использовать ее родоначальника EmWin в проекте Скачал библиотеку EmWin с официального сайта Segger, собираю проект в Eclipse NIOS версии 13.1 без использования ОС, подключил библиотеку, сейчас при компиляции вижу следующее: C:\PROJECTS\Neptun\bukvaverilog_new\software\bukvaverilog_de0nano/GUI/Config/GUIConf.c:58: undefined reference to `GUI_ALLOC_AssignMemory' obj/default/GUI/Config/LCDConf.o: In function `LCD_X_Config': C:\PROJECTS\Neptun\bukvaverilog_new\software\bukvaverilog_de0nano/GUI/Config/LCDConf.c:99: undefined reference to `GUIDRV_Win_API' C:\PROJECTS\Neptun\bukvaverilog_new\software\bukvaverilog_de0nano/GUI/Config/LCDConf.c:99: undefined reference to `GUIDRV_Win_API' C:\PROJECTS\Neptun\bukvaverilog_new\software\bukvaverilog_de0nano/GUI/Config/LCDConf.c:99: undefined reference to `LCD_API_ColorConv_M8888I' C:\PROJECTS\Neptun\bukvaverilog_new\software\bukvaverilog_de0nano/GUI/Config/LCDConf.c:99: undefined reference to `LCD_API_ColorConv_M8888I' C:\PROJECTS\Neptun\bukvaverilog_new\software\bukvaverilog_de0nano/GUI/Config/LCDConf.c:99: undefined reference to `GUI_DEVICE_CreateAndLink' C:\PROJECTS\Neptun\bukvaverilog_new\software\bukvaverilog_de0nano/GUI/Config/LCDConf.c:103: undefined reference to `LCD_SetSizeEx' C:\PROJECTS\Neptun\bukvaverilog_new\software\bukvaverilog_de0nano/GUI/Config/LCDConf.c:104: undefined reference to `LCD_SetVSizeEx' C:\PROJECTS\Neptun\bukvaverilog_new\software\bukvaverilog_de0nano/GUI/Config/LCDConf.c:105: undefined reference to `LCD_SetVRAMAddrEx' у меня следующие вопросы: 1. был ли у кого опыт использование EmWin библиотеки под Nios II без использования ОС??? 2. кто какие использовал библиотеки для отрисовки и получения координат с тачскрина под Nios II? очень прошу поделиться опытом, если есть проект под Nios II, то буду очень признателен