как втянуть данные в ПК?

AK>> вариант СЛИШКОМ очевиден. но сложен. особенно если дела не имел.

AM> Я считал USB посложнее чем ethernet (с USB я тоже дела не имел). Я не AM> прав? тут ИМХО как. USB - штука довольно специфическая. Потому тут ВРОДЕ есть примеры, которые передрать почти целиком. По крайней мере это так выглядит на первый взгляд. A ETH технология используется много лет, из за чего в примерах (если такие найдуться в применении к эхотагу) подразумивается ряд вещей которые типа все заинтересованные лица должны знать. То есть объем информации (в страницах) который надо изучить при работе "с нуля" больше.

AK>> нежелательно использовать корпуса отличные AK>> от DIP или PLCC в панельке. А ETH контроллеры в эти требования не AK>> вписываются.

AM> Боюсь что при таких требованиях выбор сужается почти до нуля...

Поясняю: нежелательно - не требование а пожелание. Если нет вариантов, придется освоить технологию :)

.
Reply to
Andrey Kekalo
Loading thread data ...

Если лень паять микросхемы, у FTDI тоже есть готовые модули с торчащими штырями, причем много разных. Цена вроде почти разумная, а вот кто таскает, не знаю.

Reply to
Andrei Minaev
23-Mar-05 08:51 Olga Nonova wrote to Oleksandr Redchuk:

ON>>> подготовка ON>>> этого пакета перед отправкой через шину-51 или i2c уж точно притормозит ON>>> трафик в среднем раз этак в 20.

OR>> А для mcs51 они и не обещают больших скоростей. Hа сайте есть где-то OR>> табличка - что выходит для нескольких разных процессоров. OR>> А сама шина там хоть и 8-битная, но под 40 мегаБАЙТ/секунду.

ON> Шина-то да, она все могет. А вот контроллер к ней подключенный?

Если мы говорим о характеристиках микросхемы W3100A или модуля IIM7010A - то надо говорить о двух вещах - скорости шины микросхемы и скорости работы внутреннего TCP/IP стека. А дальше - всё в руках разработчика - надо получить высокую среднюю скорость передачи - значит надо ставить быстрый процессор с ПДП. W3100 не виновата, если к ней подключат торомз какой или для ну совсем уж экономии выводов через I2C прицепят.

Если мы говорим о конкретной системе "контроллер + W3100A", то тогда надо выяснять конкретную задачу и среднюю скорость вычислять исходя из скорости интерфейса и скорости обработки данных.

ON> Табличку я видела. Hе поняла условия тестирования. ON> Какой задачей занимался контроллер, ON> подключенный к W3100A? Только заполнением буферов обмена и полингом ON> прерывания от W3100? Loopback test, выложенный на сайте. Контроллер опрашивает состояние приёма, выдёргивает данные во внутреннюю память, тут же пишет их назад в буфер передачи и отправляет в компьютер. Программа в компьютере берёт указанный текстовый файл (к ней сразу приложен файл a.txt, содержащий около мега буквы 'a' :-), отправляет его и принимает назад, показывает скорость. И это достаточно правильный тест, он показывает именно скорость интерфейса. А дальше - по задаче. Если MCS51 будет принимать картинку, фильтровать, выделять объекты и отправлять назад - в итоговой низкой скорости wiznet не виноват :-)

ON> Для тестирования использовался прикладываемый sochet.с? и пользующиеся им loopback-тесты.

ON> Сразу встает вопрос ON> эффективности конкретного компилятора и, отсюда, воспроизводимость ON> представленных в таблице данных. Естественно. Только скорость обмена реально определяется двумя вещами - скоростью работы *прикладной* задачи в контроллере и скорости работы подпрограммы копирования данных в этом socket.c

ON> Если Вы пробовали реальную задачу решать с ON> представленным модулем и AVR, то прошу поделиться данными о достигнутой ON> максимальной скорости потока данных. Пока только socket.c "спортил" и убедился, что нужную мне скорость (отправку данных из моего устройства в комп на скорости около 40 мегабит/сек плюс низкоскоростной двусторонний управляющий канал) я получу. Именно AVR в loopback-тесте показал чуть больше 6 мегабит/с (т.е.

6 мегабит/с из компьютера в ОЗУ AVR плюс столько же назад), после переписывания подпрограммы копирования - около 9. На той тактовой пропускная способность шины AVR - около 23мегабит в секунду (по 11.5 в каждую сторону, если пользоваться логикой теста).

