Собственно задача назревала достаточно долго, но похоже, созрела.

Немного введения. Существует "отдельностоящая" серверная. В количестве двух штук. В них бывают случаи сбоя по ~220, в результате чего кондиционер самостоятельно бывает, не запускается, в результате чего довольно быстро начинает нарастать t. Это проблема первая. В общем-то крайне близкая проблема, результат тот же, но причины разные - при переходе лето-зима и наоборот периодически кондей опять же "встает". Причины не нашли, поэтому, просто дергаем "кондиционерщиков". А за это время температура опять же, нарастает... И, наконец, еще одна проблема - в одной из серверных резервный, а в другой - боевой кондиционеры не имеют "наружнего" слива. Т.е. слив конденсата организован в локальное харнилище - по-простому - ведро. Имеет место быть ограниченность системы в силу небесконечности накопителя по простому - ведро наполняется рано или поздно. В итоге имеем задачу - собрать два схожих устройства, с возможностью дальнейшего масштабирования (планируется организация "полноценных" серверных либо просто закрытых "серверных шкафов" в других городах). Устройства должны иметь возможность мониторинга трех параметров:

1. температура (DS1820 где-то доложон валяться)

2. фиксировать пропадание электричества (по возможности с организацией RTC и запоминанием, когда пропало, когда появилось)

3. мониторить состояние ведра (исполнительный механизм, вернее, идея его организации, имеется - датчик наполнения будет самым, пожалуй, простейшим - на базе обычного кулера с поговревшей обмоткой - к крыльчатке прилажен рычаг с поплавком, поплавок всплыл, крыльчатка повернулась, датчик Холла, имеющийся внутри кулера, выдал "1" вместо "0" на выходе.

Собственно, дело за малым - начать да кончить. Не решен вопрос с выбором контроллера - боюсь, что tiny2313 просто не хватит памяти на реализацию TCP/IP. А делать прийдется именно TCP поскольку таким образом достигается масштабируемость любого уровня - и в перспективе на другой город, и в имеющихся масштабах - между этажами нет прямого интерфейса, зато свободных портов в коммутаторах найти можно. Но дальше первого же маршрутизатора UDP не протолкнешь. Собирать данные планируется на "большом брате", благо, опять же, свободных вычислительных ресурсов в контексте данной задачи на каком-нибудь из серверов найти можно с избытком.

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

Чем отличаются следующие трансформаторные развязки. На старой доброй сетевухе-комбе имеются и тот и другой, оба - 10Мбит. Но только один 16PT-006A и чуть поменьше, другой 20F001N и чуть побольше. По обвязке оба братья-близнецы. Сравнение в ДШ дало следующее:

Vend | Part Number | Package   | Cores | Temp   | Configuration

YCL   | 16PT-006A  | 16-pin DIL |    3   | +25° C | 10BASE2 & 5

YCL   | 20F001N     | 16-pin DIL |    3   | +25° C | 10BASE-T (LPF)

Что из себя представляет та и другая конфигурация? Как-то даже растерялся...

Википедия Вам в помощь.
Первый - под коаксиал, второй - под витую пару.

А по остальному.. я б ARM взял. Получится куда лучшая масштабируемость...

Вероятно, я бы тоже. Просто на полке 8-разрядники лежат, а вот ARMов немайя... К тому же, с 8-разрядными я хоть как-то знаком, а про ARMы только и знаю, что они "есть", ни что нужно для разработки на них, ни как, ни с чем, я не знать рано или поздно, конечно, дорасту, но сейчас, думаю, не готов. Да и делать буду все, видимо, исключительно в DIP/DIL/и т.п. исполнениях, чтобы "на коленке" можно было делать.

Что там iosifk про гайку M3 говорил?

А на коленке ничего делать не надо. Надо раскрутить начальство (раз есть серверные, значит есть и начальство) на закупку каких-нибудь демо-плат, и на них уже и собрать. Осталось только подобрать что-то нужное (процесор + сеть + макетные "дырочки").

Начальство мы не раскручиваем, решаем имеющуюся проблему своими силами. А нет - так хоть ночуй и карауль самолично. Но шоп работало! У начальства бывают разные политики управления. Мелкий саботаж в этом плане неуместен. И давайте не будем их здесь обсуждать, pls. Мозоли и так болят. По существу хочется вспомнить, как держать в руках паяльник, собрать что-нибудь работающее и внедрить на месте, дабы облегчить жизнь себе и коллегам, при этом получить дополнительное моральное удовлетворение с минимальными материальными затратами 

P.S.: про гайку М3. В данном случае если со всеми задачами "по отдельности" я готов справиться, то с эзернетом работаю только как админ, но не как "железячник", а посему вопрос остается прежним, ищу (заметьте, ИЩУ, а не жду, это действительно так) варианты реализации стека TCP/IP на базе AVR 8-разрядного. Рассматриваю варианты кастрации, но передавать данные все равно необходимо по IP, причины уже назвал - свичи и маршрутизаторы "по дороге от А к Б"

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

Ну а дабы не просто ругать, а быть конструктивным - http://electronix.ru/forum/index.php?showtopic=44276

Есть такие библиотеки
1. uIP
2. Procyon AVRlib

Может чем-нибудь поможет

Поиском пользуюсь, темы изучаю... Вашу ругань понимаю, но свои вопросы - есть свои... Если позволите, конечно




Про первое - изучаю, там есть ссылки вроде как даже народ начинал портировать под мелкие АВРы, но почему-то оба проекта "в стадии разработки" уже достаточно долго висят... Смушшаеть. За второе - спасибо! Еще не видел.

P.S. Нашел крайне любопытную вещь: http://www.avrfreaks.net/index.php?func=vi...=Freaks%20Tools но по ссылке на обещанные исходники.... то ли лыжи не едут, то ли я... Боюсь, что второе

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

Калибратор:



Сигнал из схемы:

Может, если еще не поздно, имеет смысл взглянуть в сторону PIC18F97J60?
На борту:
Program Memory (KB) 128
CPU Speed (MIPS) 10.5
RAM Bytes 3,808
Digital Communication Peripherals 2-A/E/USART, 2-MSSP(SPI/I2C)
Capture/Compare/PWM Peripherals 2 CCP, 3 ECCP
Timers 2 x 8-bit, 3 x 16-bit
ADC 16 ch, 10-bit
Comparators 2
Ethernet 10 Base T
Temperature Range © -40 to 85
Operating Voltage Range (V) 2 to 3.6
Pin Count 100

Все поместится в один корпус, ну плюс транс еще.

На сайте Microchip.com есть куча работающих примеров, в том числе готовый TCP/IP стек.

Увы... Даже не в "поздно" дело, а в определяющих задачу параметрах: сделать из того, что имеется в наличии.



Это, конечно, шик... Но пока для меня - фантастика... 

Совершенно не понимаю, в чем причина. Не получается получить LNK на 28J60. Пробовал уже менять - результат тот же. Не чувствует линка. Подскажите, куда копать, пожалуйста...

На данный момент так и не смог понять поведения щупов, расчитанных на частоту с запасом (описывал в 9 посте)

Но на данный момент созрел еще один вопрос. Перебрал схему, собрал на другом трансформаторе, который совмещен с разъемом. Не знаю, что изменилось, но линк стал по крайней мере, определяться. Но в изучаемом примере все равно не срабатывает стек протоколов. Поэтому, вопрос - какие существуют способы отладки Ethernet?
Как можно отследить, скажем, приходящие фреймы или что-то еще? Как искать, какая часть простейшей, грубо говоря, схемы не работает?
Оговорюсь, у осциллографа неизолированы входы, существует связь по "земляному" проводу с ПК... Хотя, можно попробовать отключать RS232 (отлаживаюсь на STK500)

Есть снифер Wireshark.
С помощью него, например, можно выяснить правильность структуры кадра, просмотреть содержание принятого/переданного кадра или вообще его наличие в сети.

С этим делом я знаком, как бы посмотреть на уровне 28J60 это дело? Может, в SPI проблемы, может, на уровне 28J60.... Вообще, сеть живет в "боевой" сети, с моей рабочей машины. На коммутаторе выделен порт специально для сниффа, дублирующий порт с девайсом. На нем ШВ ARP запросы идут. Но железка моя на них партизанит. Линк 10Мбит подняла и на этом всё...