[zuy 0]

Смотри почту

 

Ну если это не секрет, может для всех выложите?

Или на FTP залейте пожалуйста.

[lebiga 0]

Ну если это не секрет, может для всех выложите?

Или на FTP залейте пожалуйста.

 

Выкладываю

Господа, только не обессудьте! Я выкладываю предыдущую рабочую версию моего проекта. Ничего в главном файле c main не удалял. Версия для ИАР, когда-то компилировалась и в Кейле, но там были проблемы с #PRAGMA PACK(1) (еще carm). В новом Кейл МДК этой опции нет, надо везде прописывать __packed.

Главный документ из микрочипа AN833b.pdf

 

Исходники можно найти на микрочипе. Ищите mstkv220401.zip (пик18) предыд версия, есть RTL8019 драйвер. Но скорее всего это файл на вебе уже нет.

 

tcpip stack v3.6.zip(пик18) - добавлен драйвер ENC28J60

 

dsPIC_Stack_v.90.EXE - для dsPIC, интересен более ANSI написанием, добавлены новые функции

 

Могу выложить на FTP - расскажите как

tcpip_microchip_to_arm.rar

[lebiga 0]

Тут посмотрел стек от uIP - был ошарашен сложностью и заумностью формирования веб страниц - какие-то скрипты в виде букв в каждой строчке - да и преобразование в си файл потом - не понимаю, зачем так сложно. В микрочиповском я пишу веб страницу в обыкнованном веб редакторе - в нем и смотрю. Потом ужимается все хтмл файлы совместно в бин и по фтп (или через гипертерминал по сом) отправляю в атмеловскую флешку AT45 и все! Вообще-то ужатие в бин тоже можно переписать и отправлять чистые исходники, но мне влом было разбираться.

 

Особенности переменных, выводимых в веб страницу - начинается с %, типа %12 - нттр во время выдачи страницы при получении % заменяет 12 (12h) на переменную, которую я сам определил - или число, или строку. Если в веб странице надо написать % - я заменяю на % - единственное неудобство, да и то это нужно делать в cgi файлах, html идут так. Да вообще-то смотрите примеры - более информативно. Естественно пример вырезан - остальное коммерчески используется.

web_mchip_to_arm.rar

[zltigo 1]

Выкладываю

