ЛВС на основе SPI или Коммутатор кадров для SPI

[astrahard]

Имеет ли смысл применить правила коммутации как в Ethernet свитче для SPI порта? Например, в случае, если нужно собрать вычислитель с несколькими процессорами ARM?

И вообще, существует-ли SPI коммутатор работающий по принципу сетевого коммутатора как например Ethernet свитч?

Чтобы преодолеть "Ведомое устройство не может управлять потоком данных"

Последний раз редактировалось astrahard Вт янв 04, 2022 12:56:22, всего редактировалось 1 раз.

[musor]

это походу заразно вчерася 1 товарищ хотел создать мултимастерную сеть на 485
теперьэто...

[jcxz]

astrahard писал(а):

Чтобы преодолеть "Ведомое устройство не может управлять потоком данных"

Тогда это будет уже не SPI.
Да и в чём смысл? зачем?

[astrahard]

ЛВС на нескольких кристаллах ARM STM32, но с упрощенным протоколом не как Ethernet. И, хочу упрощенный RPC (remote procedure call) под упрощенный стек протокола ЛВС на основе SPI.

Добавлено after 2 minutes 57 seconds:
Вот, к примеру, есть идея RPC (remote procedure call) есть протокол сериализации. В настольной системе он сложен и объемен, но что мешает его предельно упростить для STM32 локальной сети?

Добавлено after 6 minutes 55 seconds:
Разве всякие там ModBus и CAN стеки и пр. это не пример упрощенного RPC(remote procedure call) от MS. И наоборот, разве RPC от MS это не пример усложненного CAN стека.

Что мешает нам сделать свое промежуточное решение...

Последний раз редактировалось astrahard Вт янв 04, 2022 13:03:17, всего редактировалось 1 раз.

[jcxz]

astrahard писал(а):

ЛВС на нескольких кристаллах ARM STM32, но с упрощенным протоколом не как Ethernet.

Хотите передачу данных через SPI между несколькими МК? Так никто не мешает её организовать на SPI. Если уж так хочется. Назначаете мастера и вперёд - он рулит всем обменом, периодически опрашивая ведомых.

[astrahard]

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

Последний раз редактировалось astrahard Вт янв 04, 2022 13:14:35, всего редактировалось 2 раз(а).

[jcxz]

astrahard писал(а):

Идея в том, чтобы добавить посредника, это как свитч для Эзернет, который хранит кадры в буфере до востребования.

Вопрос в нужности. А так то - сделать можно что угодно....

[astrahard]

Например, я бы предпочел купить голосовое управление не в виде сервиса от ФСБ, а в виде кристалла с локальным вызовом RPC в ЛВС (SPI) из пары тройки покупных HARD библиотек.
Это, когда продается универсальное решение в виде HARD библиотеки, последнее выглядит очень интересной бизнес моделью, которая сейчас очень широко применяется в сети. А в моем случае в локальной сети.

[SfS]

В настоящее время цена на Ethernet или WiFi чипы упала так сильно, что смысла городить что-то нестандартное нет. Это я про локальную сеть.

Даже отечественный К1986ВЕ1 в пластиковом корпусе со встроенным Ethernet на борту стоит менее 1000 руб. Кстати, там есть и другие интерфейсы шинные на борту. Отладочная плата, правда подороже, вот: https://ldm-systems.ru/product/19030

Если предполагается общение между несколькими чипами в пределах одного устройства, то всё зависит от логики их работы: если там один мастер - то SPI подойдёт, если они равноправны - то надо что-то другое городить. Да хоть ту же шину на базе UART. От скорости всё зависит.

В общем решений готовых на любой вкус полно.

[jcxz]

SfS писал(а):

Если предполагается общение между несколькими чипами в пределах одного устройства, то всё зависит от логики их работы: если там один мастер - то SPI подойдёт, если они равноправны - то надо что-то другое городить.

Необязательно. Если голова на плечах есть, то можно придумать подходящий алгоритм. Назначить одного мастером - пусть генерит SCLK, а остальные только данные гонят. Самый простой способ передачи кадров данных по такой сети: соединить всех в кольцо, MOSI каждого завести на соседа слева, а MISO - на соседа справа. И гонять кадры, снабжая их токенами-адресами назначения: принял кадр, посмотрел на токен-адрес - свой? изъял кадр из кольца; не свой - передал кадр дальше по кольцу.
Либо любой другой алгоритм и топологию сети (кольцо, звезда и т.д.).

[SfS]

jcxz писал(а):

Необязательно. Если голова на плечах есть, то можно придумать подходящий алгоритм. Назначить одного мастером - пусть генерит SCLK, а остальные только данные гонят. Самый простой способ передачи кадров данных по такой сети: соединить всех в кольцо, MOSI каждого завести на соседа слева, а MISO - на соседа справа. И гонять кадры, снабжая их токенами-адресами назначения: принял кадр, посмотрел на токен-адрес - свой? изъял кадр из кольца; не свой - передал кадр дальше по кольцу.
Либо любой другой алгоритм и топологию сети (кольцо, звезда и т.д.).

Да понятно что все можно. То, что ты предложил оно уже сделано:)

https://ru.m.wikipedia.org/wiki/Token_ring

Я ж говорю, все от задачи зависит.