|
|
  |
STM32F103x, делимся впечатлениями |
|
|
|
Apr 20 2010, 07:59
|

Гуру
     
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244

|
Цитата(SBE @ Apr 20 2010, 09:42)  Любопытно, чем сохранение контекста не удобно? Удобно, когда надо и не удобно, когда не надо. Не удобно, когда сохранение, вместо переключения банка регистров,как было у старичка ARM7. Ну упрощенная штука Cortex-M3, подогнанная под некую "самую массовую" практику использования и за счет упрощения поддающаяся разгону - хотите попугаев, они есть у нас. Тот-же контролер прерывания внесли в ядро, сделали за счет этого проще и быстрее, добавили (точнее в результате упрощения получили на халяву) мечту бездумных программеров - вложенные прерывания , но в результате все стало больше похоже на "ешьте, что дают".
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
Apr 20 2010, 11:34
|
Частый гость
 
Группа: Участник
Сообщений: 108
Регистрация: 8-09-05
Пользователь №: 8 384

|
Цитата(zltigo @ Apr 20 2010, 12:14)  Удобно, когда надо и не удобно, когда не надо. Не удобно, когда сохранение, вместо переключения банка регистров,как было у старичка ARM7. Ну упрощенная штука Cortex-M3, подогнанная под некую "самую массовую" практику использования и за счет упрощения поддающаяся разгону - хотите попугаев, они есть у нас. Тот-же контролер прерывания внесли в ядро, сделали за счет этого проще и быстрее, добавили (точнее в результате упрощения получили на халяву) мечту бездумных программеров - вложенные прерывения , но в результате все стало больше похоже на "ешьте, что дают". Уход от банка регистров при переключении это плата за вложенные прерывания. И если переключение контекста при этом происходит не медленнее чем на ARM7, то что потеряли? А вложенные прерывания с гибкой настройкой ИМХО немалая ценность, без этого рассуждения об латентности это про малоинтересный случай с одним прерыванием. M3 не упрощенная (много в ней частей проще чем в ARM7?), а получше заточенная под встроенные применения архитектура (в отличие от ARM7, в котором совсем об этом не думали, а начали применять что было). Контроллер прерывания в ядре помимо скорости, дает еще стандартизацию модели прерывания, тоже плюсик на пути к "стандарту де факто" для ядра МК.
|
|
|
|
|
Apr 20 2010, 11:52
|

Гуру
     
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244

|
Цитата(SBE @ Apr 20 2010, 13:49)  Уход от банка регистров при переключении это плата за вложенные прерывания. Спасибо, а можно было не платить? Нельзя? Мне жаль  Цитата А вложенные прерывания с гибкой настройкой ИМХО немалая ценность Для лобового программирования в стиле Super Loop c кучей длиннющих обработчиков прерываний - несомненно! А можно я так не буду делать? Цитата Много в ней частей проще чем в ARM7? На мой взгляд все. Цитата , а получше заточенная под встроенные применения архитектура Нет заточенная, а упрощенная, что не одно и тоже. Цитата Контроллер прерывания в ядре помимо скорости, дает еще стандартизацию модели прерывания, тоже плюсик на пути к "стандарту де факто" для ядра МК. С точки зрения, унификации - несомненно, но опять "ешьте, что дают" - другого контролера прерываний, например, более быстрого с банками в обмен на пресловутую вложенность, на M3 не будет.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
Apr 20 2010, 13:30
|
Частый гость
 
Группа: Участник
Сообщений: 108
Регистрация: 8-09-05
Пользователь №: 8 384

|
Цитата(zltigo @ Apr 20 2010, 16:07)  Спасибо, а можно было не платить? Нельзя? Мне жаль  Для лобового программирования в стиле Super Loop c кучей длиннющих обработчиков прерываний - несомненно! А можно я так не буду делать? На мой взгляд все. Нет заточенная, а упрощенная, что не одно и тоже. С точки зрения, унификации - несомненно, но опять "ешьте, что дают" - другого контролера прерываний, например, более быстрого с банками в обмен на пресловутую вложенность, на M3 не будет. А вы знаете как с банками и вложенные? Причем с банками то по факту в ARM7 вход в прерывание не быстрее, так где платим?  Про стиль, SuperLoop и т.п. скромно промолчу. Ключевое слово "длиннющий", вопрос масштаба, который в это понятие вкладывается, и в конечном счете времени реакции в системе со многими прерываниями разного приоритета (добро пожаловать в реальный мир  ). NVIC позволяет этот масштаб перевести в другой порядок, чем в ARM7 (ну по крайней мере когда прерываний больше 2-х) . Про упрощение дискуссия конечно субъективная, но "все" как-то слишком категорично. Особенно, если "ничего" более правильный ответ.
|
|
|
|
|
Apr 20 2010, 14:08
|

