[KRS 0]

с другой стороны, какая ему разница за сколько наносекунд до фронта клоков slave данные выставил.

разница есть! и у первых LPC, правда еще 21xx, в которых появился SSP был баг которы не позволял даже на 30 mhz работать. Там не совсем простая схема т.к. имеется возможность менять конфигурацию фронт и т.п. IMHO с этим связано.

И недавно я про это ограничение забыл и ЕМНИП на LPC1754 влетел, что SSP не работал на 50 MHZ, пришлось на 25 ставить.

 

[_pv 52]

И недавно я про это ограничение забыл и ЕМНИП на LPC1754 влетел, что SSP не работал на 50 MHZ, пришлось на 25 ставить.

ну тогда тем более lpc в топку.

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

в результате поставил блэкфин, и видимо не зря.

[wolfman 0]

если еще актуально, то можно посмотреть в сторону 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

[_pv 52]

если еще актуально, то можно посмотреть в сторону SMSC, например LAN9215:

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

[Rst7 5]

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

 

1. Читать данные с параллельного порта через DMA по внешнему стробу (организовывается через таймер).

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

[wolfman 0]

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

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

 

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

Можно еще использовать DM9000 - он побыстрее, хотя весь стек придется прикручивать снаружи.

выйдет даже дешевле.

 

[_pv 52]

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

я разницы по цене меньше чем в 3 раза не нашел.

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

IP стек всё равно прикручивать.

DM9000, кстати, еще IP/TCP/UDP контрольные суммы считать умеет, а не только езернетные - мелочь, а приятно.

 

 

[kolobok0 0]

...DM9000, кстати, еще IP/TCP/UDP контрольные суммы считать умеет...

 

Вам, как специалисту по DM9000:

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

 

(круглый)

 

[_pv 52]

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

нет, ничего он собирать не умеет.

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

соответственно dm9000 сам посчитает контрольные суммы и заменит их на свои по соотвествующим смещениям.

ну и соответственно так же проверит при приёме.

про фрагментацию точно tcp не скажу - не знаю.

но у фрагментированных пакетов разве не такой же заголовок со своей контрольной суммой на каждый кусок? только оффсет еще указан.

контрольная сумма вроде бы точно также считаться должна, только по фрагменту, не?

[kolobok0 0]

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

 

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

 

ок.

спасибо

(круглый)

 

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

 

удачи вам

(круглый)

Изменено 12 мая, 2012 пользователем kolobok0

[_pv 52]

Либо, Вы перегнули палку и милкосхема не обрабатывает корректно TCP уровень.

сам проверял только работу IP и UDP

в даташите описания CRC нет,

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