Передача данных на второй МК

30.12.2013, 00:29. **Показов** 12210. **Ответов** 30

Студворк — интернет-сервис помощи студентам

Разбираюсь, как передавать информацию между МК более одного бита, в голову пришла только одна оптимальная схема с использованием минимум по 3 ноги на каждом МК для передачи в одну сторону:

Пишущий МК
- нога №1 - по биту пишет на ногу
- нога №2 - ждет изменение (1 на 0) или (0 на 1) -что будет сигналом, что нужно отдавать следующий бит
- нога №3 - 1 или 0 - закончена передача или нет

Читающий МК
- нога №1 - по биту читает на ногу
- нога №2 - после чтения производит изменения (1 на 0) или (0 на 1) -что будет сигналом, что пишущий МК должен вернуть следующий бит.
- нога №3 - проверяем читать дальше или briok на цикл т.к. уже нет информации для чтения

Увеличив количество используемых ног - можно не хитро пустить и в обратном направлении биты.

Но тем не менее, возможно есть способ проще, а то я во всем колесо создаю, а наверняка что-то уже есть в этом направлении!

30.12.2013, 00:34

Велосипед изобретаете, товарищ. К тому-же у вас 3-я нога избыточна. Посмотрите на программную реализацию SPI, например.

@otixdos · 30.12.2013, 00:50

UART, от одного до другого МК (в одну сторону) достаточно ОДНОГО вывода.
1-Wire - в обе стороны по одной ноге.

@ShodS · 30.12.2013, 00:55

Сообщение от YomZtotov

Разбираюсь, как передавать информацию между МК более одного бита

А как далеко находятся МК друг от друга?

30.12.2013, 02:01

Читаю про SPI и UART хотя не совсем еще вник + как понимаю эти протоколы требуют поддержки со стороны МК.

ShodS, пока в эмуляторе кручусь после новогодних выходных начну на плате, грубо говоря до 10см думаю, а если не секрет объясните чайнику подробней как в этом случае влияет длина провода, я так понимаю ключевая роль в сопротивлении?

@ShodS · 30.12.2013, 02:09

Сообщение от YomZtotov

как в этом случае влияет длина провода, я так понимаю ключевая роль в сопротивлении?

Да не только...
Если контроллеры стоят на одной плате, то тогда можно обмен упростить до неприличия... например UART или SPI... причем без всяких проверок CRC и прочих хитростей.....
А вот если контроллеры общаются через длинную линию, на которую могут быть и наводки, и мало ли чего еще... то тут желательно уже страховаться... например синхронизировать начало передачи с помощью заранее обусловленного заголовка, кроме того после основного пакета передавать контрольную сумму CRC для исключения передачи ложной информации изза возможных помех и прочее...
Именно для таких случаев, я например использую вот что: http://asis-kbr.ru/forum/viewtopys.php?f=13&t=188

30.12.2013, 02:29

Сообщение от YomZtotov

Читаю про SPI и UART хотя не совсем еще вник + как понимаю эти протоколы требуют поддержки со стороны МК.

Вы не назвали свой МК. Если аппаратного SPI в нем нет, как например в tiny13, то его можно эмулировать программно.
Аппаратный 1-Wire мало где есть. Осилить программный 1-Wire будет тяжело для новичка, с таймингами могут быть проблемы + программная реализация скушает около килобайта ROM.
Для UART-а нужна стабильная тактовая частота и соответствующий кварц.

Если мало ROM, нет периферии и лишних ног, то наиболее оптимальный вариант - программный SPI.

@otixdos · 30.12.2013, 02:41

Сообщение от YomZtotov

Читаю про SPI и UART хотя не совсем еще вник + как понимаю эти протоколы требуют поддержки со стороны МК.

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

@Iddy_Im · 30.12.2013, 12:53

Если уж совсем тягостно, можно zakwire эмулировать. Т.к. оба изделия ваши, стробирующий бит не нужен, ну и на таком расстоянии не нужны CRC.
Можно даже одну ногу и для RX, и для TX использовать (к плюсу ее резистором подтянуть, а при передаче данных прижимать к нулю): если передаете 1, а на ноге 0 - значит, "та сторона" тоже что-то пытается передать.
Протокол прост до безобразия: для передачи сигнала "1" вы выдаете импульс со скважностью 75%, для передачи "0" — со скважностью 25%.
Чтение элементарно: вешается прерывание на задний фронт, при срабатывании запускается таймер на 50% длительности сигнала, как сработает таймер — снимаете значение очередного бита с "ноги".

