Небыло печали, да вот NXP сваял новую линейку со встроенным EMAC.
В новую разработку уже планировал закладывать Atmel, но вот теперь дилема.
Раньше работал с LPC2238,2214 есть кое какие наработки перефирия то наверняка такаяже, SAM7x вроде бы как новый для меня девайс, с другой стороны LPC23xx совсем свежий кристалл, даже еррату взять не удалось сегодня. Кроме того на SAM7x есть пример портированной freeRTOS со стеком IP.

Из отличий в LPC только 4-й UART, хотя мне для задачи он вообщем том лишний, надо 3
И вроде бы 16К FIFO EMAC, но паямяти чуть меньше.

Вообщем полностью на разработку полгода, а МК выбирать надо уже сейчас. Стоит ли смотреть на LPC23хх

Например, Davicom DM9161(A). RTL8201 уже староват.

Зачем пустыми словами бросаетесть? Что "все"? Мини контроллер внешней памяти начисто вместе с проблемой отсутствующий в
интересующем Вас чипе?
Похоже Вы пришли сюда для того, что-бы Вас "отговаривали", хором скандировали "сырое",
хаяли дилеров? От меня не дождетесь

Нет, найти и выбрать самостоятельно в соответствии с со своим неведомым и отнюдь не всеобъемлющим критерием "поновее" (с февраля 2007? это точно "поновее". А с марта 2006 это как? а С декабря 2005 - это хлам или еще ничего?) Причем поиски PHY "поновее" сопровождаются сетованиями на то, что LPC23xx выпускаемый с прошлого года уж слишком "поновее"

Почему пустыми? Это то что вылезло, учитывая что кристалл свежий вылезти может еще не то.


Конечно. В себе вариться ничего не сварится. Не могу сказать что надеялся что ответит кто-то кто успел поюзать LPC236х, но было бы здорово. Интерфейс внешней памяти ненужен. Дело даже не глюках, а в том что чип новый, приятно было бы услышать что у кого-то что-то на нем уже работает.

Так что насчет RMII? Из поновее, доставаемого и проверенного ?

Прощу прощения, но поновее критерий Ваш также как и продвинутый , потому и прошу НАПРИМЕР



Для меня пока я с ними не работал все новые и одинаково продвинутые
Сказать проще что имели ввиду, чем препираться , а то количесво смеющихся смайликов просто неприличное.

Не успел
Если-бы LPC237x подошел-бы сейчас идеально с запасом на развитие, но с рабочим контроллером шины.
LPC2368 не успеваю поставить по срокам в текущую железку - на все про все этот месяц, а не полгода Пришлось внешний Ethernet вешать (что в общем-то и не смертельно ни по ресурсам ни по цене, ибо голый PHY и MAC+PHY разятся незначительно и если производительность не нужна, то можно считать один черт ) на используемый ныне LPC2138.
Ну и насчет "новый", так новые все время появляются - я с LPC незадумываясь переполз на
"новый" 213x со "старого" 2124 и при первой-же необходимости с 22xx на 24xx переползу.
Подправят 237x буду и его пользовать.

Полгода на все, полный цикл ипытаний включая термокамеру и вибростенд, подготовку РКД и испытния у заказчика. А так реально 1-2 месяца. Радует только то что сейчас идет другой проект а этот можно начать через месяц, поэтому время на подобрать комплектующие, и даже заказать отладочник пока есть.


Кстати а какой MAC+PHY использовали?

Вопрос и недоразумение понял. MII - более старый интерфейс RMII - более новый.
PHY "поновее" RMII имеют. Искать более новый из уже имеющих RMII не надо.
Просто берете ЛЮБОЙ с RMII и все.





В данном случае будет использован Микрочиповский ENC28J60 на SPI. На параллельных шинах - любой из NE2000 клонов.

Кабы ненужен третий UART, можно было бы аналогично поступить, и не морочиться с новым темным пока кристаллом. Программный UART делать или внешний ставить не хочется, при программировании потом гемора больше.
А какой стек портировали на этот SPI MAC-PHY?

На не накручивайте себя "сырой", "темный" .... Обычный кристалл сделанный фирмой выпустившей не один десяток контроллеров. Баги будут, обходы их будут, но скорее всего Вы на баги и не наступите.

Стек к железу обычно относится достаточно опосредовано . Конкретно на этот чип никакой IP стек ставится не будет - там свой протокол на фрейме IEEE 802.3 сделанный в приглядку на IEEE 802.2
Ну а вообще я на "своем" стеке живу - в 90x годах пришлось делать почти с 0, потом большое влияние
Waterloo стек оказал. Отполировался, испытан за прошедшие годы. Нижний уровень "знает" NE2000 и
RTL8139/80xx совместимые чипы и UART/SLIP напрямую или любое железо на PC через "пакетный драйвер". Начинался с 286 12MHz машин, посему вполне нересурсоемок

Бери SAM7x - есть пример для FreeRTOS + можно сварганить под uCOS.

А можно вот эту фразу подробнее расшифровать ?

Попробуйте вопрос задать конкретнее, что не понятно?
Что с конкретным МАС контролером надо по разному работать это понятно? То, что UART/RS232 это вообще не сосем MAC контроллер, TCP/IP никак не зависит от того пакетный или байтовый интерфейс? То, что есть унифицированный программый интерфейс к железу называемый "Packet Driver" и поставляемый производителем железа в одной куче с драйверами под WIndows, Linux, Netware и прочими?

Так то понятно все.
У меня протокол по типу SLIP в другую разработку заложен. Что такое "пакетный драйвер" поставляемый производителем? Я пакетную часть писал сам, может можно какие-то куски если не взять то подсмотреть. А конкретно меня интересует метод передачи пакетов с подтверждением, скользящее окно реализованное в TCP не совсем устраивает - канал очень узкий.

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

Пакетный драйвер ни сном ни духом о верхнем уровне и соответственно о Sliding Windows не знает -
голый доступ к железу.
Спецификация ( для общего развития) в приложении.
Если что-то не устраивает (что не удивительно )в TCP/IP делайте свое специализированное на UDP/IP. Если не нужен глобальный интернет - руки еще более развязываются. Если устроит работа в одном сегменте сети, то вообще можно делать свои простые, компактные, максимально "реалтаймовые" протоколы.