Программирование STM8

[BlackKilkennyCat]

[uquote="VladislavS",url="/forum/viewtopic.php?p=3955433#p3955433"]Только в скорости.[/uquote]
не только.
a = b;
a = c;
это не кривой код, но без явного указания что с этим делать оптимизатор испортит логику.

[VladislavS]

С чего бы это? Он поступит точно исходя из того что за сущности из себя представляют a, b и с. От полного выкидывания кода до запуска МБР.

[BlackKilkennyCat]

Он поступит так, как видел это программист, создававший его.

[VladislavS]

Нет, он поступит в соответствии со стандартом языка программирования.

[BlackKilkennyCat]

Угу.

[jcxz]

[uquote="BlackKilkennyCat",url="/forum/viewtopic.php?p=3955434#p3955434"]a = b;
a = c;
это не кривой код, но без явного указания что с этим делать оптимизатор испортит логику.[/uquote]
Это вообще не код. И единственное что с ним сделает компилятор/оптимизатор - выдаст сообщение об ошибке. Так как типы a,b,c - не определены. А без них невозможно понять что делает этот "код".

Если же предположить что: a,b,c имеют тип int (int a,b,c;), то этот код соответствует коду:
a = c
и компилятор его нормально скомпилит.
Что такое "испортит логику" - не понимаю. Логика тут простая - "а присвоить с", какая же ещё?

Добавлено after 10 minutes 55 seconds:
[uquote="BlackKilkennyCat",url="/forum/viewtopic.php?p=3955416#p3955416"]Работа кода с оптимизатором и без всегда будет отличаться, притом в зависимости от настроек оптимизатора и код при этом не будет кривой. Отличия могут привести к неправильной работе.[/uquote]
Только скоростью. Как уже выше сказали. Если не только скоростью - код кривой.
Или приведите реальный пример такого кода, работа которого будет отличаться в зависимости от оптимизации (на нормальном компиляторе, а не некоем почти никем не используемым и давно заброшенным).

[BlackKilkennyCat]

[uquote="jcxz",url="/forum/viewtopic.php?p=3955618#p3955618"]Это вообще не код. И единственное что с ним сделает компилятор/оптимизатор - выдаст сообщение об ошибке. Так как типы a,b,c - не определены. А без них невозможно понять что делает этот "код".[/uquote]В случае разных типов я бы указал приведение к типу. Его тут есть?

тот код соответствует коду:
a = c
и компилятор его нормально скомпилит.
Что такое "испортит логику" - не понимаю. Логика тут простая - "а присвоить с", какая же ещё?

Вообще-то, есть ещё такое понятие как время. В одно время мне нужно, чтоб а равнялось б, а в другое время, чтоб с, даже если это время равно одному такту. Неважно, зачем. Это может быть что-то параллельное: что-то где-то рядом читает a. Может быть требованием какой-либо периферии, например получение доступа к флэш у STM.

Только скоростью. Как уже выше сказали. Если не только скоростью - код кривой.
Или приведите реальный пример такого кода, работа которого будет отличаться в зависимости от оптимизации (на нормальном компиляторе, а не некоем почти никем не используемым и давно заброшенным).

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

[pavel2000]

[uquote="BlackKilkennyCat",url="/forum/viewtopic.php?p=3955654#p3955654"]Вообще-то, есть ещё такое понятие как время. В одно время мне нужно, чтоб а равнялось б, а в другое время, чтоб с, даже если это время равно одному такту. Неважно, зачем. Это может быть что-то параллельное: что-то где-то рядом читает a. Может быть требованием какой-либо периферии, например получение доступа к флэш у STM.[/uquote]

Откройте для себя такое ключевое слово: "volatile".

[sergey.UA]

По поводу INT или FLOAT, в первой строчке программы, для первых трех переменных.
Изначально было так:

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

В счетчик кол.ва циклов, в десятичную переменную со знаком ( -2 147 483 648,0 : 2 147 483 647,0 ) сохраняем значение переменной с такой же разрядностью + переменная, но со максимальным значением не более 300. Т.е. логично использовать для этих целей переменную размерности INT ( - 32 768 : 32 767 ).
Всего получается 16 проходов цикла.

Не увидел разницы в кол. ве проходов цикла, как от обозначения размерности INT так и от обозначения как FLOAT.
jcxz, что вы имели в виду ?
Спасибо.

[Мурик]

Не учитесь быдлокодингу! Если на компе float выполняется быстро, то на STM8 будет очень медленно. Пишите так чтобы код был как можно оптимальнее, иначе потом придется переучиваться или будете писать медленный и ресурсоемкий былокод.
Можете посмотреть сколько тактов нужно МК без без аппаратной поддержки float для вычислений с плавающей точкой. http://purebasic.mybb.ru/viewtopic.php?id=717

[BlackKilkennyCat]

