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 для мелких контроллеров не бывает ничего ни эффективного, ни портабельного, тем более для гарварда... :-)