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

Вывод оператора print в Vivado

Подскажите плиз новичку. Среда Vivado 2019.1

Отладочная плата - "голова" от Antminer. Чип xc7z010, microSD, DDR3L - 256M x 16, NAND Flash - 256M x 8, Gigabyte Ethernet

Только начинаю осваивать, а потому такой вопрос:
1) Потихоньку осваиваю Vivado , написал первый "hello_world"
2) Программа нормально запускается, выводит нормально через USART. Освоил загрузку через "BootImage" на microSD и через JTAG.

А теперь что не работает:
1) Я не вижу вывод print в консоле. Консоль подключена к USART1
2) Я не вижу вывод xil_printf. При этом вывод XUartPs_Send выводиться нормально. Почему так?.

Примечание:
На плате выведен только USART1. При описании железа на камне проброшен только USART1. 
По всем признакам print должен кидать в консоль. Но там тишина. Куда уходить вывод с print? В USART0? Но USART0 нигде не фигурирует. Если так - как переключить на USART1?
Судя по всему вывод xil_printf завязан на BaseAddress. В system.hdf : ps7_usart_1 имеет адрес 0xe0001000. Соответственно при запуске BaseAddress имеет адрес 0xe0001000. Но ничего нет!

Т.е. Я вижу вывод XUartPs_Send и не вижу xil_printf. Почему так? Хочу все видеть. Хотя конечно это не совсем правильно смешивать отладочный вывод и нормальный вывод в USART.   

Программа ( комментарии вырезаны для компактности):

#include "xparameters.h"
#include "xuartps.h"
#include "xil_printf.h"

#define UART_DEVICE_ID                  XPAR_XUARTPS_0_DEVICE_ID

int UartPsHelloWorldExample(u16 DeviceId);

XUartPs Uart_Ps;		/* The instance of the UART Driver */

int main(void)
{
	int Status;

	/*
	 * Run the Hello World example , specify the the Device ID that is
	 * generated in xparameters.h
	 */
	Status = UartPsHelloWorldExample(UART_DEVICE_ID);

	if (Status == XST_FAILURE) {
		xil_printf("Uartps hello world Example Failed\r\n");
		return XST_FAILURE;
	}

	xil_printf("Successfully ran Uartps hello world Example\r\n");

	return Status;
}

int UartPsHelloWorldExample(u16 DeviceId)
{
	u8 HelloWorld[] = "Hello World";
	int SentCount = 0;
	int Status;
	XUartPs_Config *Config;

	/*
	 * Initialize the UART driver so that it's ready to use
	 * Look up the configuration in the config table and then initialize it.
	 */
	Config = XUartPs_LookupConfig(DeviceId);
	if (NULL == Config) {
		return XST_FAILURE;
	}

	Status = XUartPs_CfgInitialize(&Uart_Ps, Config, Config->BaseAddress);
	if (Status != XST_SUCCESS) {
		return XST_FAILURE;
	}

	XUartPs_SetBaudRate(&Uart_Ps, 115200);

	while (SentCount < (sizeof(HelloWorld) - 1)) {
		/* Transmit the data */
		SentCount += XUartPs_Send(&Uart_Ps,
					   &HelloWorld[SentCount], 1);
	}

	return SentCount;
}

В Терминале на выходе: "Hello World". Строчки ""Successfully ran Uartps hello world Example\r\n"" в терминале нет.

Изменено пользователем DanilinS

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

xil_printf работает через функцию outbyte:

void outbyte(char c) {
	 XUartPs_SendByte(STDOUT_BASEADDRESS, c);
}

Найдите ее и проверьте вашу реализацию. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В BSP settings посмотрите, что указано как std output. В частности там может стоять uart дэбагера, если он добавлен в проект.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Разобрался. Стал тыкаться в другие примеры и случайно увидел, что там вывод printf работает нормально! Далее анализ проектов, сравнение и поиск различий. Причина оказалась очень простой: отсутствие строки 

Quote

#include <stdio.h>

в начале файла.

Если строки нет, то проект собирается без ошибки, но корректного вывода нет. Меня подвели кривые демонстрационные примеры из комплекта. Сейчас все работает отлично. 

 

И еще вопрос "до кучи":

Все примеры по морганию светодиодами и опроса кнопок ( имеется в виду ARM ядром) написанные на С имеют 2 варианта.

1) Кнопки и светодиоды работают в режиме MIO. Соответственно программа напрямую ( через "xgpiops") опрашивает кнопки и зажигает светодиоды.

2) Использование AXI_GPIO. Соответственно в проекте появляется AXI_Interconnect с соответствующей обвязкой. Появляется bitstream.   Работаем через функции "gpio.h"

 

Какие принципиальные особенности каждого способа? Зачем городить дополнительный слой программной логики если я напрямую могу работать с выводами и периферией? Или там есть некоторые неочевидные особенности?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 hours ago, DanilinS said:

Какие принципиальные особенности каждого способа? Зачем городить дополнительный слой программной логики если я напрямую могу работать с выводами и периферией? Или там есть некоторые неочевидные особенности?

пины плис в обоих примерах одинаковые?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Абсолютно. Он одни работают через MIO, а другие через логику AXI_GPIO. А я не могу понять причины этого выбора. Я могу понять дополнительную обработку сигналов в FPGA. Но зачем использовать AXI_GPIO для работы с кнопками и светодиодами? Если вся логика в проце крутится. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5 hours ago, DanilinS said:

Абсолютно. Он одни работают через MIO, а другие через логику AXI_GPIO. А я не могу понять причины этого выбора. Я могу понять дополнительную обработку сигналов в FPGA. Но зачем использовать AXI_GPIO для работы с кнопками и светодиодами? Если вся логика в проце крутится. 

Что-то мне подсказывает что это не так. xdc файл надо посмотреть. MIO это сигналы процессорной подсистемы, обозначены на корпусе как PS_MIO_blablabla. Доступа логики плис к ним нет. А вот к остальным сигналам ПЛИС, обозначеными на корпусе как IO_blablabla доступ у проца через акси мост. Что естественно требует создание акси подсистемы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 3/2/2021 at 5:53 AM, des00 said:

А вот к остальным сигналам ПЛИС, обозначеными на корпусе как IO_blablabla доступ у проца через акси мост. Что естественно требует создание акси подсистемы.

Не обязательно. У цинка есть отдельный блок EMIO GPIO...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

28 minutes ago, gosha-z said:

Не обязательно. У цинка есть отдельный блок EMIO GPIO...

в пределах ограничений. но вы правы, 64 GPIO он действительно может пробросить через логику.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Еще вопросик "до кучи":

Есть Gigabite Ethernet. По мануалу я должен банк  на 2.5 вольт перевести. Собственно и Vivado об этом говорит:

Quote

"CRITICAL WARNING: [PS7-6]  LVCMOS33 (3.3V) is not supported for RGMII interface in Ethernet0. Recommendation is to use 1.8/2.5V IO."

 

Но тут на глаза попадается схема макетки EBAZ4205:  EBAZ4205/EBAZ4205-SCH.pdf

 

Там и банк, интерфейс  и чип LAN питается от 3.3 вольта. Разве так можно? 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 3/19/2021 at 10:23 PM, DanilinS said:

Еще вопросик "до кучи":

Есть Gigabite Ethernet. По мануалу я должен банк  на 2.5 вольт перевести. Собственно и Vivado об этом говорит:

 

Но тут на глаза попадается схема макетки EBAZ4205:  EBAZ4205/EBAZ4205-SCH.pdf

 

Там и банк, интерфейс  и чип LAN питается от 3.3 вольта. Разве так можно? 

 

 

 Вот руководство на русском в двух частях с большим количеством картинок как работать с  EBAZ. Тут же есть и Hello World в консоль https://fpga-systems.ru/publ/boards_review/xilinx_fpga/zynq_hw_ebaz4205/20-1-0-121

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...