Использование float не делает из кода "быдло". Количество тактов не является приоритетом.
Не учите тупым шаблонам.
Приоритетным является алгоритм, а не высосанные из пальца какие-то догмы.
Использование float чревато лишь из-за способа представления данных, в результате которого в отсутствие чёткого понимания механизма, может быть, например, неверное сравнение в условии. То, что числа с плавающей точкой обрабатываются дольше - всего лишь особенность, каковых куча.

[Reflector]

[uquote="Мурик",url="/forum/viewtopic.php?p=3955721#p3955721"]Можете посмотреть сколько тактов нужно МК без без аппаратной поддержки float для вычислений с плавающей точкой. http://purebasic.mybb.ru/viewtopic.php?id=717[/uquote]
Что-то он там не то для H750 намерял, как может получиться в полтора раза меньше F4... У меня для 480 MHz вышло 16 тактов вместо 26, а для 240 MHz, когда делитель AHB можно единичным сделать, вообще всего 11 тактов.

[jcxz]

[uquote="BlackKilkennyCat",url="/forum/viewtopic.php?p=3955654#p3955654"]В случае разных типов я бы указал приведение к типу. Его тут есть?[/uquote]
Причём тут "приведение типа"?
Что такое a,b,c? Здесь форум для телепатов?
Предполагаю что это:

Код: Выделить всё

enum {b, c};
int a;

Соответствует вашему примеру? Да! Вы это имели в виду или что-то иное? Только телепат знает что имелось в виду. И как прикажете угадать нетелепатам?

[uquote="BlackKilkennyCat",url="/forum/viewtopic.php?p=3955654#p3955654"]Вообще-то, есть ещё такое понятие как время. В одно время мне нужно, чтоб а равнялось б, а в другое время, чтоб с, даже если это время равно одному такту.[/uquote]
Для этого есть volatile. Если вам нужно именно это, то нужно описать:
int volatile a, b, c; (это опять к слову о том - зачем описывать что такое a,b,c)
И тогда будет работать именно так. Без volatile - как я описал выше.
Если человек имел виду такой алгоритм, но написал как вы привели (без volatile) - код кривой, а написатель его - сам себе дурак. Как я уже говорил. И дело не в компиляторах/оптимизаторах, а в написателе сего недоразумения. Впрочем - у неумех всегда во всём инструмент виноват.

[uquote="BlackKilkennyCat",url="/forum/viewtopic.php?p=3955654#p3955654"]Опции, отключающие или ограничивающие влияние оптимизатора на код придумали для таких неверующих в его святость, как я.[/uquote]Баги компиляторов есть, я же не отрицаю (и даже сам их находил и не один). Но в 99.99% случаев кривизна работы какого-то кода - заслуга не кривого компилятора, а прослойки между стулом и клавиатурой.
А "опции отключающие" - придумали главным образом - для возможности отладки с привязкой к исходному коду. Так как - чем выше уровень оптимизации - тем труднее сопоставить исходный код, результирующей последовательности асм-команд.
Если какие-то неумехи используют эти опции всегда (так как не умеют писать код, корректно работающий с любым уровнем оптимизации), то это говорит только об их уровне компетенции.
А нормальный программист если видит, что при включении максимальной оптимизации, програмамма стала глючить, начинает искать ошибки в своём коде. А не заметает проблему под ковёр, отключая оптимизацию. Второе - признак быдлокодера, а не программиста.

Добавлено after 9 minutes 6 seconds:
[uquote="sergey.UA",url="/forum/viewtopic.php?p=3955712#p3955712"]Не увидел разницы в кол. ве проходов цикла, как от обозначения размерности INT так и от обозначения как FLOAT.
jcxz, что вы имели в виду ?[/uquote]
Переменная счётчика цикла (fahr) у вас типа float. float - это значение с плавающей точкой. А значит операции с ним всегда имеют некую погрешность.
А значит на 16-м шаге значение fahr будет: fahr = lower + step * 16 + delta * 16
delta будет зависеть от особенностей реализации операций FPU в данном конкретном компиляторе/МК, а также - от фазы Луны (delta может быть больше или меньше 0).
А значит в каких-то случаях у вас будет 16 шагов, а в каких-то - 15 шагов.

Добавлено after 7 minutes 16 seconds:
[uquote="BlackKilkennyCat",url="/forum/viewtopic.php?p=3955753#p3955753"]Использование float не делает из кода "быдло".[/uquote]Если float - в качестве счётчика цикла - делает.

[uquote="BlackKilkennyCat",url="/forum/viewtopic.php?p=3955753#p3955753"]Приоритетным является алгоритм, а не высосанные из пальца какие-то догмы.[/uquote]А то что число проходов приведённого цикла может зависеть от фазы Луны - ничего?
Вот это и называется быдлокод - скомпилили одним компилятором - 16 проходов, другим - 15. Конечно виноват компилятор и не быдлокодер!

