Я някой който ползва това чудо на техниката производство на Wiznet.
До колко загрява чипа при теб?
Защото аз съм пуснал един такъв, но имам малко ядове с него. От време на време си забравя всичките настройки, все едно е ресетнат, но проблеми с ресет-а няма.
Прави ми впечатление, че загрява доста около 60-70 градуса на корпуса.

В интерес на истината чипа W5100 си грее,но тази температура е нормална за него.При мен не е правил проблеми да си забравя настройките.Не знам как го управляваш ,при мен е по SPI.Имах проблеми един път с ресета,който бях забравил да опроводя на платката и не искаше да тръгва всеки път ,забиваше още при старта,но когато му сложих RC групата на ресета всичко се оправи.Друг проблем който имах е дългите проводници на SPI ,не работеше устойчиво и с дебъгера го хванах че процесора отваря сокет, и той се затваря и така в безкраен цикъл.Ако не бях проиграл същия софт на предната платка щях да се хвана в него,но после го хванах че е от SPI-ая .Ако и при теб е така ти препоръчвам максимално къси писти за SPI.Най много съм пробвал до два едновременно отворени сокета единия беше за UDP,a другия за HTTP.Пробвали сме да го тормозим с колегата ,едновременно от два компютъра единия постоянно дърпаше един доста тежичък сайт записан във флаша на контролера на който имаше 4 снимки в jpeg и др, графични обекти,общо взето една АТМЕГА128 беше пълна догоре,а другият с един UDP terminal му пращаше стрингови команди да щрака разни релета .Не сме успяли да го шашнем и да забие.Тествал съм го да работи денонощно и не ми е забивал.Все пак не казвам че някога не е имало случай да забие ,но при мен това е било от разни хвърчащи монтажи или пипане на платката по време на работа.Тъй като виждам че греенето те притеснява остави край него повече място на платката за да има добра конвекция,освен това ако е затворен в някаква малка кутия без отвори също не е желателно.Спазил ли си аналогови и цифрови маси,трябва да са разделени с дросел,как ти е филтрацията на захранването ,искат се по дебели писти все пак консумацията е около 130ма.Ако има нещо друго, което можем да обсъдим относно този чип съм насреща,явно сме само двамата от форума, които са го ползвали явно защото е доста нов чип от 2006г. или колегите просто залагат на класиката, която предлагат Olimex.Аз си мисля че е един доста добър избор като цена(4,5$) и възможности все пак това е напълно хардуерeн TCP/IP стек ,интегриран MAC и PHY и поддържа
два интерфейса за управление паралелен и SPI.От контролера не се изисква толкова много за разлика от софтуерния TCP/IP стек.Общо взето конфигурираш регистри и четеш и пишеш в RAM буфера .Играх си с Микрочипското ENC и съм разочарован тотално,особено от ератите с хиляди бъгове.

tgi,
Мисля че няма да ми трябва PPP. Само TCP и DHCP (и UDP заради DHCP-то). Ще ги ползвам както каза- като пайп (като уарт канал).

