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

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

Да, собственно STM32 есть кристалы с тремя СПИ, кроме того какой-то уарт может работать как не быстрый СПИ

Точно, STM32F103R(C,D,E) чипы имеют три SPI. Правда, для этого надо отключить JTAG
Однако упоминаний, что USART может быть как SPI нигде не нашёл...

Старенькие at91 имеют spi, способный работать последовательно с четырьмя устройствами в разных режимах и на разных скоростях.

Это SAM`ы то?
Дык это всё равно ожидание, пока уйдёт пакет к одному, потом переключение на другого...
Это можно всё сделать и самому, на единственном SPI...

Можно но скорости и режимы придется каждый раз перестраивать, если надо. Вопрос удобства и всего-то.
Меня одолевают сомнения что-какой либо камень ARM7TDMI сможет проглотить без напрягов одновременные потоки данных по трем spi на приличной частоте, и при этом останентся еще что-то приличное по производительности для остальных задач, пусть даже с использованием фифо или дма. Просто мучает любопытство что за задача такая в которой нужно три spi по отдельности?

at91 just has one spi with several chip select.

Some STM32F devices support 3 hardware spi at some time.

Да на самом деле я вполне смогу обойтись и двумя эспиай. Так, балуюсь тут
Один канал на ЖКИ (132 на 176, 16 бит, 12 мегабит), а второй будут делить файловая система на MMC и девайс, которому нужно будет лить данные из файла\ов...

Просто хотелось попроще всё замутить
Однако не получится, наверное...



Actually, AT91SAM7 has two serial interfaces - SPI and SSP

As for STM32 Cortex - yes, really interesting devices, but it is impossible to use JTAG debugger while all three SPI channels are active...
Or, maybe, I`am wrong?

PS: AT32UC3B is ideal MCU for my purposes - powerful core with rich peripherals - but needs some pricy development hardware...

По-моему, там SWD для отладки остается, так что ничего страшного нет. Посмотрите сами внимательно. Ну и USART можно использовать в синхронном режиме, но там есть засады.

Я, честно говоря, не пробовал пока кортексы. Говорят, что MT-LINK с ними будет работать.
А вот с SWD вероятнее всего нет...

USART в синхронном режиме? В качестве SPI? А что делать со старт- и стоп- битами?

ЗЫ: всё-таки попробую, наверное, Cortex. Только вот макеток с подходящим камнем нет - простые только. Придётся перепаивать, или самому платку разводить...

expensive

не сочите за нравоучение

Вполне допустимо, только пишется pricey.

Судя по примерам к либам от ST нормально работает, старт и стоп биты идут без клоков, соотв не воспринимаются

Понятно. Бум знать!
Ишь, какие грамотные все вокруг


В самом деле? Хм, тогда всё становится ещё проще - скоростные каналы на SPI, а третий помедленнее - на USART. 4,5 мегабита - тоже вполне ничего скорость
И jtag свободен.
Да и вообще, наверное, подойдёт "средний" камень со 128к флешки...

PS: сейчас, кстати, кортексы на какой ревизии ядра? 1.1? А на 2.0 ещё не появились?

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

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

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

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

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



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

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

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

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

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

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

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

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

Написано же:

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

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

Ясно


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

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

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


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

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


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

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

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

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

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

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

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

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

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

Все верно, но где Вы узрели призыв писать все на асме?

ИМХО, ассемблер ARM'а никак нельзя отнести к извратным, а програмист обязан знать архитектуру системы на которой работает, в том числе и ассемблер.

P.S. Я не "воинствующий ассемблерист".

Ну, мне как-то по-барабану, сколько регистров автоматически сохраняется при входе в прерывание. Меня интересует сколько ВРЕМЕНИ занимает вход/выход, а сохраняется там 4 регистра и ещё от 0 до 8 сохраняется программно, или сразу 8 регистров попадает в стек - меня волнует мало (только с позиции расходования ресурсов), потому как я не пишу:
PUSH AX
PUSH BX
...
а пишу:
void SysTick_Handler(void)
...


Лично я на этот счет другого мнения.


Само собой, архитектуру обязан понимать, знать в общих чертах, знать где и что нужно искать. Досконально знать - конечно хорошо, но если это уже не первая, 2... 5 архитектура, а её номер больше , то досконально знать их ВСЕ мягко говоря проблематично. Зато ПОНИМАТЬ отличия, особенности каждой из них - это НЕОБХОДИМО для эффективного решения задач.

То же касается и ассемблера, хотя языки высокого уровня (тот же С) позволяют всё более и более смягчать ЭТО требование.

PS вообще между ЗНАНИЕМ и ПОНИМАНИЕМ есть разница