[BlackKilkennyCat]

[uquote="jcxz",url="/forum/viewtopic.php?p=3955761#p3955761"]А то что число проходов приведённого цикла может зависеть от фазы Луны - ничего? [/uquote]
Читайте внимательно:

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

Это я написал. Поставить сюда ржущий смайлик, что ли...

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

Понятно. Но я уже говорил - спорить не буду. Не видите очевидного, сами себе противоречите (volatile - то же опция) - Ваше счастие. Да и куда мне, неумехе-то, у которого инструмент виноват. У меня даже понимание термина "алгоритм" другое. Неверное.

[jcxz]

[uquote="BlackKilkennyCat",url="/forum/viewtopic.php?p=3955766#p3955766"]Это я написал. Поставить сюда ржущий смайлик, что ли...[/uquote]
А если написать например что-то типа:

Код: Выделить всё

static char const t[] = "0\0" "1\0" "2\0" "3\0" "4\0" "5\0" "6\0" "7\0" "8\0" "9";
for (char const *s = &t[0]; atoi(s) < 9; s += strlen(s) + 1) {
  ... //в теле цикла s не используется, только для счётчика цикла!!
}

Это быдлокод или "способ представления данных"?

Добавлено after 13 minutes 1 second:
[uquote="Мурик",url="/forum/viewtopic.php?p=3955721#p3955721"]Не учитесь быдлокодингу! Если на компе float выполняется быстро, то на STM8 будет очень медленно.[/uquote]С точки зрения скорости выполнения и громоздкости, float в том коде не самое страшное. Гораздо хуже то, что там ещё есть и double-операции. Их даже и не всякий ARM аппаратно осилит, а уж о STM8 - вообще молчу.

[sergey.UA]

Понял, спасибо. Я пока что не гонюсь за точностью, ( кол. вом циклов ), но в будущем, при обработке ( пересчете ) данных какого то, к примеру 12 - 14 битного АЦП, учту.
----------------------
К стати, здесь кто то говорил, что нет какого то определенного языка С для STM8, а как же узко специализированные ( для STM8 ), команды для работы с внутренними модулями камня, команды (функции) для приема - передачи данных по различным встроенным в чип интерфейсам ?

[jcxz]

[uquote="sergey.UA",url="/forum/viewtopic.php?p=3955780#p3955780"]Понял, спасибо. Я пока что не гонюсь за точностью, ( кол. вом циклов ), но в будущем, при обработке ( пересчете ) данных какого то, к примеру 12 - 14 битного АЦП, учту. [/uquote]Тут дело не в точности. Корректно написанное ПО должно выполняться одинаково при работе в любом окружении и компиляции любым компилятором. А у вас будет зависеть от реализации FPU и от особенностей работы его режима округления.
Поэтому типы с плавающей точкой используют только там, где это реально нужно. Для счётчика цикла они не нужны и даже вредны. И при операциях сравнения типов плавающей точки использовать операции ==, <=, >= следует осторожно, помня о погрешности и применяя вместо == проверку на диапазон.
Также следует избегать алгоритмов с накоплением ошибки вычислений (как у вас, где на каждом шаге цикла ошибка вычислений delta суммируется).

Добавлено after 5 minutes 12 seconds:
[uquote="sergey.UA",url="/forum/viewtopic.php?p=3955780#p3955780"]К стати, здесь кто то говорил, что нет какого то определенного языка С для STM8, а как же узко специализированные ( для STM8 ), команды для работы с внутренними модулями камня, команды (функции) для приема - передачи данных по различным встроенным в чип интерфейсам ?[/uquote]Нет таких команд в языке си. Как и функции - это не элементы языка.

PS: Вы бы лучше сперва учебник по си до конца дочитали, прежде чем что-то писать.

[Reflector]

[uquote="jcxz",url="/forum/viewtopic.php?p=3955761#p3955761"]Переменная счётчика цикла (fahr) у вас типа float. float - это значение с плавающей точкой. А значит операции с ним всегда имеют некую погрешность.[/uquote]
Не всегда. Если число дробное, то зависит от числа, а целые числа float может хранить без погрешности вплоть до 24-х бит, так что при шаге 20 можно столкнуться с проблемами не раньше 838861 прохода

[VladislavS]

[uquote="jcxz",url="/forum/viewtopic.php?p=3955618#p3955618"]Если же предположить что: a,b,c имеют тип int (int a,b,c;)[/uquote]Мне вот так больше нравится.

Код: Выделить всё

struct B
{
  operator int(){__enable_irq(); return 0;}  
};

struct C
{
  operator int(){__disable_irq(); return 1;}  
};

int main()
{ 
  int a;
  B b;
  C c;
  a=b;
//    CPSIE    I
  a=c;
//    CPSID    I
}

[BlackKilkennyCat]

Увидел важную информацию для программистов, ...

в МЯЯЯЯУ. всё г... там.