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

Та самия ОС не става ясно, трябва да се види дали има пример с такава комбинация.

Лошото е, че аз съвсем се опетлах.... първо гледах всевъзможни сорсове и като не тръгна, а като тоя да го направя, а като другия. По едно време ми писна и реших да го напиша както трябва да си е, щото всички са преписвали малко или много от ST, а техния код е супер гаден. Да, ама курец, документацията се разминава с кода им и по всичко личи че е сбъркана. Така че тръгнах да го ревърсвам... и вчера бях го докарал до едно ниво да пали, само дето малко като запали и се гасеше самичко. И не знам какво пипнах, днес изобщо не мога да го накарам да запали... Не знам духчета ли има наоколо кво ли...

Иначе има някаква поредица - сменя се пфи-то, пали се кор-а, чака се да запали, настройва се честоти, сменя се device-host режима пали се пор-та и т.н. Очевидно някои неща отнемат време. Примерно като му сетнеш хост режим, то не превключва веднага а след време. Трябва да го изчакаш, щото не бива да пишеш в хост регистри, ако не си в хост режим и т.н. Нормално тия неща се документират, а където може се прави с прекъсвания и то има някакви наченки на прекъсвания в хардуера. Но в Кюба първото нещо дето правят е да забранят прекъсванията и ги разрешават чак като свършат. Цялата инициализация е правят на тъмно и на фантазия. Явно са си настроили тук-там времена, е шляпат по регистрите както им дойде.
При тях може и да работи, щото всичките им примери имат закачен ID пин, така че може би хардуерно им се задейства превключването от device към хост. При мен обаче няма такава екстра и трябва софтуера да изчаква...

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

За съжаление не е само софта... и хардуерът им е един

Имам чувството че вътре са ръгнали процесор. Не е като периферия да й налееш регистрите и да хукне, ами пишеш нещо, чакаш, веднъж минава, веднъж не минава... зависи дали дебъгваш или не, зависи какво устройство си ръчкал преди това, а може и от фазата на Луната да зависи...

В момента го докарах до някаква супер сложна комбинация - ръгам една мишка първо, то превключва на low speed и по някое време умира, вадя слагам му full speed (който се търкаля на другото usb на чепа) и след няколко опита с клизма понякога стига до комуникация... Иначе ако е едно устройство и след power cycle изобщо не тръгва порта. Аз му правя заявка да запали, той се прави на разсеен...

а в линукс? ровичках го преди време и ми се стори тежко и ме отказа да го копам до разбиране, но предполагам, че за теб ще е по лесно след като вече си се борил с прасето ...

Проблемът ми е, че не мога да вдигна самолета.... Инициализацията не минава и изобщо не мога да стигна до какъвто и да е трансфер. Може би грешно съм изразил, търся работещ стек не за да гледам как се прави usb, а как инициализират периферията на ST.
Най-елементарното нещо - има хост порт, който си има регистър в който има един бит да му кажа power on и друг бит (PENA) с който ми показва кога е включен. Портът се изключва автпматично при overcurrent и т.н. Документацията не е много подробна как се клати втория бит, но ток си го клати. Не е ясно колко време трябва да го чакам да се вдигне, но пък изрично са написали никога да не се вдига софтуерно. Може само да се сваля. Дават го rc-w0. В сорсовете обаче тоя бит винаги се пише нула, винаги - все едно че е rc-w1. И то на места където едва ли искат да изключат периферията.
Хубавото е че като се вдигне или падне тоя бит получавам прекъсване. Като при падане има и други прекъсвания защо е паднал. Какво се получава при мен - понякога не иска да се вдига. Ако се вдигне пък много често пада безпричинно, т.е. няма други интеръпти.
И те така вече поне две седмици си играя с тва и още няколко битчета

Погледнах в линукс, омотано е, има някакъв ST SPEAR но ehci/ohci явно ползват някакви базови драйвери, дори няма дефинирани адреси на регистри в паметта. То и самите драйвери са по 200-300 реда, и това което на пръв поглед правят е да пускат клок на усб контролера когато ще се ползва и дотам. Мимохом само да споменем, че е писано от индийци ... най вероятно и другите им библиотеки са оутсорснати при същите, определено няма да ти е лесно ...

