Читаю reference manual на stm8s, раздел по таймерам. Вот написано, что у advanced control timer прескалер может быть: any integer from 1 to 65536. То есть, любое целое число в диапазоне 1 - 65536. Это понятно. А вот у general purpose timer прескалер может быть: any power of 2 from 1 to 32768. Тут непонятка. Имеется в виду число кратное двойке - 2, 4, 6, 8, 10, 12... или степень двойки - 2, 4, 8, 16, 32, 64 ?
UPD: Блин, туплю... "power of 2" - это же степень двойки? Получается всего 16 значений от 1 до 32768. UPD2: Ага. И записывается в регистр не само значение прескалера (как в advanced control timer), а степень двойки. Например для прескалера 128 нужно записать 7 в регистр, т.к. 2^7=128
Проверяю в дебагере, биты C14 и C15 в регистре PB_CR1 устанавливаются в единицу. Но не смотря на это, биты IDR4 и IDR5 в регистре PB_IDR хаотично переключаются. Когда ставлю внешний подтягивающий резистор - всё работает. Не пойму, что не так. То ли я где-то косячу, то ли что-то с МК. В Errata Sheet заглядывал, там про pull-up ничего не сказано.
Сначала было подумал, каким боком true open-drain, если используется режим входа? Но потом внимательно посмотрел даташит и таки да: PB4 и PB5 - true open-drain. А чуть ниже пометка: "P-buffer, weak pull-up, and protection diode to VDD are not implemented". И это два единственных пина с true open-drain.
Всё никак не привыкну после AVR, что у STM надо обращать внимание на особенности разных ножек.
Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
Карма: 16
Рейтинг сообщений: 166
Зарегистрирован: Вс дек 02, 2012 16:58:33 Сообщений: 826 Откуда: Уже не город Белых гор
Рейтинг сообщения:0
Так у них может быть питание 3,3В, а работают с I2C устройством от 5В. Вот в этом случае open drain выручает. Мне как раз понадобился такой режим - настройка внешнего устройства по I2C.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
_________________ Не ошибается только то, кто ничего не делает. Тот, кто признает свои ошибки, на них учится. Глупец же, упорствуя в своих заблуждениях, остается глупцом.
Так как автор кода ST, могу только предположить, что это было сделано, чтобы получить одну функцию. У Вас же получается две. В любом случае, SDCC впихнуло параметр в 16-ти битный регистр, так что по производительности вариант ST ничем не хуже Вашего.
А как по мне, такие вещи вообще правильней макросами делать без лишних функций.
_________________ Не ошибается только то, кто ничего не делает. Тот, кто признает свои ошибки, на них учится. Глупец же, упорствуя в своих заблуждениях, остается глупцом.
Так как автор кода ST, могу только предположить, что это было сделано, чтобы получить одну функцию.
Функция может быть и ни при чем, если вспомнить, что SR1 и SR2 отображаются в адресном пространстве по соседству и к ним обоим можно обращаться сразу, как к одному 16-битному регистру.
_________________ Не ошибается только то, кто ничего не делает. Тот, кто признает свои ошибки, на них учится. Глупец же, упорствуя в своих заблуждениях, остается глупцом.
И что дальше? Вы предлагаете писанину обдолбанных индусов возвести в ранг эталона и молиться на нее, как на сокровищницу программистской мысли? Код STM8S_StdPeriph_Lib местами вообще напоминает плоды программы социализации больных с тяжелыми формами аутизма. Типа, пусть они пишут, чего им вздумается, ST Micro выкладывает это в паблик, чтобы у больных создавалось ощущение востребованности плодов их труда. Как либо иначе объяснить всю эту долбанину исключительно сложно.
Любопытства ради, я просмотрел сейчас код в stm8s_tim2 и испытал совершенно непередаваемые ощущения. Позволю себе привести один маленький фрагмент, чтобы не быть голословным:
Начинаем разматывать этот бред с конца: функция, возвращающая результат типа FlagStatus, оператором Return описывает возврат значения переменной типа FlagStatus. Вопрос: в какой из самых запущенных стадий находится помутнение рассудка у писавшего сие, если он отдельно описывает приведение переменной типа FlagStatus к типу FlagStatus ?
Следующий момент: в секции else переменной bitstatus присваивается значение RESET. Смотрим внимательно, могла ли эта переменная иметь другое значение, если известно, что в самой первой строке функции именно это значение ей и присваивалось, а более никаких действий с этой переменной в коде функции не производится? На кой хрен вообще нужна секция else в таком случае?
Чтобы разобрать загадочные манипуляции с двумя переменными, не хватит ни времени ни страниц форума. Охарактеризую коротко -- это жесточайшая шизофрения, невиданная и непостижимая.
Как говорится, "критикуя, предлагай". Что бы написал я, если бы данный кусок кода поручили придумывать мне. Начну по порядку: тип для отображения статуса таймера я бы объявил так:
Разницу с тем, как это объявлено в STM8S_StdPeriph_Lib у буйнопомешанных индусов, представляет иной порядок размещения флагов. По сути, он обратный: флаги SR1 лежат в старшем байте, флаги SR2 в младшем. Вместо волшебных цифр, дифайны из stm8s.h
Что дает такая "перемена мест слагаемых": если переменную данного типа мысленно наложить на TIM2_SR1, то члены перечисления точно лягут по флагам того же назначения, как в регистрах TIM2->SR1 и TIM2->SR2. Это в свою очередь позволит упростить такие функции, как TIM2_ClearFlag и TIM2_GetFlagStatus. Они легко могут быть переписаны в каком-то таком виде:
Карма: 16
Рейтинг сообщений: 166
Зарегистрирован: Вс дек 02, 2012 16:58:33 Сообщений: 826 Откуда: Уже не город Белых гор
Рейтинг сообщения:0
Дико плюсую по программистскому подходу. Однако, добавлю от себя по логике работы: зачем городить функции, когда можно просто глянуть нужный флаг в регистре таймера? В моём случае, когда код инициализации uart превысил 2 килобайта, я отказался от SPL (правда, это было на STM32F051). С тех пор достаточно регистров, и не жалею. Причём и на STM8S, и на STM32F446.
я отказался от SPL (правда, это было на STM32F051). С тех пор достаточно регистров, и не жалею. Причём и на STM8S, и на STM32F446.
Согласен! Пусть попробуют при плотном коде работы с периферией покрутиться с этими жирными функциями, хоть в первой редакции, хоть во второй. Про прерывания вообще страшно подумать.
Однако, добавлю от себя по логике работы: зачем городить функции, когда можно просто глянуть нужный флаг в регистре таймера?
На вопрос "зачем", можно даже попробовать найти непротиворечивый ответ, но на то, чем за это придется платить, я предлагаю все-таки взглянуть. Речь о исполняемом коде, который получается после компиляции.
Чтобы не умножать печалей, я возьму уже причесанные функции из моего предыдущего сообщения и сравню, насколько отличается гененрируемый компилятором код, если проверять статус таймера посредством вызова функций и посредством прямого обращения к регистрам.
Простой пример:
Код:
if (TIM2_GetFlagStatus(TIM2_FLAG_CC1) == SET) { TIM2_ClearFlag(TIM2_FLAG_CC1); }
if (TIM2->SR1 & TIM2_SR1_CC2IF) { TIM2->SR1 &= ~TIM2_SR1_CC2IF; }
В первой проверке условия используется вызов функций, во второй обращение к регистрам. При включенной по максимуму оптимизации компилятор выдал следующий код:
Соптимизировалось все, стоит заметить, довольно неплохо. Функции заинлайнились и код вышел вполне компактным. Для каждой строчки я посчитал время выполнения и объем (две цифры в комментариях), которые ниже просуммировал. Итого, при использовании функций для проверки и сброса флага потребуется выполнить 14 команд, по времени это займет 17 тактов процессора и расход флеша составит 23 байта. Точно такое же действие, выполненное через обращения к регистрам, потребует выполнения двух команд, трех тактов процессора и девяти байт флеша. Выигрыш по размеру кода около трех раз, по скорости почти шесть. Цифры говорят сами за себя и комментировать тут больше нечего.
Еще хотелось бы заметить вот что: SPL вызывает грустные чувства не только тем, что код написан безобразно, безобразен так же и дизайн библиотеки. Вот прямо по этим двум функциям можно предъявлять претензии. Причем, не по тому, как они написаны, а относительно того, что они вообще делают. Ну нафиг ведь не сдалось проверять или сбрасывать оба статусных регистра таймера вместе. SR2 хранит флаги относящиеся только к режиму захвата (причем, для отображения редкой ситуации т.н. перезахвата). В остальных режимах (а их большинство и используются они много чаще) данный регистр в принципе не может содержать полезной информации и/или использоваться осмысленно. Но какая-то светлая индусская голова решила, что "нужно трясти" и вот с тех пор оно трясется безостановочно и совершенно безо всякого смысла.
У меня вообще ощущение, что STM8 производитель забросил на самотёк и больше не планирует поддерживать, а зря - в определённой нише даже 32F030 жирновато будет, ИМХО.
писанину обдолбанных индусов ... молиться на нее, как на сокровищницу программистской мысли? социализации больных с тяжелыми формами аутизма ... чтобы у больных ... эту долбанину исключительно сложно.
Я уже как-то писал, что подобный лексикон заставляет мое воображение услужливо рисовать склочную бабу, не способную вообще ни к какому виду общения без эмоционального накала и перехода на личности (пусть даже личности авторов SPL) Если считаете себя специалистом, так ведите себя соответствующе.
a5021 писал(а):
Любопытства ради, я просмотрел сейчас код
Ну раз ST предлагает эту библиотеку в качестве эталона и другой библиотеки я на просторах инета не встречал, то вариантов у нас не много: 1. Использовать ее непосредственно 2. Использовать ее в виде документации, но программируя самостоятельно 3. Не использовать ее вообще, руководствуюясь только datasheet
Я склоняюсь, ко второму варинту, о чем уже писал выше:
ptr писал(а):
А как по мне, такие вещи вообще правильней макросами делать без лишних функций.
Поэтому оптимальность и красота кода в ней мне глубоко монопенисуальна. А вот явные баги - нет. Поэтому про багу я и написал. А все что изложили Вы вообще ни на что не виляет, так как все эти лишние преобразования типа и присвоения на результирующий код не повлияют, благодаря оптимизатору.
a5021 писал(а):
Сравните с оригиналом и почувствуйте, что называется, разницу.
Если Вы склоняетесь к первому варинту использования этой библиотеки, то IMHO, Вы сильно не правы. Вне зависимости от качества кода SPL, при наличии всего трех регистров общего назначения, они, в случае функции, любым компилятором буду гоняться в стек и обратно. Очень не эффективно и с точки зрения производительности, и с точки зрения расхода памяти. Если ко второму, как и я, смысл Ваших исследований - нулевой. Если Вы склоняетесь к третьему варианту, то зачем Вы тогда вообще в эту библиотеку полезли? Времени лишнего что ли навалом?
Убедительная просьба, о багах в SPL здесь писать, потому что не всякий новичок их сразу заметит. О качестве кода - не стоит. Так можно всю ветку загадить не принеся ни йоты толку. А эмоциональные оценки оставьте, пожалуйста для склочных баб или, хотя бы, для сайтов знакомств
_________________ Не ошибается только то, кто ничего не делает. Тот, кто признает свои ошибки, на них учится. Глупец же, упорствуя в своих заблуждениях, остается глупцом.
Убедительная просьба, о багах в SPL здесь писать, потому что не всякий новичок их сразу заметит. О качестве кода - не стоит. Так можно всю ветку загадить не принеся ни йоты толку.
В этом нет никаго смысла. Ибо SPL сама по себе один большой баг и предназначена она лишь для знакомства с СТМ8, а не для полноценной работы с ней. Это типа придаток к демокоду. Да и тема здесь не про SPL, а про СТМ8 вообще, если вы ещё не заметили.
Добавлено after 9 minutes 42 seconds:
Chettuser писал(а):
У меня вообще ощущение, что STM8 производитель забросил на самотёк и больше не планирует поддерживать, а зря - в определённой нише даже 32F030 жирновато будет, ИМХО.
STM8 это как бы улучшение ST7. И этим всё сказано. СТМ как бы и не скрывает, что в приоритете СТМ32, а схожесть периферии заложили специально, чтобы можно было переходить с СТМ8 на СТМ32 и с СТМ32 на СТМ8 в случае необходимости. Поэтому СТМ8 и выглядит как придаток к СТМ32 для самых мелких решений.
Так как scorpi_0n понизил рейтинг моего сообщения, делаю вывод, что он считает, что тут в SPL баги нет. Кто тоже так считает - присоединяйтесь
a5021 присоединился. Есть еще кто, столь же уверенный, что это не бага в SPL?
_________________ Не ошибается только то, кто ничего не делает. Тот, кто признает свои ошибки, на них учится. Глупец же, упорствуя в своих заблуждениях, остается глупцом.
Последний раз редактировалось ptr128 Вс дек 11, 2016 22:58:13, всего редактировалось 2 раз(а).
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 28
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения