Оператор "printf" и функция "putchar" для работы с символьным LCD Опции

[Буратино]

не понимаю, что за беда с выводом.
Прописал "putchar" в виде:

Код

void putchar( char c ) {
    if ( !c )
    return( 0 );
    Transmit_Byte( c );  /*функция отправки сообщения в последовательный порт*/
}

LCD оснащен контроллером, который принимает данные по последовательному порту и выводит на экран дисплея 16*02
Не могу разобраться почему:

printf("%a", 30.0) выводит "???"
printf("%.2A", 30.0) выводит "???"
printf("%c", 'a') ничего выводит
printf("<%3c|%-3c>", 'a', 'b') выводит "< крокозябра >"
и т.д. совсем другими словами не то что я ожидаю.

printf("Hello World!") выводит "Hello World!", но если использовать длинную строку или несколько операторов "printf" со строками, то выводятся куски строк в хаотичном порядке.
размер Data Stack в компиляторе IAR установил в 0x300.

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

Сообщение отредактировал Буратино - Mar 19 2010, 12:46

[Буратино]

Все, разобрался (хотя и остались некоторые непонятки):
Не включил в проект #include <stdio.h>
---
zltigo, прошу прощения, что наорал на Вас, злой очень был.
Все никак не решусь на новый виток в образовании, вот если бы ногу или руку сломать (на крайний случай ветрянка сойдет), чтоб дома в кровати валяться и книги умные читать..

Сообщение отредактировал Буратино - Mar 19 2010, 18:28

[zltigo]

Все, разобрался (хотя и остались некоторые непонятки):

Некошерно смотрится дергание бита разрешения прерывания . Ну и volatile для UART_TxHead0 лишнее - только warning вызывает. tmptail0 лишняя сущность... Про имена помолчу.... Прототипы своих функций тоже игнорируем

[Сергей Борщ]

Некошерно смотрится дергание бита разрешения прерывания

Нормально смотрится. Нужны прервания - разрешаем, не нужны - запрещаем. Флаг-то аппаратно торчит всегда, когда свободен буфер передачи. Это вам не '550.

Ну и volatile для UART_TxHead0 лишнее - только warning вызывает.

Формально - не лишняя. Переменная меняется в другой относительно прерывания нити.

tmptail0 лишняя сущность...

Вовсе нет. Без нее получаем предупреждение компилятора на неопределенный порядок чтения двух volatile в сравнении.

[zltigo]

Нормально смотрится. Нужны прервания - разрешаем, не нужны - запрещаем. Флаг-то аппаратно торчит всегда, когда свободен буфер передачи.

Свободен сдвиговый регистр - записываем прямо в UART, не свободен в буфер и по прерыванию уже вычитываем, либо по анализу указателей, либо флаг можно завести.

Формально - не лишняя. Переменная меняется в другой относительно прерывания нити.

Абсолютно лишняя, ибо пока выполняется обработчик она измениться за его пределами не может. для Tail volatile нужен, Head - нет.

Вовсе нет. Без нее получаем предупреждение компилятора на неопределенный порядок чтения двух volatile в сравнении.

Два volatile, повторяю, ну совсем не нужны, а warning, гарантировано при if ( UART_TxHead0 != UART_TxTail0 ) вылезет хоть есть tmptail0, хоть нет.

[Сергей Борщ]

Свободен сдвиговый регистр - записываем прямо в UART, не свободен в буфер и по прерыванию уже вычитываем, либо по анализу указателей, либо флаг можно завести.

И все эти телодвижения только ради того, чтобы не запрещать/разрешать прерывание? Нафиг. Хорошо, пусть даже идем вашим путем. В прерывании вычитываем из буфера. Буфер пуст - все данные переданы. Что делать дальше? Флаг прерывания сбросить невозможно - для этого нужно что-то начать передавать. Если выйдем из прерывания не запретив его - тут же попадем в это же прерывание снова. Что мы можем сделать кроме как запретить это прерывание? Еще раз повторяю - это не '550, тут не получается начать генерить прерывания положив первый байт в передатчик. И такая реализация дает более компактный код, без всяких лишних проверок "свободен/не свободен сдвиговый регистр".

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

Ну хорошо, тут соглашусь.

Два volatile, повторяю, ну совсем не нужны, а warning, гарантировано при if ( UART_TxHead0 != UART_TxTail0 ) вылезет хоть есть tmptail0, хоть нет.

