Esp32 mux matrix

dokoff

Доброго времени.

Есть некоторая задачка.. есть мастер и два слейва.. Между ними железяка - ESP32.
Задача сделать мультиплексор (приключение) шины SPI. В идеале через матрицу GPI сделать сквозное прохождение сигнала от мастера к нужному слейву, без участия ядра. Т.е. без обработки входящего сигнала самим MCU.
Вопрос собственно заключается в следующем. Если у матрицы GPIO Esp32 переключить один GPIO на другой GPIO? Если есть, то ткните носом куда глядеть.
Благодарю

Пардон, что загадил форум. Ответ, как не удивительно, был найден в интернетах

https://esp32.com/viewtopic.php?t=4253

Реклама

pasha_zv

а нога CS уже законом запрещена?
.... я чтото пропустил

Реклама

dokoff

pasha_zv, Вроде нет. Но я вроде про чип селект ничего и не спрашивал.
Там написано "между". И очевидно (если чип селект не подходит), то шину необходимо мутиплексировать целиком. Потому что сама ESP будет выступать масторм для одного из слейвов, пока основной мастер должен работать с вторым слейвом.
Изначально хотелось избавится от внешнего мультиплексора 1:4, коих аж 4 штуки бы пришлось городить.
Вот вопрос и заключался ... может ли ESP сама выступать в качестве мультиплексора.
На ESP32 можно 4 отдельных лупа и перенаправить из них / в них нужные сигналы GPIO на уровне внутреннего MUX. Что вполне достаточно для все шины SPI без извращений.

pasha_zv

мля, но ведь проще сигнал CS переключать чем весь поток - MOSI-MISO... ээээээ

Реклама

dokoff

pasha_zv, Еще раз.
Без этой схемы с MUX на борту ESP схема получается такая...
2 слейва + 2 мастера.
Мне нужно забрать у 1 мастера 1 слейв и отдать ему 2 слейв. После этого 2 мастер получает 1 слейв и сним работает. Т.е. мне нужны две независимые шины.
Вот идея как раз была задействовать MUX ESP, чтобы коммутировать это все внутри матрицы. Т.е. у него на входах будет один мастер и два слейва.
MUX переключил для 4 ног на другие 4 ноги, а дальше общайся с нужным (свободным) слейвом сколько влезет. Надоело с этим общаться, перекоммутировал на другие 4 пина через MUX и общайся со тем который освободился.
Решение кстати рабочее. Если скорости низкие относительно. А вот 4 мгц клока эта схема не осилила.
Пойду поищу есть ли такие матрицы на STM.

Реклама

HardWareMan

dokoff, а для чего такой изврат? Что-то фильтруете?

Реклама

dokoff

HardWareMan, Есть мастер и слейв. Слейв - это память. Устройство скапливает в памяти данные. Это готовое устройство заводское.
Вот задача примерно отобрать у мастера этот слейв и подсунуть аналогичный (второй), а с первым работать с помощью левой есп (который в этой схема второй мастер). Отправлять данные в базу на серваке.

Я не помню подробностей SPI. Возможно там есть "сигнал ждать" мастеру, типа подтяжкой какой-то конкретной линии к земле, через коммутирование. Что сильно бы упростило задачу. Но проблема все равно была бы с MOSI и SCK. Они работают на выход, манипуляция этими линиями вторым мастером чревата. В моем конкретном случае там еще и данные летят раз 8 в сек. Что вообще создает еще гемор попасть в это окно, чтобы данные не потерять.
Потому нужно физически отнимать линию SPI.

HardWareMan

dokoff, тогда зачем вам второе ОЗУ, если вы можете его эмулировать, попутно сливая данные "куда нужно"? Просто снимаете родное ОЗУ, подключаете свою ЕСП и понеслась.

Добавлено after 12 minutes 8 seconds:
Что касается арбитража, то я вас огорчу: интерфейс SPI не подразумевает аппаратные хэндшейки, только внутри протокола и они индивидуальные для каждого типа слейва. Так что ваш выбор это эмуляция этого ОЗУ. Я так полагаю, букварь на неё у вас есть а сама она небольшая (кстати, а что за чипс?), так что с этим проблем не будет.

dokoff

HardWareMan, Это sd карта. 8Гб) Так что эмулировать ее не получится. Я кстати не говорил, что это ОЗУ. Да и у ESP там работы хватает без обслуживания линии SPI (без того чтобы притворяться слейвом этого устройства эмуляцией).
--Что касается арбитража, то я вас огорчу: интерфейс SPI не подразумевает аппаратные хэндшейки, только внутри протокола и они индивидуальные для каждого типа слейва.
Ну я и говорю, что не помню подробностей протокола. Теоретическое предположение, которое мне бы не помогло.

Опять же, в целом, схема эта (MUX GPO) рабочая, если скорость передачи данных условно средняя. Вполне себе прекрасно работает. Но 4> мгц для тактовой шины уже каша получается.
Как я понимаю в STM нет такой штуки как MUX (я имею ввиду директ на другой GPIO), при беглом просмотре. Сейчас нашел мультиплексор на 4x2:1 в одном корпусе. Два мультиплексора ценой по 1$ должны решить проблему и вообще забыть про заморочки. Правда мультиплексоры в наше время не очень популярная штука, нужно побегать чтобы найти где их купить.

HardWareMan

[uquote="dokoff",url="/forum/viewtopic.php?p=4626225#p4626225"]HardWareMan, Это sd карта. 8Гб) Так что эмулировать ее не получится.[/uquote]
Это не так. Всё поддаётся эмуляции. Ну хорошо, допустим карта просто большая. Тогда другой вариант: чем вас не устраивает пассивный логгер? Цепляетесь ESPшкой на шину этой карты и слушаете транзакции. Пассивно, никак себя не проявляя (даже MISO не нужно в этом случае). Если SD висит на SPIа не на SDIO, то там ограниченный набор команд и аргументов. Можно просто слушать и при небольшом анализе вычленять чистые данные на трансляцию по воздуху. Если сложно, то можно сделать простое зеркалирование записей в карту: команд записи только 2, при обнаружении запоминать номер сектора (для некоторых карт - абсолютный адрес) и сами данные и отсылать на хост по воздуху. А хост уже сам построит "образ" из записей и разберётся где полезные данные а где обслуживание системы FAT. Примерно, так работает Shadow Copy в Windows, например. Но если хочется возиться с коммутацией и иметь риски потерять данные - это ваше дело, конечно.

dokoff

HardWareMan, А потерять данные по воздуху и городить на стороне сервера "собирательный механизм" это не риск потери данных?) Не вижу смысла усложнять, когда все можно сделать просто. Есть карта, которая заполнятся. Заполнилась - карту забрал, подсунул другую. Сиди спокойно работай со свободной картой. Не вижу минусов в физической коммутации никаких. Одни плюсы. Дешево и надежно.
Даже если взять вопрос эмуляции... на кой черт городить эмуляцию, обрабатывать входящий поток данных, отвечать на них, потому в перерывах это все перекладывать на карту и еще нужно найти время и ресурсы это все отправлять потом на сервер.

Ради любопытства и интереса я бы может поковырялся с разными вариантами извращений, исключительно из-за практического любопытства... неделю-другую... но это работа.
PS Я сюда пришел сюда в тему с конкретным вопросом про MUX GPIO. Альтернативные варианты кроме этого и физического мультиплексора пока не рассматриваю, по причине их иррациональности на данный момент. Если мультиплексоры по какой-то причине не прокатят, то тогда уже буду думать где новый забор поставить. Но за идеи все равно спасибо.

HardWareMan

dokoff, потерять данные по воздуху это не потерять данные вообще, ведь они всё равно будут записаны в карту. Что касается эмуляции карты то тут всё проще, чем думается, ведь там не нужно думать логику FS, этого сама карта не умеет. Обычные запросы: сохрани этот сектор, выдай вон тот. При этом, там есть элемент арбитража (через задержку выдачи токена данных). Поэтому вообще не понятно мне такое упорство, может быть мы чего-то не знаем из-за NDA? Ну да ладно, желаю вам решить этот ребус.

Добавлено after 1 minute 27 seconds:
PS Я бы решал этот вопрос через внешний дискретный мукс, чтобы никак не влиять на скорость и целостность шины.