Правильное выполнение арифметических операций?

[ARV]

Вот тип данных и набор операций с ним

то есть для того, чтобы отмасштабировать АЦП из абстрактных 10-12 битов в конкретные вольты надо освоить С++ и использовать портянку кода?! ну нет, увольте, проще 3 раза float перемножить-поделить.

[tonyk]

проще 3 раза float перемножить-поделить.

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

[ARV]

При большом количестве операций (а это как раз и был мой случай на практике) действия с плавающей точкой (ПТ) ведут к накоплению погрешности.

ну, кто ж этим спорит? только надо трезво оценивать эти погрешности... float может дать погрешность в 6-ом знаке... то есть для того, чтобы накопилась ошибка в 3-ем знаке после точки, а это есть инженерно-приемлемый вариант (точность до третьего знака), надо "накопить" аж 1000 вычислений... мне сложно представить ситуацию, когда для вычисления какой-либо характеристики требуется сделать 1000 умножения/деления и т.п.

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

[Ivanoff-iv]

Деление в АВР программное и делается сдвиговым методом (сродни делению столбиком), увеличение разрядности в этом случае не сильно замедляет процесс - увеличение разрядности делимого с 16 до 32 бит замедлит деление в 2 раза.
Если рассматривается АВР Мега, то там есть аппаратное умножение и операция *1000 занимает немного тактов
Поэтому код вида a = (unsigned long)b * 1000 / c; должен выполниться быстрее всего. (кроме того в нем отсутствует перекладывание данных "из пустого в порожнее", как у метода с остатком) и преобразование типов, как у метода с float.
ПС: деление со сдвигом по сути своей и есть деление с остатками, только остаток тут находится после каждого деления на 2 (сдвига)...

[Jack_A]

Dimon456 Тут нет самого главного: подпрограммы, которую это самое RCALL. Если не секретно , хорошо бы получить сам hex. Охота повозиться с ним для получения ясности, благо свободного времени появилось навалом: санкции, блокада, по заграницам мотаться не надо. Чтоб не загружать форум, можно в мел: gaev43@inbox.ru

Добавлено after 16 minutes 11 seconds:
[uquote="ARV",url="/forum/viewtopic.php?p=4203010#p4203010"]float может дать погрешность в 6-ом знаке... то есть для того, чтобы накопилась ошибка в 3-ем знаке после точки, а это есть инженерно-приемлемый вариант (точность до третьего знака).[/uquote]
Полностью согласен - если не идёт расчёт траекторий ракет или каких-то там метрологических изысканий , точности float более чем достаточно. Есть известный эффект: при лобавлении очень маленького числа к очень большому от маленького часть теряется вплоть до полного 0 ввиду нормализации. Но это - не вина float, это следствие конечной длины машинного слова. Целочисленные операции дают гораздо бо'льшую погрешность ввиду отбрасывания остатков (деление) и быстрое переполнение (умножение).

Спойлер

В моей давней практике работы был смешной случай. Прибор реального времени, цейтнот жуткий, каждая микросекунда на счету. Накропал (на асме, ес-но) собственную "короткую" плавучку: байт - знак-порядок, два байта -мантисса (со скрытым разрядом). Точности хватало с избыткои. Но в конце надо было суммировать, суммировать... No problem. Сумматор - с нормальной 3-байтовой мантиссой и простенькая подпрограммка суммирования 3 с 4-байтным float . Работало на ура. Иначе пришлось бы брать камень покруче, бакса на 2 дороже. А серия, а частник-хозяин...

[AlexS4]

>В потемках 0 не заметил.
ну самое интересное осталось за кадром (то что припрятоано за джампером в 04D4)
и уже по кусочкам того что видно ясно что речь скорее всего о 300-700 тактов. с учетом распаковки флота под вывод на дисплей скажем - будет порядка 1mS@1MHz. а вариат с 16битными целими примерно в 5-10 раз быстрее и использует вдвое меньше регистров(что отдаляет неочевидную но оч серьезную угрозу лавинообразной неэффективности перегрузок в стек)

