помогите с потоком AVR

[ARV]

Странно... Привели в пример перевод мануала, который доносит мою мысль... Но с моими словами не согласились...

Добавлено after 4 hours 16 minutes 16 seconds:
кстати, если обратиться к широкоизвестным протоколам для символьных терминалов, то концепция управляющих последовательностей неплохо вписывается в принятые для avr-gcc "потоки" и без залезания в закрытые структуры... функция, получающая байт, вполне может его анализировать и менять какие-то параметры отображения, если получит управляющую последовательность, и хранить это не в "чужой" структуре, а в своей собственной. в этом случае, кстати, есть шанс создать девайс, который будет корректно работать и с "настоящими" терминальными программами точно так же, как со своим встроенным дисплеем.

[slav0n]

хранить это не в "чужой" структуре, а в своей собственной

ну, так он же про это и написал:

одно можно с уверенностью сказать что поле:
void *udata; /* User defined and accessible data. */

указатель типа воид, то есть для хранения пользователем адреса чего угодно.
и в библиотеке есть функция для обращения к этим данным, и туда я запишу адрес структуры, поля которой, в свою очередь,
будут хранить данные о позиции курсора, цвете символа и фона

и указатель udata будет связывать "свою собственную структуру" с используемым потоком

[ARV]

Зачем хранить указатель на свою структуру в зарезервированным поле чужой структуры? Чтобы получить его обратно в параметре самописной функции, которая и так имеет доступ к этим данным?!

[slav0n]

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

[ARV]

так каждый поток, по сути, требует свою функцию ввода-вывода символа, а эта функция уже имеет доступ к любым "своим" данным и в дополнительных указателях не особо-то и нуждается... т.е. своя функция вместо своя структура.

[slav0n]

так каждый поток, по сути, требует свою функцию ввода-вывода

а что, это обязательно?
нельзя использовать одну функцию для разных потоков?

[ARV]

Конечно можно, и принципиально структура потока для этой цели и предназначена, но для МК категории AVR это, имхо, избыточно.

Мне трудно представить устройство, которое одновременно на два разных физически, но функционально однотипных (чтобы работать с ними одной функцией) терминала выводит разную информацию... Но если это и в самом деле нужно, подход с передаваемой в единую функцию структурой для потока представляется мне уместным.

[RobSchneider]

Все сказанное Вами с моего последнего поста в тему моих мыслей. Спасибо за диалог!
Кстати, для AVR, действительно планируется два интерфейса, и для каждой требуется своя функция ввода-вывода.
например в UART-USB - это раз! и здесь мне(микроконтроллеру) не надо помнить где курсор остановился.
А для дисплея,- надо помнить где курсор, а так же текущий цвет текста и фона. Но вот в процессе реализации действительно возник вопрос,
а нафиг мне в FILE эти данные размещать. получается в итоге как-то неудобно.

вот мой пример:

Спойлер

Код: Выделить всё

typedef struct {  //указатель на символ, координаты курсора экрана lcd x, y, цвет символа, цвет фона 
	void *chr;
	uint16_t px;
	uint8_t py;
	uint16_t ct;
	uint16_t cb;
}lcd_char;

int main(void)
{
sei();

static FILE mystdout = FDEV_SETUP_STREAM(lcd_putchar, NULL, _FDEV_SETUP_WRITE);
static lcd_char cursor_param={NULL,0,0,WHITE,BLACK};
	 //структура с начальными координатами, цветом курсора(выводимого символа) и цветом фона.

fdev_set_udata(&mystdout, &cursor_param); // пользуемся представленным интерфейсом для инициализации 
//mystdout.udata=&cursor_param;        //передаем эти параметры в структуру типа FILE
stdout = &mystdout; //передача адреса структуры с указанием функции вывода символов в UART

а функция вывода на экран, вроде получается красиво:

Спойлер

Код: Выделить всё

//Не обращайте внимание на символ, адрес которого приходится помещать в эту же структуру.
//это атавизм, - так у меня функция вывода на экран символа параметры принимает
static int lcd_putchar(char c, FILE *stream) //функция вывода символов на экран
{
	lcd_char *cursymbol= fdev_get_udata(stream); //берем адрес на структуру lcd_char из stream
	if (c='\n')
	{ 
		if (cursymbol->py <= 199)  
		{
		draw_winds(&clear,1); //очистим экран	
		cursymbol->px=0;    //перевод каретки на новую строку
		cursymbol->py+=20;
		return 0;
		}
		else
		{
		cursymbol->px=0; //печать с начала страницы
		cursymbol->py=0;
		return 0;	
		}
	}
	cursymbol->chr=&c; //добавляем в ту структуру адрес текущего выводимого символа
	lcd_print(cursymbol); //выводим этот символ на экран
	if (cursymbol->px <= 287)//если есть еще где печатать по х (319 - 2*16) то двигаем курсор вправо
	{
		cursymbol->px+=16;
	}else if (cursymbol->py <= 199)//если есть еще где печатать по y (239 - 2*20) то двигаем курсор на новую строку
	{
		cursymbol->px=0;
		cursymbol->py+=20;
	}else //иначе переводим курсор в начало экрана
	{
		cursymbol->px=0;
		cursymbol->py=0;
	}
	
	return 0;
}

и вот теперь мне надо напечатать по середине экрана красными буквами на желтом фоне:

printf ("Hello, world");

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

Код: Выделить всё

cursor_param.px=160;
cursor_param.py=120;
cursor_param.ct=RED;
cursor_param.cb=YELLOW;
printf ("Hello, world");

Так, что действительно, не знаю нужно ли задействовать этот stream*

[slav0n]

ну да, не надо изысков. читай внятное описание модуля

Имеется возможность связать с пото-
ком дополнительные пользовательские дан-
ные при помощи fdev_set_udata(), которые
затем могут быть извлечены в реализаци-
ях функций ввода-вывода символа при по-
мощи fdev_get_udata() и обработаны, как
требуется. Это, например, позволит реали-
зовать одну функцию ввода-вывода, рабо-
тающую с различными UART. В этом слу-
чае функции ввода-вывода сохраняют кон-
текст различных UART в области данных
пользователя между своими вызовами.

[RobSchneider]

А, дошло.
то есть к двум потокам привязана одна универсальная функция вывода символа,
которая в свою очередь будет ориентироваться на "правила обращения" с этим потоком
в зависимости от информации полученной из FILE. udata для каждого ведь будет своя!

но с этим соглашусь пожалуй:

Спойлер

Конечно можно, и принципиально структура потока для этой цели и предназначена, но для МК категории AVR это, имхо, избыточно.

Мне трудно представить устройство, которое одновременно на два разных физически, но функционально однотипных (чтобы работать с ними одной функцией) терминала выводит разную информацию... Но если это и в самом деле нужно, подход с передаваемой в единую функцию структурой для потока представляется мне уместным.