Някой да е виждал колекция от хедърчета с дефиниции на регистрите на PHY чепчета?

Има известни разлики в регистрите, а по закона на мърфи съм сложил пфи (LAN8720) за което нямам код. А кодът дето портвам даже идея си нямам за какво phy е правен, по регистри долко-горе пасва на тексасците. Та сега трябва да чета поне 2 чаршафа за да видя какво прави кода с едното phy и как да го направя същото с моето пфи.

С две думи ще е досадна работа, освен ако не намеря нещо готово... и за предпочитане код, който може да работи с повече от 1 пфи...

миро,
няма обща рецепта за PHY.
въпреки, че първите десетина регистъра са почти еднакви, стандарт няма и не се знае на кой киртак какво ще му дойде.

затова - четеш ID-то на чипа и пускаш съответната функция. отделни .c и .h файлове за всеки PHY, няма как.
в линукса има доста пълен комплект от сорсове, които след съответното изрязване ще ти вършат работа.
на мен лично повече ми харесват от FreeBSD, прецени.

също ще е важно да измислиш нивото на абстракция. според мен е разумна на мета-ниво да имаш функции като get_status, get_cap, set_cap, set_led и т.н., които да привръзваш към съответния PHY "драйвер", който да се грижи за конкретните битове в регистрите.

и не е лошо да имаш функция phy_read и phy_write, които да виждаш от по-горно/публично ниво. много помага за дебъг и нов PHY.

аз попаднах на 2 PHY на марвел, които имат еднакви ID-та, въпреки че са съвършенно различни чипове/регистри. добре, че единия е гигабитен, за другия е само 10/100, та може да се различат. мисълта ми е, че щом чехъли като марвел са го допуснали, вероятността и други да са го неправили не е малка.

Не ми се рови из лайнукси, ще се опитам да мина по тънката лайсна

Хер нъта видях че има просто API за няколко пфи-та ама за съжаление без моя... То лошото е, че ползвам STM а те имат ужасен стил на писане. Не издържах и тръгнах да пренаписвам дефинициите и функциите на MAC-а, няколко дена само copy&paste докато изравня регистрите им с чаршафите. Досадна работа...
Естествено нямат никаква абстракция за пфи ниво

Можеш да погледнеш HAL-а на чибито. Там му викат "mii", хедърът е os\hal\include\mii.h - http://sourceforge.net/p/chibios/svn/HEAD/tree/trunk/os/hal/include/mii.h
Във версия 2 на чибито няма дефиниция за твоя чип, но във версия 3 се е появил - поне като идентификатор, но предполагам че е влязъл покрай някой порт на платка или демо, не ми се търси точно откъде, но ти ще се ориентираш.



Едит: май оттук:
https://github.com/tosqa/tosqa-ssb/blob/master/apps/netdemo/board.h
http://chibios.sourceforge.net/docs/hal_stm32f4xx_rm/mac__lld_8c.html
http://chibios.sourceforge.net/docs/hal_stm32f4xx_rm/mac_8c.html

Абе случайно някой да е ползвал lwIP с STM32?

Аз не че имах някакви очаквания от ST, обаче тоя код дето са го нашляпали е просто някаква загадка. Според мен това и за демо не става, камо ли да се ползва...

ужас... разширих търсенето до "някакъв" порт за lwiP, но без успех

Не мога да повярвам просто... не може да няма нито един работещ проект с етернет за stm32 ?!

търсиш под вола... коза. или бяла лястовица.

Етернета по принцип е много по-прост от USB за подкарване. Има пет функции на кръст дето трябва да се напишат за да тръгне lwIP-то. Предполагах, че ST няма да са ги написали добре, както и USB стекът им е грозен, ама чак пък толкова да отбият номера не съм очаквал
За съжаление не само аз съм разочарован... има няколко проекта дето твърдят че са подкарали нещата, но от "уважение" към ST не искат да публикуват сорсове. Интересно, че и в нито един от RTOS-четата не виждам нищо готово. Явно ще се спасяваме поединично...