имхо маразм на 8/16битках так влоб делать арифметику, которая элементарно упрощается для конкретного частного случая.

[tonyk]

Целочисленные операции дают гораздо бо'льшую погрешность ввиду отбрасывания остатков (деление) и быстрое переполнение (умножение).

Смотря какое целое. Тот BigInt, что я показал выше, при переполнении автоматически наращивает разрядность. Если не ошибаюсь, то и в Яве происходит автоматическое увеличение разрядности большого целого.
У меня в проекте рассчитывался ПИД регулятора. Требовалось разрядность 70 или 72 бит, точно не помню. Ещё нюанс. Не во всех библиотеках времени выполнения есть возможность легко перехватить ошибку вычисления с плавающей точкой.
В своей среде программирования поделите на ноль и посмотите, что получится и как это разрулить.

[WatchCat]

Вот тип данных и набор операций с ним:

Нифига себе портянка.
Если так уж хочется создания своих типов и переопределения операций - то надо на языке Ada писать.
Там это штатно есть и такого монстрообразного кода не требует. И много чего еще хорошего есть.
И для AVR реализация Ады таки существует и работает!
https://sourceforge.net/p/avr-ada/wiki/Home/
Недостаток ровно один - в сети практически нет готовых примеров кода которые можно было бы скопировать в свой проект. То есть абсолютно всё надо писать самому с нуля. Хотя на Аде писать доставляет удовольствие.
Ну и прикиньте что такое с нуля написать и отладить например работу с TWI по прерываниям.
Диаграмма состояний конечного автомата выглядит вот так:
http://easyelectronics.ru/img/starters/ ... agramm.GIF
Можно конечно взять половину если нужен только режим master,но всё равно писать много.
Есть конечно средство,упрощающее программирование конечных автоматов:
https://imatix-legacy.github.io/libero/index.htm
Но с ним самим еще разбираться надо. Там документация довольно невнятая. Трудно понять как описывать конечный автомат на входном языке этой штуки чтобы оно совпадало с замыслом автора и делало именно то что надо.
Хотя сама эта генерилка кода конечных автоматов у меня в линуксе собралась и запустилась.
Одному,увы, всё сразу не охватить. А истинных "свободных художников" от программирования нынче как-то мало,все в коммерцию ударились...
Постоянно вылезают какие-то мелкие проблемки которые надо решать.
Вот например только что: привычный vmlab не умеет симулировать atmega328p, взял proteus. А он локальные переменные в функциях не отображает. И везде на форумах говорят что это типа от того что какое-то несовпадение в форматах отладочной информации возникло с некоторой версии gcc. Лезу разбираться. Оказалось, proteus не может показать те переменные которые компилятор неявно объявил регистровыми. Лежат они в регистрах,а не в стеке,и адреса памяти у них конечно нет. Вот и не показывает.
А случилось это тогда,когда gcc внедрил вот такую оптимизацию даже при включенной опции -Og.
На время отладки это не сложно обойти - или оптимизацию выключить совсем (-О0) тогда переменные как положено в стек кладет, или эти переменные временно как volatile пообъявлять,что дает тот же результат. Но ведь даже на kazus.ru где больше всего любят proteus почему-то никто об этом не написал. Ну или я не нашел через свой медленный сельский интернет по радиоканалу.
Но у меня есть неограниченное количество свободного времени на разбирательства с вот такими особенностями поведения,а профессиональным разработчикам естественно некогда,их тоже можно понять,они бабло рубят. Мне-то за программирование тут в деревне никто не заплатит:) Поэтому я и говорю что я то ли свободный художник то ли графоман от программирования:-)

[ARV]

У меня в проекте рассчитывался ПИД регулятора. Требовалось разрядность 70 или 72 бит, точно не помню.

стесняюсь спросить: а как так вышло, что 100500 мильёнов ПИД-регуляторов в мире реализованы без такой разрядности? даже не к ночи будь помянуто, на 8-битных контроллерах?!
чует моё сердце: что-то тут не так...

В своей среде программирования поделите на ноль и посмотрите, что получится и как это разрулить