Гуру
     
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244

|
Цитата(SBE @ Apr 20 2010, 15:45)  А вы знаете как с банками и вложенные? И знать не хочу  . Но тем не менее ручками push/pop получается немногим хуже автоматического сервиса. Короче делается просто. Цитата Причем с банками то по факту в ARM7 вход в прерывание не быстрее, так где платим?  Львинную долю тактов ARM7 гипотетически съедает могущая попасться длиннющая в 20 тактов команда групповой пересылки всех регистров. Ее в принципе, можно не использовать. Чистые потери контроллера прерываний для FIQ 7 тактов за это мы получаем 5 регистров, а не всего пару на автомате запушированных. Затем в M3 из прерывания нужно не только войти но и выйти. Это ЕЩЕ 12 тактов. При этом мы за эти такты, повторяю, получаем всего пару регистров общего назначения, а не как у FIQ пять. Давайте еще добавим для корректнго сравнения push и pop банкированных регистров. Кто сказал "быстрее"? Что получаем? Несколько тактов в Corteх-M3 за счет того, что контроллер в ядре, естественно, экономится. Длинные, команды похерили. Все, в остальном на push/pop в тактах проигрыш. По времени подняв частоту под два раза в результате более получаем терпимые времена. Потенциальное ускорение от внесение контроллера в ядро С ЛИХВОЙ ушло в качестве платы за упрощение контроллера. Цитата Про стиль, SuperLoop и т.п. скромно промолчу. Ключевое слово "длиннющий", вопрос масштаба, который в это понятие вкладывается, и в конечном счете времени реакции в системе со многими прерываниями разного приоритета (добро пожаловать в реальный мир  ). Меня всегда умиляла замена понятия время реакции понятием количество тактов до выполнения первой команды обработчика прерывания. Толку от того, что я быстро ввалюсь в обработчик, а потом начну пушировать регистры мало. Толку от того, что я быстро ввалившись в обработчик НО НЕ УСПЕВ ВЫДАТЬ ОТВЕТНОЕ ВОЗДЕЙСТВИЕ буду прерван вложенным прерыванием на фиг знает какое время, ВООБЩЕ НИКАКОГО. Какое такое, говорите "время реакции"? "Добро пожаловать в реальный мир",.....? Это Вам следует прежде всего задуматься о реальном мире, а не о своем представлении о нем. Я в реальном мире живу с середины 80x, и все мнимые радости вложенных прерываний познал еще в зеленом возрасте на Intel 8080/86/88, где они организованы были так-же просто, как и ныне в новейше-простейшем M3. Цитата Про упрощение дискуссия конечно субъективная,... В минимальнейшей степени.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
Apr 20 2010, 15:41
|
Частый гость
 
Группа: Участник
Сообщений: 197
Регистрация: 8-04-05
Пользователь №: 3 977

|
Цитата(zltigo @ Apr 20 2010, 18:23)  И знать не хочу  . Но тем не менее ручками push/pop получается немногим хуже автоматического сервиса. Короче делается просто. Львинную долю тактов ARM7 гипотетически съедает могущая попасться длиннющая в 20 тактов команда групповой пересылки всех регистров. Ее в принципе, можно не использовать. Потенциальное ускорение от внесение контроллера в ядро С ЛИХВОЙ ушло в качестве платы за упрощение контроллера. Извините, а какая связь между упрощением контроллера и тем, что в кортексе запихивают автоматом в стек 5 регистров общего назначения? Кстати, непонятно зачем нужно целых 12-5=7 тактов, чтобы запихнуть в стек адрес возврата и состояние процессора. Идеал в этом смысле был ADIшный ADSP218x. У него, чтобы перейти от синхронного запроса прерывания к обработчику, требовался всего 1 такт. Цитата(zltigo @ Apr 20 2010, 18:23)  Меня всегда умиляла замена понятия время реакции понятием количество тактов до выполнения первой команды обработчика прерывания. Толку от того, что я быстро ввалюсь в обработчик, а потом начну пушировать регистры мало. Так это - так называемые преимущества RISC архитектуры. Которая совершенно не годится для контроллеров и давно устарела для байтовых мельниц. В том же ADSP в этом толк есть - в нем через такт после запроса от таймера может начать исполняться команда обработчика, дергающая внешнюю ногу, которая не нужны регистры. Для простого обработчика может вообще не потребоваться ни одного регистра.
|
|
|
|
|
Apr 20 2010, 16:58
|
Частый гость
 
Группа: Участник
Сообщений: 108
Регистрация: 8-09-05
Пользователь №: 8 384

|
Цитата(zltigo @ Apr 20 2010, 18:23)  Львинную долю тактов ARM7 гипотетически съедает могущая попасться длиннющая команда групповой пересылки всех регистров. Ее в принципе, можно не использовать. А за оставшиеся такты мы получаем чистый банк регистров в том числе и общего назначения, а не всего несколько на автомате запушированных. Затем в M3 из прерывания нужно не только войти но и выйти. Это ЕЩЕ 12 тактов. При этом мы за эти такты, повторяю, получаем всего несколько регистров общего назначения, а не целый банк. Что получаем? Несколько тактов в Corteх-M3 за счет того, что контроллер в ядре, естественно, экономится. Длинные, команды похерили. Все, в остальном в тактах проигрыш. По времени подняв частоту под два раза в результате более получаем терпимые времена. Потенциальное ускорение от внесение контроллера в ядро С ЛИХВОЙ ушло в качестве платы за упрощение контроллера. Вот-вот, поэтому групповую пересылку и отключают, что совсем не идет на пользу производительности из-за часто используемых операций сохранения/извлечения контекста. В Кортексе к длинным командам еще деление добавилось. Не все так печально если нужен полный контекст, оставшиеся 8 регистров догружаются LDM. В тактах в сумме не хуже получается чем в ARM7 с учетом LDM/STM и входа-выхода. Выход из IRQ в ARM7 тоже не бесплатный. Весело в ARM7 будет только для единственного прерывания на FIRQ без LDM/STM. Правда ваша, что потенциально в M3 могло быть еще быстрее при сохранения банков, но ценой все же не столько усложнения, а вложенности (и "длинных" команд). ИМХО оно того стоило. Цитата Меня всегда умиляла замена понятия время реакции понятием количество тактов до выполнения первой команды обработчика прерывания. Толку от того, что я быстро ввалюсь в обработчик, а потом начну пушировать регистры мало. Толку от того, что я быстро ввалившись в обработчик НО НЕ УСПЕВ ВЫДАТЬ ОТВЕТНОЕ ВОЗДЕЙСТВИЕ буду прерван вложенным прерыванием на фиг знает какое время, ВООБЩЕ НИКАКОГО. Какое такое, говорите "время реакции"? "Добро пожаловать в реальный мир",.....? Это Вам следует прежде всего задуматься о реальном мире, а не о своем представлении о нем. Я в реальном мире живу с середины 80x, и все мнимые радости вложенных прерываний познал еще в зеленом возрасте на Intel 8080/86/88, где они организованы были так-же просто, как и ныне в новейше-простейшем M3. Не обижайтесь, мы с вами примерно одно время в "реальном мире"  , наверняка много каких архитектура попробовали с прекрасных времен К580. Извините, не понравилась категоричность. Вы правы, что не надо упрощать понятие реакция. Только речь про разделение времени между многими прерываниями, когда появляется понятие "приоритет". Понятно, что когда много, кто-то да НЕ УСПЕЕТ ВЫДАТЬ ОТВЕТНОЕ ВОЗДЕЙСТВИЕ. В случае если нет вытеснения, более приоритетное прерывание опять же будет ждать "фиг знает какое время", пока закончится текущий обработчик. В ARM7 всегда будет "задвинуто" прерывание пришедший позднее, а М3 можно сделать, что задержано будет менее приоритетное (а можно и не делать, есть выбор, причем можно изменять стратегию по ходу). ИМХО гораздо более гибче и правильнее. И предсказуемее латентность прерывания, которое уже не будет ограничиваться самым медленным обработчиком. Справедливости ради, если приоритета прерывания только 2, ARM7 с раздельнм FIRQ/IRQ будет не хуже. Оно, конечно, что кошернее разделять время по приоритетам на уровне IST RTOS, только времена реакции будут совсем другими.
|
|
|
|
|
Apr 20 2010, 17:12
|

Гуру
     
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244