аз не бих се изразил толкова опростенчески.
може би "прост стек" по стандарта се реализира относително лесно.
обаче проблема е по-скоро в милионите експлойти, защитеност от всевъзможни простотии, идващи по мрежата.

ако ще правиш стек, дето ще го оставиш на поляната, на дъжд и вятър, вълци, хиени и лъвове, всеки да си пробва торбата с трикове и хакове... това ми се струва мисия невъзможна, особено за малка въшка. "истинск" стек се човърка с десетки години и пак понякога го издупват. пък и нещата не опират само до (ниските нива на) стека.

Изобщо не става дума за писане на нов стек...
Масовата практика при тоя клас контролери и/или RTOS е да се ползва lwIP. От публичните това е изборът, има по-малки като uIP ама то вече съвсем изцедено като за 8/16-бит. Другите стекове или не са фрее, или се ползват само от някой си некъде си... Докато lwIP си е прилично тестван в десетки платформи с OS без OS, всякак. Ползвал съм го, нямам забележки, даже много прилично написан като се предвид сложността на материята. Стандартно API, всъчщност 3 варианта за API от към приложения, от към джелязо са само няколко функции дето трябва да се имплементират - инициализация, пращане на фрейм, получаване и тва в общи линии.

Примерно за пращането callback-a ти дава фрейма като списък от буфери/пакети. Тия гамени заради DMA-то копират и препакетират данните в други буфери дето са закачени към DMA дескрипторите. Айде, излишно memcopy... ама тва да беше проблема. В първата им версия даже при копито не са си направили труда да проверяват размера на буферите. Ако тръгнеш да пращаш по-голям пакет и айде.... Явно хората са изпищяли, сложели са по-добро нацепване. Но до там. А принципно трябва да има опашка, щото в момента ако стека се опита да прати два фрейма един след друг тия ще дропнат втория ако DMA-то е заето. Да ама като се махне копирането и като сложа опашката ще трябва и да се грижа да освобождавам буферите. Освен това кодът им на тия е такъв, че може по средата на фрейма да стане издънка, изобщо отваря ми се работа

нямам спомен - lwIP оправя ли се с разбъркани пакети?

Със сигурност няма грижи, а как точно се оправя не помня или не знам, щото не ми се е налагало да се ровя из него. А сме го тествали, вече години има наши устройства и то в корпоративни мрежи с голямо натоварване. Единствено броадкастите ни моряха много, щото на луминари без DMA само изчитането и изхвърлянето на пакетите товареше на 100% cpu usage...

A пък и то разбъркани, разбъркани... колко да са разбъркани като нямаме памет? Прозореца я има 4К я няма

Нямам хардуер с етернет на стм32, но чибито си има поддръжка на lwip и има доста демота които го ползват. Това като име например:

Дръпни си chibistudio и ще получиш целия пакет заедно със средата.
Иначе по приказки олимекската платка дето има етернет е най-често спряганата и ползвана (като комбинация стм32 + етернет).

Гледах го чибито... поне по версията дето имам и те са минали по тънката лайсна. Пак е по-добре от STM-ския драйвер, щото са ОС и могат да си позволят да блокират докато DMA-то е заето. Единствения недостатък е, че като блокират блокира и получаването. Не е фатално, просто номерът с блокирането при мен няма да стане толкова просто...

мда... при получаване бозата е още по-голяма.

При ST няма обработка на никакви грешки. Само да им излязат битчета за начало и край на фрейма и го подават на стека, без да ги интересува дали са валидни данни. Ако пък не им излязат битчетата още по-зле, нито на стека го дават, нито пък го махат от опашката на DMA.
Чибито обработват грешките... само дето пак са спестили малко код и изхвърлят фреймове с повече от един сегмент. То може и така да стане, само дето аз не съм сигурен много...