ON> Я в исходниках заметила кристаллозависимые инструкции(макросы?) типа ON> EX0 = 0; С ними как быть? "ой, ну да, конечно". Это место (обработка прерывания и запреты/разрешения) правились на автомате и я про них забыл. Конечно, надо изменить заголовок обработчика прерываний и команды запрета/разрешения.

OR>> Теперь его (socket.c) надо допереписать, чтобы сделать полную ON> Очень интересно. Продукт будет коммерческий?

Какой продукт?

В котором будет стоять IIM7010A? Конечно. Кушать-то хочется, и не мне одному.

Переписанный нормальным образом socket.c и loopback-тесты с сайта? Это не продукт :-), это мелкий эпизод.

p.s. А с чего такой интерес? Ведь на C для мелких контроллеров не бывает ничего ни эффективного, ни портабельного, тем более для гарварда... :-)

Reply to
Oleksandr Redchuk

Hello, Oleksandr! You wrote to "Olga Nonova" snipped-for-privacy@starline.ee on Wed, 23 Mar 2005

21:25:37 +0000 (UTC):

OR> Если мы говорим о характеристиках микросхемы W3100A или модуля OR> IIM7010A - то надо говорить о двух вещах - скорости шины микросхемы OR> и скорости работы внутреннего TCP/IP стека. А дальше - всё в руках OR> разработчика - надо получить высокую среднюю скорость передачи - OR> значит надо ставить быстрый процессор с ПДП. W3100 не виновата, если OR> к ней подключат торомз какой или для ну совсем уж экономии выводов OR> через OR> I2C прицепят.

OR> Если мы говорим о конкретной системе "контроллер + W3100A", то OR> тогда надо выяснять конкретную задачу и среднюю скорость вычислять OR> исходя из скорости интерфейса и скорости обработки данных.

У этой медали есть ещё одна сторона :-). Мне представляется маловероятным чтобы кто-то использовал ethernet в качестве радиального интерфейса. Следовательно, девайс будет занимать только часть полосы, а на остальное найдутся другие желающие.

With best regards, Alexander Derazhne

Reply to
Alexander Derazhne

Здравствуйте, Уважаемый Oleksandr!

Thu Mar 24 2005 00:25, Oleksandr Redchuk wrote to "Olga Nonova":

OR> Если мы говорим о характеристиках микросхемы W3100A или модуля OR> IIM7010A - то надо говорить о двух вещах - скорости шины микросхемы OR> и скорости работы внутреннего TCP/IP стека. А дальше - всё в руках OR> разработчика - надо получить высокую среднюю скорость передачи - значит OR> надо ставить быстрый процессор с ПДП. W3100 не виновата, если к ней OR> подключат торомз какой или для ну совсем уж экономии выводов через OR> I2C прицепят.

Консенсус.

OR> Если мы говорим о конкретной системе "контроллер + W3100A", OR> то тогда надо выяснять конкретную задачу и среднюю скорость OR> вычислять исходя из скорости интерфейса и скорости обработки данных.

[skipped]

ON>> Если Вы пробовали реальную задачу решать с ON>> представленным модулем и AVR, то прошу поделиться данными о достигнутой ON>> максимальной скорости потока данных.

OR> Пока только socket.c "спортил" и убедился, что нужную мне OR> скорость (отправку данных из моего устройства в комп на скорости OR> около 40 мегабит/сек плюс низкоскоростной двусторонний управляющий OR> канал) я получу. OR> Именно AVR в loopback-тесте показал чуть больше 6 мегабит/с (т.е. OR> 6 мегабит/с из компьютера в ОЗУ AVR плюс столько же назад), после OR> переписывания подпрограммы копирования - около 9. Hа той тактовой OR> пропускная способность шины AVR - около 23мегабит в секунду (по 11.5 OR> в каждую сторону, если пользоваться логикой теста).

А если попробовать оптимизировать на ассемблере время передачаи по шине AVR? Дизассемблированный код этого участка в socket.c видели? Есть там резервы?

[skipped]

OR> Переписанный нормальным образом socket.c и loopback-тесты с сайта? OR> Это не продукт :-), это мелкий эпизод.

OR> p.s. А с чего такой интерес? Ведь на C для мелких контроллеров OR> не бывает ничего ни эффективного, ни портабельного, тем более для OR> гарварда... :-)

Интерес вызван новой задачей, в которой должно быть как минимум 100Mb по FTP и низкоскоростной динамический HTTP. Поскольку я раньше работала на AVR, то исследую возможность остаться в этом ряду кристаллов. Однако, все более и более убеждаюсь, что по скоростям никак не пролезть. Придется наверное действительно переходить на что-то 32-битное с DMA и тактом под 100MHz.

Всего Вам Хорошего Ольга

Reply to
Olga Nonova

Здравствуйте, Уважаемый Alexander!

Thu Mar 24 2005 02:19, Alexander Derazhne wrote to Oleksandr Redchuk:

OR>> Если мы говорим о конкретной системе "контроллер + W3100A", то OR>> тогда надо выяснять конкретную задачу и среднюю скорость вычислять OR>> исходя из скорости интерфейса и скорости обработки данных.

AD> У этой медали есть ещё одна сторона :-). Мне представляется AD> маловероятным чтобы кто-то использовал ethernet в качестве радиального AD> интерфейса. Следовательно, девайс будет занимать только часть полосы, а AD> на остальное найдутся другие желающие.

Эта проблема более-менее решабельна с помощью гигабитных свичей. До десяти 100Mb в "звезде" могут работать с таким свичем практически без торможения.

Всего Вам Хорошего Ольга

Reply to
Olga Nonova
23-Mar-05 23:19 Alexander Derazhne wrote to Oleksandr Redchuk:

OR>> Если мы говорим о конкретной системе "контроллер + W3100A", то OR>> тогда надо выяснять конкретную задачу и среднюю скорость вычислять OR>> исходя из скорости интерфейса и скорости обработки данных.

AD> У этой медали есть ещё одна сторона :-). Мне представляется AD> маловероятным чтобы кто-то использовал ethernet в качестве радиального AD> интерфейса. Следовательно, девайс будет занимать только часть полосы, а AD> на остальное найдутся другие желающие.

"Вы будете смеяться", но я полез туда именно с этой целью - "другие желающие" будут сидеть на другой карточке. Мне нужен быстрый канал точка-точка (относительно, 100Mbit ethernet это, вообще говоря, довольно медленный интерфейс :-).

USB2.0 вусмерть не устраивает расстоянием, мне нужно 15-30 метров (Ну ты же знаешь, что 15 метров RS232 - это так, в пределах лаборатории :-), а в соседнюю лабораторию да по кабельным каналам, да чтобы под ногами не валялось - то уже и мало)

На lvds serdes-ах раньше получил 320мегабит на 15 метров, думаю, можно и дальше на такой низкой (минимально возможной для serdes-ов) скорости, но мне для текущей задачи столько не надо, а захватчики такие в PCI - дорого.

Про "прозрачные" удлиннители USB2.0 через UTP-5kat знаю, но это лишние деньги, которые можно было бы потратить, если бы USB2.0 устройство было данностью, но если всё равно на своём конце самому делать - то нет смысла.

wbr,

Reply to
Oleksandr Redchuk
24-Mar-05 14:21 Olga Nonova wrote to Oleksandr Redchuk:

OR>> 6 мегабит/с из компьютера в ОЗУ AVR плюс столько же назад), после OR>> переписывания подпрограммы копирования - около 9. Hа той тактовой OR>> пропускная способность шины AVR - около 23мегабит в секунду (по 11.5 OR>> в каждую сторону, если пользоваться логикой теста).

ON> А если попробовать оптимизировать на ассемблере время передачаи по шине ON> AVR? ON> Дизассемблированный код этого участка в socket.c видели? Есть там ON> резервы? После замены идиотского (даже для случая, когда скорость не волнует)

int i; for(i=0;i<len;++i) *dst++ = *src++;

на развёрнутый цикл (в рассчёте на то, что копироваться всегда будут сотни байт-килобайт)

uint8_t len1 = len % 8;

len /= 8;

while(len1--) *dst++ = *src++;

while(len--) { *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; }

там на ассемблере если и наиграются, то на уревне 1/10 такта в пересчёте на копируемый байт. Учитывая предел 5 тактов на байт (2 во внутреннем плюс 3 во внешнем пространстве) - нет смысла переписывать, скорости это не прибавит.

Reply to
Oleksandr Redchuk

Здравствуйте, Уважаемый Oleksandr!

Fri Mar 25 2005 08:40, Oleksandr Redchuk wrote to "Olga Nonova":

ON>> Дизассемблированный код этого участка в socket.c видели? Есть там ON>> резервы?

OR> После замены идиотского (даже для случая, когда скорость не волнует)

OR> int i; OR> for(i=0;i<len;++i) OR> *dst++ = *src++;

OR> на развёрнутый цикл (в рассчёте на то, что копироваться всегда будут OR> сотни байт-килобайт)

OR> uint8_t len1 = len % 8;

OR> len /= 8;

OR> while(len1--) OR> *dst++ = *src++;

OR> while(len--) OR> { OR> *dst++ = *src++; OR> *dst++ = *src++; OR> *dst++ = *src++; OR> *dst++ = *src++; OR> *dst++ = *src++; OR> *dst++ = *src++; OR> *dst++ = *src++; OR> *dst++ = *src++; OR> }

OR> там на ассемблере если и наиграются, то на уревне 1/10 такта в пересчёте OR> на копируемый байт. Учитывая предел 5 тактов на байт (2 во внутреннем OR> плюс 3 во внешнем пространстве) - нет смысла переписывать, скорости это OR> не прибавит.

Отлично оптимизировано! Только не надо после этого утверждать, мол, переписать готовый socket.c ничего не стоит. Стоит! Вы сами только что это показали. Требуется вдумчивое вникание в исходники и отлов глупостей с багами. Это к вопросу о бузупречности библиотек в исходниках на Си.

Согласитесь, что будь socket написан на ASМе, замеченных Вами глупостей не случилось бы.

Всего Вам Хорошего Ольга

Reply to
Olga Nonova

Hello Olga.

25 Mar 05 10:13, you wrote to Oleksandr Redchuk:

ON> Согласитесь, что будь socket написан на ASМе, замеченных Вами ON> глупостей не случилось бы.

Ага. Они были бы незамечены. ;)

Alexey

Reply to
Alexey Boyko

Hello, Oleksandr! You wrote to "Alexander Derazhne" snipped-for-privacy@i.com.ua> on Thu, 24 Mar 2005

20:24:17 +0000 (UTC):

OR>>> Если мы говорим о конкретной системе "контроллер + W3100A", то OR>>> тогда надо выяснять конкретную задачу и среднюю скорость вычислять OR>>> исходя из скорости интерфейса и скорости обработки данных.

AD>> У этой медали есть ещё одна сторона :-). Мне представляется AD>> маловероятным чтобы кто-то использовал ethernet в качестве AD>> радиального интерфейса. Следовательно, девайс будет занимать только AD>> часть полосы, а на остальное найдутся другие желающие.

OR> "Вы будете смеяться", но я полез туда именно с этой целью - "другие OR> желающие" будут сидеть на другой карточке. OR> Мне нужен быстрый канал точка-точка (относительно, 100Mbit ethernet OR> это, вообще говоря, довольно медленный интерфейс :-).

А тогда зачем, собственно, ip-стек?

OR> USB2.0 вусмерть не устраивает расстоянием, мне нужно 15-30 метров OR> (Ну ты же знаешь, что 15 метров RS232 - это так, в пределах OR> лаборатории :-), а в соседнюю лабораторию да по кабельным каналам, OR> да чтобы под ногами не валялось - то уже и мало)

Нууу... Это смотря на какой скорости. В крайнем случае можно и омодемить оба конца и получить 56К. Ну, не 56К, но во всяком случае не хуже 14400.

OR> На lvds serdes-ах раньше получил 320мегабит на 15 метров, думаю, OR> можно и дальше на такой низкой (минимально возможной для serdes-ов) OR> скорости, но мне для текущей задачи столько не надо, а захватчики OR> такие в PCI - дорого.

А кто такие serdes-ы ?

OR> Про "прозрачные" удлиннители USB2.0 через UTP-5kat знаю, но это OR> лишние деньги, которые можно было бы потратить, если бы USB2.0 OR> устройство было данностью, но если всё равно на своём конце самому OR> делать - то нет смысла.

Может сразу на оптику стоит смотреть? Насколько я понимаю, это сейчас как сетевушка лет 10 тому - не слишком дёшево, но уже не экзотично.

With best regards, Alexander Derazhne

Reply to
Alexander Derazhne
25-Mar-05 07:13 Olga Nonova wrote to Oleksandr Redchuk:

OR>> len /= 8; OR>> while(len1--) OR>> *dst++ = *src++; OR>> while(len--) OR>> { OR>> *dst++ = *src++; OR>> *dst++ = *src++; OR>> *dst++ = *src++;

ON> Отлично оптимизировано! Только не надо после этого утверждать, мол, ON> переписать ON> готовый socket.c ничего не стоит. Стоит! Вы сами только что это показали.

Во-первых, "переписывалось" с Keil/C51 на avr-gcc, данный кусок к этому переписыванию отношения не имеет. Абсолютно.

Во-вторых, это уже оптимизация на скорость. При оптимизации на размер (кто сказал, что бывает нужна оптимизация только на скорость??) тот глупый for надо было бы заменить на простой while(len--) *dst++ = *src++;

ON> Согласитесь, что будь socket написан на ASМе, замеченных Вами глупостей ON> не случилось бы. "ага, щас". А то я не видел чужих исходников на асме. На асме с очень большой вероятностью там было бы

L1: ld r0,X+ st Y+,r0 sbiw r24,1 brne L1

т.е. цикл не был бы развёрнут. Тот, кто об этом задумывается - задумывается независимо от языка. Кто не задумывается - не задумывается также независимо.

Reply to
Oleksandr Redchuk
25-Mar-05 20:21 Alexander Derazhne wrote to Oleksandr Redchuk:

OR>> "Вы будете смеяться", но я полез туда именно с этой целью - "другие OR>> желающие" будут сидеть на другой карточке. OR>> Мне нужен быстрый канал точка-точка (относительно, 100Mbit ethernet OR>> это, вообще говоря, довольно медленный интерфейс :-).

AD> А тогда зачем, собственно, ip-стек? MAC-raw - пакетами кидаться? Можно, конечно, и даже скорость повыше будет, но хочется удобства и стандартизации, по портам развести управление, передачу данных, отладку. Не выдумывать очередной велосипед. Ведь унутре тех raw-пакетов всё равно свои придётся делать. Ну будет на каое-то количество байт меньше заголовок, ну и что? В перспективе всё равно захочется вплоть до уё, пардон, web-интерфейса для сервисников - не лепить же отдельный ком-порт на устройстве для терминалки или не писать же спецсофтину, которая теми своими пакетами достучаться может до настроек внутри устройства. Выигрыш от отказа от стека будет сомнителен, возни меньше не станет, в итоге выйдет что-то нестандартное, с которым ещё придётся нахлебаться.

OR>> На lvds serdes-ах раньше получил 320мегабит на 15 метров, думаю, OR>> можно и дальше на такой низкой (минимально возможной для serdes-ов) OR>> скорости, но мне для текущей задачи столько не надо, а захватчики OR>> такие в PCI - дорого.

AD> А кто такие serdes-ы ? serializer/deserializer. Они разные бывают, я пользуюсь теми, которые FlatLink/CameraLink. DS90CR285/286, sn75lvds82/83 Берут 21 или 28 бит параллельно в темпе от 20 до 60-80MHz и выбрасывают их в 4 или 5 витых пар соответственно, приёмная часть вываливает опять параллельные данные и синхросигнал. мультиплексирование 7:1. ЖКИ-панели большого размера в этом виде получают данные.

21 бит - это RGB 6:6:6 + vsync + hsync + blank :-) 28 - RGB 8:8:8 + vsync + hsync + blank + reserved

OR>> Про "прозрачные" удлиннители USB2.0 через UTP-5kat знаю, но это OR>> лишние деньги, которые можно было бы потратить, если бы USB2.0

AD> Может сразу на оптику стоит смотреть? Стоит, но не сразу. Точнее, *смотреть* стоит сразу, но *делать* надо более простым и быстрым путём.

AD> Насколько я понимаю, это сейчас AD> как сетевушка лет 10 тому - не слишком дёшево, но уже не экзотично. Во-первых, цена не настолько не волнует, чтобы вообще на неё не смотреть. Во-вторых, я сейчас "быстренько-быстренько" сделаю медь, а там напряг спадёт и я "ммедленно-ммедленно" обсмотрю всё.

wbr,

Reply to
Oleksandr Redchuk

Hello, Oleksandr! You wrote to "Alexander Derazhne" snipped-for-privacy@i.com.ua> on Sat, 26 Mar 2005

05:39:15 +0000 (UTC):

OR>>> "Вы будете смеяться", но я полез туда именно с этой целью - OR>>> "другие желающие" будут сидеть на другой карточке. OR>>> Мне нужен быстрый канал точка-точка (относительно, 100Mbit OR>>> ethernet это, вообще говоря, довольно медленный интерфейс :-).

AD>> А тогда зачем, собственно, ip-стек? OR> MAC-raw - пакетами кидаться? Можно, конечно, и даже скорость повыше OR> будет, но хочется удобства и стандартизации, по портам развести OR> управление, передачу данных, отладку. Не выдумывать очередной OR> велосипед. OR> Ведь унутре тех raw-пакетов всё равно свои придётся делать. Ну будет OR> на каое-то количество байт меньше заголовок, ну и что? OR> В перспективе всё равно захочется вплоть до уё, пардон, OR> web-интерфейса для сервисников - не лепить же отдельный ком-порт на OR> устройстве для терминалки или не писать же спецсофтину, которая теми OR> своими пакетами достучаться может до настроек внутри устройства. OR> Выигрыш от отказа от стека будет сомнителен, возни меньше не станет, OR> в итоге выйдет что-то нестандартное, с которым ещё придётся OR> нахлебаться.

Выиграш будет только один - отсутствие игр со стеком. Насколько я понял из контекста - некий покупной девайс может обменяться с 100М сеткой парой пакетов, но не способен обработать их поток при полном использовании полосы, так? Развести пару-тройку потоков можно и по одному байтику-заголовку в пакете, зато куча стекового сервиса оказывается не нужной: соединение радиальное, короткое, роутинга нет - следовательно, никаких коллизий, недоставок, несовпадений контрольных сумм, нарушений последовательности пакетов и т.д. Что касается web-интерфейса, то по опыту - на предидущей работе ARM7 (20МГц/4М ОЗУ + 2М флешки) только этим и занимался. И проблем с организацией такого динамического сервера - выше крыши. Отладка и сопровождение этого средства отладки быстро превратится в отдельный проект. Оно тебе надо? :-)))) Если нет задачи роутить этот интерфейс через инет для удалённого обслуживания/администрирования/обновления, то сервисный DB9 - самое оно, IMHO. Кстати, в упомянутом устройстве без него также не обходилось (ну никак). Т.е. вэб вэбом, а RS232 рулит :-))).

AD>> А кто такие serdes-ы ? OR> serializer/deserializer. OR> Они разные бывают, я пользуюсь теми, которые FlatLink/CameraLink. OR> DS90CR285/286, sn75lvds82/83 OR> Берут 21 или 28 бит параллельно в темпе от 20 до 60-80MHz и OR> выбрасывают их в 4 или 5 витых пар соответственно, приёмная часть OR> вываливает опять параллельные данные и синхросигнал. OR> мультиплексирование 7:1. OR> ЖКИ-панели большого размера в этом виде получают данные. OR> 21 бит - это RGB 6:6:6 + vsync + hsync + blank :-) OR> 28 - RGB 8:8:8 + vsync + hsync + blank + reserved

Ага. Сенкс, буду знать, что такое бывает.

With best regards, Alexander Derazhne

Reply to
Alexander Derazhne

Olga, ты ещё здесь сидишь?

Пятница Март 25 2005 10:13, Olga Nonova wrote to Oleksandr Redchuk:

ON> Отлично оптимизировано! Только не надо после этого утверждать, мол, ON> переписать готовый socket.c ничего не стоит. Стоит! Вы сами только что ON> это показали. Требуется вдумчивое вникание в исходники и отлов ON> глупостей с багами.

Это вопрос качества документации, в частности комментариев в исходнике. Разумных комментариев нет - автор почти наверняка ваял халтуру...

ON> Согласитесь, что будь socket написан на ASМе, замеченных Вами ON> глупостей не случилось бы.

Лихо! ;)))

Георгий

Reply to
George Shepelev

Здравствуйте, Уважаемый George!

Sun Mar 27 2005 00:34, George Shepelev wrote to Olga Nonova:

ON>> Отлично оптимизировано! Только не надо после этого утверждать, мол, ON>> переписать готовый socket.c ничего не стоит. Стоит! Вы сами только что ON>> это показали. Требуется вдумчивое вникание в исходники и отлов ON>> глупостей с багами.

GS> Это вопрос качества документации, в частности комментариев в исходнике. GS> Разумных комментариев нет - автор почти наверняка ваял халтуру...

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

ON>> Согласитесь, что будь socket написан на ASМе, замеченных Вами ON>> глупостей не случилось бы.

GS> Лихо! ;)))

Конечно не случилось бы. Ассемблерщик, по натуре,- экономный и очень практичный человек. Он не даст себя увлечь "академическими фантазиями". Поэтому все получается максимально эффективно по компактности и быстродействию.

Всего Вам Хорошего Ольга

Reply to
Olga Nonova

Hello Andrey!

21 Mar 05 20:09, you wrote to All:

AK> Есть задача несколько офтопичная - нужно обеспечить обмен с ПК со AK> скоростью 200-250кбайт\сек полный дуплекс, не сильно загружая AK> процессор ПК (он эти данные обрабатывать должен на лету). Каким Если тебя устроит 120 кбайт/сек, то это предельная паспортная частота чипа, на котором собран USB шнур от сотика. Чип называется PL2303. В противном случае, тебе придется делать ECP, а у него с дуплексом полный нуль. AK> IDE - вариант, но как сделать стандартное IDE устройство? Разбираться AK> длинно. может пример есть где? Hичего сложного. IDE это огрызок ISA шины, не более того. Грабли в другом: отдельные биосы, не обнаружив положенный по стандарту дивайс, вообще отрубают интерфейс (Либо сбрасывают его в PIO-0). Возможно, что рулить интерфейсом после этого придется ручками, согласно даташиту от мамы.

AK> USB - как я понимаю загрзка проца ПК высокая. Или нет? может у кого AK> данные есть? Он идет через DMA.

AK> ECP/EPP - ИМХО самый приятный вариант. Тока опять же нормальное AK> опписание на AK> ECP+DMA найти не получается. Может кто носом ткнет.Да, а как там с AK> дуплексом? С дуплексом никак. Описание существует отдельно на ECP и отдельно на DMA. И, конечно, отдельно на чипсет.

Anatoly

Reply to
Anatoly Mashanov
26-Mar-05 19:35 Alexander Derazhne wrote to Oleksandr Redchuk:

AD>>> А тогда зачем, собственно, ip-стек? OR>> MAC-raw - пакетами кидаться? Можно, конечно, и даже скорость повыше OR>> будет, но хочется удобства и стандартизации, по портам развести OR>> управление, передачу данных, отладку. Не выдумывать очередной OR>> велосипед.

AD> Выиграш будет только один - отсутствие игр со стеком. Насколько я понял AD> из контекста - некий покупной девайс может обменяться с 100М сеткой AD> парой AD> пакетов, но не способен обработать их поток при полном использовании AD> полосы, Некий мой (даже не мой, я его только причесал лет 5-6 назад, довёл до запускаемсти/работоспособности без разработчика :-) девайс вообще ничего не слышал про 100M сетку. Девайс умеет по RS232 получать команды и отвечать на них и по IDE-шнурку отдавать данные (монопольно и тупо - не как ATAPI устройство, а как просто регистры с адреса такого-то). В нём внутри нет ресурсов ни на ATAPI-устройство, ни на что другое. Теперь прошёл некий круговорот в природе и я вернулся к этому изделию. Сейчас нужно, чтобы он и не знал ничего про сетку - сделать ему "гейт". В следующих устройствах (даже не в следующих поколениях этого, это так и умрёт) поддержка сетки должна быть уже встроенная и не факт, что на WizNet вообще - это будет обдумываться.

AD> Развести пару-тройку потоков можно и по одному байтику-заголовку в AD> пакете, зато куча стекового сервиса оказывается не нужной: соединение А потом мне скажут поцепть несколько таких на один комп. А потом окажется, что надо предоставлять устройство в OEM-версии, так сказать, и потенциальный покупатель будет писать основной софт сам и неизвестно где и как. И всё равно попросят "что-то стандартное" (Кстати, какой-нибудь winsock даёт лазить на таком низком уровне? Надо в MSDN глянуть...). А уже сейчас в "небоевом" варианте, не на объекте, а при отладке/экспериментах (когда высокая скорость не так и нужна) было бы удобно просто подключить это дело в офисную сетку и по очереди лазить туда то мне, то разработчику основного софта. Да, на нижнем уровне можно организовать закат солнца вручную, но мне показалось, что проще сразу сказать "а, IP-сь оно всё в порт".

AD> Что касается web-интерфейса, то по опыту - на предидущей работе ARM7 AD> средства отладки быстро превратится в отдельный проект. Оно тебе надо? AD> :-)))) Если нет задачи роутить этот интерфейс через инет для удалённого AD> обслуживания/администрирования/обновления, А призрак этого бродит вокруг (до фраз "какого фига до сих пор это невозможно" дело ещё не дошло, но...).

wbr,

Reply to
Oleksandr Redchuk

Olga, ты ещё здесь сидишь?

Воскресенье Март 27 2005 10:23, Olga Nonova wrote to George Shepelev:

ON>>> Отлично оптимизировано! Только не надо после этого утверждать, ON>>> мол, переписать готовый socket.c ничего не стоит. Стоит! Вы сами ON>>> только что это показали. Требуется вдумчивое вникание в ON>>> исходники и отлов глупостей с багами. GS>> Это вопрос качества документации, в частности комментариев в GS>> исходнике. Разумных комментариев нет - автор почти наверняка ваял GS>> халтуру... ON> В данном случае дело было не в документации и не в комментариях,

Hу да, комментариев просто не было ;)

ON> а в обычном для сишников "академическом" подходе к программированию.

Это всё-таки лучше, чем ваять по принципу "лишь бы хоть как-то заработало".

ON> Там авторы написали фрагмент программы теоритически верно, но жутко ON> неэффективно по быстродействию. А скорость, в вопросе связных задач,- ON> одна из главных вещей.

Это нормально. Для достаточно сложных задач я сам частенько сперва делаю "академическую" версию софта, которая обязана работать без ошибок. И потом использую её для проверки результатов оптимизированных версий на этапе отладки. Просто у некоторых халтурщиков до оптимизации не доходит. "Сдать и забыть". Hедовольным юзерам втюхивается идея, что компьютеры-де становятся всё быстрее... :-/

ON>>> Согласитесь, что будь socket написан на ASМе, замеченных Вами ON>>> глупостей не случилось бы. GS>> Лихо! ;))) ON> Конечно не случилось бы.

Вы рановато начали отмечать 1 апреля ;)

ON> Ассемблерщик, по натуре,- экономный и очень практичный человек.

Странно, многие программеры именно из соображений "экономии и практичности" переходят на C.

ON> Он не даст себя увлечь "академическими фантазиями". Поэтому все ON> получается максимально эффективно по компактности и быстродействию.

Если человек не разбирается в базовых ("академических") принципах программирования, работает другой принцип - сварганенная на ассемблере поделка не работает либо делает совсем не то, что надо ;-) А глупости можно написать на любом языке, в том числе и на естественном...

Георгий

Reply to
George Shepelev

Winsock вроде не должен по определению. Он открывает сокеты - это порождение сетевого уровня. Копаться в канальном уровне позволяет, например, NDIS.

И вообще,

formatting link
позволит начать копаться, не забивая голову деталями спецификации NDIS и сакральными знаниями про "драйвер минипорта".

Однозначно. Трудно представить себе аргументы против использования IP.

Reply to
Andrei Minaev

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.