|
Цитата(vallav @ Apr 20 2010, 17:56)  В том же ADSP в этом толк есть - в нем через такт после запроса от таймера может начать исполняться команда обработчика, дергающая внешнюю ногу, которая не нужны регистры. Для простого обработчика может вообще не потребоваться ни одного регистра. Не первый раз несете эту и не только эту ахинею  . Я даже не поленюсь сделать copy-paste из ADSP-218x DSP Hardware Referencel Код Interrupt Latency For the timer, IRQx, and SPORT interrupts, latency is at least three full cycles from the time when an interrupt occurs to the time when the first instruction of the service routine is executed. This latency is shown in Figure3-2. Two cycles are required to synchronize the interrupt inter- nally, assuming that setup and hold times are met (for the IRQx input pins). Итого не менее 3x, до 4x тактов, но там дальше и дополнение есть: Код Since interrupts are only serviced on instruction boundaries, before execu- tion continues, the instruction(s) executed during these two cycles must be fully completed, including any extra cycles inserted due to Bus Request/Bus Grant or memory wait states. Посему и более 4x тактов. Финиш. Цитата(SBE @ Apr 20 2010, 19:13)  Оно, конечно, что кошернее разделять время по приоритетам на уровне IST RTOS, только времена реакции будут совсем другими. Времена реакции будут такими, какими НАДО. То, на что надо рекордно низкое время будет делаться в обработчике прерывания, причем без вложенности. Что-то помедленнее будет делаться в обработчике прерывания без вложенности и продолжаться далее в системе. То, что по ограниченности понимания тупо суется в длинный обработчик прерывания для которого разрешена вложенность и в результате этого НИ О КАКОМ детерминированном времени и говорить не приходится, будет делаться на уровне системы с гарантированными ею приоритетами и временами. В этом случае время затраченное на переключение контекста вполне сравнимо с небольшим обработчиком прерывания, который так или иначе будет прерывать текущий обработчик и ТОЖЕ должен заботится о сохранении контекста.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
Apr 20 2010, 17:13
|

Профессионал
    
Группа: Свой
Сообщений: 1 202
Регистрация: 9-01-05
Из: Санкт-Петербург
Пользователь №: 1 861

|
Который раз слышу заявление авторитетных людей, что в прерывании должен только флаг взводиться, все остальное - вне. Тогда на кой вообще использовать прерывания, а потом полить флаг? На мой скромный взгляд (в реальном мире я с 1985, а в эмбедед с 2000ых), таких идеальных случаев с флагами не бывает, поэтому всегда нужен "простор" в виде свободных регистров.
Мне кажется хорошей альтернативой огромным обработчикам - переключение одного и того же вектора прерывания на различные "короткие" обработчики в зависимости от ситуации.
З.Ы. ни в коем случае не нарываюсь на холивар, просто интересуюсь.
--------------------
Если сверху смотреть, то сбоку кажется, что снизу ничего не видно.
|
|
|
|
|
Apr 20 2010, 17:24
|

Гуру
     
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244

|
Цитата(Dron_Gus @ Apr 20 2010, 19:28)  Который раз слышу заявление авторитетных людей, что в прерывании должен только флаг взводиться, все остальное - вне. Тогда на кой вообще использовать прерывания, а потом полить флаг? С операционными системами, Вы помнится знакомы. Посему вызывает интерес, почему поминается некий вырожденный случай с флагом? В обработчике прерывания может вызываться и планировщик. В последствии в зависимости от желания или сразу по выходу из обработчика, либо по отдаче/отборе управления от текущей задачи будет произведено переключение задач.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
Apr 20 2010, 18:17
|
Гуру
     
Группа: Свой
Сообщений: 2 712
Регистрация: 28-11-05
Из: Беларусь, Витебск, Строителей 18-4-220
Пользователь №: 11 521

|
Цитата(vallav @ Apr 20 2010, 18:56)  Так это - так называемые преимущества RISC архитектуры. Которая совершенно не годится для контроллеров и давно устарела для байтовых мельниц. Договорились.  А можно узнать что не устарело? А я считаю, что RISС архитектура очень удачная. И плата за упрощение - достойная, а результат упрощения (скорость) оправдывается. В данном случае я не про cortex, а вообще. Да и длинные обработчики - тоже имеют право на существование. Давайте исходить из того, что подходов к решению разных задач может быть много. Иначе надо объявить всех, кто продумал приоритеты, разработал и использует - идиотами. Но это большая группа людей. Как минимум надо задуматься об этом.
|
|
|
|
|
  |
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0
|
|
|