Для начала PIC PICу рознь. Даже если о старых и мелких, то простите там выбор чипов для точного попадания в проект очень и очень неплох.

На C я пишу.



Эээ... Как насчет, например, ADD R8,R9 в тумбе, слабо? Я к тому, что использование регистров R8-R12 возможно только как хранилищ, нельзя непосредственно производить операции с ними. Как на AVR нельзя, например, непосредственный операнд загрузить в младшие регистры. Это минус. Да и вообще, в тумбе кастрированный набор комманд, где трехадресность, где сдвиги? В этом смысле AVR32 более продуман, там все регистры ортогональны до конца.

С другой стороны, если так подходить - так по мне PowerPC рулит, я еще со 103тьего начинал. 32 регистра и вперед.



Вы не поверите, я тоже сторонник ARM-режима. В одной операционной системе я даже не довел до ума диспечер системных вызовов, работал только в ARM-режиме, а в Thumb - нет. И люди даже слова не сказали. А для тех юзеров, кто когда-нибудь раскроет рот о больших размерах выполняемых файлов (озу там, на платформе, хватает), у меня есть секретное оружие - загрузка секций .elf-файлов через zlib ))

Да, но черт возьми, а в новой ARM-парадигме под названием Cortex ARM-режима вообще нет. Есть костыль - вместо BLX - выполнение комманды ARM-режима. Во как, неожиданно?



Не спасает. Точнее, не нужна. Потому как MAC-уровень реализован программно. И программно выдавать данные или принимать со скоростью 10мбит мне пофиг, на 8 или 32х битах. А внутри стек устроен таким образом, что пересылается минимальное количество данных, не в последнюю очередь в связи с ограничением по озу. Негде буфера раскладывать. Вот и приходится иметь два маленьких буфера для эзернет-пакетов, прямо в них же и разбирать данные, там же и генерировать ответы и т.д.

А на фига делать программный MAC ?! Полно контроллеров со встроенным аппаратным, разница в цене даже при многотысячных тиражах не перекроет перерасход зарплаты на написание софтового, да еще и медленного (100 мбит/1Гбит - не видать как своих ушей).

А почему не и PHY до кучи? Не удалось помахать ножками на 10MHz, а только на 2,5
Только вот почему вы этот трюк называете ТCP/IP стеком? В сколь-нибудь обычных реальных применениях требования к нему заментно другие.


Дело даже не в медленном, а в том,что пару буферов - в реальной сети не выживут никак, только в тепличных точка-точка с единственным протоколом. Ну и насколько сие полезно в реальности?

А часто и не нужно столько. Нужен один интерфейс на всю систему. И Ethernet - вполне хорошая альтернатива.



PHY пока только в одну сторону могу - USART'ом в SPI-режиме.
Хотя была версия и с приемом тактовая частота проца синхронизировалась ФАПЧем с принимаемым потоком и тем-же USART'ом принималась. Только рассыпухи много, PHY за 1$ решает много проблем



Я не этот трюк называю TCP/IP стеком. TCP/IP стеком я называю задачу, которая представляет из себя вечный цикл, в котором обрабатываются входящие пакеты (они принимаются процедурой, реализующей MAC RX, на прерывании), генерируются выходные пакеты, и, для TCP-сокетов вызываются колбеки о соединении, приходе данных, необходимости сгенерировать следующую порцию данных, необходимости отката, о подтверждении переданных данных принимающей стороной, и о разрыве соединения (культурно или аборт). Столь не совпадающий с bsd_socketами интерфейс был придуман для минимизации затрат оперативной памяти. Хотя, как оказалось, ничем не хуже банальных send/recv. Имею я право называть это TCP/IP-стеком?
Собственно, эта задача и требует 28 регистров проца, стековых переменных не хранит. Сами данные сокета занимают 38 байт.



Обоснуйте. Я понимаю, что flow-controll методом back-pressure не панацея, однако, работает, так что считайте, буферов - сколько в свиче на порт - все мои. Кроме того, жизнеспособность железки проверялась на практике, благо под рукой есть пионернет о 500 компьютерах без роутеров, загаженый вирусней и качанием порнографиии, вполне можно тестироваться

На свинство это больше похоже

Отсутствие роутеров никакой особой роли не играет, ибо основную дурную нагрузку отсеивает поминаемый switch. Загрузка сети пятьюстами компьютерами только наруку - Вам меньше прилетит. А с хабами (да, да вымерли они) принимать весь поток и прессовать не пробовали . А поведение разнообразных свичей? В общем, повторюсь, на типичное применение сие совсем не тянет. И полагаете, ARM аналогичной стоимости не потянул?

Примерно в той-же степени, как самобеглую коляску с двигателем от кофемолки собранную у себя в гараже называть Автомобилем. Для этого несомненно нужно иметь знания, проявить недюженную смекалку и упорство. Но в 21 первом веке это Автомобилем не называется. Я в 80x успешно реализовывал нечто подобное на Z80, правда с макообразным железом, но на 4x меагерцах и наряду с массой других задач. Но нормальной ту работу никогда не считал.

