[Arlleex 131]

@Vasily_, понял, спасибо!

14 минут назад, Vasily_ сказал:

Я пробовал ставить, и потом снес, это что-то монстрообразное и нафиг не нужное.

Я когда-то помогал товарищу с какими-то обычными пиками - впечатление было ровное такое же...

15 минут назад, Vasily_ сказал:

USB, QSPI привязан к конкретным ногам. Обычный SPI может сидеть на любом SERCOM.

Да, там в табличке, в целом, все понятно расписано. Меня очень расстроило, что QSPI сидит на одних ногах с SDHC

Ладно, буду думать - кроме QSPI/SDHC был у меня еще один конфликт по ногам - но закрыл уже эту веб-морду.
Завтра поковыряю даташит, чтобы определиться на 100% - брать этот МК или нет.

[Vasily_ 45]

7 минут назад, Arlleex сказал:

QSPI сидит на одних ногах с SDHC

Что-то вы попутали, я такого не помню. Надо глянуть может так и есть.

Упд.. Посмотрел, в 100 ногом можно разнести.

[Obam 30]

"Design Checklist Basic 32-Bit MCU Design and Troubleshooting Checklist " - один из самых ценных документов "под замком": уррроды!!! Во времена Atmel-я не было такого Ж8-((

[AleksBak 0]

8 часов назад, Obam сказал:

"Design Checklist Basic 32-Bit MCU Design and Troubleshooting Checklist " - один из самых ценных документов "под замком": уррроды!!! Во времена Atmel-я не было такого Ж8-((

Вот этот "Basic 32-Bit MCU Design and Troubleshooting Checklist (PIC32MZ, PIC32MX, PIC32MK, PIC32C, and SAM Devices)" что ли?

[Arlleex 131]

Что это вообще такое? Что в этом документе? На сайте недоступен (ошибка сервера), по вышеприведенной - регистрироваться надо, не хочу.

[Baser 5]

39 минут назад, Arlleex сказал:

Что это вообще такое? Что в этом документе? На сайте недоступен (ошибка сервера), по вышеприведенной - регистрироваться надо, не хочу.

  Что там, не знаю, но доступ есть, вот ссылка на свободный доступ, месяц полежит:
"Basic 32-Bit MCU Design and Troubleshooting Checklist (PIC32MZ, PIC32MX, PIC32MK, PIC32C, and SAM Devices)"

[Arlleex 131]

40 минут назад, Baser сказал:

  Что там, не знаю, но доступ есть, вот ссылка на свободный доступ, месяц полежит...

Глянул, спасибо... Это, как я понял, гид по быстрому аппаратному старту (для схемотехников будет полезно).

@Vasily_, а не подскажете еще один интересный момент? У Вас SERCOM на один выбранный IOSET выведен?
Потому как в документации (стр. 39, п. 6.2.8 "IOSET Configurations") меня смутило крайне странное замечание, а именно

Цитата

6.2.8 IOSET Configurations
The SAM D5x/E5x has multiple peripheral instances, mapped to different IO locations.
Each peripheral IO location is called IOSET and for a given peripheral, signals from different IOSET cannot be mixed.
For a given peripheral with two pads PAD0 and PAD1:
    • Valid: PAD0 and PAD1 in the same IOSETn.
    • Invalid: PAD0 in IOSETx and PAD1 in IOSETy.

Далее, естественно, приведены эти самые таблицы IOSET-ов, например, для SERCOM0 это

Т.е. они утверждают, что если, например, я хочу вывести UART + Flow Control (RTS/CTS), я должен выводить это в пределах одного IOSET-а. Например, IOSET1.
А взять, например, часть сигналов с IOSET1, а часть с IOSET3 (потому что ну вот так получилось, не вмещается другая какая-нить периферия) - нельзя.

Собственно говоря, ни в описании на периферию (SERCOM, USART/SPI/I2C), ни на PORTs, нет упоминания о том, как выбираются эти самые IOSET-ы.
Потому что, кроме как странного замечания в даташите, ничего не мешает вывести сигналы одного модуля на разные IOSET-ы. Вы пробовали так?

По крайней мере, слабо представляю, как тогда у них реализовано "автоопределение", к какому же IOSET-у я все-же подцепился.

[Vasily_ 45]

9 часов назад, Arlleex сказал:

У Вас SERCOM на один выбранный IOSET выведен?

Да.

Передатчик  может выводится только на SERCOM PAD[0] вроде так было.

9 часов назад, Arlleex сказал:

Вы пробовали так?

Нет.

[Obam 30]

...вот ссылка на свободный доступ, месяц полежит...

Вот спасибо!

Это, как я понял, гид по быстрому аппаратному старту (для схемотехников будет полезно).

Полезно - не то слово: проверка по всем хитрым пунктам, гарантированно не спалишь микруху (с AT91SAM7 ещё атмел такие доки делал).

Собственно говоря, ни в описании на периферию (SERCOM, USART/SPI/I2C), ни на PORTs, нет упоминания о том, как выбираются эти самые IOSET-ы

В "портах" PMUX выбирает периферию (A..N - до хренища, чесслово!!!).

[Arlleex 131]

8 часов назад, Obam сказал:

Полезно - не то слово: проверка по всем хитрым пунктам, гарантированно не спалишь микруху (с AT91SAM7 ещё атмел такие доки делал).

А как ее можно умудриться спалить?
Разве что скинуть разводку на студента и он перепутает питание.

8 часов назад, Obam сказал:

В "портах" PMUX выбирает периферию (A..N - до хренища, чесслово!!!).

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

Т.е. у каждого SERCOM есть некие расшаренные PADs - абстрактные места объединения сигналов от самбодулей USART/SPI/I2C. Их 4 штуки.
Так вот на каждый PAD можно подключить несколько разных физических пинов МК. Нестыковка именно здесь (о ней я писал выше).
Документация говорит, что я не могу использовать пины в разных IOSET-ах. То есть, например, PAD[0]...PAD[4] должны быть подключены к IOSET1.
При этом каждый мультиплексор настраивается отдельно в модуле GPIO (PORT). Стало быть, либо

• микрочип обманывает (мягко говоря), и выводить с разных IOSET-ов можно;
• внутри есть какая-то логика блокировки мультиплексоров (тогда как выбирается приоритетный вход, на который все равняются?).

P.S. Ладно, с этого момента, если будут нестыковки по этому камню, тему вынесу в отдельную ветку, дабы не засорять текущую.

[ataradov 0]

Поясню по IOSET. При разводке кристалла, ограничения на тайминги сделаны только внутри IOSET.  Если выбрать сигналы с разных IOSET, то логически ничего не сломается, но есть вернятность, что задержки между сигналами будут не соответствовать спецификации. Это нужно, так как развести эту гору мультиплексоров по всему кристалу и получить разумную максимальную частоту не так просто.

 

На практике это только ограничивает SPI и синхронный USART. И только на скоростях близких к предельным. Для всех остальных протоколов это не так важно.

Изменено 30 января, 2021 пользователем ataradov

[Arlleex 131]

@ataradov, спасибо, это я и хотел тогда узнать