разница есть! и у первых LPC, правда еще 21xx, в которых появился SSP был баг которы не позволял даже на 30 mhz работать. Там не совсем простая схема т.к. имеется возможность менять конфигурацию фронт и т.п. IMHO с этим связано.
И недавно я про это ограничение забыл и ЕМНИП на LPC1754 влетел, что SSP не работал на 50 MHZ, пришлось на 25 ставить.

ну тогда тем более lpc в топку.
надо было как-то spi на ~40МГц две штуки да память внешнюю, присматривался к различным АРМам, далеко не во всех так можно было.
в результате поставил блэкфин, и видимо не зря.

если еще актуально, то можно посмотреть в сторону SMSC, например LAN9215:
Highly Efficient Single-Chip 10/100 Ethernet Controller
with HP Auto-MDIX.
Highlights
Optimized for medium performance applications
Efficient architecture with low CPU overhead
Easily interfaces to most 16-bit embedded CPU’s
Integrated PHY with HP Auto-MDIX
Supports audio & video streaming over Ethernet:
multiple standard-definition (SD) MPEG2 streams

чем он лучше уже упомянутых dm9000a и ksz8851, учитывая что он в 3-4 раза дороже их?

Ну для LPC17xx есть два способа.

1. Читать данные с параллельного порта через DMA по внешнему стробу (организовывается через таймер).
2. Использовать I2S. Он в Slave-mode работает до полста мегагерц. Хоть это и не описано в User Manual, но я имею ответ от техподдержки NXP по этому поводу.

dm9000a и ksz8851 их не знаю, т.к не использовал.

LAN9215 имеет, с одной стороны, классический интерфейс адрес/данные, ширина данных 16 бит, с другой стороны готовый Ethernet со встроенным phy. По цене всего лишь в два раза дороже, а учитывая, что выйдет даже дешевле.

я разницы по цене меньше чем в 3 раза не нашел.
по функциональности они все (dm9000, ksz8851 и lan9215) ничем не отличаются, та же асинхронная 8/16 разрядная шина с одной стороны, внутри МАС и phy с другой стороны.
IP стек всё равно прикручивать.
DM9000, кстати, еще IP/TCP/UDP контрольные суммы считать умеет, а не только езернетные - мелочь, а приятно.

Вам, как специалисту по DM9000:
значит ли это что он умеет собирать пакеты на IP уровне? Или считает только не дефрагментированные???

(круглый)

нет, ничего он собирать не умеет.
при посылке можно в него запихать пакет с чем попало вместо контрольной суммы, как для езернетного фрейма, так и для IP/UDP (у последних контрольная сумма от заголовка только считается насколько помню).
соответственно dm9000 сам посчитает контрольные суммы и заменит их на свои по соотвествующим смещениям.
ну и соответственно так же проверит при приёме.
про фрагментацию точно tcp не скажу - не знаю.
но у фрагментированных пакетов разве не такой же заголовок со своей контрольной суммой на каждый кусок? только оффсет еще указан.
контрольная сумма вроде бы точно также считаться должна, только по фрагменту, не?

опс. возможно вы и правы, и говоря о контрольной сумме TCP мы имеем ввиду IP сами пакеты. давно было дело. надо смотреть умные документы а лень матушка.

ок.
спасибо
(круглый)

переборол лень. не совсем в вумные залез. глянул. нет всё таки мне не изменяет память. у TCP своя у IP пакета своя CRC. Т.е. получая разрезанные IP данные Вы не сможете корректно считать TCP. так что... вопрос остался открытым. Либо, Вы перегнули палку и милкосхема не обрабатывает корректно TCP уровень.

удачи вам
(круглый)

Сообщение отредактировал kolobok0 - May 12 2012, 10:26

сам проверял только работу IP и UDP
в даташите описания CRC нет,
есть только регистр с тремя битами для включения генерации CRC, для IP, для UDP, и для TCP. первые два работают нормально, TCP не трогал.