"Понимает" и "знает в общих чертах" каждый первый, но на деле обычно оказывается, что знаний не хватает даже на 2+2

Ладно, это уже off.

"знает в общих чертах" - это да, а вот с ПОНИМАНИЕМ обычно очень туго.
Это легко отличить, поставив вопрос, для ответа на который требуется АНАЛИЗ разрозненных знаний (сами же про 2+2 и сказали).
Да и знания без понимания не очень-то полезны, разве что понты колотить

О, вот правильное слово! Достаточно редкая способность, к сожалению.

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

На ВСЕХ армах плохо с дерганием ножками. Обычно это занимает порядка 0,1-0,5мксек на одно изменение состояния, и слабо зависит от частоты ядра (здесь влияет частота соответствующей шины - АРВ, АРВ2...) Для STM32 это АРВ2 и порядка 0,22мксек на одно изменение состояния при максимальных частотах ядра и шин и использовании стандартных библиотек. Если дергать без использования библиотек, то порядка 0,12мксек
Вообще армы не для ногодрыжества сделаны, и в этом деле они уступают даже некоторым восьмибитникам, например силабсам.

Ну одним-то пином STM32 точно может дрыгать быстро - MCO

Да, на "скоростное ногодрыганье" рассчитывать не стоит - за этим к PIC'ам, AVR'ам и т.п.

В качестве примера: на SAM7 непосредственно команда записи с доступом через ABP, работающей на частоте ядра, занимает 3 такта. Но к этому придется приплюсовать время на загрузку указателей и данных, если они не готовы.

То есть для STM32 при частоте ядра в 72 МГц (пер. шина=36 МГц) последовательная установка и сброс пина займут 12 тактов = импульсы частотой 6 МГц?

Где-то так +/- лапоть. По крайней мере на большее точно рассчитывать не стоит.

Не выше 2,5МГц
И STM32 дает далеко не самый плохой результат
Шина АРВ2 тоже 72МГц
И забудьте про такты, здесь всё несколько иначе: количество тактов непостоянно

Странно, а откуда так много набегает?

2,5 МГц? Ну это просто позорище. А я ещё думал про софтовый SPI...

Софтовый можно, но медленный и с малым траффиком. Повторюсь: для задачи нужно ПРАВИЛЬНО выбирать МК, а не потому что он 32-битный или новый или красивый.
Вам должен подойти High-density STM32, у них есть 3 SPI, тем более если надо поддерживать файловую систему, то еще и ОЗУ нужно побольше (у High-density по 48 или 64кБ, у Medium только до 20кБ)
Кроме того, USART можно использовать как SPI, но там можете не разойтись по каналам DMA (критично для высокого траффика), нужно внимательно смотреть. Я бы без разговоров брал High-density STM32 и закрывал тему.

А "ногодрыг" надо по-возможности заменять на аппаратные модули, благо здесь они уже очень неплохи. То, что в STR91 я городил на 3 таймерах с синхронизацией друг друга, здесь легко сделал на одном.

Можно и на STR91 сделать, там 2SPI, но в качестве третьего можно (не пробовал) настроить USART, здесь и ОЗУ побольше (64 или 96кБ), и побыстрее он, но два питания (1,8В и 3,3В) и периферия похуже, чем у STM32.
Конечно, на одной ST свет клином не сошелся, ищите и обрящете

Да, я уже практически определился. Буду моделировать на стартер ките со "средним" STM32, а потом, если не хватит памяти (или возникнут проблемы с USART в роли SPI), заменю камень на более "заряженный"
Ещё неплохие кортексы LM3S..., жаль только, что у них UART без синхронного режима - третий последовательный кканал негде взять

Спасибо всем за советы!

Хе, попробовал на LM3S601 при тактовой 50 МГц. На пине присутствуют импульсы с частотой ~8 МГц:
Нажмите для просмотра прикрепленного файла
Код исполняется из флеш, причём интересно, что полупериоды сигнала одинаковы по времени, несмотря на присутствие перехода после команды сброса пина...

Правда, потребление чипа при этом ~90 ма, а я стабилизатор для макетки всего на сотню поставил, работает на пределе

ЗЫ: ещё хотел спросить - на данном арме нет епром, а надо изредка перезаписывать несколько десятков байт конфигурации.
Что посоветуете - поставить внешнюю мелкую епромку, или использовать одну страницу (1 килобайт) программной памяти контроллера?

У нее ресурс меньше на несколько порядков. Так что если часто перезаписывать - наверно лучше епромину. А если конфигурация, калибровочные таблицы, котрые меняютяся от силы раз тысячу за все время службы устройства- то можно и флешью обойтись.