Мдаа, както и предполагах ...

Поне си признават, че ползват готово IP за усб-то, току виж е същото в твоя контролер ...

@palavrov, къде ги гледаш тия неща?

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

http://www.st.com/stonline/stappl/resou ... assID=1156
http://www.st.com/web/en/resource/techn ... 254644.pdf
page 61

Не ме питай що точно там отворих а не в даташита - сам не мога да си го обясня днес
То в нашата работа, половината от майсторлъка е ровенето в интернет и в чужди сорсове ...

Сега на свежа глава каквото ми се върти въпроса - явно има стандарт за ohci/ehci контролери, щом в линукс има 2 общи драйвера (в които между другото има разни интересни флагчета като например: has_synopsys_hc_bug) и всичко стъпва на тях, дали в микроконтолера който ползваш не е пак някакъв такъв стандартен? Т.е. тогава всеки друг драйвер на сорс би бил добра отправна точка, най много да има разлики как се пали/гаси/калти и т.н.

Не, усб-то на спеар-а определено е различно...

Възможно е да са взаимствали някаква част, но регистрите са различни и трудно ще се хване логиката. Приликата е в това, че по параметри са близки и двете имат по 12 ендпоинта, което е нестандартно. И на двете места host и device са отделни губернии, което създава повече грижи за софтуера. При луминари примерно е един хардуер или поне изглежда като един, защото за трансферите няма разлика дали ги правиш като хост или девайс. Ползвам едни и същи функции, сам тук-там има дребни разлики...
Докато при ST отделно правя хост, отделни девайс защото са различни регистри с различна логика. Като хост-а седи като някаква кръпка буквално. И с някаква собствена терминология, не е "еднпоинт" ами "канал".... Има някакъв "порт" дето явно е нещо между контролера и пфи-то, ама каква му е точно функцията не знам. Как девайс-а директно си говори и се оправя с пфи-то, а за хост-а трябва да минава през порт също не знам...

Както и да е, сега го преправям за пореден път дано да тръгне....

Ихаа.... след дълга и мъчителна борба най-накрая имам някаква комуникация

Обаче е изцяло по метода на двамата руски учени Натъманенко и Нагоденко
Разбрах защо не ползват прекъсвания при инициализация гадовете, щото са като дискотека... идват по няколко накуп, често и взаимно изключващи се (едновременно conect и disconnect).
Както и да е, до някъде го докарах. Лошото е, че има определени комбинации в които се дъня и не е много ясно как да ги обработвам. Една читава документация сега щеше да ми свърши работа. Чудя се дали да пробвам съпорта им на тия юнаци или да не си губя времето

Някой да е подкарвал hid клавиатурка?

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

ето линк към пакет примери, в който съм видял HID:
http://ww1.microchip.com/downloads/en/softwarelibrary/microchip-application-libraries-v2012-07-18-windows-installer.exe

те hid имат ама на мен ми трябва обработката на скан-кодовете... както и да е, явно ще викам Неволята

тъкмо си бях помислил, че съм приключил и с USB и STM и днес ново двайсе... Пускам sleep mode (WFI в idle task) и изненада - usb host-a не ще да бачка, всичко останало включително и usb device бачка.
По едно време се сетих, че има гейт контрол на клоковете в low power mode, пуснах да не спира клока на хоста, обаче не помога. Ефект никакъв.
С две думи имам два проблема - първо защо хоста не бачка дори и с разрешен low power клок и второ, защо всички останали периферии бачкат, при условие че по подразбиране в слийп режим нямат клок. Аз верно че имам часовник на 1ms и това ме събужда, обаче и по половин милисекунда да спира клока на UART-а трябва да почне да изпуска байтове или да греши битове. Но аз така и не видях да има подобни проблеми.
Направо съм в шах...