LINUX.ORG.RU

delay stm32f103

 ,


0

1

здрасьте здрасьте люди добрые. ну вот и ожидаемая тема с просьбой помочь разобраться в задержках для stm32f103. пытался реализовать с помощью циклов, но получается что-то уж очень не настраиваемое и время задежки очень мало. нашел что правильно делать delay нужно с помощью systick, но открыв RM в упор не вижу адресов регистро, что очень странно. нагуглил какие-то адреса

0xE000E010 ;	Systick_Control_and_Status_Register
0xE000E014 ;  	Systick_Reload_Value_Register
0xE000E018 ;    Systick_Current_Value_Register
0xE000E01C ;    Systick_Calibration_Value_Register
если я хочу чтобы светодиод вспихивал и и гас через 2сек то как правильно нужно написать и расчитать? поправте пожалуйста для начала надо в SYST_CSR в нулевой бит записать '1' и в первый бит также '1'.
адрес SYST_CSR=0xE000E010

.cpu cortex-m3
.thumb
.word 0x2000000
.wort _start

.section .text
.global _start
_start:



mov r5, =0xE000E010
mov r1, #1
str r1, [r5];  пальцем в небеса! ну пусть я попаду в нулевой бит, а как высчитать первый бит?
у меня вопрос к вам, уважаемые форумчане, вот адрес SYST_CSR=0xE000E010, как высчитать его первый, второй и последующие нужные биты? только с помощью побитовых операций? если есть другой способ и описан в документации, то пожалуйста скажите в какой именно ?



Последнее исправление: Assembler (всего исправлений: 1)
Ответ на: комментарий от aiqu6Ait

Начинать нужно с более простых контроллеров - AVR, PIC, x51

И в чём, по-твоему, принципиальная разница? Чем это, скажем, AVR-5 проще Кортекса-М3? По-моему так наоборот — на 32-битной архитектуре всё намного проще, чем на 8-битной, на которой ещё и с фьюзами иногда надо поприседать.

Ассемблер у всех плюс-минус одинаковой простоты.

anonymous
()
Ответ на: комментарий от anonymous

В том, что сам контроллер гораздо проще устроен. Никакой возни с тактированием, с десятком регистров для простого действия. В случае AVR (про другие сказать ничего не могу - не имел с ними дела) отличная документация, в том числе на русском - Евстифеев. Естественно, куча учебников и статей - те же ДиХалт, Ревич.

Да начать хоть с работы с портами. В AVR это один бит на настройку и один на управление. Номера битов соответствуют номерам портов. В STM32 это 4 бита на настройку (причем расположенных по-разному в разных контроллерах) и 1-4 бита на управление. Вон Ассемблер через bitband управлять пытается. Понятно, что нормальные люди так делать не будут, у них только ODR и BSRR, но все же.

Минимальный код: в STM нужно, пусть и немного, но магии с указателем стека и расположением по адресу 0x0800’0000, в AVR просто пишешь с начала инструкцию за инструкцией.

Адреса периферии: 32 бита, точное значение которых еще надо найти против 6-8 бит, которые прописаны явно.

на которой ещё и с фьюзами

Фьюзы да, проблема. Но никто не мешает по началу тактироваться от встроенного генератора на 1 МГц. А для экспериментов собрать фьюз-доктор.

COKPOWEHEU
()
Ответ на: комментарий от COKPOWEHEU

Никакой возни с тактированием

Так не возись. Тебя никто не заставляет. На АВР-ах, даже на тиньках тоже можно повозиться, там и PLL тоже бывает и фьюзы под разные кварцы.

отличная документация

Ну это да. Но это же не достоинство архитектуры.

Да начать хоть с работы с портами.

Ну и что там сложного? Всё описано на трёх страницах RM с картинками. Так же как и у АВР. А вот хотя бы сложить два 32-битных числа на восьмибитке — уже надо скилуху.

в AVR просто пишешь с начала инструкцию за инструкцией

Ага. И потом, когда ничего не будет работать, понимаешь, что забыл инициализировать стек. Не во всех АВР его контроллер сам инициализирует, частенько там по дефолту лежит голый ноль.

никто не мешает по началу тактироваться от встроенного генератора на 1 МГц

На СТМ-ках тебе точно так же никто не мешает тактироваться без вообще каких-либо настроек от HSI.

anonymous
()
Ответ на: комментарий от anonymous

Так не возись. Тебя никто не заставляет. На АВР-ах, даже на тиньках тоже можно повозиться, там и PLL тоже бывает и фьюзы под разные кварцы.

Вот именно что на AVR возиться с тактированием не обязательно. А на STM уж как минимум подать его на периферию придется.

Ну это да. Но это же не достоинство архитектуры.

