Оператор "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, хоть нет.

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

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

Вспомнил, зачем Head должен быть volatile. Долго же в мозгу зрело, не давало покоя - ну не совсем же сдуру я его делал volatile! Если компилятор достаточно умный и решит встроить uart_t::send (например, если он вызывается только из одной точки программы), то без volatile он имеет полное право закешировать в основном коде Head в регистре и обработчик вместо одного байта будет каждый раз выстреливать весь буфер от начала до конца.

Кстати, и буфер тоже должен быть volatile. В противном случае компилятор имеет полное право перенести запись в буфер после изменения Head и разрешения прерывания.

[zltigo]

то без volatile он имеет полное право закешировать в основном коде Head в регистре...

Это по любому глобальная переменная. Даже при встраивании функции область работы с этой переменной и область cуществования локальной переменной Tmp четко определена телом бывшей функции и при выходе за ее пределы должна быть синхронизирована с памятью. Если этого не будет сделано, то компилятор не умный, а вовсе даже с ошибками.
Даже допустим, что компилятор плюет на все и всех, но даже в этом случае uart_t::send должна встроися в некий вечный цикл, причем ничего особо кроме вызова send() не делающий, дабы была куча неиспользуемых регистров и компилятор мог ими разбрасываться. Что-то за уши притянутое.

Кстати, и буфер тоже должен быть volatile. В противном случае компилятор имеет полное право перенести запись в буфер после изменения Head и разрешения прерывания.

Ну это вообще понесло
Вместо:

Код

  TxBuffer[ TxHead ] = byte;
    TxHead = Tmp;
    UCSRB |= (1<<UDRIE);

Сделать

Код

    TxHead = Tmp;
    UCSRB |= (1<<UDRIE);
  TxBuffer[ TxHead ] = byte;

Может он тогда имеет право и вообще генерить любые побочные эффекты и точки следования ему не указ?

[ReAl]

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

Код

#include <avr/io.h>
uint8_t i;
inline void ppi() {
        uint8_t temp = i + 1;
        i = temp;
}

void foo(uint8_t n) {
        while(n--) {
                ppi();
                PORTB = 0;
        }
}

Код

foo:
    tst r24
    breq .L6
    lds r18,i
    mov r25,r24
.L5:
    out 56-32,__zero_reg__
    subi r25,lo8(-(-1))
    brne .L5
    add r18,r24
    sts i,r18
.L6:
    ret

Всегда считал, что тут всё правильно. Хотя тут нет ни намёка на работу с i "в пределах тела бывшей функции".
Аналогично при встраивании uart::send при отправке строки вполне может на первом байте разрешить прерывания (записать в UDR - не важно), но обновить head в глобальной переменной только в конце строки.

Вместо:

Код

  TxBuffer[ TxHead ] = byte;
    TxHead = Tmp;
    UCSRB |= (1<<UDRIE);

Сделать

Код

    TxHead = Tmp;
    UCSRB |= (1<<UDRIE);
  TxBuffer[ TxHead ] = byte;

Может он тогда имеет право и вообще генерить любые побочные эффекты и точки следования ему не указ?

Ну аж так нельзя, так как у массива индекс выходит другой. А со сгенерированным компилятором временным указателем или индексом, сохраняющем предыдущее значение - вполне.
Точки следования не к этому. Вон в примере выше от точек следования в ppi() вообще ничего не осталось. И инвариантный код из цикла оптимизатором выносится с полным правом это делать, хоть при этом точки следования и меняются местами - от _независимых_ операций.
Там в стандарте есть такое слово "observable behavior", такая перестановка

Код

  uint8_t * ptr = &TxBuffer[ TxHead ];
    TxHead = Tmp;
    UCSRB |= (1<<UDRIE);
    *ptr = byte;

для не-volatile TxBuffer "видимое поведение" не меняет. А если ещё и TxHead не-volatile, то можно и так:

Код

    UCSRB |= (1<<UDRIE);
    TxBuffer[ TxHead ] = byte;
    TxHead = Tmp;

и тут даже внтренняя переменная для индекса/адреса не нужна. И в этом смысле TxHead должен быть volatile как у Сергея, так и в 11-том сообщении автора темы.

Как-то очередной версией копилятора в scmRTOS

Код

class TCritSect
{
public:
    TCritSect () : StatusReg( SREG ) { cli(); }
    ~TCritSect() { SREG = StatusReg; }
private:
    TStatusReg StatusReg;
};

    INLINE inline dword GetTickCount() { TCritSect cs; return Kernel.SysTickCount; }

при не-volatile на тот момент SysTickCount начало компилироваться не как

Код

   dword tmp;
   cs.StatusReg = SREG;
   cli();
   tmp = Kernel.SysTickCount;
   SREG = cs.StatusReg;
   return tmp;

а как

Код

   cs.StatusReg = SREG;
   cli();
   SREG = cs.StatusReg;
   return Kernel.SysTickCount;

Тут http://forum.sources.ru/index.php?showtopic=201904 эти все перестановки кода обсуждались. Тему неплохо почистили от ругни, но суть оталась :-)
Уже нужно было где-то процитировать - тогда нашлась в последнем сообщении опечатка, исправлялсь, поэтому дата у него оторванная от остальных.