Странно... Привели в пример перевод мануала, который доносит мою мысль... Но с моими словами не согласились...
Добавлено after 4 hours 16 minutes 16 seconds: кстати, если обратиться к широкоизвестным протоколам для символьных терминалов, то концепция управляющих последовательностей неплохо вписывается в принятые для avr-gcc "потоки" и без залезания в закрытые структуры... функция, получающая байт, вполне может его анализировать и менять какие-то параметры отображения, если получит управляющую последовательность, и хранить это не в "чужой" структуре, а в своей собственной. в этом случае, кстати, есть шанс создать девайс, который будет корректно работать и с "настоящими" терминальными программами точно так же, как со своим встроенным дисплеем.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
хранить это не в "чужой" структуре, а в своей собственной
ну, так он же про это и написал:
RobSchneider писал(а):
одно можно с уверенностью сказать что поле: void *udata; /* User defined and accessible data. */
указатель типа воид, то есть для хранения пользователем адреса чего угодно. и в библиотеке есть функция для обращения к этим данным, и туда я запишу адрес структуры, поля которой, в свою очередь, будут хранить данные о позиции курсора, цвете символа и фона
и указатель udata будет связывать "свою собственную структуру" с используемым потоком
Зачем хранить указатель на свою структуру в зарезервированным поле чужой структуры? Чтобы получить его обратно в параметре самописной функции, которая и так имеет доступ к этим данным?!
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
чтобы привязать свою структуру к потоку. допустим, если есть несколько потоков и у каждого разные управляющие параметры в "своей собственной структуре"
так каждый поток, по сути, требует свою функцию ввода-вывода символа, а эта функция уже имеет доступ к любым "своим" данным и в дополнительных указателях не особо-то и нуждается... т.е. своя функция вместо своя структура.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Конечно можно, и принципиально структура потока для этой цели и предназначена, но для МК категории AVR это, имхо, избыточно.
Мне трудно представить устройство, которое одновременно на два разных физически, но функционально однотипных (чтобы работать с ними одной функцией) терминала выводит разную информацию... Но если это и в самом деле нужно, подход с передаваемой в единую функцию структурой для потока представляется мне уместным.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Все сказанное Вами с моего последнего поста в тему моих мыслей. Спасибо за диалог! Кстати, для 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, вроде как так рекомендовали, а зачем? спрашивается если там хранится ссылка на "мою" структуру. обращение громоздким будет, придется разбивать код на строки, достать данные (или сгенерировать временно) а потом положить назад. будет наглядней для меня написать:
Имеется возможность связать с пото- ком дополнительные пользовательские дан- ные при помощи fdev_set_udata(), которые затем могут быть извлечены в реализаци- ях функций ввода-вывода символа при по- мощи fdev_get_udata() и обработаны, как требуется. Это, например, позволит реали- зовать одну функцию ввода-вывода, рабо- тающую с различными UART. В этом слу- чае функции ввода-вывода сохраняют кон- текст различных UART в области данных пользователя между своими вызовами.
А, дошло. то есть к двум потокам привязана одна универсальная функция вывода символа, которая в свою очередь будет ориентироваться на "правила обращения" с этим потоком в зависимости от информации полученной из FILE. udata для каждого ведь будет своя!
но с этим соглашусь пожалуй: Спойлер
ARV писал(а):
Конечно можно, и принципиально структура потока для этой цели и предназначена, но для МК категории AVR это, имхо, избыточно.
Мне трудно представить устройство, которое одновременно на два разных физически, но функционально однотипных (чтобы работать с ними одной функцией) терминала выводит разную информацию... Но если это и в самом деле нужно, подход с передаваемой в единую функцию структурой для потока представляется мне уместным.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 15
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения