Язык СИ для микроконтроллеров

**ARV** · 26 октября, 2017

1 час назад, COKPOWEHEU сказал:

Все эти фокусы нужны чтобы собирать оптимальный код под любую платформу, используя ее особенности. Поэтому якобы неопределенное поведение (char<<7) вполне можно использовать - если точно известен диапазон платформ.

В данной теме я и говорю не про любые платформы, а про embedded, где по большей мере царят GCC и немного IAR с Keil. Поскольку я вообще ограничен платформой AVR, то в плане переносимости меня беспокоят только эти МК, т.е. ARM, например, не входит в круг моих интересов. И с этой ограниченной точки зрения я высказываю свои суждения. И, как мне кажется, с учетом сказанного только что, вы не поколеблете мою точку зрения никак - я могу все учесть, и стандарт (насколько я его знаю) мне только помогает. Придумывать варианты, когда это может быть не так, мне неинтересно.

1 час назад, COKPOWEHEU сказал:

В Си же для этого придется приводить оба числа к 16-битным со всеми вытекающими последствиями

В Си это уже делается автоматически. Т.е. пример неудачный

Только что, ARV сказал:

Поэтому якобы неопределенное поведение (char<<7) вполне можно использовать

Можно. Но приведите мне довод, когда это предпочтительнее (uint8_t << 7), работающее на любых платформах?

Реклама

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

**COKPOWEHEU** · 26 октября, 2017

2 минуты назад, ARV сказал:

платформой AVR

То есть вы не учитываете что байт может быть не 8-битным. А ведь стандарт это не гарантирует. Другое дело что в 99% случаев учитывать это не вижу смысла - разве что добавить

#if (CHAR_BITS != 8)
#error сами мучайтесь с нестандартными системами
#endif

6 минут назад, ARV сказал:

В Си это уже делается автоматически. Т.е. пример неудачный

Пример был про эффективность кода (скорость, размер прошивки), а не удобство записи.

7 минут назад, ARV сказал:

Можно. Но приведите мне довод, когда это предпочтительнее (uint8_t << 7), работающее на любых платформах?

Понятия не имею! Сами же говорили что не интересуетесь абстрактными примерами. Сейчас мне тоже неохота их выдумывать. Разве что когда char используется именно как символ. Ну и писать char все-таки быстрее чем uint8_t.

Реклама

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

**ARV** · 26 октября, 2017

5 минут назад, COKPOWEHEU сказал:

То есть вы не учитываете что байт может быть не 8-битным.

Вы сами не учитываете, что в первую очередь я сам следую собственным советам Я всем рекомендовал пользоваться типами строгой размерности С99, поэтому проблема char меня абсолютно не касается - я применяю uint8_t - в соответствии со стандартом С99.

5 минут назад, COKPOWEHEU сказал:

Пример был про эффективность кода (скорость, размер прошивки), а не удобство записи

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

5 минут назад, COKPOWEHEU сказал:

Разве что когда char используется именно как символ

Когда char используется, как символ, его не надо двигать!

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

Изменено 26 октября, 2017 пользователем ARV

Реклама

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

**COKPOWEHEU** · 26 октября, 2017

2 часа назад, ARV сказал:

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

Ну, раз верите, что тут возразить.

2 часа назад, ARV сказал:

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

Вы сначала приведенные опровергните прежде чем новые требовать.

**ARV** · 27 октября, 2017

8 часов назад, COKPOWEHEU сказал:

Вы сначала приведенные опровергните прежде чем новые требовать

Позвольте, уважаемый!

Я говорю, что если соблюдать требования и учитывать ограничения стандарта, это повредить не может никак, а скорее (и даже практически однозначно) поможет. Вы приводите аргументы неопределенного поведения и говорите, что может. Но ведь это означает, что вы предлагаете НЕ УЧИТЫВАТЬ неопределенное поведение компилятора по стандарту, что противоречит моим принципам! То есть вы не опровергаете мои подходы, а доказываете свои! Если отказаться от типов с неопределенной размерностью (точнее, с платформо-зависимой), а использовать СТАНДАРТНЫЕ типы С99, количество вариантов undefined behavior, на которые можно нарваться в своих программах, кардинально уменьшается. Аналогично есть возможность СТАНДАРТНЫМИ средствами и разумным подходом к кодописанию ИСКЛЮЧИТЬ все оставшиеся подобные ситуации. Если ТАК НЕ ДЕЛАТЬ - вы безусловно правы. А вот ЕСЛИ ДЕЛАТЬ ТАК - безусловно прав я. Во всяком случае безусловность этого вы не опровергли.

И я не собираюсь вас опровергать, ведь это вы начали возражать моим принципам программирования А я согласен, что если делать плохо (в том числе не по стандарту или по выборочным местам стандарта, не обращая внимание на предупреждения о неопределенном поведении компилятора), то можно нарваться на проблемы.

**COKPOWEHEU** · 27 октября, 2017

В общем случае неопределенное поведение дают:

преобразование float->int (6.3.1.4)

использование внутри #include символов / , \ , ' , " (6.4.6)

даже доступ к полю атомарной структуры (6.5.2.3)

Еще можете посмотреть примеры тут https://habrahabr.ru/post/136283/

https://habrahabr.ru/post/229963/

https://habrahabr.ru/post/230777/

**ARV** · 27 октября, 2017

Только что, COKPOWEHEU сказал:

В общем случае неопределенное поведение дают

И? Договаривайте

Что может заставить программиста использовать в своей программе эти "особенности", кроме лени и неопрятности стиля?

В руководстве к автомобилю написано "не рекомендуется начинать движение на непрогретом двигателе". Это означает, что, в принципе, не запрещено, т.е. можно, но за последствия, если вдруг таковые будут, отвечать придется водителю - его предупредили. Так и здесь: стандарт говорит, что делать-то можно, но надо иметь ввиду неопределенное поведение. И делать это не будет нарушением стандарта, но ЗАЧЕМ так делать?!

Все приведенные вами случаи (и не только они - вообще все, описанные в стандарте) элементарно исключаются из обихода другими стандартными приемами.

Хабрахабр я регулярно читаю, и практически всегда там рассматриваются проблемы, о которых я говорю "хотел геморроя, когда так делал?". Если главное стремление сделать с переподвыподвертом - то и нечего жалиться на побочные эффекты...

**COKPOWEHEU** · 27 октября, 2017

Вы хотите сказать что никогда не делаете преобразование float->int?

Или не используете относительные пути к подключаемым библиотекам? Хотя бы #include <avr/io.h>

Не верю.

**ARV** · 27 октября, 2017

Только что, COKPOWEHEU сказал:

Вы хотите сказать что никогда не делаете преобразование float->int?

Читайте внимательнее мои высказывания, и тогда а)вам не придется переспрашивать, и б)мне не придется повторять.

float -> int дает неопределенный результат когда? когда мы, например, пытаемся 1Е12 впихнуть в int. Если мне приходится что-то подобное делать (не припоминаю), я всегда учитываю диапазоны значений (вспоминайте - я уже говорил о контроле переполнений и т.п.). Если я ЗНАЮ, что float у меня не превысит INT_MAX, можно пользоваться подобных преобразованием.

Или вы имеете ввиду явное приведение типов?

Только что, COKPOWEHEU сказал:

Или не используете относительные пути к подключаемым библиотекам? Хотя бы #include <avr/io.h>

Использую, как же. Но так как вы не следите за мыслью, а оспариваете все формально, я вам поясняю: особенность указания путей для конкретной платформы компиляции не порождает ПЛОХО РАБОТАЮЩУЮ ПРОГРАММУ, или НЕАДЕКВАТНО работающую. Все мои рассуждения о пользу стандарта при написании кода направлены именно на избежание проблемы, когда небрежно состряпанная программа работает не так, как задумывалось. Если же путь найден не будет, то и программа скомпилирована не будет, соответственно, никаких проблем в ее РАБОТЕ не возникнет по определению. Что пытаетесь доказать вы - мне неведомо. Сформулируйте свое мнение окончательно, чтобы я хотя бы это смог понять.

**ruhi** · 27 октября, 2017

36 минут назад, COKPOWEHEU сказал:

Вы хотите сказать что никогда не делаете преобразование float->int?

Или не используете относительные пути к подключаемым библиотекам? Хотя бы #include <avr/io.h>

Не верю.

Если Вы находите возможным жаловаться на проблемы реализации преобразования float->int на С-ях, тут как раз и получается что поколения разработчиков С какие то недоумки по сравнению с Вами, и только Вы поняли их ошибку!

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

**ARV** · 27 октября, 2017

Только что, ruhi сказал:

или я опять потерял тему обсуждения???

Нет, на этот раз в точку!

Изменено 27 октября, 2017 пользователем ARV

**COKPOWEHEU** · 27 октября, 2017

5 часов назад, ARV сказал:

Использую, как же. Но так как вы не следите за мыслью, а оспариваете все формально

Я оспариваю ваше категоричное высказывание

В 26.10.2017 в 18:35, ARV сказал:

я могу все учесть, и стандарт (насколько я его знаю) мне только помогает.

Использование конструкции #include <avr/io.h> формально является неопределенным поведением.

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

**ARV** · 27 октября, 2017

21 минуту назад, COKPOWEHEU сказал:

Может признаете наконец

Я так понимаю, женщины вам никогда не отказывают? Ибо вам легче отдаться, чем убедить, что не хочется это делать...

Я стоял и буду стоять на своём: стандарт Си, если его хорошо знаешь, только помогает делать качественные, надежно и правильно работающие программы.

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

**COKPOWEHEU** · 27 октября, 2017

То есть вы не будете использовать <avr/io.h>? Поведение этой записи не соответствует стандарту.

**ARV** · 28 октября, 2017

16 часов назад, COKPOWEHEU сказал:

Поведение этой записи не соответствует стандарту

Если вы сообщите мне, каким образом применение этой строки может изменить поведение моей программы с правильного на неправильное (или непредсказуемое) - не буду. Стандарт говорит, что ему все равно, как компилятор отреагирует на эту строку, он не ОПРЕДЕЛЯЕТ эту ситуацию. На работоспособность кода такое "не стандартное поведение" компилятора (хотя вполне со стандартом - что стандарт не определил, то реализую, как хочу) никак не влияет. И говорить об этом просто бессмысленно.

**COKPOWEHEU** · 28 октября, 2017

Это может повлиять на компилируемость программы. На других системах может быть другой резделитель директорий, например, обратный слеш. Таким образом, формально этот код не является переносимым.

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

Впрочем, можно поступить и наоборот: вы приведете достаточный кусок своего кода, а я поищу в нем несоответствия стандарту (хотя не обещаю что будет быстро)

**ARV** · 28 октября, 2017

21 минуту назад, COKPOWEHEU сказал:

Впрочем, можно поступить и наоборот

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

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

На других системах слеш может означть совсем иное, и в итоге программа не скомпилируется. После устранения НЕРЕАЛИЗОВАННОЙ В СТАНДАРТЕ возможности ОСТАЛЬНАЯ ЧАСТЬ, СДЕЛАННАЯ ПО СТАНДАРТУ, будет работоспособной на 100%. Если стандарт говорит "про слеш - это не ко мне!" - как вы можете утверждать, что что <avr/io.h> не соответствует стандарту?! UB - это аспект, не затрагиваемый стандартом. Т.е. обо всем стандарт говорит, а об этом - не желает даже напрягаться. Так что мимо ваш пример.

**COKPOWEHEU** · 29 октября, 2017

Я уже цитировал ваше утверждение что всегда дословно придерживаетесь стандарта, что это 100% защищает от подобных ошибок (про ошибки алгоритма речь не идет, они с языком не связаны).

16 часов назад, ARV сказал:

UB - это аспект, не затрагиваемый стандартом.

То что стандарт языка не затрагивает, может быть на разных компиляторах или платформах реализовано по-разному. Именно об этом речь и шла: если вы используете тот же слеш, делает вашу программу потенциально непереносимой или, хуже того, потенциально ошибочной. Допустим, есть ОС в которой слеш не является спецсимволом и может входить в имя файла*. Тогда ваш include подхватит не нужную библиотеку, а постороннюю, в которой может быть другой код. Это маловероятная, но возможная ситуация. Совсем правильно было бы обернуть такой код в #define, проверяющие тип компилятора, платформу и прочее. Но так никто не делает. Да, все полагаются на UB, все пишут потенциально небезопасный код. Просто потому что подобные экзотические платформы встречаются исчезающе редко. То же самое и с другими подобными ситуациями: для цикла от 0 до 1000 я выберу int а не uint16_t, потому что на всех известных мне платформах int как минимум 16-битный и его достаточно для цикла. Хотя стандарт этого и не гарантирует. Вы можете сами посмотреть исходные коды сложных программ и убедиться в подобном подходе (только что посмотрел случайные места кода ядра - вовсю используется те же int или long).

*) я, кстати, проверял обратную ситуацию: создал на виндовом разделе каталог "a\b" (это его имя). При этом в проводнике он отображался как "a" и зайти туда было невозможно.

**ARV** · 31 октября, 2017

В 29.10.2017 в 11:53, COKPOWEHEU сказал:

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

Вот только что прочитал заметку с хабра... цитирую кусочек:

Цитата

Рассмотрим пример. Представим тщательно написанный код на С:


void process_something(int size) { 
  // Catch integer overflow. 
  if (size > size+1) 
    abort(); 
  ... 
  // Error checking from this code elided. 
  char *string = malloc(size+1); 
  read(fd, string, size); 
  string[size] = 0; 
  do_something(string); 
  free(string); 
}

Всё, как вы и говорили: используется код, проверяющий int на переполнение. Но, простите, какой дебил на это пошел?! Сколько надо дряни выпить или вкурить, чтобы пойти на ЗАВЕДОМОЕ UB?! Чем хуже проверка на INT_MAX, не дающая UB?

if(size > INT_MAX-1)
  abort();

Какая зараза толкнула кодописателя под руку выбрать int для РАЗМЕРА ОБЛАСТИ ПАМЯТИ, величине, сугубо БЕЗЗНАКОВОЙ, т.к. отрицательного размера физически не может существовать?! uintXX_t подошел бы тут гораздо лучше, и при этом не породил бы UB.

То есть я к чему клоню? Способов выстрелить себе в ногу МНОГО БОЛЬШЕ ОДНОГО, и тупость программиста не исправит никакой стандарт. А если программист с головой дружит, стандарт ему ТОЛЬКО ПОМОЖЕТ.

Изменено 31 октября, 2017 пользователем ARV

**oldmao** · 31 октября, 2017

Я наблюдаю и тащусь... Нахера мне стандарт, если я использую конкретную реализацию компилятора?
Нужно будет перенести - так проще переписать, Всё разное - особенно порты.

**ARV** · 31 октября, 2017

5 минут назад, oldmao сказал:

Нахера мне стандарт, если я использую конкретную реализацию компилятора?

А нахера ПДД, если при наличии двух глаз и хорошей реакции можно ездить и выживать при этом? Нахера САНПИНы, если каждый и так видит, что в рот сует и где живет?

Стандарт нужен для того, чтобы разные люди понимали и, главное, предугадывали поведение своих коллег. Понимаете? Если вы заявляете, что пишите на Си, я вправе ожидать, что мы поймем написанное друг другом ОДНОЗНАЧНО. Причем я надеюсь на это благодаря наличию стандарта языка Си. А вы на что?

В 27.10.2017 в 13:35, COKPOWEHEU сказал:

Вы хотите сказать что никогда не делаете преобразование float->int?

Из недавно процитированной статьи, точнее, её первой части, я выяснил, что на самом деле UB возникает из приведения указателя на int к указателю на float с последующим разыменованием оного. Что, в общем-то, опять же очевидно: память, занятая int распределена побитово (и побайтово) совсем не так, как во float, и ожидать от разыменования указателя магического превращения одного формата данных в другой - глупо.

**ruhi** · 1 ноября, 2017

18 часов назад, oldmao сказал:

Я наблюдаю и тащусь... Нахера мне стандарт, если я использую конкретную реализацию компилятора?
Нужно будет перенести - так проще переписать, Всё разное - особенно порты.

Вот вы интересные люди! О чем вы спорите не понятно!

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

Но:

я, например, читал С-стандарт только когда занимался тестированием QNX-компилятора, потому что я должен был указать пункт стандарта в описании баги, а так в большинстве случаев мне не нужно ЧИТАТЬ стандарт, потому что, то что там написано, для меня очевидно или я предпочитаю проверять свое понимание логики работы компилятора создавая тестовые куски кода и разбирая ошибки и ворнинги, которые по ним выдает компилятор или разные компиляторы, если есть подозрения на неправильную работу одного из них.

Потом если стандарт существует и поддерживается (есть там какая то организация-достаточно серьезная которая следит за актуальностью и практикой применения), значит он был нужен и остается нужен, тут не о чем спорить, вы поспорьте еще о том что земля круглая!

**dim3740** · 5 ноября, 2017

Здравствуйте! Помогите, плз, с прерывание по таймеру Т1, атмега 328р. Светодиод на PD5 в цикле не загорается.

#define F_CPU 16000000
#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h> 

int Nom1; // счетчик
int main(void)
{
       DDRD |= (1 << PD5);  // свето на выход
  
       Nom1=4; 
       TCCR1B = (1<<WGM12); // Режим CTC (сброс по совпадению)
       TCCR1B |= (1<<CS11); //запускаем таймер1 с предделителем на 8
       OCR1A=20000; // начальная уставка
       TIMSK1 = (1<<OCIE1A); // Разрешить прерывание по совпадению
       sei();

       while(1)
       {
           //_delay_us(900);

           if (Nom1<2)   // декремент идет в прерывании Т1.    
           {
               PORTD |= (1<<5);  //свет
             _delay_ms(200);
              PORTD &= ~(1 << 5);
              _delay_ms(200);
              Nom1=4;
          }
       }
}

ISR (TIMER1_COMPA_vect)  // сюда заходим весьма редко, но в while почему то не возвращаемся

{
       Nom1--;
       TCNT1=0; // сбрасываем счетный регистр чтоб считать снова с нуля
       OCR1A = 20000;
}

Изменено 5 ноября, 2017 пользователем dim3740

**ARV** · 5 ноября, 2017

21 минуту назад, dim3740 сказал:

Светодиод на PD5 в цикле не загорается

Все переменные, которые используются одновременно в прерывании и в других местах программы, должны быть объявлены volatile

**dim3740** · 5 ноября, 2017

@ARV , огромное спасибо! Все заработало! Хотя странно, что в других проектах и так работало иногда, просто ставил задержку в цикл... А может это был глюк)))

Войти

Язык СИ для микроконтроллеров

Рекомендуемые сообщения

Ссылка на комментарий

Поделиться на другие сайты

Топ авторов темы

Топ авторов темы

Популярные посты

John44

COKPOWEHEU

COKPOWEHEU

Изображения в теме

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Присоединяйтесь к обсуждению

Последние посетители 0 пользователей онлайн

Сообщения

Похожий контент