Вполне "механический" порт на ARM и так не выдающегося творения Microchip. Сам стек не расматривал, но "драйвер ENC28J60" смотрел пару месяцев назад очень внимательно - произвел неприятное впечатление :(. Стиль написания обсуждать не буду, но практически полное отсутствие обработки нештатных ситуаций "впечатлило" :(. Практически единственное место, где что-то обозначено в этом направлении заканчивается "блестящим" выходом их положения - перезагрузкой!!! контроллера.

А при портировании даже этот фиговый листок был убран :(. При механическом переносе на 32bit платформу не сочли нужным убрать фатальные warnings "Use of address of unaligned structure member" :( Как оно работает???

[lebiga 0]

Вполне "механический" порт на ARM и так не выдающегося творения Microchip. Сам стек не расматривал, но "драйвер ENC28J60" смотрел пару месяцев назад очень внимательно - произвел неприятное впечатление :(. Стиль написания обсуждать не буду, но практически полное отсутствие обработки нештатных ситуаций "впечатлило" :(. Практически единственное место, где что-то обозначено в этом направлении заканчивается "блестящим" выходом их положения - перезагрузкой!!! контроллера.

А при портировании даже этот фиговый листок был убран :(. При механическом переносе на 32bit платформу не сочли нужным убрать фатальные warnings "Use of address of unaligned structure member" :( Как оно работает???

 

Системы эксплуатируются уже год, рестарта из-за ошибок при приеме заголовков не замечал. Use of address of unaligned structure member - работаем с __packed или #pragma pack - все ок. Ничего не мешает перенести обработку некоторых нештатных ситуаций из других драйверов микрочипа или дописать свое. Для меня главное преимущество этого стека - полные исходники и см. пред. сообщение!

lan_driver.rar

Изменено 6 мая, 2007 пользователем lebiga

[zltigo 1]

Системы эксплуатируются уже год, рестарта из-за ошибок при приеме заголовков не замечал.

Естественно. Вы даже его выбросили.

    // Validate the data returned from the ENC28J60.  Random data corruption,
    // such as if a single SPI bit error occurs while communicating or a
    // momentary power glitch could cause this to occur in rare circumstances.
    if(header.NextPacketPointer > RXSTOP || ((BYTE_VAL*)(&header.NextPacketPointer))->bits.b0 ||
       header.StatusVector.bits.Zero ||
       header.StatusVector.bits.CRCError ||
       header.StatusVector.bits.ByteCount > 1518 ||
       !header.StatusVector.bits.ReceiveOk)
    {
;//Reset();
    }

Забыли :)

 

Use of address of unaligned structure member - работаем с __packed или #pragma pack - все ок.

Паковка это из "другой оперы".

Ничего не мешает перенести обработку некоторых нештатных ситуаций из других драйверов микрочипа или дописать свое.

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

Я сейчас тоже буду использовать этот контроллер для быстрой модификации устройства, но информацию о поведении и разрешении проблем приходится добывать или эмпирическим путем, либо обильно стелить соломку :(

[lebiga 0]

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

Я сейчас тоже буду использовать этот контроллер для быстрой модификации устройства, но информацию о поведении и разрешении проблем приходится добывать или эмпирическим путем, либо обильно стелить соломку :(

 

Только что глянул - у микрочипа вышла новая версия 4.02 от 11 апреля. Обработку ошибок так и не сделали, зато добавили вкусностей - TCPPerformanceTest, UDPPerformanceTest, netbios, telnet намного лучше, dns клиент и т.д. Буду разбираться и что-то апгрейдить в своих проектах.

А о соломке - предлагаю обмен информацией, тем более, что у меня есть кому собирать баги при эксплуатации.

[zltigo 1]

Только что глянул - у микрочипа вышла новая версия 4.02 от 11 апреля.

Странно, но я вижу только V3.6

http://www.microchip.com/stellent/idcplg?I...sUserText=28j60

А о соломке - предлагаю обмен информацией, тем более, что у меня есть кому собирать баги при эксплуатации.

Стек меня не интересует в принципе - свой наработан. На баги в эксплуатации я права не имею :). Ну на счет того что получится на железном уровне для 28J60 - подумаю, возможно выложу.

[lebiga 0]

Странно, но я вижу только V3.6

 

http://ww1.microchip.com/downloads/en/Devi...tack%204.02.zip

 

ссылки находятся по поиску документа с ключевым словом TCP

Изменено 6 мая, 2007 пользователем lebiga

[zltigo 1]

Обработку ошибок так и не сделали,

Ну инициализацию подправили для мягких перезагрузок теперь корректнее, баг в MACGetHeader() c порчей текущего банка при одном из выходов неуклюже залатали. Убрали зависание в MACFlush(). Какая-то совершенно дурацкая заплатка в MACGetArry() для указателя на буфер равного 1. C бодуна похоже :( Добавили кучку установок 0 банка. Выкинули тест памяти (наверное догадались его два раза подряд запустить и насладиться результатом). Передатчик стали тупо (вне зависимости от успешности окончания передачи) сбрасывать перед каждой новой активизации передачи - настораживает!

И очень плохое - похерили несколько буферов передачи - типа нет функции - нет проблем :(

Если это действительно у них такая "борьба с багами" при использовании нескольких буферов, то очень тоскливо :(

зато добавили вкусностей....

Лучше-бы "фундамент" не латали, а нормальный сделали: (. Если у них и "вкусности" так написаны, то я лучше на хлебе и воде посижу :)

[lebiga 0]

Ну инициализацию подправили для мягких перезагрузок теперь корректнее, баг в MACGetHeader() c порчей текущего банка при одном из выходов неуклюже залатали. Убрали зависание в MACFlush(). Какая-то совершенно дурацкая заплатка в MACGetArry() для указателя на буфер равного 1. C бодуна похоже :( Добавили кучку установок 0 банка. Выкинули тест памяти (наверное догадались его два раза подряд запустить и насладиться результатом). Передатчик стали тупо (вне зависимости от успешности окончания передачи) сбрасывать перед каждой новой активизации передачи - настораживает!

И очень плохое - похерили несколько буферов передачи - типа нет функции - нет проблем :(

Если это действительно у них такая "борьба с багами" при использовании нескольких буферов, то очень тоскливо :(

 

Лучше-бы "фундамент" не латали, а нормальный сделали: (. Если у них и "вкусности" так написаны, то я лучше на хлебе и воде посижу :)

 

Вот поискал - оказывается народ писал драйвера, причем писал сразу под арм

 

http://www.embeddedrelated.com/groups/lpc2000/show/12049.php

http://hubbard.engr.scu.edu/avr/avrlib/doc...__enc28j60.html

или см файл

enc28j60_driver.zip

[zltigo 1]

Вот поискал - оказывается народ писал драйвера, причем писал сразу под арм

Народ могое что "писал", переписывыал и "выкладывал", только толковое среди всего выкладываемого встречается крайне редко :(. Кто-же хорошее выкладывает :). Ничего удивительного, если даже производители с именем и деньгами обычно выкладывают более чем сомнительного качества исходники :(. Похоже ниша сэмплописательства плотно оккупирована студентами или в лучшем случае восточными программистами. Поискоим информации по 28j60 занимался очень плотно. Из многих зол Микрочиповский "драйвер" пожалуй наименьшее. Большая часть на нем и базируется.

[lebiga 0]

Вот прицепил стек 4.02 микрочипа в свое устройство...

Первое впечатление - работает намного устойчивее 3 версии, http страница от долгого пассивного висения тормозить не начинает. Телнет наворочен слишком, искать пароля и юзера прямо в памяти ENC - долго, а потом освобождать буффер чтением в NULL - плохо(это просто не работает - запись по адресу 0 вызывает abort).

 

Драйвер ENC28J60 более оптимизирован - приемный буффер и передающие на каждый tcp сокет организованы прямо в памяти ENC. Но это привело к тому, что нужно было уменьшить величину передающих буфферов и уменьшить длину строк в телнете.

 

Нашел ошибку, скорее из-за компилятора ИАР, в MCC18 проблем нет(8-бит!)

 

typedef unsigned long DWORD; // 32-bit unsigned

 

из tcpipconfig.h:

#define MAX_TCP_SOCKETS (8ul)

#define TCP_TX_FIFO_SIZE (200ul)

#define TCP_RX_FIFO_SIZE (200ul)

 

из tcp.h:

typedef struct _TCB

{

NODE_INFO remote;

WORD_VAL remotePort;

WORD_VAL localPort;

 

WORD txUnackedTail;

WORD remoteWindow;

DWORD MySEQ;

DWORD RemoteSEQ;

BYTE retryCount;

TICK retryInterval;

SHORT sHoleSize;

WORD wFutureDataSize;

} TCB;

#define RESERVED_TCP_MEMORY ((DWORD)MAX_TCP_SOCKETS*((DWORD) (TCP_TX_FIFO_SIZE+1)+(DWORD)TCP_RX_FIFO_SIZE+(DWORD)sizeof(TCB)))

 

и в mac.h

// MAC RAM definitions

#define RAMSIZE 8192ul

#define TXSTART ((RAMSIZE-1ul) - (1ul+1514ul+7ul) - RESERVED_TCP_MEMORY)

 

Буфферы налазили друг на друга, причина - ошибка вычисления RESERVED_TCP_MEMORY, компилятор иар 4.41, устранил так:

 

#define RESERVED_TCP_MEMORY (MAX_TCP_SOCKETS*( (TCP_TX_FIFO_SIZE+1)+TCP_RX_FIFO_SIZE+sizeof(TCB)))

 

Вот хочу спросить:

для максимальной надежности в системе с http и telnet управлением - лучше работать с пакетами какой длины - 100-200 байт или 1000 байт? Строка get у меня длинная (много параметров) - до 1000 байт.

Если в http используются 2 фрейма - сколько минимум http (а соответственно и tcp) сокетов нужно открыть, чтобы страницы грузились побыстрее. IE6 вроде открывает не более 4х.

FTP требует 2 tcp сокета для управления и данных - это я уже выяснил экспериментально.

[zltigo 1]

#define RESERVED_TCP_MEMORY ((DWORD)MAX_TCP_SOCKETS*((DWORD) (TCP_TX_FIFO_SIZE+1)+(DWORD)TCP_RX_FIFO_SIZE+(DWORD)sizeof(TCB)))

с преобразованиями (DWORD) - дурь однозначная - выбрасываь везде, тем более, что константы UL описаны.

для максимальной надежности в системе с http и telnet управлением - лучше работать с пакетами какой длины - 100-200 байт или 1000 байт?

Что такое 'надежнось' и каков канал связи.... Если это то, что я понимаю, то лучше мелкими.

.. сокетов нужно открыть, чтобы страницы грузились побыстрее.

Думаю открывайте по минимуму, иначе контролер на облуживании сокетов будет слабейшим звеном.

[defunct 0]

Паковка это из "другой оперы".

Паковка из "той оперы", т.к. заменяет все LDR/STR(W) на эквиваленты LDR/STR( B ) в случае невыровнянных полей.