Форум РадиоКот

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

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

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

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

Спойлер

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

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

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

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

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

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

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

Eddy_Em писал(а):CAN же очень даже нужен! как иначе соединить штук 50 драйверов шаговиков?

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

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

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

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

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

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

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

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

Спойлер

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

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

Можно через Proteus)) Подключаем МК к выходу звуковой карты компа и управляем работой МК... прям из Proteus)) Можно через Java)) Подключаем МК к выходу звуковой карты компа и управляем работой МК... прям из Java)) Для удобства можно использовать Java терминал... А можно через обычный браузер... Хотя интересней через браузер + Java сервер + VPN )) И всё это с обходом NAT... И разумеется всё с шифрованием... куда же без него)) ...
и т.д.

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

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

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

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

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

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

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

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

ну и каким образом человек непосредственно может увидеть своими глазами, что там отправил МК через порт?[/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

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

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

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