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

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

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

ИМХО, если нужна большая производительность - выбирайте NXP. Раньше у них была менее удобная периферия, но сейчас положение исправляется.
Я бы взял NXP.

А с портом оси проблем не возникнет?

Так хорошо, что выбор есть.

2238 в природе не существует, ну а периферия естественно, или аналогична, или преемственна с LPC213x

Преемственность по некоторой отработанной периферии у LPC тянется аж с С51, errata давным давно лежит на сайте - что значит "не удалось взять"?

Для LPC21хх тоже есть "пример" - не лучше и не хуже.

Да.

На сайте NXP - The page you requested is not available. Как это понимать незнаю.


А переточить на встроенный EMAC сложно будет? С Ethernet первая разработка.

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

Как показывает опыт, документы на сайте NXP лучше искать гуглем


Нет, не сложно.

Да???
http://www.standardics.nxp.com/products/mc...etric/~LPC2378/

Да нет, пожалуй. Это удивительно :
http://www.mt-system.ru/price.search.mt?ke...e=2&size=50
На складе. Бери - не хочу.

Вообщем все упирается в доступность кристаллов. Самый гнусный вопрос.
Интересно появятся ли LPC23хх в ближайщий месяц?????


очень удобно
Поиск по самому NXP помог, там все имена у них попутаны.
Кстати если параметрика заходить тоже правильно. А если со страницы 2368 то имя ерраты другое.

Что-то еррата на 2368 подозрительно и непривычно скудная
На 2214 и 2138 куда обильнее было

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


Правят, значит. Фатальная ошибка в errata одна, да и то не на LPC2368.

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

А чем черевато что LPC поддерживает только RMII, MII не поддерживается судя по еррате?

Немного меньше будет выбор подходящих PHY, только и всего.

Ничего себе "удобство" - нет и когда будет не знаем. Удобно!? Начинайте работать так, как действительно удобно.

Купите более продвинутый PHY из поновее c RMII и все.

Да нет тут проблем, если комплектация в России через диллеров доступна в принципе, то всегда поставляют без разговоров.


А например какие?
В принципе насколько я понимаю в RMII обмен по паре бит, а MII по 4-бита. Вообщем разводить меньше это хорошо.

Доступна, поставляют, о чем плач?


Возьмите схему Evalution Board от ARM/Keil, например.
Поиск по PHY RMII Transceiver в интернете сделать слабо?
Или сразу в, например, efind.ru по RMII?

Я же спросил - а НАПРИМЕР, из поновее. Или мне чтобы совет получить надо все PHY сначала перечислить которые найду? Ну MICREL вроде рекламмируют из поновеее. Как? C Atmel я на 8201 хотел делать, но там MII.

А поиск по NXP и такие вещи дает
http://electronix.ru/forum/lofiversion/index.php/t22415.html
почитаешь - сырое все абсолютно.

Например, 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. Если не нужен глобальный интернет - руки еще более развязываются. Если устроит работа в одном сегменте сети, то вообще можно делать свои простые, компактные, максимально "реалтаймовые" протоколы.

А где можно глянуть примеры таких протоколов?

Каких "таких"?
Если речь идет о UDP надстройках, то там вроде все достаточно явно под себя любимого делается,
естественно перед этим следует ознакомится с TCP, как "венце" абстактного протокола передачи
абстракных данных.
Возможно какие-то реализации/улучшения и существуют, но я и не искал особо - просто делал свое в меру разумения.
Если речь идет о полной самоделке на голом Ethernet фрейме, то я подумаю, может выложу краткое описание своего, если интересно.

Спасибо.


Я так и поступил, но кое чего не нравится, кое что необходимо переделать. Поэтому прежде чем браться все ломать, хочу подсмотреть как делается у других. Надо добиться "гарантированной" доставки пакетов, с минимумом затрат трафика. Сейчас это уже реализовано, по типу "скользящего окна" только немного хитрее - окно не просто скользит но и может распадаться, но не все устраивает. Эти функции возложены на прикладной софт ЭВМ, тогда как хочется нагрузить ими свое железо, не думая в прикладной задаче о доставке вообще.


Конечно.

Бегло посмотрел.
"...recommend that the upper-layer protocols invoke lock-step flow control to
avoid packet loss."
А вот где подсмотерть разные реализации flow control, я хочу затолкать этот уровень в железку.

О "голом" фрейме. Про UDP знаю немного, некоторые рекомендуют на нем организовывать SNMP. Свою самоделку интересно было бы посмотреть, но интересно также чего предлагают широкодоступного.