Потому как вымерли - не пробовал. Однако, специально писал програмки для зафлуживания сети, дабы знать, когда начнет дропать пакеты.


Почему же?



Да там броадкаста будь-здоров. А особенно хорошо, когда роутер падает и все компы начинают кричать в сеть arp-запросами, "где мой 192.168.15.1 или 192.168.5.254, где мой интернет?" )) Я ж говорю, пионернет, ни виланов, ни управляемых свичей, топология сети - пришел магистральный кабель, воткнут в один порт мыльницы, из другого порта - ушел на следующий свич, в свободные порты натыкано юзеров... Ну как обычно, вообщем. Так что нормальный полигон.



Ну вот на данный момент софт в LPC2102 лезет впритык, свободного места нет. Берем следующий, LPC2103. Он у нас 21грн, Mega168 - 13грн. И еще эксперимент ставить, все ли так хорошо с Fast IO, как утверждают. С другой стороны, я вот новый MAC вроде написал, для кварца 16МГц, значит, можно вообще к любой меге прикручивать Ethernet.



Давайте посмотрим на это дело с такой стороны. Обычная доза RAM в свичах на порт порядка 10кбайт. Врядли будет больше выделено в камне. Какая разница, где эти пакеты лежат и дожидаются обработки, в свиче или в камне, или в отдельном эзернет-контроллере? А наплодить пакетов в сети можно столько, что любой девайс начнет дропать входящие.




А что тогда по Вашему может называться TCP/IP-стеком? Почему такое неприятие?



Спасибо, что Вы мне не отказываете в наличии знаний.



Я польщен.



Дык это, без труда - не выловишь и рыбку из пруда.

Проблема банальная - свичи дешевеют и превращаются в полное дерьмо непонятно как работающее
Точнее работающее по принципу пусть другое железо и TCP/IP разбирается.
Встречаются нормальные, но все больше и больше непойми что... Знаю на своей шкуре - использую года с начала 90x в жесткой реалтаймомой системе протокол на Ethernet фрейме в ограниченной одним hub|switch|router сети. Даже на древних hub без проблем, да коллизии, но они детектируются и шустро перепередаются. Старые switch - вообще просто песня. Но последние годы просто хлам идет. Причем под одной и той-же маркой меняется начинка и все... Ставлю роутеры - более менее, хотя всякие нюансы совместимости fullduplex c разнообразными сетевыми картами в полный рост - отключать приходится.


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

Честное слово, я искренне!



Это сколько в конвертируемых валютах? Luminary Cortex c MAC по 3-4 бакса. Может некотрые проблемы стоит решать организационными методами - купить не мегу,не в ближайшем гастрономе а то, что больше подходит и приемлимо стоит.

Да и бог с ним. Пусть не отражает коллизию дальше в сеть, нефиг было лить столько пакетов, что начало дропать. Главное, пусть накапливает пакеты у себя в буфере, пока я их обрабатываю. Если переполнился, то тут уже ничего не спасет. Точно так же может переполниться и буфер в железном маке.



Ничего страшного. Дропнет, да и все. Я даже вилан-теги обрабатываю (в отличии, например, от 2.4 ядра в линухе , это к вопросу о высокой планке)

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


1 убитый енот равен 5 гривен. Цены я привел розничные. А покажите, что там за Луминари, в смысле, дайте ссылочку на даташит да на цены?

http://www.luminarymicro.com/products/ethernet.html
С ценами в розницу правда что-то очень плохо - c Ethernet вдвое дороже! "обычных"
http://search.digikey.com/scripts/dksearch...l?KeywordSearch

Я это... По теме пять копеек вставить хочу
Открываем даташит на любой AT91SAM7xx и читаем:

30 мегагерцовый флеш у Атмела уже реально работает, почему тогда 32MГц XMega сомнения вызывают?

Справедливости ради...
В AVR всего лишь 32 регистра по 8 бит, в то время как в ARM 14 регистров общего применения по 32 бита. Все регистры AVR влезут в 8 регистров ARMа. Аргумент не защитан.

После отцитированного уже внушает основательные надежды.

С математикой у Вас конечно все в порядке, 32*8<14*32. Только вот не получается так переменные плотненько раскладывать. Чтобы в одном 32-хбитном регистре было например char, char и short. Т.е. при ручной работе конечно можно с битовыми полями работать, но какой же это код получится?

Хотя, сейчас попробую еще раз под ARM собрать, посмотрим, что последние оптимизации нам принесли...

Круговой сдвиг регистра на любое число бит выполняется за 1 такт. Далее младший байт пишете куда-либо. За 1 такт можно сдвинуть любой регистр, объединить его с маской (или любая другая арифметическая или логическая операция) и положить в другой (временный) регистр. Вообще, там много скоростных операций (трюков) для работы с байтами. Именно эту часть проекта можно написать на асме, как и дрыгание ножками.