Тюю... Невнимательно посмотрел исходник. Рассмотрел только TransmitByte, увидел, что она очень похожа на один из вариантов используемого мной кода и экстраполировал этот вывод и на обработчик прерывания. Виноват. У автора ветки действительно лишний.

Код

void uart_t::send(uint8_t byte)
{
    uint8_t Tmp = (TxHead + 1) & (UART_TX_BUFF_SIZE - 1);
    while(Tmp == TxTail)
       ;       // Buffer full
    TxBuffer[ TxHead ] = byte;
    TxHead = Tmp;
    UCSRB |= (1<<UDRIE);
}

inline void  uart_t::UDRE_handler(void)
{
    uint8_t Tmp = TxTail;
    UDR = TxBuffer[ Tmp ];
    TxTail = Tmp = (Tmp + 1) & (UART_TX_BUFF_SIZE - 1);
    if(Tmp == TxHead)
        UCSRB &= ~(1<<UDRIE);
}

[zltigo]

И все эти телодвижения....

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

И такая реализация дает более компактный код, без всяких лишних проверок "свободен/не свободен сдвиговый регистр".

Очень очень зависит от конкретики и железа. Компактность кода, тоже не всегда синоним скорости - для тех контроллеров, у которых периферия находится на медленной шине безусловное действие прочитать-изменить-записать флаг в при каждом вызове передачи байта катострофически проигрывает по времени, например, анализу софтового флага.

У автора ветки действительно лишний.

Код

inline void  uart_t::UDRE_handler(void)
{
    uint8_t Tmp = TxTail;
    UDR = TxBuffer[ Tmp ];
    TxTail = Tmp = (Tmp + 1) & (UART_TX_BUFF_SIZE - 1);
    if(Tmp == TxHead)
        UCSRB &= ~(1<<UDRIE);
}

Ну вообще-то и у тебя лучше обойтись без.

Код

union {
volatile uint8_t TxTail;
uint8_t TxTail_int;
};

inline void  uart_t::UDRE_handler(void)
{
    UDR = TxBuffer[ TxTail_int ];
    TxTail_int = (TxTail_int + 1) & (UART_TX_BUFF_SIZE - 1);
    if(TxTail_int == TxHead)
        UCSRB &= ~(1<<UDRIE);
}

Меньше указивок, меньше думать и больше свободы компилятору.
P.S.
Кстати, в таких случаях я предпочитаю НЕ накладывать маску на индексы при их наращивании - пусть крутятся по полному циклу, а маска накладывается при использовании индекса. В этом случае одними действием вычитания индексов можно узнать сколько байтов в буфере - бывает нужно при пакетной передаче.

[Сергей Борщ]

Очень очень зависит от конкретики и железа. Компактность кода, тоже не всегда синоним скорости - для тех контроллеров, у которых периферия находится на медленной шине безусловное действие прочитать-изменить-записать флаг в при каждом вызове передачи байта катострофически проигрывает по времени, например, анализу софтового флага.

В данном случае код был под конкретный контроллер - AVR. В котором, во-первых, периферия висит на быстрой шине (других просто нет), а во-вторых - без сброса разрешения прерывания просто не получится.

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

Так я же написал - это один из вариатнтов. Опять же, речь идет об AVR, у которого FIFO нет (двойная буферизация не считается), и толку от знания "сколько конкретно байт в буфере" нет никакого.

Код

void uart_t::send(uint8_t byte)
{
    uint8_t Tmp = TxHead;
    while((uint8_t)(Tmp - TxTail) >=  (uint8_t) UART_TX_BUFF_SIZE)
    ; // Buffer full
    TxBuffer[ Tmp++ & (UART_TX_BUFF_SIZE - 1) ] = byte;
    TxHead = Tmp;
    UCSRB |= (1<<UDRIE);
}

inline void uart_t::UDRE_Handler()
{
    uint8_t Tmp = TxTail;
    UDR = TxBuffer[ Tmp++ & (UART_TX_BUFF_SIZE - 1) ];
    TxTail = Tmp;
    if(Tmp == TxHead)
        UCSRB &= ~(1<<UDRIE);
}

Но результирующий код получается длинее на 6 байт. И чего я на него перешел? Надо вернуться к первому - память кода может пригодиться.

Меньше указивок, меньше думать и больше свободы компилятору.

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

Впрочем, мы уклонились от темы ветки.

[ReAl]

Фу. union в таком применении - грязный хак.

продолжая уклоняться - если уж всё равно плюсы, то можно попробовать http://electronix.ru/forum/index.php?showt...mp;#entry535341