3xSPI в небольшом корпусе, В TQFP64 или меньше? Опции

[koyodza]

Ещё хотел спросить про контроллер прерываний в кортекс - м3.

Как я понял, в нём нет встроенной возможности прервать выполнение текущего обработчика прерывания с низким приоритетом при появлении прерывания с более высоким приоритетом?
Текущая ISR процедура по-любому будет выполнена до конца и только затем начнёт работать ISR более приоритетного прерывания?

А вот в стареньких ARM7TDMI обработчик IRQ вроде как мог быть прерван появлением FIQ? Или тоже нет*

Докладываю: в STM32 (Cortex-M3) рвётся, только что специально проверил

[aaarrr]

Как я понял, в нём нет встроенной возможности прервать выполнение текущего обработчика прерывания с низким приоритетом при появлении прерывания с более высоким приоритетом?
Текущая ISR процедура по-любому будет выполнена до конца и только затем начнёт работать ISR более приоритетного прерывания?

Тогда почему он называется Nested Vectored Interrupt Controller?

On the Cortex-M3, exception prioritization, nesting of exceptions, and saving of corruptible
registers is handled entirely by the core to permit efficient handling. This means that interrupts
remain enabled by the core on entry to every exception handler.

А вот в стареньких ARM7TDMI обработчик IRQ вроде как мог быть прерван появлением FIQ? Или тоже нет*

И не только FIQ при некоторых программных телодвижениях.

[sonycman]

Значит, на кортексе даже не нужно прилагать особых усилий, чтобы работали вложенные прерывания? Отлично!
А то, прочитав на сайте arm.com статью про NVIC, сложилось впечатление, что обработчики вызываются строго по очереди...

[Sanek_spb]

Значит, на кортексе даже не нужно прилагать особых усилий, чтобы работали вложенные прерывания? Отлично!
А то, прочитав на сайте arm.com статью про NVIC, сложилось впечатление, что обработчики вызываются строго по очереди...

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

Вообще контроллер прерываний в кортексе очень не плох, портит его только SVC, который нельзя вызывать откуда угодно.

[sonycman]

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

Вообще контроллер прерываний в кортексе очень не плох, портит его только SVC, который нельзя вызывать откуда угодно.

Да, да. Ударились в описание работы tail-chaining. А я всё ждал откровений про вложенные прерывания...

А что подразумевается под автоматическим сохранением контекста при возникновении исключения? Сохранение всех регистров CPU (12 штук плюс флаги состояния - больше 50-ти байт!), или только регистра состояния? Если первое, то это делается с похвальной скоростью - всего за 12 тактов!

SVC - это аналог SWI в ARMv4?

ЗЫ: какая разница между терминами exceptions и interrupts?

[aaarrr]

А что подразумевается под автоматическим сохранением контекста при возникновении исключения? Сохранение всех регистров CPU (12 штук плюс флаги состояния - больше 50-ти байт!), или только регистра состояния? Если первое, то это делается с похвальной скоростью - всего за 12 тактов!

Написано же:

When an exception takes place, the Program Counter, Program Status Register, Link Register and the R0-R3,R12 general purpose registers are pushed on to the stack.

Т.е. 8 регистров всего.

[Sanek_spb]

SVC - это аналог SWI в ARMv4?

Есть инструкция, которая пендит интеррапт под названием SerViceCall, она имеет тот же опкод что и SWI, служит примерно для того же, но есть разница в механизмах работы SWI и SVC поэтому и переименовали, чтобы люди разобрались и аккуратненько всё портанули со старых армов.

[sonycman]

Есть инструкция, которая пендит интеррапт под названием SerViceCall, она имеет тот же опкод что и SWI, служит примерно для того же, но есть разница в механизмах работы SWI и SVC поэтому и переименовали, чтобы люди разобрались и аккуратненько всё портанули со старых армов.

Ясно

Написано же:

Т.е. 8 регистров всего.

Хм, но почему не сохранили остальные регистры? Все таки придётся дополнительно их сохранять...

[aaarrr]

Хм, но почему не сохранили остальные регистры? Все таки придётся дополнительно их сохранять...

Потому что написанная в соответствии со стандартом процедура не имеет права их портить. Не придется ничего сохранять.

[sonycman]

Потому что написанная в соответствии со стандартом процедура не имеет права их портить. Не придется ничего сохранять.

Это вы про Calling Convention?
А, понятно. Если потребуется большее кол-во регистров, то процедура должна будет их сохранить...


ЗЫ: всё вроде хорошо, но когда, наконец, можно будет настраивать частоту SPI (и не только) более дискретно, а то или 18 мегабит, или сразу 9... тьфу

[koyodza]

Ясно
Хм, но почему не сохранили остальные регистры? Все таки придётся дополнительно их сохранять...

Потому, что не так много фанатов пишут сейчас на асме, тем более на ARM, у которого асм - извращение редкостное. А компилятор с того же С эти особенности может использовать на пользу.

когда, наконец, можно будет настраивать частоту SPI (и не только) более дискретно, а то или 18 мегабит, или сразу 9... тьфу

Интересно, как Вы это себе представляете? Отдельный PLL для SPI? Или fractional baud rate generator? Только ЗАЧЕМ?

[sonycman]

Интересно, как Вы это себе представляете? Отдельный PLL для SPI? Или fractional baud rate generator? Только ЗАЧЕМ?

Ну, зачем - думаю всем понятно. Чтобы получить широкий диапазон частот периферии не изменяя частоту ядра...
Да ладно, не обращайте внимания, это я так, брюзжать уже начал...

ЗЫ: хотя PLL - штука хорошая. Вот, например, на SAM7S нельзя было устанавливать частоту ядра отличной от 48, если была необходимость пользоваться USB... а на STM32 уже два PLL
Прогресс, однако!

[koyodza]

Ну, зачем - думаю всем понятно. Чтобы получить любую желаемую частоту периферии не снижая частоту ядра. Да ладно, не обращайте внимания, это я так, брюзжать уже начал...

ЗАЧЕМ иметь на SPI любую частоту? Что, 9МГц или 6МГц не устраивают, непременно надо 7МГц? Это же синхронный интерфейс, в отличие от UART здесь нет необходимости получать точное значение частоты.

[sonycman]

ЗАЧЕМ иметь на SPI любую частоту? Что, 9МГц или 6МГц не устраивают, непременно надо 7МГц? Это же синхронный интерфейс, в отличие от UART здесь нет необходимости получать точное значение частоты.

Да, 9 МГц маловато. Надо 14. Зачем лишние тормоза? А 18 - уже многовато.

[koyodza]

Да, 9 МГц маловато. Надо 14. Зачем лишние тормоза? А 18 - уже многовато.

Имхо, к вопросу оптимизации нужно подходить более системно, а не пытаться из отдельно взятого узла получить что вздумается. Может, окажется что другой МК нужен, или вообще задачу не на МК нужно делать.