Отправка числа 0 (ноль) по уарту

[urmlr]

Может кому-то лучше делать int вместо char

О да! Что нам все эти Керниганы и Ричи с Томсонами а заодно и с АНСИ комитетами по языку "С"? Придурки они все конечно же! То-ли дело МЫ! Гиганты ума и программирования!

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

[Cybermaker]

О да! Что нам все эти Керниганы и Ричи с Томсонами а заодно и с АНСИ комитетами по языку "С"? Придурки они все конечно же! То-ли дело МЫ! Гиганты ума и программирования!

Если бы у нас как у них было 640 кб оперативки - то нам было бы всё равно. Но так как у нас её значительно меньше - мне вот, допустим, нафиг не надо чтобы ,при создании массива, строка "Hello world" была записанна в двухбайтовом юникоде. Потому и логично использовать всего лишь один флаг вместо удвоения памяти под каждый символ.

[urmlr]

Если бы у нас как у них было 640 кб оперативки

Оооо-Хо-Хо-Хо!!! (голосм Санта Клауса). Язык "С", его стандартная библиотека и операционка Unix делались на машине PDP-11 с размером оперативки 56 кб.

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

И никто не говорит об удвоении памяти под каждый символ, если getchar возвращает int, это совсем не значит что этот int надо в память фигачить, это сделано (одна из причин) чтобы можно было писать нечто вроде:

int c;
...
while( (c=getchar()) != EOF)
{
...
  *((char *) ptr++) = c;
...
}

Где значение 'EOF' вне диапазона значений байта.

[Cybermaker]

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

Тем не менее на 32 битных системах каждый символ занимает 2 байта.

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

[Godzilla82]

Тем не менее на 32 битных системах каждый символ занимает 2 байта.

Даже если он описан как:

char stroka[] = "привет"; 

И почему тогда не 4? Со словом не путаете?

А насчёт int и значения getchar() "вне диапазона" - попишет народ программки, поймёт, что был неправ, глядишь - и толк будет. А так - пока сами не поймут - хоть объясняй, хоть не объясняй.

[Someone]

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

Придерживаясь стиля компилятора, в котором это было, я бы организовал кольцевой буфер так:

interrupt [USART0_RXC] void usart0_rx_isr(void)
{
 char status,data;
 status=UCSR0A;
 data=UDR0;

 if (!(status & (FRAMING_ERROR | PARITY_ERROR | DATA_OVERRUN)))
 {
   rx_buffer0[rx_wr_index0]=data;
   if (++rx_wr_index0 == RX_BUFFER_SIZE0) rx_wr_index0=0;
 }
}


#ifndef _DEBUG_TERMINAL_IO_
#define _ALTERNATE_GETCHAR_
#pragma used+
char getchar(void)
{
 char data;
 
 data = '';
 if (rx_rd_index0 != rx_wr_index0)
 {
   data = rx_buffer0[rx_rd_index0];
   if (++rx_rd_index0 == RX_BUFFER_SIZE0) rx_rd_index0=0; 
 }
  return data;
}
#pragma used-
#endif

В случае, если автору хочется вызывать гетчар, не зная, лежит ли в буфере символ (я то проверял бы, есть в буфере символ, и если есть, вызывал бы гетчар),

#ifndef _DEBUG_TERMINAL_IO_
#define _ALTERNATE_GETCHAR_
#pragma used+
char getchar(void)
{
 char data;
 
 data = '';
 uart_data = 0;
 if (rx_rd_index0 != rx_wr_index0)
 {
   data = rx_buffer0[rx_rd_index0];
   uart_data=1;
   if (++rx_rd_index0 == RX_BUFFER_SIZE0) rx_rd_index0=0; 
 }
  return data;
}
#pragma used-
#endif

[urmlr]

я бы организовал кольцевой буфер так

В этом фрагменте кода контроля переполнения нет вообще. Т.Е. если, скажем, программа которая вызывает getchar зависнет, то принимаемые символы так и будут писаться в буфер, перезаписывая друг дружку. Если же этот код будет просто работать медленно и на какой-то момент rx_wr_index0 "наедет" на rx_rd_index0, то вы потеряете целый буфер.
Плюс, этот код не может принять нулевой байт, ибо возврат нуля идентичен отсутствию байта в буфере.

Второй фрагмент, собственно, не лучше.

[Someone]

В этом фрагменте кода контроля переполнения нет вообще.

Имхо в кольцевом буфере контроль переполнения не особенно и нужен, но если так сильно хочется, см. ниже.

Т.Е. если, скажем, программа которая вызывает getchar зависнет, то принимаемые символы так и будут писаться в буфер, перезаписывая друг дружку.

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

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

Данный код будет работать быстрее исходного, т.к. короче и оперирует с меньшим числом переменных. В исходном же коде при описанной ситуации наезда rx_wr_index0 на rx_rd_index0 (сам факт наезда между прочим сигнализирует о переполнении) только поставится флаг переполнения, и точно так же потеряется буфер. И если уж сильно надо ставить флаг переполнения, то

interrupt [USART0_RXC] void usart0_rx_isr(void)
{
 char status,data;
 
 status=UCSR0A;
 data=UDR0;

 if (!(status & (FRAMING_ERROR | PARITY_ERROR | DATA_OVERRUN)))
 {
   rx_buffer0[rx_wr_index0]=data;
   if (++rx_wr_index0 == RX_BUFFER_SIZE0) rx_wr_index0=0;
   if (rx_wr_index0 == rx_rd_index0) rx_buffer_overflow0=1; 
 }
}

Плюс, этот код не может принять нулевой байт, ибо возврат нуля идентичен отсутствию байта в буфере.

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

Второй фрагмент, собственно, не лучше.

Во втором случае (напоминаю, так сделано в исходном коде), гетчар можно вызывать без предварительной проверки наличия данных в буфере, и если он возвращает 0, а uart_data == 1, очевидно, что по уарт в буфер пришел 0, который гетчар и возвращает. Кстати, в исходном коде не хватает сброса этого флага, т.е. программист должен его сбрасывать сам перед вызовом гетчар. И если забудет, то будет считать, что приходят сплошные 0 .

[urmlr]

Имхо в кольцевом буфере контроль переполнения не особенно и нужен [...] только поставится флаг переполнения

Самое опасное что только может быть, это код который работает и выдаёт похожие на правильные, но неправильные результаты. С вашим имхом вы как раз на пути туда. А вот отлов переполнения как раз позволяет предотвратить это и что-то таки сделать. Что именно уже зависит от конкретной аппликухи.

Я ведь не зря писал, что я делал бы вызов гетчар только если в буфере что-то лежит

То есть ваш код имеет недокументированные и неочевидные взаимосвязи. Сиречь поддерживаться в нормальных производственных условиях не может.

в исходном коде не хватает сброса этого флага

В нормальном исходном коде с нормально сделанной функцией getchar этот флаг не нужен вообще. Это ещё одна причина почему в стандарте getchar возвращает именно int а не char. Потому как иметь какой-то ещё мистический флаг означает нарываться на неприятности. Баги сиречь.

Данный код будет работать быстрее исходного

Код должен для начала работать правильно, а быстрее или нет - второй вопрос.

Резюме: экзамена по программированию вы бы у меня не сдали

[_guardianangel]

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

Правда??!!! А как тада весь Unix работает? Может там по дефолту CP-1251 стоит? Знаете не замечал. Всегда UTF-8. По поводу компилеров - в делфях и вижуал студиях начиная с 2005 версии юникод по дефолту стоит.