проблема тоже надуманная. непредсказуемое деление на ноль ВСЕГДА возникает только при крайне неряшливом программировании. рискну оценить в 99% вероятность исключения этой ситуации при грамотном проектировании программы без дополнительных телодвижений.

написать и отладить например работу с TWI по прерываниям

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

[WatchCat]

[uquote="ARV",url="/forum/viewtopic.php?p=4203081#p4203081"]стесняюсь спросить: а как так вышло, что 100500 мильёнов ПИД-регуляторов в мире реализованы без такой разрядности? даже не к ночи будь помянуто, на 8-битных контроллерах?![/uquote]
Стесняюсь признаться - я постеснялся задать тот же вопрос с теми же аргументами профессиональному разработчику.
Куда мне, деревенщине, мэтров критиковать...
Может там область применения высоконаучная - только там такая точность и бывает нужна обычно.
Мы же не знаем что это и для чего делалось.
А ученые - люди часто не богатые и вполне могут дешевые AVR в своих приборах использовать,это совершенно нормально.

чует моё сердце: что-то тут не так...

Мое тоже.

непредсказуемое деление на ноль ВСЕГДА возникает только при крайне неряшливом программировании

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

даже не делал попытки использовать прерывания для этой цели, как и сам модуль аппаратного TWI ни разу не задействовал... не могу понять - какие нужды могут заставить идти по этому тернистому пути?!

Начну со второй части аргумента - а как без TWI снимать данные с экзотического специфического АЦП INA226?
Мне он в моей автономной солнечной энергетике крайне удобен своими свойствами.
А насчет тернистого пути - я же говорил что я свободный художник и мне просто интересно сделать красивое решение,а не "в лоб".
Благо свободного времени на подобные развлечения у меня неограниченное количество.
Можно сказать я фактически программно-аппаратный арт-объект создаю. Самовыражаюсь таким образом.
Программа,виртуозно жонглирующая прерываниям - у меня вызывает ассоциацию с музыкой.
И смею сказать - у меня это получается. Молодость вспоминаю,когда на 8086 подобные фокусы приходилось вытворять. Там небыло технической возможности написать класс на С++. Считали такты также как сейчас на микроконтроллерах.
Понятно что сейчас эти мои умения никому не нужны,просто мне это нравится.

[ARV]

а я очень интересуюсь: у вас есть какой-то особый способ цитировать так, что цитаты оказываются под другим авторством?

а как без TWI снимать данные с экзотического специфического АЦП INA226?

ну вот я свою практику начинал с того, что написал свои ассемблерные ногодрыжные функции для работы по протоколу I2C и пользовался ими лет 5, пока не нашел готовую библиотеку на Си, тоже дрыгоножную. к тому времени я и сам мог бы на Си написать, но было уже лень...

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

Добавлено after 4 minutes 25 seconds:

экзотического специфического АЦП INA226

посмотрел даташит: с точки зрения интерфейса - совершенно никакой экзотики, классический I2C. что там по параметрам - не вникал, но для программиста это АЦП вот совсем не экзотика.

[WatchCat]

а я очень интересуюсь: у вас есть какой-то особый способ цитировать так, что цитаты оказываются под другим авторством?

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

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

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

я и сам мог бы на Си написать, но было уже лень...

Мне не лень - я развлекаюсь. Кто-то телик смотрит,кто-то пиво пьет,кто-то шахматные задачки решает,а я вот программки пишу.

экзотического специфического АЦП INA226

посмотрел даташит: с точки зрения интерфейса - совершенно никакой экзотики, классический I2C. что там по параметрам - не вникал, но для программиста это АЦП вот совсем не экзотика.

Я как раз именно про параметры говорил. А для программиста да - такой же как и прочие с подключением по i2c. Потому и удивился как это модуль TWI не использовали ни разу. Теперь после пояснения про дрыгоножную реализацию - понял. Но ведь при такой реализации надо или опрос готовности по прерыванию таймера делать или холостой цикл крутить. Первый вариант - это опять же прерывание,а второй мне эстетически очень сильно не нравится. Ну такой вот я человек - у меня сильно стремление сделать красиво. Рациональному объяснению это не поддается.

