Мне вот такой алгоритм укладывания не нравится своей громоздкостью, а уж сдвиг со сложением -- это вообще прием из курса знакомства с ардуиной.
ИМХО это вы накручиваете для Си логические И и сдвиги совершенно нормальные операнды если читали классику по Си то согласитесь, что они придуманы лет за 40 до ардуины я не смотрел листинги (не было интереса), но могу предположить, что машинный код моего и вашего варианта плюс минус равнозначны
a5021 писал(а):
Код:
for (uint8_t i = 0; i < BMP180_PROM_DATA_LEN / 2; i++) { *buf = i2c_read(); *--buf = i2c_read(); buf += 3; }
да пожалуйста. Что мешает указатель не инкрементировать, а декриментировать? Код по размеру будет тот же, но порядок поменяется Это то, что я выше назвал - все равно перекладывать, в каком направлении класть без разницы
Использование модульных источников питания открытого типа широко распространено в современных устройствах. Присущие им компактность, гибкость в интеграции и высокая эффективность делают их отличным решением для систем промышленной автоматизации, телекоммуникационного оборудования, медицинской техники, устройств «умного дома» и прочих приложений. Рассмотрим подробнее характеристики и особенности трех самых популярных вариантов AC/DC-преобразователей MW открытого типа, подходящих для применения в промышленных устройствах - серий EPS, EPP и RPS представленных на Meanwell.market.
Любую оптимизацию можно попытаться охаять в таких формулировках.
Цитата:
я не смотрел листинги (не было интереса), но могу предположить, что машинный код моего и вашего варианта плюс минус равнозначны
А я смотрел и профилировал. Причем, выбирал из трех вариантов (правда, для stm32): а) сдвиг + сложение; б) манипуляции с указателем (приведенный выше); в) считывание по i2c в массив с использованием DMA + проход со свопом байтов. Самым быстрым и компактным оказался вариант "б".
Вопрос оптимизации в данном случае вообще не должен стоять, передача данных будет несоизмеримо дольше осуществляться чем самый неоптимальный алгоритм переворачивания байт. Поэтому в таких случаях предпочтение должно отдаваться самому очевидному и наглядному способу, ибо с этим потом работать не одному программисту. И вообще, что-то мне подсказывает что в системе команд должна быть инструкция которая меняет байты в слове.
Если говорить про оптимальность той или иной конструкции в Си обективный критерий только один - эфыективность полученоого машинного кода. Оптимизация влияет на это прямым образом
Наглядность важная вещь, но не абсолютная. Комментарии в этом важнее
Нет, столь тщательно я свои действия не документирую, чтобы сейчас же назвать точные цифры. По ходу написания мне достаточно быстрого сравнения разных реализаций одного и того же, чтобы принять решение, какую лучше использовать. Оптимизация так же может выполняться по разным критериям. В моем случае -- это скорость, т.к. запас по объему флеша есть, а скорость величина критичная.
Насчет "передача дольше", у меня трансфер по i2c выполняется с использованием слипа, т.е. загрузили данные в регистр, стартовали передачу и спать. Окончание передачи будит ядро. Запустили чтение и опять спать, пока весь байт не приползет. А вот дальше надо все делать максимально быстро, т.к. в это время энергопотребление максимально и в моем случае -- это самый важный ресурс, который надлежит оптимизировать.
Боюсь тут не всё однозначно в плане потребления. Максимально быстро не всегда означает максимально экономично в энергетическом плане. Статическое потребление контроллером не зависит от скорости выполнения, но и оно довольно небольшое. Количество энергии потраченное на обработку данных будет зависеть исключительно от количества переключений и не всегда это коррелирует с количеством тактов, особенно когда задействованы разные инструкции. Кстати, а как по энергетике будет отражаться вход/выход из спящего режима? Это может убить всю экономию...
Выход из режима sleep для F030 по времени занимает четыре такта. Именно столько времени проходит с того момента, как случился ивент, до начала исполнения инструкции, следующей после WFE. Других никаких накладных расходов нет.
Говорить о том, что какие-то инструкции более энергоэффективны, а какие-то менее, не имеет смысла до того момента, пока дело не касается какой-то конкретной последовательности машинных команд. Однако, расходы связанные с неизменными энергозатратами по выполнению единичной команды, позволяют утверждать, что чем этих команд меньше, тем для энергоэффективности лучше. Правило, чем меньше команд, тем меньше затраты энергии, будет работать во многих, если не в большинстве, случаев. По любому, разница между энергоэффективностью разных команд намного меньше, чем разница между активным состоянием и режимом сна. Чем раньше уйдем в сон, тем больше сэкономим энергии.
когда прилетают данные, обработчик срабатывает, но начинает срабатывать бесконечно, работает бесконца, хотя на входе всего 22 байта если точку останова из обработчика убираю и иду программу пошагово то как только прилетает первый байт - у меня отладка зависает, т.е. уходит в исполнение последней строки кода main на которой нажал F10 и больше не возвращается. Не важно какая строка кода, ависает именно с прилетом первого байта
а как же информация о том, что он сбрасывается после чтения из UART_DR?
Цитата:
This bit is set by hardware when the content of the RDR shift register has been transferred to the UART_DR register. An interrupt is generated if RIEN=1 in the UART_CR2 register. It is cleared by a read to the UART_DR register. In UART2 and UART3, it can also be cleared by writing 0. 0: Data is not received 1: Received data is ready to be read.
У меня есть подозрение, что чтение регистра данных в обработчике компилятор вообще вынес, т.к. дальше с этими данными никаких операций не производится.
У меня есть подозрение, что чтение регистра данных в обработчике компилятор вообще вынес, т.к. дальше с этими данными никаких операций не производится.
возможно, хотя висло и до того как я строку ниже закоментировал поставил принудительный сброс флага, виснуть перестало
мне бы сначала принять пакет, когда заработает то можно из любопытства убрать принудительный сброс и проверить будет работать или нет
пока что у меня ерунда выходит. С другого МК через RS485 шлю бакет со стартовым символом по началу мусор прилетал поставил паузу после переключения у передатчика max485 на передачу в 100мсек, стартовый символ поймал но остальные данные - опять нули...
т.е. пока у меня прием на STM8 не работает, где то я ошибаюсь хотя передача уже отлажена, в обратную сторону все работает на ура
Заработало, было две проблемы - косяк в организации буфера и потребовалось вставить задержки после переключения max485 перед передачей и задержка после передачи до возврата в режим чтения
Задержки сделал тупыми циклами. А как правильно делать задержки в единицы и десятки мсек?
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 5
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения