Arduino.ru

Искать 23xx.

Можно чуть подробнее? :) Если речь идет о микрочиповской памяти 23K или C, то вроде как она с интерфейсом SPI. Или я не то ищу?

https://www.microchip.com/wwwproducts/en/47L64

Любопытная штука, спасибо, читаю.  В моем случае логичнее 47C, ибо до 5 вольт.

А касательно связки из двух контроллеров и одной памяти нет соображений? :)

Абсолютно никаких.
Мои архитектурные решения обычно подразумевают одну точку логгирования. Но они и не на МК.

И не будет, пока схему не выложите.

Какая схема, это же банальный I2C. :)

Две линии, к ним подключены SCL и SDA у нанки, у меги и у FRAM микрухи. Земли у всех общие, питание 5 v тоже. Вот и вся схема. Подтягивающие резисторы есть и у нанки, и у меги. Штатные (что там robotdyn ставит), я ничего не трогал. 

Программно - у нано wire инициализировано с адресом, как я понимаю это и есть режим slave, у меги просто wire.begin(). Нано пишет в пару десятков адресов FRAM, мега читает эту пару десятков адресов плюс пишет и читает в свои адреса, другие.

Код, извините, выкладывать не буду, ибо пол пол мегабайта суммарно будет. :)

Кроме них на этой же шине живет несколько АЦП да RTC. Собственно, все работает, и вопрос только в том, на сколько корректно разрулятся коллизии средствами железного I2C в дуинах, если у нас запись в FRAM совпадет по времени... 

У меня не совсем логгирование, тут скорее некая точка обмена данными между контроллерами. Просто тут два пути, или городить протокол с вопросами/ответами/контрольными суммами, и отвлекать на эту беседу оба контроллера, или тупо один постоянно пишет в микросхему памяти все, что узнал, а второй читает, что надо и когда надо.

Протокол с обменом организовать не проблема (собственно, я на пробу уже поднимал его через uart), но с учетом задачи, уж больно мне нравится мысль использования точки обмена. Потому как это проще и надежнее. Но вот вопрос коллизий при одновременном доступе к микросхеме памяти я не совсем понимаю

Ну, тогда, извините, удачи!

Евгений, вы сейчас меня реально заинтриговали. Серьезно, какую схему вы хотите увидеть, если у нас по сути три девайса висят на I2C? ЧТО ИМЕННО вы там хотите увидеть? Поясните, пожалуйста.

Что я там SCL с SDA перепутал? Так оно тогда бы не работало скорее всего. Что питание общее - уже сказал.

Касательно кода - для меги это 370k, для нанки 40k, или мне оттуда код обращения к FRAM вытаскивать? Так он сделан на основе трудов уважаемых b707 да sadman41, есть отдельная тема на этом форуме.

Еще раз - вопрос не в том, что у меня сделано неправильно.

Вопрос в том, на сколько ВООБЩЕ корректно обращаться двумя контроллерами к одной микросхеме памяти по I2C без каких-либо защит/проверки занятости и так далее, чисто средствами библиотеки wire. Для ответа на этот вопрос ни схема, ни прошивка нафиг не нужны, это ОБЩИЙ вопрос. 

Возможно, что кто-то так уже делал, потому и спрашиваю. Гугл дает ответы начиная от того, что все разрулится само по себе средствами аппаратной реализации I2C в AVR, и до предложений кидать логическую линию между контроллерами, чтобы исключить возможность одновременного доступа.

Причем все это обсуждается в теории.

 

http://arduino.ru/forum/pesochnitsa-razdel-dlya-novichkov/pesochnitsa-dl...

Сообщение №1.

"Я Троцкого не читал, но со всем советским народом..."

Я выше все написал, как говорится - умному достаточно. Будет желание что по делу написать - прочитайте, нет - я переживу. :)

Вот-вот.

Меня вот всегда интересовало, с какой целью на форум пишут люди, принципиально не желающие выполнять Правила форума. На что они надеются?

На здравый смысл. А есть еще варианты?

Уважаемый, вы вопрос-то мой прочитайте.

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

Но я задаю совершенно ОБЩИЙ вопрос. Для ответа на него - достаточно двух ЛЮБЫХ дуин на один вольтаж, и ЛЮБОЙ микросхемы памяти FRAM или EEPROM на их вольтаж. Потому что схема элементарная.

И суть вопроса - столкнуться дуины лбами, будучи собранными по этой элементарной схеме (общее питание и общие линии I2C) или нет. 

Не тот тут вопрос, чтобы код и схема была нужна. Вы ж даже не задумываетесь, вы требуете с меня код и схему просто потому ЧТО, а не потому что это реально надо. 

А смысл? :) 

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

Если у Наны с Мегой питание общее, в чём трудности-то?  Отдай по одной ноге у каждой под семафор и спи спокойно. 

один из вариантов... а что там ТС наваял - бог знает.

вот именно поэтому и надо видеть схему и код...

А без схемы и кода получается что-то типа "Хочу посоветоваться, как правильно борщ варить. Я сам уже сварил, но что-то сомневаюсь... Только свой борщ я вам не покажу и попробовать не дам, пусть вместо этого все, кто умеют - приходят со своим борщем - и тогда мы сравним..."

Вы определитесь - вы хотите выяснить, не насажали ли именно _Вы_ ошибок, или вы хотите конкурс борща устроить? :)

Здравый смысл не подходит, т.к. несовместим с игнорированием Правил форума.

Еще варианты?

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

Опять же, элементарных схем - тысячи. Которая именно у Вас?

Я с Вас ничего не требую. Я просто напоминаю, что пока нет кода и схемы, нет и предмета для обсуждения.

Вариантов схемы - много, и обсуждение выше это уже показало. Какой протокол Вы используете для избежания коллизий - нам тоже неизвестно. Что обсуждать то?

А, так вы просто не смогли понять мой вопрос в первом посте? :) Тогда понятно. 

Не страшно, я вам на пальцах объясню. Итак, смотрим первый пост - начало такое:

Вопрос есть - тестирую тут связку, когда у меня две дуины работают с одной FRAM.

О чем говорит это предложение? О том, что собирать ничего не надо - все уже собрано. Потому как написано - "тестирую". Дальше - в следующем абзаце такое предложение:

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

Ключевое слово - все работает. Т.е. мало того, что схема собрана - даже скетчи написаны. И - да - все работает. Но я первый раз такое сделал, поэтому чутка сомневаюсь, могут ли быть нюансы.

Поэтому следующее предложение идет такое:

Кто нить так извращался? Есть там какие-то подводные камни?

Полагаю, вам непонятно слово "извращался". Все забываю, что вы тут почти все в книге рекордов Гиннеса по долгожительству, и лексикон у нас с вами чутка разный. Каюсь, надо было выбрать другое слово. В данном случае, подразумевалось - пробовал ли кто-то такую связку?

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

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

Соответственно, такому человеку нафиг не нужна ни моя схема, ни мой код, у него они были свои, и он ЗНАЕТ, ПОЧЕМУ он так сделал и на какие грабли наступал.

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

Касательно придуманных вами кучи возможных схем - это ваши тараканы. :) Элементарное подключение в случае I2C может быть только одно - две линии на соответствующие порты дуин. Все прочее - это вы сами придумали. И о том, как именно подключено - все было сказано.

Но вы вы ж не читатели, вы ж писатели. ;) Хоть и местами умные, с этим не поспоришь.

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

А в целом - я понял, что на практике такую связку никто из отписавшихся не тестировал, а значит - буду тестить сам. Ибо пару раз за два дня связка подвисала до резета одного из контроллеров, а значит надо заняться исключением коллизий. :) А для начала - поиском момента возникновения.

P.S. Если что - я это сообщение пишу не потому, что от этого может быть какой-то толк. А скорее просто развлекаюсь, пока контроллеры на соседнем столе данные гоняют. С наступающим! :)

 

"Не смог" и "не захотел" - немного разные вещи.

Вопросы бывают разные. И прежде, чем вникать в суть вопроса, я обычно пытаюсь оценить - а стоит ли это делать.

Ну и где?

Каждый волен писать сообщения в соответствии со своими желаниями. И Вы здесь не исключение. :)

Тоже с наступающим!

 

PS. На всякий случай: интерфейс, правда, не I2C, а SPI (что, кстати, логично: у I2C слишком низкая скорость передачи для RAM), но в остальном - очень приятная штука ESP PSRAM64. Петрович о ней писал: http://arduino.ru/forum/programmirovanie/primer-ispolzovaniya-esp-psram64h-s-arduino и у меня о ней самые благоприятный впечатления при использовании совместно с stm32.

  Вам DetSimen уже все стоящее посоветовал.  А вообще это конечно изващение,  тем более что и мега и нана имеют свои еепромки. "не хочу отвлекать" звучит как-то странно, принимая во внимание что в любом случае тратится время на передачу-прием. "Не знаю как синхронизировать процессы" звучит более убедительно, но это всего лишь мое предположение.

Да, сейчас как раз прикидываю, кто из них двоих будет вешать запрет на пользование шиной. :) Скорее всего мега.

У меня данные обновляются ~десять раз в секунду, на сколько при таком раскладе хватит епрома? :) Плюс запись в EEPROM достаточно медленная и требует пауз. У FRAM с этим все куда лучше, а если перейду на SRAM, так и вовсе все будет хорошо. Да и FRAM есть в текущем конфиге, причем с запасом по емкости.

Касательно синхронизации вопросов нет, просто я вычисляю время фактической загрузки микроконтроллеров, дабы понимать что с ресурсами. Банально считаю количество микросекунд, которые занимают процессы в пределах фактически прошедшей секунды. И как бы по тестам наименьшее число ресурсов оба два тратят тогда, когда один пишет в память, а второй читает. Как минимум при обмене между ними по uart и по i2c расклад такой. Это с учетом пакетов в 5-8 байт с crc. Uart, кстати, заметно быстрее нежели i2c. Но это логично с учетом того, что на i2c есть еще периферия, а uart я могу выделить чисто под эту задачу. Но как бы с памятью все равно получается быстрее. :)

Количество пакетов, если важно - порядка 200 в секунду, 6 байт - запрос, 8 байт - ответ. Как бы с одной стороны немного, а с другой  - не мало c учетом анализа запроса и выдачи нужного ответа.

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

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

  Ну это Вы бросьте! :) i2c даже при тактовой 100кГц работает быстрее , чем уарт на 115200. А процы могут общаться и при 1МГц на шине. А раз уж они на одной шине i2c находятся, то ставить промежуточный буфер данных конечно можно, но (имхо) лишино смысла. 

И тем не менее по тестам получилось так. Я не про чистую скорость именно передачи, а про мой случай, когда кроме отправки данных по I2C МК еще и опрашивает другую периферию опять же по I2C. И их там таких двое. :) Загрузка МК была выше при работе с I2C.

По чистой я не сравнивал, смысла нет, ибо так мне все равно не сделать. Хотя конечно есть, над чем поработать в плане ускорения, тут безусловно. Но все равно толпа на шине будет. Посмотрим, я еще чутка поработаю на алгоритмом обмена по uart, и посмотрю на результат и количество ошибок. Его плюс - я могу выделить по железному порту только на это, без лишних игроков. Было бы у нас по два железных I2C, цены бы не было. :)

Если ты ДВА семафора не поставишь, забуть, что это я тебе советовал, когда словишь deadlock. 

А почему просто не общаться по I2C мастер-слейвом?

Да, логично. Оба два должны иметь возможность узнать, что другой УЖЕ влез на шину. Не сразу осознал, спасибо за подсказку. 

Я пробовал - с учетом того, что на шине кроме них достаточно чистых слейвов, получается заметно медленнее. Не по скорости общения, а по ресурсам, которые МК тратят на эту процедуру. Сейчас один по своему графику пишет данные в FRAM, а другой читает, когда ему надо - оно получается быстрее, чем если один шлет второму запрос, тот его обрабатывает, шлет ответ. Я с этого начинал. 

Тогда по UART, если свободны. Уж куда проще и не мешает никто.

С точки зрения простоты без разницы, что не мешает - это безусловно. Тоже пробовал. И тоже с точки зрения общей загрузки системы получается дольше тупой записи и чтения в память.

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

Просто любой протокол обмена - это всегда во первых минимум три байта сервисных во всех посылках, во вторых обработка запроса и выдача нужного ответа. При этом всём оба МК продолжают заниматься своими делами. Один собирает информацию для передачи, второй отображает, вычисляет, логгирует результаты, взаимодействует с юзверем и так далее. Пока что в боевых условиях самым быстрым оказался способ использования буферной памяти, как я и сказал. По факту - посмотрим. Так-то я на uart изначально и целился, с учетом того, что он есть и никак больше не задействован. :) А запись в память решил попробовать просто в качестве эксперимента.

Возвращаясь к uart - обмена по uart еще в том, что я смогу физически разделить шины I2C. Каждый из МК будет работать с периферией в своем изолированном сегменте I2C. Это, конечно, хороший довод.

Но надо тестить.

Это уже от вашего протокола зависит. Если ведомый только читает, то достаточно одного байта команды. И даже подтверждение излишнее.

При всем уважении - одного байта никогда не достаточно. Как нам узнать, что он не побился по дороге?

Поэтому необходимая обвязка - это байт начала пакета, байт конца пакета и байт crc. 

В моем случае ведомый получает запрос от мастера и отвечает в зависимости от этого запроса. Мастер, соответственно, посылает запрос, а потом обрабатывает полученный ответ.

А..., ну тогда да. Дорога то длинная, ухабистая. Что то про монашку с огурцом вспомнилось.)
Тогда и с I2C не мешало бы перестраховаться.

Фееричнее идиотизма, чем такое "инженерное решение", я, если честно, давно не видел.

Скажем так - при использовании uart и того же RS485 на несколько бОльших расстояниях проверка по CRC лишней не бывала. Использовать его для передачи в пределах одного устройства мне пока не доводилось, поэтому возможно я перестраховываюсь. И кстати, мне помнится, что монашка надевала презерватив на свечку. ;)

Можно немного раскрыть тему? В чем именно вы видите идиотизм?