// на STM32 я zakwire чуть по-другому сделал: измерял скважность каждого импульса, но сейчас понял, что это нафиг не нужное занятие.

@ShodS · 30.12.2013, 14:47

Сообщение от Iddy_Im

можно zakwire эмулировать.

Ух ты... и такое чудо есть..... я чет даже и не слышал о таком :)...

@omokost · 30.12.2013, 16:01

Сообщение от Iddy_Im

...Протокол прост до безобразия: для передачи сигнала "1" вы выдаете импульс со скважностью 75%, для передачи "0" — со скважностью 25%.
Чтение элементарно: вешается прерывание на задний фронт, при срабатывании запускается таймер на 50% длительности сигнала, как сработает таймер — снимаете значение очередного бита с "ноги"...

Похоже описка, по заднему фронту импульс уже прошел, что измерять? Или логика негативная?

@oxytt · 30.12.2013, 17:18

Iddy_Im, интересный вариант)
А как начало посылки обозначить?

@omokost · 30.12.2013, 17:46

Сообщение от oxytt

...А как начало посылки обозначить?

Очевидно же:

вешается прерывание на ... фронт

Неочевидно, это только для одноплатного межконтроллерного обмена.

@oxytt · 30.12.2013, 20:11

Сообщение от "omokost"[/quote

Очевидно же:

из этого очевидно как отделить нули от единиц, а насчет начала посылки или даже тупо начала байта совсем не очевидно

@Iddy_Im · 30.12.2013, 21:18

Сообщение от oxytt

Iddy_Im, интересный вариант)
А как начало посылки обозначить?

По прерыванию же. Вот если "прозеваем" бит, тогда все усложнится. Но тут можно придумать с интервалами между байтами (как в оригинальном zakwire).

Кстати, почему мой метод измерения скважности - говно (точнее, он работает, но работает лишь потому, что я не реагирую на биты четности): в протоколе zakwire в последнем бите слова нет "конца" (т.к. протокол работает на основе измерения уровня сигнала в центре периода). А вот с прерываниями все будет работать отлично.

@Iddy_Im · 30.12.2013, 21:22

Сообщение от oxytt

из этого очевидно как отделить нули от единиц, а насчет начала посылки или даже тупо начала байта совсем не очевидно

Очень даже очевидно: в начале байта будет первый бит. Который начинается перепадом с 1 на 0. Вот как раз прерыванием по заднему фронту мы его и поймаем. Просто в стандартном zakwire первым идет строб (по которому можно измерить общую длительность импульса, чтобы знать, на какое время выставлять таймер в остальных битах). Если скорость известна, он просто отбрасывается. Если неизвестна - измеряем длительность стробового бита (и скважность - если она сильно отличается от 50%, то это - явно не строб). Ну и дальше каждый раз после прерывания по заднему фронту ставим таймер на T/2.

31.12.2013, 00:24

SPI интерфейс самый идеальный, вообще я обожаю синхронные интерфейсы.

@Stiit.mi · 31.12.2013, 02:04

Я за манчестер )

@oxytt · 31.12.2013, 02:29

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

@Stiit.mi · 31.12.2013, 02:56

Тут чуть с другой стороны зайти надо
Если есть аппаратно - то UART вне конкуренции. Маньяки могут использовать USORT
Если нет аппаратного UART, то любой другой аппаратный (SPI или I2C), все одно проще, чем софтом
Если дрыгать ногами - то я выбираю манчестер, легко кодируется, легко декодируется. Или связку SPI - софтовый мастер аппаратный слейв.

Новые блоги и статьи Все статьи Все блоги /
Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .
Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .	Фото: Daniel Greenwood kumehtar 13.11.2025	Расскажи мне о Мире, бродяга kumehtar 12.11.2025 — Расскажи мне о Мире, бродяга, Ты же видел моря и метели. Как сменялись короны и стяги, Как эпохи стрелою летели. - Этот мир — это крылья и горы, Снег и пламя, любовь и тревоги, И бескрайние. . .

YomZtotov

	Передача данных на второй МК 30.12.2013, 00:29. Показов 12210. Ответов 30 Метки нет (Все метки) Разбираюсь, как передавать информацию между МК более одного бита, в голову пришла только одна оптимальная схема с использованием минимум по 3 ноги на каждом МК для передачи в одну сторону: Пишущий МК - нога №1 - по биту пишет на ногу - нога №2 - ждет изменение (1 на 0) или (0 на 1) -что будет сигналом, что нужно отдавать следующий бит - нога №3 - 1 или 0 - закончена передача или нет Читающий МК - нога №1 - по биту читает на ногу - нога №2 - после чтения производит изменения (1 на 0) или (0 на 1) -что будет сигналом, что пишущий МК должен вернуть следующий бит. - нога №3 - проверяем читать дальше или briok на цикл т.к. уже нет информации для чтения Увеличив количество используемых ног - можно не хитро пустить и в обратном направлении биты. Но тем не менее, возможно есть способ проще, а то я во всем колесо создаю, а наверняка что-то уже есть в этом направлении!

6502
	30.12.2013, 00:34
	Велосипед изобретаете, товарищ. К тому-же у вас 3-я нога избыточна. Посмотрите на программную реализацию SPI, например.

@otixdos 0 / 0 / 0 Регистрация: 12.04.2013 Сообщений: 241
	30.12.2013, 00:50
	UART, от одного до другого МК (в одну сторону) достаточно ОДНОГО вывода. 1-Wire - в обе стороны по одной ноге. 0

YomZtotov
	30.12.2013, 02:01
	Читаю про SPI и UART хотя не совсем еще вник + как понимаю эти протоколы требуют поддержки со стороны МК. ShodS, пока в эмуляторе кручусь после новогодних выходных начну на плате, грубо говоря до 10см думаю, а если не секрет объясните чайнику подробней как в этом случае влияет длина провода, я так понимаю ключевая роль в сопротивлении?

@Iddy_Im 0 / 0 / 0 Регистрация: 21.11.2012 Сообщений: 1,400
	30.12.2013, 12:53
	Если уж совсем тягостно, можно zakwire эмулировать. Т.к. оба изделия ваши, стробирующий бит не нужен, ну и на таком расстоянии не нужны CRC. Можно даже одну ногу и для RX, и для TX использовать (к плюсу ее резистором подтянуть, а при передаче данных прижимать к нулю): если передаете 1, а на ноге 0 - значит, "та сторона" тоже что-то пытается передать. Протокол прост до безобразия: для передачи сигнала "1" вы выдаете импульс со скважностью 75%, для передачи "0" — со скважностью 25%. Чтение элементарно: вешается прерывание на задний фронт, при срабатывании запускается таймер на 50% длительности сигнала, как сработает таймер — снимаете значение очередного бита с "ноги". // на STM32 я zakwire чуть по-другому сделал: измерял скважность каждого импульса, но сейчас понял, что это нафиг не нужное занятие. 0

@oxytt 0 / 0 / 0 Регистрация: 16.03.2013 Сообщений: 4,224
	30.12.2013, 17:18
	Iddy_Im, интересный вариант) А как начало посылки обозначить? 0

Oxford
	31.12.2013, 00:24
	SPI интерфейс самый идеальный, вообще я обожаю синхронные интерфейсы.

@Stiit.mi 0 / 0 / 0 Регистрация: 26.04.2010 Сообщений: 1,445
	31.12.2013, 02:04
	Я за манчестер ) 0

@oxytt 0 / 0 / 0 Регистрация: 16.03.2013 Сообщений: 4,224
	31.12.2013, 02:29
	SPI хорош, бескомпромисен и быстр но многовато проводов изначально и их количество растет с ростом числа устройств его сложно удлинить через какие-нибудь драйвера типа max485 короче на мой взгляд он подходит только там, где нужны высокие скорости, но еще нет готовности перейти на параллельный обмен 0

@Stiit.mi 0 / 0 / 0 Регистрация: 26.04.2010 Сообщений: 1,445
	31.12.2013, 02:56
	Тут чуть с другой стороны зайти надо Если есть аппаратно - то UART вне конкуренции. Маньяки могут использовать USORT Если нет аппаратного UART, то любой другой аппаратный (SPI или I2C), все одно проще, чем софтом Если дрыгать ногами - то я выбираю манчестер, легко кодируется, легко декодируется. Или связку SPI - софтовый мастер аппаратный слейв. 0