Вопросы о С.

STT

Ок, спасибо. Мне просто попробовать разобраться.

Ant

а вот такой вопрос:
в некоем примере наткнулся на такой финт, написанный под Keil

Код:

enum {TEMP,HUMI};

char s_measure(unsigned char mode)
{ 
    case TEMP   :  break;
    case HUMI   :  break;
    default     : break;    
}


s_measure(HUMI);

как-то нелогично объявляется тип перечисления. точнее, он вообще не объявляется.
или подразумевается, что раз проц 8-битный, то и дефолтный тип тоже 8 бит?

amx

Ant писал(а):

а вот такой вопрос:
в некоем примере наткнулся на такой финт, написанный под Keil
...
как-то нелогично объявляется тип перечисления. точнее, он вообще не объявляется.
или подразумевается, что раз проц 8-битный, то и дефолтный тип тоже 8 бит?

Всё верно, это яркий пример того, как не надо делать. К тому же вы явно пропустили switch, а если это оригинал - то вообще полная чушь.

Ant

а, да, switch выкусил случайно.
ну мне-то был интересен не свитч, а именно муть с объявлением перечисления.

Ant

сижу туплю:

Код:

char s_measure(unsigned char *p_value)
{ 
  *(p_value)  =s_read_byte(ACK);    //read the first byte (MSB)
  *(p_value+1)=s_read_byte(ACK);    //read the second byte (LSB)
}

как понять *(p_value) и *(p_value+1) ?

MrYuran

Ant писал(а):

сижу туплю:

как понять *(p_value) и *(p_value+1) ?

Первое - значение байта по адресу, на который указывает указатель.
Второе - значение по следующему адресу.

amx

MrYuran писал(а):

Ant писал(а):

сижу туплю:

как понять *(p_value) и *(p_value+1) ?

Первое - значение байта по адресу, на который указывает указатель.
Второе - значение по следующему адресу.

Единственное дополнение, в общем следующий адрес - это не адрес больший на единицу, а больший на размер элемента.
*(p_value) и *(p_value+1) можно записать как p_value[0] и p_value[1] соответственно.

Ant

а кстати, по предыдущему вопросу с enum {TEMP,HUMI}
дефолтный размер понятен. но неужели существует ещё и дефолтный ряд значений?

amx

Ant писал(а):

а кстати, по предыдущему вопросу с enum {TEMP,HUMI}
дефолтный размер понятен. но неужели существует ещё и дефолтный ряд значений?

А как же, значения начинаются с 0 и далее по возрастанию. Можно явно указать значение, если необходимо.

Ant

вы не поверите, снова выдалось некоторое время на Си. курю всё тот же небольшой кусок кода и всё-таки не вдупляю..

Код:

// 1. объявляем структуру, состоящую из инта и флоата (простите за мой французский)
typedef union 
{ unsigned int i;
  float f;
} value;

//////////////////////////////////////////////
char s_measure(unsigned char *p_value)
{
  *(p_value)  =s_read_byte(ACK);    //read the first byte (MSB)

  // 4. тут вообще непонятки: сдвиг на байт (см. объявление p_value на входе в функцию), -- это что, заполнение инта в два захода?
  *(p_value+1)=s_read_byte(ACK);    //read the second byte (LSB)
}

//////////////////////////////////////////////
int main(void)
{
   // 2. объявляем две переменные ранее объявленного "структурного" типа.
   value humi_val,temp_val;

   // 3. тут уже работаем с длинами переменной, равными байту (??), но ведь i у нас объявлен в структуре как инт
   error+=s_measure((unsigned char*) &humi_val.i);  //measure humidity
   
   if(error!=0) s_connectionreset();                 //in case of an error: connection reset
   else
      { humi_val.f=(float)humi_val.i; }         

посмотрите кто в этом всём понимает, последовательность вопросов я отметил особо))
PS код выдернут из стандартного примера работы с SHT10 с их сайта

Steel.ne

