Comments 33
В Reference manual к МК STM32F407 про NVIC почти нет информации. Но есть ссылка на отдельный документ— чем больше долбаюсь с ST, тем меньше понимаю за что их любят то. У TI мануалы шикарные. У NXP они весьма неплохие. У Freescale адский ад с форматированием, но все собрано в кучу и достаточно структурированно. А у ST приходится тасовать вагон PDF'ок между всеми мониторами и еще не забывать что куда ссылается. Единственное что STM32F4Discovery как-то стала массовой бордой, да и функционально на ней куча всего, потому что в свете mbed это как-то не выглядит конкурентным преимуществом.
Цена отладочной платы очень важна при изучении. Ни кто не захочет без серьезных на то причин покупать плату за 500$, а свою делать не каждый рискнет (да и цена выйдет не малой).
В 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 настраивать сложно, чтобы помигать светодиодом.
На счет: «новичку лезть сразу в 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. не хочу продолжать этот разговор, к топику не относиться, вас все равно не переделает (как впрочем и меня :-)))
Да и либы для работы с внешней периферией обычно делаются с использованием библиотек производителя.
Например, у Stellaris не все аппаратные возможности реализуются через SPL.
А про примеры, я в связке SPL + LwIP ловил ошибку утечки памяти, которая приводила к вылету через неделю (частота опросов была не высока). До первого вылета даже не проверял использование памяти. Всего ушло около 2 недель на поиски. Пример был с сайта ST.
Правда, в SPL с USB тоже беда: косяк на косяке и косяком погоняет. Мучил-мучил я себя, пытаясь причесать их быдлокод, но плюнул. Так и не поднял одновременно оба USB на STM32F407.
Спасибою
Надеюсь, с ним всё хорошо, и просто нет времени на педагогику.
судя по моему последнему комментарию в этой статье — я скоро не буду писать даже комментарии :-))
да здравствует демократия…
великий «all» всегда все знает, знает как, знает почему, и поэтому проще не писать или писать переводные статейки о чем нить научно-популярном (космос, атом, химия...) — чем что то специализированное (потому что всегда найдется афигенный спец (и не один) и эта кучка спецов наставит минусов :-)) а вот те кому эта статья действительно помогла и была интересна — просто находятся в RO и ни писать, ни голосовать не могут :-)))
Вот за такое нытьё про минусы и появляется желание поменять плюс к карме на минус. Если у вас отбивает желание писать указание на несоответствие ваших слов действительности — лучше вообще не пишите, будет меньше разочарований несовершенным миром.
так по чуть чуть комментарии…
а в основном общаюсь в личке…
по поводу минусов-плюсов — как заметил «здешние правила» — так вообще перестал на них внимание обращать, и стараюсь отмечать только то что нравиться (+) и избегаю оценивать что не нравиться — потому что возможно просто мне это не нужно, а кто то этого ждал и именно это было ему необходимо…
все мы разные…
Но, увы… Я вот тоже написал пару статеек для таких же новичков, как я, чтобы облегчить им жизнь.
Но бдительные супер-профессионалы в области не смогли пройти мимо и не ткнуть меня носом в то, что они это уже знают, «да и вообще...».
Теперь не пишу, и комментирую довольно редко.
я тоже забил :-) здесь у меня только тех статьи - мне тут редактор нравится... и все.. делать здесь нечего.. здесь про космос котируются статьи, переводные какие нить по типу " как я отремонтировал тесла и поменял аккумуляторную ячейку при помощи отвертки" и что нить из истории информатики... а остальное здесь - не нужно.
У локальных переменных обработчика прерываний собственный стек прерываний(вариант а) или локальные переменные прерывания находятся в стеке конкретного потока, в котором возникло прерывание(вариант b)?
Кто копирует регистры в стековый кадр при прерывании? Какой код?
не совсем понятен ваш вопрос...
--Что именно не понятно?
--Кто выполняет низкоуровневые операции по обработке прерываний?
--Как процессор понимает куда именно в main() возвращаться после отработки функции обработчика прерывания (например переполнения таймера)?
--Как регистр PC узнает куда возвращаться после обработки прерывания?
--Что происходит между окончанием последней строчки С-функции обработки прерывания и продолжением исполнения С-функции в main в которой прерывание произошло?
--Каков подробный алгоритм обработки прерываний?
Это же не по волшебству происходит...
Я писал много кода для STM32 и там были прерывания и что-то не припоминаю, чтобы мне приходилось парковать регистры вручную. Однако прерывания работали. Значит кто-то паркует и распаковывает регистры процессора. Кто?
это происходит аппаратно... описано в PM на ядро...
сохраняются R0-R3, R12, LR, PC, PSR
ну и при возврате соответственно осуществляется их восстановление..
а что нужно восстанавливать ядро узнает из значения регистра LR - в нем не адрес возврата при входе в прерывание, а служебное значение... вот по нему аппаратно и фиксируется необходимость восстановления значения регистров со стека...
p.s. за что вы меня отминусили не понятно.. наверное за мое желание вам помочь... во истину кусаете руку дающего :-(
на сим прощаюсь... минусуйте дальше...
Как в ARM Cortex-M сгенерировать прерывание при переполнении операций суммы или умножения?
Начинаем изучать Cortex-M на примере STM32, часть 2