[aaarrr 69]

На LPC и SAM портировать можно, но смысла большого нет - младшие кристаллы с MAC стоят достаточно дешево.

 

А идея и реализация красивые :a14:

[Mc_off 0]

RESPECT !!!

 

Спасибо огромное !

[Rst7 5]

младшие кристаллы с MAC стоят достаточно дешево

 

Да не скажите, вполне ничего так бесплатное приложение получается к LPC2103 например, или LPC213x-01. Тут нас zltigo все время пугает приходом супер-камней LPC1000 (если не ошибаюсь), тоже может круто получиться (хотя качество кодегенерации у IAR под Cortex оставляет желать лучшего)...

[singlskv 0]

Немного не по теме основного топика, но начал смотреть Ваш код с main и увидел:

    while(ADCSRA_ADSC);
    __disable_interrupt();
    *p=ADC;
    __enable_interrupt();

и не понял смысл запрещения прерывания на время считывания ADC.

Зачем это сделано ?

 

Ааа, понял, просто для того чтобы 16бит значение считывалось за раз,

просто я такое чтение ADC в основном цикле никогда не использую и подумал что это нужно(зачем то, иногда) для правильного

считывания ADC.

[zltigo 1]

zltigo все время пугает приходом супер-камней LPC1000...

Да не пугаю совершенно и не думаю, что они супер по возможностям будут, но цены в нижней ценовой категории скорее всего подвинут. А то Luminary с Ethernet :) на борту совершенно дикие цены имеют для мелких потребителей. А так скорее всего достаточно обычные Cortex-M3 - софтовую эмуляцию можно пробовать уже сейчас на STR32. Только не могу придумать для чего можно применить подобные решения - для большого количества мелких девайсов уж слишком Ethernet структура громоздкой (не сколько дорогой, сколько именно громоздкой и ненадежной из-за обилия кабелей и свичей) получается. А если девайсы штучные, то и ультраэкономия как-то менее привлекательна. Что остаетя? Что-то офигенно массовое для бытового потребления? Что?

 

Ааа, понял, просто для того чтобы 16бит значение считывалось за раз,

просто я такое чтение ADC в основном цикле никогда не использую...

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

[singlskv 0]

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

Да использую, использую....,

просто при беглом просмотре мне показалось что это защита на время считывания 10бит регистра

ADC, и кстати к аккурантности в этом вопросе есть некоторые предпосылки...,

ну а потом просто понял что здесь 16бит защищенный доступ в чистом виде...

[Rst7 5]

ну а потом просто понял что здесь 16бит защищенный доступ в чистом виде...

 

Причем, именно для записи значения, для считывания из ADC он нафиг не нужен.

[GDI 0]

Идея очень хорошая и ее по праву можно поставить в один ряд с софтовой реализацией USB на AVR. Сам когда то думал о таком, но дальше идеи дело не зашло.

 

Теперь это надо как то красиво назвать, например EtherAVR или AVR-MAC и разместить где нибудь в интернете, например на embedders.org, могу дать контакты, если что.

[alexander55 0]

Что-то офигенно массовое для бытового потребления? Что?

Дешевая замена Xport - первое, что приходит в голову.

PS. Если удастся подключать через OPC-драйверы, то тогда открывается широкая дорога в АСУТП.

Представьте только, WinCC, InTouch совместимость.

[Rst7 5]

PS. Если удастся подключать через OPC-драйверы,

 

Я так понимаю, имеется в виду уже поступившее предложение о конверторе Modbus<->Modbus over TCP?

 

Ну давайте попробуем реализовать. Можете кратенько написать, чего надо? Только не надо отсылать читать мануал по Modbus over TCP ;)

[alexander55 0]

Я так понимаю, имеется в виду уже поступившее предложение о конверторе Modbus<->Modbus over TCP?

Да.

 

Ну давайте попробуем реализовать. Можете кратенько написать, чего надо? Только не надо отсылать читать мануал по Modbus over TCP ;)

Вобщем-то уже реализовано.

По-простому.

Используется протокол TCP/IP, соответствующего WinSock 1.1.

Сервис использует TCP/IP порты, незадействованный в системе.

Обычно контроллеры общаются с другими через сервер данных (база данных) по изеру и выступают в качестве клиентов.

Протокол OPC является посредником, он интерпретирует данные TCP/IP портов в пакетах и разносит их по полям ее. Этот протокол предназначен для стыковки с любым типом оборудования. Он весь гибко программируется (порты, поля пакетов).

Каждый производитель систем автоматизации считает своим долгом разработать свой набор :

- сервер данных (по их мнению наиболее быстрый)

- драйвер OPC

- систему визуализации.

Надо не релизовывать, а проверять на предмет конфигурируемости и совместимости с тем или иным продуктом.

PS. Надеюсь, что не запутал Вас.

[7403 0]

Я так понимаю, имеется в виду уже поступившее предложение о конверторе Modbus<->Modbus over TCP?

 

Ну давайте попробуем реализовать. Можете кратенько написать, чего надо? Только не надо отсылать читать мануал по Modbus over TCP ;)

В MODBUS может использоваться 2 режима передачи данных: ASCII или RTU. RTU более интересен, т.к. применяется CRC16, а скорость передачи вдвое выше. Также его реализация получается проще(или компактнее).

В RTU-режиме сообщение начинается с интервала тишины равного времени передачи 3,5 символов. Максимальная длина фрейма - 255 байт. Для Modbus over TCP разбирать содержимое фрейма необязательно, достачно знать начало и его длину. Алгоритм работы приблизительно такой:

Со стороны USARTа: ожидание начала пакета, приём пакета до интервала между ними в 3,5 символа или до длины 255, пересылка полученного пакета в ethernet. Аналогично со стороны ethernet.

 

Возможно, лучше было бы пересылку пакетов осуществлять после проверки CRC.

Вот так выглядит фрейм:

---------------T----------T-----------T-----------T----------T---------------¬

¦ старт_____¦ адрес_¦функция_¦ данные_¦ CRC__¦ конец ¦

+-------------+---------+-----------+-----------+----------+---------------+

¦T1-T2-T3-T4¦ 8 бит ¦ 8 бит ¦n x бит ¦ 16 бит ¦T1-T2-T3-T4 ¦

L--------------+---------+-----------+-----------+----------+---------------

[alexander55 0]

Этот вариант самый удобный для реализации контроллера, т.к. ПО не изменяется.

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

[Erv&Sed 0]

RST7 я вас правильно понял, у вас реализован в том числе и HTTP протокол???

[Rst7 5]

у вас реализован в том числе и HTTP протокол???

 

Весьма неполный, как Вы понимаете.