Ant писал(а):

вы не поверите, снова выдалось некоторое время на Си. курю всё тот же небольшой кусок кода и всё-таки не вдупляю..

PS код выдернут из стандартного примера работы с SHT10 с их сайта

попробую изобразить в танце

PS. В комментариях непонятный порядок байт, АВР вроде little-endian

Ant

и последний вопрос: в Си такой подход это норма? я имею в виду, один раз объявить одну переменную двухбайтной, потом кучу раз обращаться к её байтам по отдельности -- и всё для того, чтобы единожды в самом конце взять весь инт целиком. и это ещё в аппноте.

не проще было завести просто две однобайтных переменных - и код стал бы понятнее в разы?..

digitdroid

Ant писал(а):

и последний вопрос: в Си такой подход это норма? я имею в виду, один раз объявить одну переменную двухбайтной, потом кучу раз обращаться к её байтам по отдельности -- и всё для того, чтобы единожды в самом конце взять весь инт целиком. и это ещё в аппноте.

не проще было завести просто две однобайтных переменных - и код стал бы понятнее в разы?..

Когда это применяется по делу, то да. Просто С хорошим компилятором обычно очень хорошо переводится в нативный код.
Сдвиги, маски и прочее занимают 1-2 команды процессора. Память не расходуется зря и скорость выполнения не страдает.
А вот побайтовое обращение обычно медленнее на многих архитектурах, чем работа с int или long (16, 32, 64bit).
Именно поэтому С и называют "высокоуровневым ассемблером".

Steel.ne

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

Я бы использовал такую конструкцию:

Код:

i = (myReadTemp()<<8) | myReadTemp();

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

Код:

   i = 0;
  a0:   10 92 67 00    sts   0x0067, r1
  a4:   10 92 66 00    sts   0x0066, r1

   p = (uint8_t *)&i;
  a8:   86 e6          ldi   r24, 0x66   ; 102
  aa:   90 e0          ldi   r25, 0x00   ; 0
  ac:   90 93 65 00    sts   0x0065, r25
  b0:   80 93 64 00    sts   0x0064, r24

   *(p) = myReadTemp();
  b4:   0e 94 49 00    call   0x92   ; 0x92 <myReadTemp>
  b8:   80 93 66 00    sts   0x0066, r24
   *(p+1) = myReadTemp();
  bc:   00 91 64 00    lds   r16, 0x0064
  c0:   10 91 65 00    lds   r17, 0x0065
  c4:   0e 94 49 00    call   0x92   ; 0x92 <myReadTemp>
  c8:   f8 01          movw   r30, r16
  ca:   81 83          std   Z+1, r24   ; 0x01

   i = 0;
  cc:   10 92 67 00    sts   0x0067, r1
  d0:   10 92 66 00    sts   0x0066, r1

   i = (myReadTemp()<<8) | myReadTemp();
  d4:   0e 94 49 00    call   0x92   ; 0x92 <myReadTemp>
  d8:   18 2f          mov   r17, r24
  da:   0e 94 49 00    call   0x92   ; 0x92 <myReadTemp>
  de:   31 2f          mov   r19, r17
  e0:   20 e0          ldi   r18, 0x00   ; 0
  e2:   90 e0          ldi   r25, 0x00   ; 0
  e4:   28 2b          or   r18, r24
  e6:   39 2b          or   r19, r25
  e8:   30 93 67 00    sts   0x0067, r19
  ec:   20 93 66 00    sts   0x0066, r18

Ant

Steel.ne писал(а):

Я бы использовал такую конструкцию:

Код:

i = (myReadTemp()<<8) | myReadTemp();

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

amx

Steel.ne писал(а):

Я бы использовал такую конструкцию:

Код:

i = (myReadTemp()<<8) | myReadTemp();

В общем случае порядок вычисления не определён. С вероятностью 50% можно получить как правильный результат, и ещё 50% остается на инвертированный. Лучше уж так:

Код:

i = s_read_byte(ACK) & 0xFFU;
i |= (s_read_byte(ACK) & 0xFFU) << 8;

На счёт "лишних" побитовых И можно особо не волноваться, компиляторы ныне достаточно умные что бы понять что от результат вызова функции нужен только младший байт.

Steel.ne

Ant писал(а):

Steel.ne писал(а):

Я бы использовал такую конструкцию:

Код:

i = (myReadTemp()<<8) | myReadTemp();

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

ээээ. Конечно.
Ты наверно невнимательно смотрел, что у тебя в функции творится

Код:

*(p_value)  =s_read_byte(ACK);    //read the first byte (MSB)

  // 4. тут вообще непонятки: сдвиг на байт (см. объявление p_value на входе в функцию), -- это что, заполнение инта в два захода?
  *(p_value+1)=s_read_byte(ACK);    //read the second byte (LSB)

два раза читаем, соответственно старший и младший байты. Не?

Steel.ne

amx писал(а):

Steel.ne писал(а):

Я бы использовал такую конструкцию:

Код:

i = (myReadTemp()<<8) | myReadTemp();

В общем случае порядок вычисления не определён. С вероятностью 50% можно получить как правильный результат, и ещё 50% остается на инвертированный. Лучше уж так:

Код:

i = s_read_byte(ACK) & 0xFFU;
i |= (s_read_byte(ACK) & 0xFFU) << 8;

На счёт "лишних" побитовых И можно особо не волноваться, компиляторы ныне достаточно умные что бы понять что от результат вызова функции нужен только младший байт.

Согласен. Я так написал только для примера - вместо записи по указателю мы собираем через сдвиги и OR
порядок строк может быть и обратным, в зависимости от того, что первым приходит MSB или LSB.

led_fan

[quote="Ant"]вы не поверите, снова выдалось некоторое время на Си. курю всё тот же небольшой кусок кода и всё-таки не вдупляю..

Код:

// 1. объявляем структуру, состоящую из инта и флоата (простите за мой французский)
typedef union 
{ unsigned int i;
  float f;
} value;

это юнион! со структурой не имеет ничего общего!!!
ну и дальнейшие рассуждения перечитать после внимательного чтения букваря.
т.е. по факту, в памяти uint и float лежат по одному адресу. на чем, собственно, и основано чтение младшего и старшего байтов инта.

PRC

led_fan писал(а):

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

Это надо в заголовок, красными и мигающими буквами, выделить.

dosikus_2

led_fan писал(а):

Ant писал(а):

это юнион! со структурой не имеет ничего общего!!!

Гы... Свершилось . Наконец то хоть кто то вдуплился.
Честно говоря после местных перлов о static сильно сомневался .

led_fan

да я сразу отдетектил, просто на тот момент был чисто читателем... ;)

ну а про статик и про "небольшие преувеличения" я в той теме там отписался, как и о причинах... ;)
подтверждением чему, собсно, очередной (этот) топик... ну и вопрос дрвласа про ребут буквально пару дней спустя... %)

Ant

PRC писал(а):

led_fan писал(а):

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

Это надо в заголовок, красными и мигающими буквами, выделить.

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

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

digitdroid

По факту viewtopic.php?p=222631#p222631
А то дольше глаза ломаешь, чем отвечаешь.

led_fan

Ant писал(а):

PS букварь я читал. видимо, слишком был примитивный.

читай еще раз, а потом и еще. до полного просветления.

Цитата:

PPS про юнионы и структуры гуглил, везде всё это описывается в одной главе и различия из них не делается. впрочем, зачем я это объясняю.

смотри:

Код:

union u16convert
{
uint16_t value;    //!< for word access
struct u16bytes   //!< for byte access
{
uint8_t low;   //!< byte member
uint8_t high;   //!< byte member
};

};

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

есть разница, правда?

Easyelectronics.ru

Вопросы о С.

Кто сейчас на конференции