RS 232 в Ethernet Поделитесь знаниями

[EFrol]

EFrol вот для PIC-ов мне все это незнакомо я шил только готовые прошивки когда-то. Что там и как надо делать честно хз...
Начать можно с моих приборов, что есть. Сделать конвертеры в Modbus приборов в наличии. Потом уже перейти к чему-то удаленному.
Ну и сделать вариации сквозных интерфейсов через модем, типа через mqtt, или просто как TCP клиент чтобы было подключение.

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

Я с Вами абсолютно согласен. Если мы сделаем такой конвертер, то дальше можно реализовать подключение чего угодно.
Даже подключив потом ПМ01, реализовать тот же MQTT-модем.

Я называю эту идею: Универсальный конвертер. Максимально дешевый и программируемый.

А вот идет сборка его прототипа:

Платка контроллера с RS485 + RS232_TTL + импульсный БП 220v на 5v600mA

[melky]

EFrol напишите в личку, с чего будем начинать. Что мне надо будет купить? я еще дома гляну, что у меня валяется. точно знаю, какая-то LiLu платка есть, Arduino Nano вроде есть.
Что тут может помочь для реализации? На макетке могу спаять для тестов что-то и т.д.

Надо понять вообще состав как железа так и программной части для создания конвертера.

[EFrol]

Ну вообще-то как бы все уже выложено в эту тему. Все карты на столе.
- сама идея
- варианты реализации
- даже прототипы есть (RS485 Slave<->(RS485Master, RS232Master)

Я пишу на Assemblere. Может кто сможет написать IDE для Windows (для компиляции с ST и загрузки в PIC12 через ПР-КП10/ПР-КП20).
Тогда это позволило бы сделать результат массовым (общедоступным).
Может кто поможет с массовым производством?! Может предложит другую схему (более дешевую, без изменения ТЗ)?!

[melky]

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

Ну и программа. я на C# немного пишу из-за Scada, на C и тем более Асме тяжело. Ну на С еще смогу код опросов приборов адаптировать наверное, на Асме вряд ли.

заказывать мелкосерийное производство в России не выгодно вообще. Даже на 2-х сторонние платы с металлизацией мне такие суммы озвучивали, что просто за страну стыдно
Собственно у самого была идея применять что-то готовое в виде Arduino Nano, те же ESP. И по факту разработать надо типа материнской платы, на которую потом эта ESP или Arduino припаивается, там же разъемы, интерфейсы с обвязкой и готовая плата питания.

[EFrol]

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

Ну и программа. я на C# немного пишу из-за Scada, на C и тем более Асме тяжело. Ну на С еще смогу код опросов приборов адаптировать наверное, на Асме вряд ли.

заказывать мелкосерийное производство в России не выгодно вообще. Даже на 2-х сторонние платы с металлизацией мне такие суммы озвучивали, что просто за страну стыдно

Да. На ASM писать тяжело. Сейчас бьюсь с математикой для плавающей запятой. Т.к. некоторые приборы возвращают дробные значения (да еще в ASCII-коде), а их надо конвертировать в 4-х байтный Float, чтобы передать по Modbus.
Прототип заказывал в https://rezonit.ru/

[melky]

ну на C# биться со строковыми float нет проблем хоть точка разделитель, хоть запятая, все готовое есть. А на Асме наверное печалька с этим... Почему не С ? разве там нет библиотек для этих целей? или тогда код сильно большой получается?

[EFrol]

ну на C# биться со строковыми float нет проблем хоть точка разделитель, хоть запятая, все готовое есть. А на Асме наверное печалька с этим... Почему не С ? разве там нет библиотек для этих целей? или тогда код сильно большой получается?

Библиотека есть, но для PIC18. Сейчас портирую на PIC12. Код несильно большой - помещается!

[melky]

ну если только это помещается, то как поместится код опроса протокола? там нифига не настолько маленький код. И преобразование строк и преобразования из BCD в int, uint и так далее... Тот же расчет CRC табличный или в виде кода...
В общем там целый набор преобразований.
Библиотека драйвера Логики у меня занимает примерно 65 кб на C# и это без учета механизмов, которые она использует из ядра Scada системы.
PIC12 со своими 2К тут кажется и рядом не валялся, и даже 8К не спасет.

Нужна другая микросхема для конвертера однозначно.

[EFrol]

ну если только это помещается, то как поместится код опроса протокола? там нифига не настолько маленький код. И преобразование строк и преобразования из BCD в int, uint и так далее... Тот же расчет CRC табличный или в виде кода...
В общем там целый набор преобразований.
Библиотека драйвера Логики у меня занимает примерно 65 кб на C# и это без учета механизмов, которые она использует из ядра Scada системы.
PIC12 со своими 2К тут кажется и рядом не валялся, и даже 8К не спасет.

Нужна другая микросхема для конвертера однозначно.

Да. Тут я с Вами тоже согласен.
И когда я писал MQTT-клиента на ASM - даже был уверен, что упрусь в нехватку ресурсов.
Но сейчас смотрю на отчет компилятора:

                              Program Memory Usage 
                               Start         End      
                           ---------   ---------      
                            0x000000    0x000000      
                            0x000004    0x0002fd      
                            0x000600    0x000671      
                            0x000700    0x00076d      
                            0x008007    0x008008      
                            0x00f000    0x00f084      
            1122 out of 2311 program addresses used, program memory utilization is 48%

и думаю, что делать с оставшимися 52% программной памяти?!

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

[melky]

Да я все понимаю, но переписывать код на Асм я точно не буду, на это нет просто времени. Если есть возможность выбрать чип для конвертера, точнее для устройства, которое будет опрашивать приборы и предоставлять данные в Modbus, то надо исходить из того, чтобы ему хватило памяти при программировании на C.
Все таки разобраться с адаптацией кода на С думаю будет легче, чем на Асм. В любом случае надо пробовать.

просто платы типа OrangePi 2 я видел у китайцев по 2т.р. что очень скромно. Всего-то нужно добавить питание и RS485. И писать ничего особо не надо. Просто ставить Linux и настраивать.
Банально, посмотрите сколько весит в байтах таблица для CRC по Modbus, если применять табличный метод.