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

[sonycman]

Хочется иметь в небольшом (типа TQFP64) корпусе три аппаратных SPI (что-то не тянет программно делить шину на несколько устройств).
Ядро типа ARM7, желательно, ~50 МГц.
Нашёл пока только AT32UC3B - все USART могут работать и как SPI, очень удобно

А что-нибудь из Cortex`ов умеет такое?

[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 регистров всего.

[sonycman]

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

Ясно

Написано же:

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

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

[koyodza]

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

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

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

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

[aaarrr]

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

Что тогда не извращение? У ARM'а замечательно простой и понятный ассемблер.

[koyodza]

Что тогда не извращение? У ARM'а замечательно простой и понятный ассемблер.

Я раньше тоже "воинствующим ассемблеристом" был, ещё на 8080 и Z80, потом на 86. Но жисть расставила всё на свои места: достаточно крупный проект непросто сделать на ассемблере, а поддерживать тем более. Про использование чужого кода я вообще молчу. Не так давно дали мне проект на 51 немного "доработать", более 12000 строк. Написано, прямо скажу, ужасно. Да и необходимости писать на ассемблере в данном случае вообще не было. Короче, разобрался с функционалом, прошелся два раза по листингу и переписал на С, получил не более 5000 строк, дополнительные функции, и примерно тот же объём двоичного кода.
ЗАЧЕМ уродоваться на асме для ARM - не понимаю абсолютно. Экономить пару десятков нсек? Так всё равно один раз ножкой дёрнуть - и вся экономия коту под хвост, и улетели сотни Ваших сэкономленных наносекунд. Код ужимать? Что, не влазим в 128/256/512кБ кода? Это же ARM, это не 8051 с его 128 байт ОЗУ и 4кБ кода, там в этом конечно же был смысл.

Я ни в коем случае не призываю к отказу от оптимизации. Я сам ненавижу монстров, которых порождает современное программирование, с его гигабайтами кода и гигагерцами. Я только сторонник "срединного пути"

[sonycman]

ЗАЧЕМ уродоваться на асме для ARM - не понимаю абсолютно. Экономить пару десятков нсек? Так всё равно один раз ножкой дёрнуть - и вся экономия коту под хвост, и улетели сотни Ваших сэкономленных наносекунд.

А что, на STM32 так плохо с "дёрганием" ножками? Сколько это, приблизительно, занимает тактов?