Это достоинство существующей в настоящий момент экосистемы. А архитектура у AVR гораздо проще и примитивнее, с этим никто не спорит. Для многих задач она подходит хуже просто потому что настроек и режимов меньше. Но для первого знакомства именно это - огромный плюс.

Ну и что там сложного? Всё описано на трёх страницах RM с картинками. Так же как и у АВР. А вот хотя бы сложить два 32-битных числа на восьмибитке — уже надо скилуху.

Ну и как же записать настройку того же PC13 в голубой пилюле на «обычный выход» чтобы помигать светодиодом? Получается либо вырвиглазие как в HAL, где заполняется специальная структура, либо еще большее вырвиглазие с GPIO_CRH_MODE13_0, GPIO_CRH_MODE13_1, GPIO_CRH_CNF13_0, GPIO_CRH_CNF13_1. Даже человеко-читаемая запись вроде (GPIO_PP_50MHz << ((13-8)*4)) нуждается в комментариях.

Сравните с DDRB |= (1<<4);

Ага. И потом, когда ничего не будет работать, понимаешь, что забыл инициализировать стек. Не во всех АВР его контроллер сам инициализирует, частенько там по дефолту лежит голый ноль.

Это «когда» наступит когда человек дойдет до подпрограмм или прерываний. К тому времени он либо про стек прочитает, либо наткнется на волшебную комбинацию

ldi temp, low(RAMEND)
out SPL, temp
ldi temp, high(RAMEND)
out SPH, temp

Вот она во всех учебниках по ассемблеру встречается. И, обратите внимание, явная инициализация стека лучше способствует пониманию, чем неявная как в STM.

На СТМ-ках тебе точно так же никто не мешает тактироваться без вообще каких-либо настроек от HSI.

Подачу тактирования на периферию это не отменяет.

COKPOWEHEU
()
Ответ на: комментарий от izzholtik

Да что вы на bitband взъелись, прикольная же штука

Сама по себе да. Но для Ассемблера учить ее сейчас все равно что учить алгоритмы быстрого умножения, не умея складывать на пальцах.

COKPOWEHEU
()
Ответ на: комментарий от COKPOWEHEU

явная инициализация стека лучше способствует пониманию, чем неявная как в STM

в обоих случаях явная - по-разному инициализируется. AVR был когда-то прикольный только потому лучше другого старья с регистром-аккумулятором и страничной памятью для С подходил

anonymous
()
Ответ на: комментарий от anonymous

в обоих случаях явная

В минимальном коде для stm - не явная. Там ведь нет инструкции записи в sp. Ну есть какое-то чиселко, которое зачем-то пишут перед адресом ресета.

AVR был когда-то прикольный только потому лучше другого старья с регистром-аккумулятором и страничной памятью для С подходил

А сейчас подходит для обучения. Не пугать людей 32-битными регистрами с кучей ненужных полей.

COKPOWEHEU
()
Ответ на: комментарий от COKPOWEHEU

Там ведь нет инструкции записи в sp. Ну есть какое-то чиселко, которое зачем-то пишут перед адресом ресета

ты просто не понимаешь что такое инициализация стека - у STM его надо явно инициализировать, у AVR тоже, у PIC - нет

The PIC stack is a dedicated bank of registers (separate from programmer-accessible registers) that can only be used to store return addresses during a function call (or interrupt). 

https://en.wikibooks.org/wiki/Embedded_Systems/PIC_Microcontroller#The_PIC_Stack

anonymous
()
Ответ на: комментарий от COKPOWEHEU

вырвиглазие

Так это тоже не проблема архитектуры. Пиши на асме.

Сравните с DDRB |= (1<<4);

Сравни:

CONFIGURE_PIN (GPIOC, 13, O_OPEN_DRAIN);
anonymous
()
Ответ на: комментарий от anonymous

вырвиглазие

Так это тоже не проблема архитектуры. Пиши на асме.

CONFIGURE_PIN (GPIOC, 13, O_OPEN_DRAIN);

Отличный пример кода на асме. А если серьезно, то на асме подобное получится еще менее читаемо, чем на Си.

CONFIGURE_PIN (GPIOC, 13, O_OPEN_DRAIN);

То есть вот это вы считаете хорошим кодом для объяснения как работают порты и какие регистры за них отвечают?

Для использования - вопросов нет, отличный вариант. Но для обучения регистров в нем не видно.

COKPOWEHEU
()
Ответ на: комментарий от COKPOWEHEU

То есть вот это вы считаете хорошим кодом для объяснения как работают порты и какие регистры за них отвечают?

Конечно.

Ведь GPIOC — в CMSIS определён как ((GPIO_TypeDef *)GPIOC_BASE), а GPIOC_BASE — как (APB2PERIPH_BASE + 0x00001000UL), а APB2PERIPH_BASE — как (PERIPH_BASE + 0x00010000UL), а PERIPH_BASE — как 0x40000000UL. В то же время, структура GPIO_TypeDef определена как 7 32-битных полей, первые два из которых — CRL и CRH. Таким образом, значение GPIOC соответствует адресу регистра CRL, а (uint32_t*)GPIOC + 1 — адресу CRH. То есть вполне себе можно рассматривать GPIOC как адрес одного 64-битного регистра для настройки всех пинов порта C.

Вот. Заодно разобрались не только в регистрах, но и в том как устроена библиотека CMSIS. Разве это не прекрасно?

anonymous
()
Ответ на: комментарий от anonymous

Конечно.

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

COKPOWEHEU
()
Последнее исправление: COKPOWEHEU (всего исправлений: 1)
Ответ на: комментарий от aiqu6Ait

х51 действительно проще STM32

Регистров, если я правильно помню, в с51 — четыре банка по 7 штук, при том, что часть из них используется только по косвенной адресации. Стек, там, вроде, только в основной памяти может быть, которой с гулькин нос и эта же память мапится на регистры. Плюс туда же ещё и «бит-банд» с, если опять же правильно помню, отдельными инструкциями доступа к отдельным битам. Но асм там да, не сложный. Так и в Кортекс-М3 он простой, если без флоатов и векторных расширений. И регистры общего назначения тут все с прямым доступом. Опять же не надо загружать адрес через 8-битные половинки. В Кортексах при входе в прерывание помимо адреса возврата автоматам пушатся r0-r3, lr, PSR — это же просто чудесно! А lr при входе в leaf-функции вообще позволяет обходиться без пушей. Не знаю. Мне нравится.

anonymous
()
Ответ на: комментарий от anonymous

Тут ведь все зависит от постановки задачи. Если есть задача разобраться с контроллерами и ASM, то надо брать 8051. Они просты и доступны, диодами мигают, да я на них даже логарифмы считал.

Если надо писать рабочий код - тогда нужен С, возможно со вставками, HAL и прочие ништяки, выбор платформы продиктован задачей.

aiqu6Ait ★★★★
()
Последнее исправление: aiqu6Ait (всего исправлений: 1)
Ответ на: комментарий от aiqu6Ait

Если есть задача разобраться с контроллерами и ASM, то надо брать 8051

Или AVR, или PIC, или любые другие простые контроллеры. Просто лично я работал только с AVR, а потом STM32 и RISC-V, поэтому про х51 или PIC мало что могу сказать. Хотя если, как Анонимус говорит, там память поделена на банки - это им в минус.

Если надо писать рабочий код - тогда нужен С

Конечно. Выбрать достаточно мощный контроллер (может, даже 8-битку если задача позволяет) и писать на Си. Критичные места - Асм.

Ну а всякие Ардуины, включая HAL, только если уж совсем со сроками плохо и пониманием, что ЭТО потом придется поддерживать.

COKPOWEHEU
()
Ответ на: комментарий от COKPOWEHEU

Ну а всякие Ардуины, включая HAL, только если уж совсем со сроками плохо и пониманием, что ЭТО потом придется поддерживать.

А с этим я не согласен. Проект должен быть сделан слоями, слои отдельно тестироваться. Тогда HAL можно переносить от одного изделия на следующее, занимаясь только логикой.

aiqu6Ait ★★★★
()
Ответ на: комментарий от aiqu6Ait

А с этим я не согласен. Проект должен быть сделан слоями, слои отдельно тестироваться. Тогда HAL можно переносить от одного изделия на следующее, занимаясь только логикой.

Что вы понимаете под HAL? Если Hardware abstraction level вообще - то безусловно да. Хотя слоев там может быть больше двух.

А если конкретный HAL от ST, то нет, очень уж он ужасен.

COKPOWEHEU
()
Ответ на: комментарий от COKPOWEHEU

Ну после доработки HAL от ST там мало осталось, так что полусамописный HAL, унифицированный сверху между несколькими используемыми контроллерами.

aiqu6Ait ★★★★
()
Ответ на: комментарий от aiqu6Ait

Ну после доработки HAL от ST там мало осталось, так что полусамописный HAL, унифицированный сверху между несколькими используемыми контроллерами.

Тут согласен. В темах по ST под HAL’ом чаще подразумевается собственно ST’шная версия, где все настраивается ужасными структурами.

А вот нормальная абстракция поверх периферии это чуть ли не необходимость при мало-мальски большом коде.

Хотя если говорить про обучение, сначала придется без абстракции. Просто потому что сначала надо разобраться какой функционал универсальный, а какой платформо-зависимый.

COKPOWEHEU
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.