Существует какой-либо протокол для обмена данными по uart ?

[Eddy_Em]

[uquote="roman.com",url="/forum/viewtopic.php?p=3908253#p3908253"]CAN - это дёшево ? ))[/uquote]
Я уже выше говорил: 300 рублей себестоимость CAN<>USB с гальваноразвязкой.
А если у кого-то руки из жопы растут и он не может сделать сам, пусть покупает за 500 баксов =D
CAN же очень даже нужен! Скажем, как иначе соединить штук 50 драйверов шаговиков? А на али есть уже готовые, причем, сравнительно дешевые! Самопал такого уровня выйдет не дешевле.

Да, Ethernet в два раза дороже... Но зато МК подключается напрямую компу... по Интернету !!!

Угу, и в МК нужно городить TCP/IP? Да даже UDP - жесть!

[Jack_A]

[uquote="ARV",url="/forum/viewtopic.php?p=3909013#p3909013"]никаких модбасов, кэнов и т.п.[/uquote]
Ну мастера мы из мухи слона раздувать. CAN, Ethernet... Человеку, мож, просто от одного МК до другого пару байтов перекинуть на 5см. Да и этого уже, похоже, не нужно.

Спойлер

Вспоминаю (может, уже писал об этом) : когда по причине здоровья ушёл с Team Leader - ства, мой молодой преемник: "Всё переделать! Вот у тебя слейв отвечает на запрос 1 байтом состояния. Надо - строкой: 'Ready' , 'Error Nr XX' " Чем лучше? - спрашиваю. - Скорость обмена увеличится? Надёжность повысится ? "Нужно так! И всё!" - отвечает .
На моё счастье, тут и пенсия подоспела. И пошли они, солнцем палимы...

И ещё: мне смешно было наблюдать, как при обсуждении протокола шли аргументы типа: а если по твоему интерфейсу - топором - он будет работать? Мой - будет!

[ARV]

Вот у тебя слейв отвечает на запрос 1 байтом состояния. Надо - строкой: 'Ready'

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

[Eddy_Em]

Да и при непосредственной работе с железкой сериализация - крайне нужная и полезная вещь! Просто воткнул железку, открыл терминал, да пиши себе команды и читай ответ.
Что до CAN, так я его вспомнил в контексте необходимости связи нескольких железяк для упрощения реализации протокола (т.к. там уже все нужные проверки есть). А связать два МК можно большим количеством способов, но никакой хитрожопый протокол там придумывать не нужно. Хоть бинарные структуры с данными гоняй (если оба МК с одинаковой "конечностью").

[roman.com]

а если по твоему интерфейсу - топором - он будет работать?

Ну всякие же бывают в жизни ситуации))

CAN же очень даже нужен! как иначе соединить штук 50 драйверов шаговиков?

Мне CAN не нужен.
Соединить штук 50 драйверов шаговиков можно как угодно)) Хоть по радио))

в МК нужно городить TCP/IP? Да даже UDP - жесть!

UDP жесть ? )) Жесть - это соединять МК с компом напрямую (без адаптера) ! ))

Вот видео как это сделать -
https://www.youtube.com/watch?v=mwcvElQS-hM
https://www.youtube.com/watch?v=m4f4OzEyueg

А вот я соединил ATmega8 со воим компом напрямую !

Ethernet-Atmega8.jpg

(196.01 КБ) 165 скачиваний

А вот я соединил ATmega8 со воим роутером напрямую !

TL-WR703N_Schematic AR9331.jpg

(179.48 КБ) 165 скачиваний

А всякие там стеки сетевых протоколов ARP, TCP, UDP, DHCP, ICMP.... это вообще не проблема)) Можно написать самому, а можно использовать готовые... В адаптерах типа W5500 уже готовый стек всех необходимых протоколов...

[Jack_A]

[uquote="ARV",url="/forum/viewtopic.php?p=3909252#p3909252"]всегда следует избегать ситуаций, когда искаженная информация не может быть отделена от правильной[/uquote]
Это само собой. Естественно, была CRC. Но предполагалась работа в не очень качественных сетях (это от нас не зависело, как заказчик сделает). Поэтому вероятность искажения была очень даже ненулевая. Передать короткий пакет - больше шансов принять его неискажённым и не тратить время на перезапрос.
А в программе верхнего уровня на РС, приняв корректный байт состояния, развернуть его в понятное сообщение - делать из этого проблему - смешно.
Eddy_Em

Да и при непосредственной работе с железкой сериализация - крайне нужная и полезная вещь! Просто воткнул железку, открыл терминал, да пиши себе команды и читай ответ.

В данном конкретном случае работа "а-ля диспетчер" не планировалась . Устройства работают в пределах цеха, программа на РС периодически опрашивает их и журналирует инфу в файл. В каком виде - компактно, как принято от дивайса - или развёрнуто, доступно для чтения как текстовый - это меня не касалось, делал другой чел. Главное было - обеспечить в условиях не очень качественной сети приём нужного количества данных.

Спойлер

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

[roman.com]

Как ещё можно соединить два МК или МК + комп ? Вариантов куча)) Протокол любой... включая самопальный))

Можно через Proteus)) Подключаем МК к выходу звуковой карты компа и управляем работой МК... прям из Proteus))

Proteus-ATmega128.jpg

(132.07 КБ) 162 скачивания

Можно через Java)) Подключаем МК к выходу звуковой карты компа и управляем работой МК... прям из Java))

Java-ATmega128.jpg

(166.29 КБ) 156 скачиваний

Для удобства можно использовать Java терминал...

Java-Терминал.jpg

(110.91 КБ) 157 скачиваний

А можно через обычный браузер... Хотя интересней через браузер + Java сервер + VPN ))

VPN-Браузер-Java-ATmega128.jpg

(206.2 КБ) 155 скачиваний

И всё это с обходом NAT...

NAT Table.jpg

(71.61 КБ) 154 скачивания

И разумеется всё с шифрованием... куда же без него))

шифрование.jpg

(116.1 КБ) 168 скачиваний

...
и т.д.

Короче... Вариантов столько, что просто чата не хватит всё разобрать))

[Али777]

Ого, написано сколько. Извиняюсь проглядел... Тоже подумывакал понаписакать свой протокол. Да там всего три команды так сказать.
1. С мк на скуде в другой мк на сервере, отправка номера карты mifare. Если карта в базе есть обратно ответ "OK" либо "NO".
2. Отправка события мк скуда по карте "пройдено" / "не пройдено". Ответ "OK"
3. Отправка события "открытие скуда по пульту" в мк возле сервера. ответ "OK"

: + номер команды + data 10 байт + crc + (cr+lf)

[Starichok51]

но текстовая информация лучше тем, что может быть воспринята человеком непосредственно, без разработки специальных средств.

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

[a1000]

Ну например через монитор порта.

[ARV]

[uquote="Starichok51",url="/forum/viewtopic.php?p=3911879#p3911879"]

но текстовая информация лучше тем, что может быть воспринята человеком непосредственно, без разработки специальных средств.

ну и каким образом человек непосредственно может увидеть своими глазами, что там отправил МК через порт?[/uquote]ну вот я мог бы сделать такой протокол обмена, в котором старт пакета был бы байтом 0xFF, стоп - 0xFE, а сам пакет имел бы переменную длину (второй байт) и байт-стаффинг (чтобы отличать 0xFF и 0xFE внутри пакета от старта-стопа пакета), а в конце была бы двухбайтная CRC.
чтобы отладить моё устройство, я должен был бы написать на ЯВУ какую-то GUI для компа, которая бы понятные мне команды (типа "включить выход 1" или "вернуть значение с АЦП канала 2") переводила бы в понятне МК пакеты... так? вручную ввести подобный пакет очень сложно...

а теперь посмотрим, как бы я отлаживал устройство, если бы обмен с ним был текстовым типа C:P1=1 или C:A2= (C: - признак команды, P - порт, А - канал АЦП, остальное догадайтесь).

я бы открыл putty и прекрасно вводил бы все команды и наблюдал бы ответы вроде "ОК" или "А2=237".

ну и что проще и удобнее? любая консольная программа позволила бы мне ВИЗУАЛЬНО видеть весь обмен, и работать с МК, как будто я - второй МК или вторая программа.

если надо отладить обмен между двумя МК или МК-ПК, так есть программы, позволяющие "вклиниваться" в обмен и наблюдать проходящие там данные. и в этом случае так же куда понятнее видеть текстовый обмен, нежели что-то типа 00 22 3E 27 0F 12 EE

[Starichok51]

у меня есть пара проектов в разделе "Питание" - блок питания и измеритель емкости аккумуляторов.
так там у меня совсем примитивный собственный протокол.
ПК отправляет 4 байта:
1 - код команды
2 - номер параметра
3 - младший байт записываемого значения параметра
4 - старший байт записываемого значения параметра

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

[roman.com]

А я все команды отправляю/принимаю одним пакетом. Причём пакет фиксированной длины.
Это повышает надёжность. Кроме CRC приложение и МК проверяет ещё и длину пакета:
Len != 64 > error
А сами команды - это просто флаги.
При этом мне не надо помнить что означает каждый бит. За меня это делает приложение.
Пример: Wireshark всё делает за меня ))

Screenshot_1.jpg

(54.98 КБ) 156 скачиваний

По такому принципу работают все мои приложения.