Заголовок сообщения: Re: Как передать int по USART?
Добавлено: Вт апр 07, 2015 17:07:52
Встал на лапы
Зарегистрирован: Чт май 09, 2013 10:50:04 Сообщений: 135
Рейтинг сообщения:0
Аlex писал(а):
Почему этот вопрос именно при переходе на char у вас возник ? Вы вообще в курсе чем они отличаются ?
Функция не моя. Взял её из даташита на Atmega8 стр. 132 поэтому вопросов и небыло)) char от -128 до 127 unsigned char от 0 до 255 вот из-за диапазонов у меня и вопрос.
USARTу пофиг, что передавать, он передает байт, а что в нем - символ или короткий int или еще чего - без разницы. Цифровые символы '0'...'9' имеют коды 0х30 ... 0х39, так что и в signed и в unsigned без разницы.
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
000020b4 <__udivmodhi4_ep>: 20b4: 88 1f adc r24, r24 20b6: 99 1f adc r25, r25 20b8: 5a 95 dec r21 20ba: a9 f7 brne .-22 ; 0x20a6 <__udivmodhi4_loop> 20bc: 80 95 com r24 20be: 90 95 com r25 20c0: bc 01 movw r22, r24 20c2: cd 01 movw r24, r26 20c4: 08 95 ret
В каком месте тут "во МНОГО" (большими жЫрнЫми буквами, для усиления эффекта) раз медленнее, если оно делается всё тем же способом сложения-вычитания? Не надо пытаться быть умнее хорошего компилятора. Пишите нормальный человекопонятный код, а не дебильные циклы "двадцатьпервым пальцем" и всё будет ок.
После этой замены размер прошивки увеличился на 42 байта, и это еще не добавлена прединициализация элементов display_symbols нулем или 0x30 (впрочем, она не должна существенно изменить размер кода).
Что мы видим - на получение одного значения теперь надо не 6 опкодов вызова функции, а 14/13/12. Функция размером 20 машинных операций/опкодов. Соответственно решение с циклом while займет больше места ( 3*6 + 20 < 3*13) в прошивке даже если в коде будет только три цикла.
Вызываемая функция - делает ту же математику вычитанием, соответственно не может быть "во МНОГО" раз медленнее.
Так в реальной программе всё равно будет использоваться деление, а операций будет не три, а больше - то использование нормальных функций, а не цикла - выгоднее по размеру и не уступает по скорости.
Кроме того, прикладной программист может и не знать всех оптимизационных трюков, которые заложили разработчики компилятора, а в некоторых случаях - и возможностей процессора.
если оно делается всё тем же способом сложения-вычитания?
да, подпрограмма деления тоже делается способом сложения-вычитания, только ты, видимо, забыл, что там сложения-вычитания у тебя делаются 17 (семнадцать) раз. а вычесть, например, 1000 нужно максимум 9 раз. а минимум - вообще ни разу. что быстрее, всегда делать 17 кругов или сделать (максимум) 9 кругов, или вообще не сделать ни одного круга?
_________________ Мудрость приходит вместе с импотенцией... Когда на русском форуме переходят на Вы, в реальной жизни начинают бить морду.
Ну чтож, я спросил, вы показали. ) Спасибо, посмотрел, увидел.
Но использование циклов для решения задачи всё равно остается говнокодом, в этой части мое мнение остается без изменений, т.к строгой необходимости использования именно цикла вместо оператора деления в общем случае я не вижу.
Если в проекте не хватает производительности на оператор деления - то его использование циклов не спасет, т.к. когда выпадет "9999" то число циклов отличаться будет уже не так МНОГО, как в варианте "1111". А проект, который работает только при 1111 и валится при 9999 .... ну вы поняли мысль.
строгой необходимости использования именно цикла вместо оператора деления в общем случае я не вижу.
а то, что оператор деления использует циклы, ты опять забыл? так посмотри свой представленный код с делением.
pavel2000 писал(а):
использование циклов для решения задачи всё равно остается говнокодом
так что, использование оператора деления также будет говнокодом, так как оператор деления использует циклы. даже говнокодом в квадрате против вычитания и сложения, так как работает медленнее, чем вычитания и сложения.
_________________ Мудрость приходит вместе с импотенцией... Когда на русском форуме переходят на Вы, в реальной жизни начинают бить морду.
Язык программирования придуман не для того, чтобы процессору было легче, а чтобы легче было человеку. Любой, сколь угодно миниатюрный и/или сверхбыстрый код есть говно, если на его понимание человеку требуется больше усилий. Весь "гениальный" код - код одного программиста, и умирает вместе с ним, т.к. никому более не нужен. В отличие от.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Но использование циклов для решения задачи всё равно остается говнокодом
А то, что в системе команд некоторых МК нет операции умножения-деления - как с этим быть? И ничего, что код написан на Си - от этого такая команда в МК волшебным образом не появится. Компилятор, зная конкретную модель МК , сам решает - использовать соответствующую команду или подпрограмму при отсутствии необходимой. СпойлерНа бывшей моей работе как-то я выразил сомнение в оптимальности и вообще работоспособности увиденной программы. И их шеф заявил так: "Программа написана на языке Си, компилятор ошибок не выявил - НЕПРАВИЛЬНОЙ ОНА БЫТЬ НЕ МОЖЕТ! " О существовании понятия "логическая ошибка" бедняга понятия не имел.
любой, сколь угодно миниатюрный и/или сверхбыстрый код есть говно, если на его понимание человеку требуется больше усилий. Весь "гениальный" код - код одного программиста, и умирает вместе с ним, т.к. никому более не нужен. В отличие от.
Это гораздо практичнее, нежели отсутствие коммерчески успешного устройства вообще. В попытке получить "правильный" код можно вообще ничего не получить. Ну и само видение "правильного" кода - очень индивидуальное понятие. Это особенно заметно для чисто радиотехнических устройств, где написать "правильный" с точки зрения классического программиста код вообще невозможно - настолько экзотически используются аппаратные ресурсы для генерации режима реального времени. Можно канешна посоветовать взять более мощный чип МК, а равно добавить в схему FPGA, что возможно и с инженерной точки зрения будет оправдано, но тогда это "правильное" во всех отношениях устройство (включая его код) будет нужно только его создателю. Рынок его не примет. Дорого. А с "не совсем правильным" кодом, который ВОЗМОЖНО не осилит некий гипотетический программист пришедший на смену автору, можно упростить ситуацию правильно написанными комментариями и сопроводительной документацией с описанием алгоритмов и генерируемых диаграмм работы. Помнится, что в 80-х годах прошлого века найти в программах обслуживающих бортовую РЛС сам код было отдельной нетривиальной задачей. Комментариев было больше, чем кода. А читать код и понимать его было доступно только программистам с профильным образованием прикладной математики со специализацией в обработке радиолокационных сигналов. Я вот сегодня примерно такой же код писал для сходного по генезису устройства (не подумайте ничего про БРЛС - сугубо мирное и гражданское)...
ЗЫ. Павел2000 может считать это сообщение обещанным ему. Тут в соседней ветке коллега roman.com решает создать из мусора в собственном столе не меньше, чем PHY Ethernet. Вот с ним пообщайтесь на предмет "правильного кода". Он парень веселый. Рассмеется вам в лицо. Я так думаю.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 27
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения