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

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

RESPECT !!!

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

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

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

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

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

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


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

Да использую, использую....,
просто при беглом просмотре мне показалось что это защита на время считывания 10бит регистра
ADC, и кстати к аккурантности в этом вопросе есть некоторые предпосылки...,
ну а потом просто понял что здесь 16бит защищенный доступ в чистом виде...

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

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

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

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

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

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

Да.


Вобщем-то уже реализовано.
По-простому.
Используется протокол TCP/IP, соответствующего WinSock 1.1.
Сервис использует TCP/IP порты, незадействованный в системе.
Обычно контроллеры общаются с другими через сервер данных (база данных) по изеру и выступают в качестве клиентов.
Протокол OPC является посредником, он интерпретирует данные TCP/IP портов в пакетах и разносит их по полям ее. Этот протокол предназначен для стыковки с любым типом оборудования. Он весь гибко программируется (порты, поля пакетов).
Каждый производитель систем автоматизации считает своим долгом разработать свой набор :
- сервер данных (по их мнению наиболее быстрый)
- драйвер OPC
- систему визуализации.
Надо не релизовывать, а проверять на предмет конфигурируемости и совместимости с тем или иным продуктом.
PS. Надеюсь, что не запутал Вас.

В 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--------------+---------+-----------+-----------+----------+---------------

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

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

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