[AlexS4]

[uquote="Ivanoff-iv",url="/forum/viewtopic.php?p=4203014#p4203014"]Деление в АВР программное и делается сдвиговым методом (сродни делению столбиком), увеличение разрядности в этом случае не сильно замедляет процесс - увеличение разрядности делимого с 16 до 32 бит замедлит деление в 2 раза.[/uquote]
tbf это несовсем так потому что и каждая итерация становится тяжелее, сдвигать и вычитать(сравнивать) приходится например не 2 байта а 4
грубо можно считать что зависимость квадратичная.

[Dimon456]

Dimon456 Тут нет самого главного: подпрограммы, которую это самое RCALL. Если не секретно

А какой тут секрет

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

avr-gcc version 9.2.0 (GCC)

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

[Ivanoff-iv]

[uquote="AlexS4",url="/forum/viewtopic.php?p=4203136#p4203136"]это несовсем так[/uquote] согласен, сдвигать надо больше, но сравнивать - нет, сравнивать по разрядности делителя.
Кстати всё делимое шатать нет нужды, достаточно держать в памяти размерность делителя + 1 регистр, в нашем случае 3 регистра, а 4й (и, если потребуется, то и последующие) подгрузить, когда 3й освободится. (там счетчик итераций уже есть, по нему и отслеживать, когда требуется подгрузка)

[ARV]

где-то натыкался на исходники avr-libc, и там вроде как были все функции деления/умножения... а сейчас полез - умножение нашел, да и то только 16х16, а деления вообще не могу найти... а надо было бы просто исходники проанализировать, а не рассуждать тут абстрактно ни о чем...

[WatchCat]

Кстати, на тему GCC вопрос:
В документации сказано,что в процессе отладки рекомендуется использовать -Og так как при этом с одной стороны остаются выключенными те виды оптимизации которые мешают отладчику,а с другой - делаются дополнительные проходы для сбора полезной для отладчика информации которая потом пишется в исполняемый файл. Вот только в случае именно AVR использование -Og приводит к включению использования регистровых переменных,которое отладчику таки мешает. Чего не происходить при -O0.
Вот здесь приведены флаги оптимизации которые включает -Og:
https://gcc.gnu.org/onlinedocs/gcc/Opti ... tions.html
Однако моего уровня английского не хватило чтобы понять какой именно из этих включившихся флажков отвечает за регистровые переменные.
Моя идея состоит в том,чтобы вместо включения "обобщенного" -Og включить отдельно по списку все те же флажки кроме "мешающего".
Может быть кто-то более свободно владеющий языком подскажет?
Или наплевать на такие тонкости и просто при отладке -O0 использовать? Во всяком случае какого-то вреда для моих программ я от -O0 не заметил. Отлаженные в таком режиме и затем собранные с -Os работают нормально.

[ARV]

вместо включения всех, кроме, можно оставить включенными все, но выключить один конкретный

я точно не уверен, но вроде бы лучший кандидат на исключение - флаг -fcprop-registers. чтобы его выключить, надо добавить no-: -fno-cprop-registers. т.е. получится так: -Og -fno-cprop-registers

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

[Jack_A]

[uquote="Dimon456",url="/forum/viewtopic.php?p=4203154#p4203154"]А какой тут секрет[/uquote]
Нет, я не имел в виду, что секрет - в какой среде оно сделано, а : если эта прога сама не тайна , то выслать мне hex для препарирования в целях ясности. Впрочем, мой ынтузиазм в этой теме иссяк, проблемы набежали, так что...

[tonyk]

стесняюсь спросить: а как так вышло, что 100500 мильёнов ПИД-регуляторов в мире реализованы без такой разрядности?

Это адаптивный регулятор, хоть и ПИД. Формула довольно большая, плюс много сравнений разных вспомогательных параметров для настройки коэффициентов.

проблема тоже надуманная. непредсказуемое деление на ноль ВСЕГДА возникает только при крайне неряшливом программировании. рискну оценить в 99% вероятность исключения этой ситуации при грамотном проектировании программы без дополнительных телодвижений.

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