Mиро,
И аз от четенето до момента се спрях на lwIP ( http://savannah.nongnu.org/projects/lwip ).
Интересно ще ми е да ми кажеш какви проблеми си хванал с него. Luminari го предлагат с техният пакет.

Мисля си, че най-добре ще е устройството да не изисква никакви настройки на рутерите, свичовете или хъбовете на мрежата в която ще се включи. Т.е. инсталатора единственно да го плъгне и то само да се самоконфигурира. т.е. инсталатора да няма нужда да има каквато и да било квалификация за да го подкара. IP адреса и порта на сървъра с който устройството ще си комуникира ще са зададени преди инсталацията(примерно от локална клавиатура или както казваш орез WEB интерфейс). Инсталацията трябва да е елементарна.

Не мисля, че времето което си отделил за "луд развой" да пишеш и портваш РТОС и стекове за АРМ7 е било напразно. В крайна сметка идеята е да реюзваме тестван и проверен софтуер. РТОС-а и стека са много малка част от софтуера на приложението което правиш.Нещо повече - те са относително "стандартизирани". Базовите функции и функционалност на всичките РТОС-и са идентични.
Примерно утре се появява нов процесор - по-евтин и по-добър, или пък сегашният който ползваш го спират от производство - би било чудесно ако можеш приложението ти почти без усилия (или с минимални такива) да по подкараш върху новата платформа.

Ако си си портвал, модифицирал и къстъмизирал примерно TCP стека за АРМ7 - то не виждам защо да не го използваш и с друг процесор - примерно АРМ9 или какъвто и да било (стига да има необходимата ти функционалност).

Лично аз винаги предпочитам да ползвам мой софтуер (библиотеки) в проектите си. Имам проблем в ровенето, разчитането и разбирането на чужди програми (да не говорим за зле документираните и тези с оскъдни коментари). Искам точно да знам как ми работят програмите, а не да ползвам кодови модули като "черна кутия" ... Е- човек не може да да си напише всичко сам, но няма лошо да се опитва да се стреми да го прави полека-лека...

relsys,
Устройството което визираш е супер, само дето страда от сериозен недостатък - само 10MB е и трябва ръчно да сетнеш порта на суитча или хъба да е на 10мБ. Това лично мене не ме кефи. Микрочип нямат (до колкото знам) 10/100МБ , а имат само 10МБ етернет решения.
Другото което не ме кефи е, че на пик 18 (заради архитектурата му) няма как да пуснеш читава РТОС, която да е преемптив. На времето преди 4 год. и аз като "горд пикоборец" портвах и къстъмизирах един кърнел за пик 18 позволяваш преепмтив превклучване на контекста. Тръгна, ама не е работа. Да не говориме, как стои въпроса с плаващата математика поддържана от компилатора ... Оказа се, че тя не е реентрантна в компилатора на микрочип. Като изключим математиката - компилатора може да го накараш да генерира реентрантен код ...
Иначе продължаваме да ползваме пикове в нашите проекти, но ги ползваме като "щтракалки. За сериозните устройства ползваме сериозни процесори.

Новите серии на микрочип - примерно пик24 вече приличат на "истински" процесори, но пък при наличието на толкова други - може би единственно цената им би ме накарало да ги използвам в бъдещи проекти... знам ли ...

аз не бих разчитал на нищо, което в нормални условия е на 70С

Значи аз нямам чак такъв опит с lwIP, борехме само няколко проблемчета на нещо павено с това. Всъщност повечето от проблемите се оказаха че не са в самия стек. Примерно, съвсем нормално е за такъв стек по подразбиране да ползва малки прозорци... Но така трансферът е страшно бавен - пакетче по пакетче, ужас... Но това се оправя лесно с sockopt увеличаваш буфера на >10К (стига да имаш памет).
Единствено един таймоути май бяха при отваряне на сокет не можахме да оправим. Всъщност оправихме ги като изключихме DHCP-то ама то такова оправяне... Мисля си че причината беше някъде из стека, но така и не я открих и може би затова съм го запомнил с лошо. Иначе доколкото знам е едно от най-добрите решения за малки системки (не че аз имам опит с други та да сравнявам)...
Сетих се - и с приоритетите имаше проблем. Не видях начин да нацепя стека части, а пък приложението управляваше някакъв хардуер който си искаше време на реакция. Ако сложиш по-нисък приоритет на приложението стека бачка, обачка хардуера умира. Или обратно... А пък проблемът е че стекът понякога отнема страшно много CPU, затова нямаше как да бъде с висок приоритет.



Мда... от ARM7 на ARM9 мога да мина почти без да пипам софта. Въпросът обаче е че няма смисъл, щото в моя ОС имам драйвер само за един дисплей и постно GUI, а ако мина на АРМ9 по-добре да подкарам нещо от сорта на Линукс примерно с TFT тъч скрийн и всички екстри. С две думи моите неща нямат бъдеще за съжаление...
Нямам TCP стек, иначе бих ти го предложил като решение
Виж за GSM имам драйвери и някакво що-годе прилично решение, макар че щеше да е много по-читово ако добавя и CMUX, за да подкарам и повече от един сокет щото на мен ми трябват... Но все няма време и я карам само с един сокет. Всъщност приложението ми симисли че работи с много сокети, само дето вътрешно в стека ми ги отварям/затварям постоянно, така че към gsm-a имам само 1 отворен.
От моите неща щеше да има смисъл, ако не беше излязъл Кортекс. Той е доста различен софтуерно и ще ми отвори много работа, а пък за мен това няма никакъв смисъл, щото нищо не печеля от прехода ARM7->Кортекс (M3/M0).


Така де, lwIP е прилично решение, въпросът РТОС-а кво мислиш, според минимума трябва да ти е нещо от сорта на eCos, ама тва на Кортекс с 64К RAM е несериозно....

Относно RTOS-a мисля като за начало да използвам тази на Кеил. Има сорс кодове, а и имаме известен опит с нея на АРМ7.
Икономична е от към РАМ. Самата тя не използва много рам за системни нужди заедно със сист. стек. (под 1кБ). Вече за юзърските стекове на тасковете - зависи от тасковете ...
За интер-таск комуникация като мемори пулове и т.н. - зависи от приложението пак.
От към РОМ е под 4-8кБ. зависи какво използваш от нея.
Има порт за Кортекс, в който все още чистят разни бъгове, но може към момента да се "стъпи" на нея мисля...
Освен това КЕИЛ средата поддържа разни глезотийки от рода да разглеждаш стекове на тасковете, състояния на тасковете, мем.пуловете, MSG боксовете и т.н.

Е, рано или късно ще "мигрирам към нещо фри, или пък ще къстъмизирам КЕИЛ-ската за да се компилира с GCC.

Преходът към GCC e въпрос на време и търпение
Аз нямам спомени що за ОС имат Кейл, но щом имате сорс+опит и бачка с lwIP - няма кво да го мислиш... Отложи мигрирането за някой друг път

Както и аз смятам да мигрирам към Кортекс, ама ... Само за мен няма смисъл, може би ако сме повече хора и стъпим на обща опън сорс платформа да менкаме едно-друго, но и това са небивалици...

Миро,
не мисля че са небивалици. Средата (компилатор + IDE), операционната система, стека и GUI-то мисля че са малко или много "стандартни" неща и всеки един от нас като юзър малко или много ги използва на готово. Т.е. всеки един от нас няма така да се каже някакво ноу-хау което да е вложил в тях. Може би единственно това - да ги подкара.
Ноу-хауто на всеки един от нас мисля че е в приложението, коету създава върху РТОС-а, GUI-то и стека.
Та в този смисъл не виждам никаква причина да не обменяме сорсове и опит свързани с подкарването на компилатор, IDE, RTOS, GUI и TCP/IP стек например. Готов съм да опитаме нещо такова. Никога до сега не съм го правил, но все някога има първи път, нали ?

Веднага мога да ви кажа, че поне с РТОС-а няма да се получи съвместна дейност. Поне до колкото познавам Миро (от форума), той ще иска РТОС които има максимален контрол върху всичко - напр. хардуера задължително през драйвери и интерфейси. Аз пък например в повечето случай от РТОС искам просто да превключва за отрицателно време, да заема няколко байта и да не ми се бърка по никакъв начин в хардуера

Не се обезкуражавайте де. От мен - събрано и работещо GCC+Eclipse+GDB за Кортекс Иначе и на мен ми предстои пускане на стек върху кортекс, ама аз пак ще търся нещо което просто да отвори един сокет и да работи стабилно. И да заема отрицателно количество ресурси.

Цецо,
аз имам същата представа за РТОС-а и за стека.

Относно драйверите - те са съвкупност от прекъсвания и таскове. (дали тасковете ще ги наречем системни или не - въпрос на интерпретация ...)

Примерно драйвер за ЕЕПРОМ - съвкупност от таск с ппределен приоритет (според приложението) и функция обработваща прекъсване. Таска приема в пошенската си кутия заявката за запис в еепрома (заявката съдържа адресав еепром-а, броя байтове за запис, данните които ще се записват , както и номера на таск-а на който да се върне информация как е изпълнена заявката). Таск-а инициализира SPI-я и зарежда в еепром-а данните. Стартира записа и разрешава прекъсване по ЕЕПРОМ, с което ЕЕПРОМ-а съобщава когато е бизи/реди. След това ЕЕПРОм таска се приспива на евент флаг. Когато записа в ЕЕПРОМ-а завърши - той ще установи сигнала си реди/бизи, което ще предизвика прекъсване. Процесоре в прекъсването единственно ще сетне евент флаг-а, на който е приспан ЕЕПРОМ таск-а и ще излезе от прекъсване. Когато РТОС-а види, че има условие да събуди ЕЕПРОМ таск-а - той ще бъде събуден и ще върне информация за еепром операцията на указаният таск. (тука не съм разгледал случаите когато има шерване на ресурс (примерно SPI между ЕЕПРОМ и друго устройство), както и обработките на ТАЙМ-АУТ на операция).

Т.е. организацията на драйверите не мисля, че е кой-знае колко сложно - така че всеки си ги пише или портва сам ( зависят от конкретното приложение и процесор ).

И аз смятам, че РТОС-а трябва просто да превключва за отрицателно време, да заема минимална памет (РАМ/РОМ) и да не ми се бърка по никакъв начин в хардуера ...

Миро, ти какво ще кажеш?

> Относно драйверите - те са съвкупност от прекъсвания и таскове. (дали тасковете ще ги наречем системни или
> не - въпрос на интерпретация ...)

Не е непременно само въпрос на интерпретация. Една от възможните интерпретации е, че системните таскове
вървят в супервайзорен режим, а останалите - не; това е функционална разлика.

> Примерно драйвер за ЕЕПРОМ - .....

Описанието ти звучи съвсем смислено. Е, в някои ситуации е възможно таскът, дето пипа директно
хардуера, да не бъде приспиван, а направо убиван и пускан при нужда - ако има някаква файда от това (което
не е непременно така, де).
Но в крайна сметка това, което приложението би видяло в истинска ОС, би било устройство (или "файл",
едно ниво по-нагоре), в което може да пише байтове на определен офсет. Колко трае това и как става
физически остава "скрито" в device driver-а.

> Т.е. организацията на драйверите не мисля, че е кой-знае колко сложно - така че всеки си ги пише или портва сам
> ( зависят от конкретното приложение и процесор ).

За сложно не е сложно. Но е дяволски важно каква организация ще изгради човек в *началото*,
защото му предстои да живее в тая обстановка занапред.

> И аз смятам, че РТОС-а трябва просто да превключва за отрицателно време,
> ...

Времето за превключване да е малко е хубаво, но далеч не е толкова интересно (а и няма толкова
много различни начина да го направи човек).
Това, което е истински важно - и което много малко системи правят грамотно - е колко IRQ латентност
добавя превключването на таскове, т.е. колко време държи маскирани прекъсванията.
Останалото са подробности.

> да заема минимална памет (РАМ/РОМ) и да не ми се бърка по никакъв начин в хардуера ...

За паметта верността е очевидна, за "никакъв" начин чак няма как, но с перифериите
scheduler-ът наистина няма работа. Свястно написаните ОС ти дават възможност да правиш
всичко, каквото ти трябва в рамките на съответен device driver или (в по-модерен вариант)
в рамките на някакъв специално написан обект, ако системата поддържа динамична структура
от обекти.

Ми представата за драйверите е малко по различна при Миро. Поне аз с такова впечатление съм останал. То по принцип и така трябва да бъде де. Драйвера не е просто високопреоритетен таск. Драйвера трябва да работи на ниво кернел, че и по високо. Въобще когато се правят драйвери, се изискват познания върху самия кернел. Та идеята на миро е че на юзера не му трябва да пише драйвера - той го ползва. В това естествено има много логика.

Обаче. Аз общо взето гледам да деля проекти, сметалки и всичко останало на минимално разклонения. Т.е. за мен RTOS са два вида - прости и сложни Проста е например FreeRTOS. Сложна е linux. Същото е и с сметалките. Прост е кортекса, както и всичко което ползва ресурси под общ похлупак. Сложно е всичко дето има памет на външна шина. От тук - просто правило: за прости проекти - проста RTOS, прост процесор. За сложни - тури си ARM9, тури лайнукс и да ти е мирна главата. Като ползвам това делене, при мен не съществуват проблеми от типа - прост контролер със сложна RTOS. Или RTOS която е проста ама не съвсем.

Та мисълта на това лирическо отклонение е че аз затова не ща да чувам за драйвери при РТОС пусната върху Кортекс. Там ми стига да има нещо да щрака тасковете, някой и друг семафор, месидж и лок механизъм и толкоз. За какво са ми драйвери - съвременните контролери имат по 2-3 SPI, 2-3 UART-а. Закачаш всичко на отделни шини и така....Гледам никакви споделяния на хардуерни ресурси да няма и ми е мирна главата.
Докато Миро има малко по друг мироглед относно RTOS-ите.

нормално

> ... Въобще когато се правят драйвери, се изискват познания върху самия кернел.

Не особено големи - ако системата е добре организирана.

За да напишеш драйвер за DPS (просто давам пример с това, което знам), трябва
да напишеш само:
- как от устройството се четат N байта на адрес M,
- как към устройството се пишат N байта от адрес M,
- как се проверява колко байта има за четене от устройството,
- как се четат/задават параметри към устройството.

Това, което трябва да знаеш от системата (освен формата на десктриптора и
това, че N е в D1, M в А0 и т.н. известни детайли), е, че когато чакаш някакво
събитие в цикъл вместо да се въртиш и да я държиш изцяло трябва да
изпълняваш xtask$ (или някоя от немалкото вариации, добре, те искат малко
повече познаване, но и без тях може а и то не е толкова много), та да превключи
scheduler-ът към друг таск за известно време.

Трябва и да знаеш как да върнеш статус, но и това е нищожно като
обем знания.

Да - относно времето за реакция на прекъсване сте абсолютно прави, че трябва да е малко. Но от какво зависи то ? От това колко време прекъсванията са забранени например, когато се изпълняват системни заявки към РТОС. Обикновенно вътре при обработката на тези системни заявки - прекъсванията се забраняват. Примерно при взимане на мемори блок от РТОС - функцията за заделяне на памет държи прекъсванията забранени докъто се изпълнява. т.е. по времето на критичната и секция.

Е, ако процесора поддържа хардуерно приоритети на прекъсванията си и позволява вложени прекъсвания - проблем няма, ако се използват "фаст интеръпти". т.е.това са прекъсвания, чийто приоритет е над системният ( най-висок е) и в които е ЗАБРАНЕНО извикването на системни за РТОС-а функции.
Всички останали прекъсвания в които се извикват системни функции трябва да са с по-нисък приоритет.
Ако при обработката на "фаст интеръпт" трябва все пак да се извика системна функция (примерно вдигане на евент флаг) - то това може да стане като от "фаст" прекъсването се извика (предизвика) друго прекъсване (примерно софтуерно или хардуерно със сетване на INT флаг на неизпозвана хардуерна процесорна периферия)
и в това "изкуствено" прекъзване да се извика съответната системна функция.

А иначе квалификацията на Цецо за РТОС-ите и процесорните системи ми хареса. Аз лични се интересувам от "прости" РТОС работещи в едночипов вариянт (без външни рам и ром). Има процесори с над 128кБ вътрешна рам и с над 512кБ флаш. Та да ги напълниш с код - явно проекта трябва да е доста амбициозен и определено не за екип от 2-3 програмиста. Дай-боже всички от нас все по такива проекти да работиме