Как стать автором
Обновить

Комментарии 33

Интересно, продолжайте.

В Reference manual к МК STM32F407 про NVIC почти нет информации. Но есть ссылка на отдельный документ
— чем больше долбаюсь с ST, тем меньше понимаю за что их любят то. У TI мануалы шикарные. У NXP они весьма неплохие. У Freescale адский ад с форматированием, но все собрано в кучу и достаточно структурированно. А у ST приходится тасовать вагон PDF'ок между всеми мониторами и еще не забывать что куда ссылается. Единственное что STM32F4Discovery как-то стала массовой бордой, да и функционально на ней куча всего, потому что в свете mbed это как-то не выглядит конкурентным преимуществом.
STM32 стали популярны до появления STM32F4. Я думаю, что важную роль играет цена и доступность в России.
Цена отладочной платы очень важна при изучении. Ни кто не захочет без серьезных на то причин покупать плату за 500$, а свою делать не каждый рискнет (да и цена выйдет не малой).
Pin2Pin совместимость разных серий дорогого стоит. Чаще всего отличаются вообще только МК в раных корпусах, а в пределах одного корпуса можно выбирать нужный МК по функционалу. Ну и кода под STM32 побольше чем под остальные кортексы. Близок разве что TI со своей линейкой LPC. Отладчик под STM32 (ST-Link v2)тоже стоит копейки, в отличие от других.
В Reference manual к МК STM32F407 про NVIC почти нет информации. Но есть ссылка на отдельный документ

NVIC — штука не специфичная для STM32, оно описано в Cortex-M4 Technical Reference Manual, зачем ещё раз дублировать в мануале от ST?

Об этом и речь…
очень тяжело искать информацию…
если штука не специфичная — то сделали бы тогда ссылку на общий документ…
а иначе сначала ищешь в специфичном документе, потом после того как не найдешь — начинаешь искать где же это написано… :-(
понятно что это от ламерства личного, но и тыкать в него не хорошо, лучше бы помогли понять «высокий» уровень документации ST

Если вы берётесь писать под ARM, то не прочитать их литературу, описывающую стандартный функционал, несколько странно. Если кто-то в каждый reference manual добавляет ещё 100+ страниц с описанием стандартного функционала — это их личное дело.


Ещё добавлю что на первой же странице STM32F407 Reference manual есть раздел "Related documents" со следующим текстом:


Available from STMicroelectronics web site (http://www.st.com):
• STM32F40x and STM32F41x datasheets
• STM32F42x and STM32F43x datasheets
For information on the ARM Cortex®-M4 with FPU, refer to the STM32F3xx/F4xxx Cortex®-M4 with FPU programming manual (PM0214).

В PM0214 есть раздел 4.3 посвященный NVIC.


Кстати, вы думаете, что эти 260 страниц тоже надо включить в STM32F407 Reference manual?

конечно вы правы!
и новичек, когда берется изучать что либо сразу знает где и что прочитать и где и что написано…

у меня после атмел документация ст мягко говоря ввела в шок… и разобраться очень и очень тяжело сначало…
а сейчас — конечно легко рассказывать где и что…

p.s. критиковать сделанное проще чем сделать :-) а я например очень благодарен автору за статью — некоторые моменты как то из вида упускал, теперь буду внимательнее :-)

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


Конечно, stm32 сильно сложнее чем, скажем, avr. Но это предсказуемо, и новичку лезть сразу на arm как-то странно. Это как жаловаться, что mmu в arm9 или cortex-a настраивать сложно, чтобы помигать светодиодом.

ничего не мешает, вот и ищешь сначала в специальных частях, а потом потому что написано в первой странице (поочереди), одновременно еще с сайта ST поглядывая и самое главное еще и ищешь не знаешь что именно :-))) да если еще в английском не так силен — так вообще веселье :-))

На счет: «новичку лезть сразу в ARM странно» — а что здесь такого? или для того чтобы лезть в AVR сначала нужно пройти через 51ые? а до этого через i8080/z80, а до них через четырех-битки?

p.s. не любите вы новичков :-( не понимаю за что…

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


Если же этот абстрактный новичок начинает жаловаться что всё сложно и непонятно, но упорно не хочет:


  • читать техническую документацию (да, на английском, но это так и будет, переводы вещей типа ARMv8-M TRM бывают, но обычно стоят как крыло от самолёта и их выход происходит существенно позже появления оригинала, если вообще происходит),
  • изучать базовые принципы проектирования цифровых электронных схем,
  • разбираться как работает тактирование, различные шины и интерфейсы передачи данных и т. п.,

то этот конкретный новичок не вызывает никакого уважения и сочувствия.


Да, перед тем как лезть в относительно сложный мир arm7 и/или cortex-m крайне желательно получить опыт на чём-нибудь простом. Будет это avr, pic, msp430, 8051/8052 — не суть. Важно то, что после получения опыта с чем-нибудь 8/16-битным человек уже не будет пугаться принципиальных схем io-пинов, временных диаграмм работы интерфейсов, понимать зачем нужно тактирование, как работают стандартные интерфейсы и т. п., и будет развиваться дальше.


Иначе на человека сваливается какая-нибудь схема тактирования stm32f1 с пачкой шин, pll, прескейлерами на разных кусках, тактированием usb, rtc и eth phy или описание работы nvic, dma, i2s, и он не может понять и выделить основное, что ему сейчас нужно, какие части документации надо читать et cetera.


не любите вы новичков :-( не понимаю за что…

К новичкам я отношусь нейтрально, с какого перепугу я должен их любить — я не ведаю. А вот идиотов — не люблю, профдеформация-c.

а никто и не жалуется, наоборот -рапортует о том что все таки разобрался и нашел :-)

и для новичка это достижение…
а тут появляются гуру которые это прошли и уже забыли какого это было искать в начале пути…
и именно об этом и идет речь…
и вот после того как новичок рассказывает новичку с чем он столкнулся и что где нашел, слышит в ответ — «все вы ламеры, читать не хотите, ноете, и вообще рассказываете о каких то банально простых вещах»

терпимее нужно быть,
не все живут в Москве, не все имеют возможности посещать семинары и смотреть вебинары, не все учили английский…
в конце концов не все радиоэлектроникой занимаются профессионально — для многих это хобби как охота или рыбалка…

p.s. не хочу продолжать этот разговор, к топику не относиться, вас все равно не переделает (как впрочем и меня :-)))
Что общество думает про библиотеку www.libopencm3.org/? При первом просмотре API у нее намного симпатичнее чем у stm-овской библиотеки, видно что libopencm3 программисты писали.
Не вижу больших преимуществ. Все-таки, инициализация периферии выполняется один раз (бывают, конечно исключения), а потом идет работа с основной программой. Зачем изучать библиотеки сторонних разработчиков, которые не дают ощутимых плюсов?
Да и либы для работы с внешней периферией обычно делаются с использованием библиотек производителя.
В продолжение темы о библиотеках, хочу уточнить. Бытует в онлайн-просторах мысль, что SPL кишит множеством ошибок, багов и неточностей. Скажите, кто в курсе, действительно их так много и настолько сильно они могут испортить код вплоть до epic fail без возмножности найти ошибку за 2n часов?
Находил пару ошибок у TI в библиотеке периферии, где была проблема с инициализацией UART если до этого были «неожиданные» махинации с клокингом. Вообще код драйверов периферии хоть зачастую и не тривиален, но его можно прочитать и понять за разумное время.
под SPL обычно понимают Standard Peripherals Lirary от ST Micro. Лично я столкнулся с тем, что FSMC новой версии не работала с LCD на ILI9320. При этом старая библиотека инициализирует все правильно.
Не только в ошибках дело. Опечатку в адресе или битовом поле вы найдете быстро. Да и я давно их уже не встречал.
Например, у Stellaris не все аппаратные возможности реализуются через SPL.

А про примеры, я в связке SPL + LwIP ловил ошибку утечки памяти, которая приводила к вылету через неделю (частота опросов была не высока). До первого вылета даже не проверял использование памяти. Всего ушло около 2 недель на поиски. Пример был с сайта ST.
Скачал, посмотрел — примерно такая же дрянь, как и SPL. И нет полноценной работы с USB.
Правда, в SPL с USB тоже беда: косяк на косяке и косяком погоняет. Мучил-мучил я себя, пытаясь причесать их быдлокод, но плюнул. Так и не поднял одновременно оба USB на STM32F407.
Все еще ждем продолжения :)
Спасибою
За идею 5+, за реализацию — 3-… Подобный цикл статей очень необходим, но! Проверяйте пожалуйста уже написанное на предмет ошибок. Еще в предыдущей статье после фразы «записать значение в биты» я поймал временный диссонанс, после которого дальнейшее восприятие статьи было сведено на нет. В этой части что то подобное: начинаем с РС6, потом откуда то волшебным образом всплывает РС7, с которым оказывается «все интереснее», потом (уже наверное потеряв интерес к загадочному РС7) снова наше внимание переключается на РС6. Мой совет, после написания статьи, кроме проверки на элементарные ошибки (кои за год все еще не исправлены), постарайтесь прочитать написанное от третьего лица, будто вы новичок, набрели на интересную статью и, засучив рукава, решили «победить светодиод» на М4.
Автор не появлялся на Хабре с 15 августа 2015, очень жаль… Было интересно читать.
Надеюсь, с ним всё хорошо, и просто нет времени на педагогику.
да тут на хабре так ставят оценки, что честно говоря писать что-либо желание быстро отбивают…

судя по моему последнему комментарию в этой статье — я скоро не буду писать даже комментарии :-))

да здравствует демократия…
великий «all» всегда все знает, знает как, знает почему, и поэтому проще не писать или писать переводные статейки о чем нить научно-популярном (космос, атом, химия...) — чем что то специализированное (потому что всегда найдется афигенный спец (и не один) и эта кучка спецов наставит минусов :-)) а вот те кому эта статья действительно помогла и была интересна — просто находятся в RO и ни писать, ни голосовать не могут :-)))

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

да в общем то больше и не пишу…
так по чуть чуть комментарии…
а в основном общаюсь в личке…

по поводу минусов-плюсов — как заметил «здешние правила» — так вообще перестал на них внимание обращать, и стараюсь отмечать только то что нравиться (+) и избегаю оценивать что не нравиться — потому что возможно просто мне это не нужно, а кто то этого ждал и именно это было ему необходимо…

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

я тоже забил :-) здесь у меня только тех статьи - мне тут редактор нравится... и все.. делать здесь нечего.. здесь про космос котируются статьи, переводные какие нить по типу " как я отремонтировал тесла и поменял аккумуляторную ячейку при помощи отвертки" и что нить из истории информатики... а остальное здесь - не нужно.

У локальных переменных обработчика прерываний собственный стек прерываний(вариант а) или локальные переменные прерывания находятся в стеке конкретного потока, в котором возникло прерывание(вариант b)?

Кто копирует регистры в стековый кадр при прерывании? Какой код?

не совсем понятен ваш вопрос...

--Что именно не понятно?
--Кто выполняет низкоуровневые операции по обработке прерываний?
--Как процессор понимает куда именно в main() возвращаться после отработки функции обработчика прерывания (например переполнения таймера)?

--Как регистр PC узнает куда возвращаться после обработки прерывания?
--Что происходит между окончанием последней строчки С-функции обработки прерывания и продолжением исполнения С-функции в main в которой прерывание произошло?

--Каков подробный алгоритм обработки прерываний?

Это же не по волшебству происходит...


Я писал много кода для STM32 и там были прерывания и что-то не припоминаю, чтобы мне приходилось парковать регистры вручную. Однако прерывания работали. Значит кто-то паркует и распаковывает регистры процессора. Кто?


это происходит аппаратно... описано в PM на ядро...

сохраняются R0-R3, R12, LR, PC, PSR

ну и при возврате соответственно осуществляется их восстановление..

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

p.s. за что вы меня отминусили не понятно.. наверное за мое желание вам помочь... во истину кусаете руку дающего :-(

на сим прощаюсь... минусуйте дальше...


--Как тогда реализован механизм вызова обычных C-функций под капотом?

--Как функция после отработки возвращается обратно в ту функцию, которая ее вызвала?

--каковы накладные расходы на вызов функции?

--Чем вызов обычной функции отличается от вызова программного прерывания?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории