Абе ако има кръпки, по-добре да са си скрити в стека. Той поне се пише еднократно и после надявам се няма да ми си налага да си спомням за недомислиците на ST.

Изпускането и без друго не ме кефи, защото няма начин да се реши на ниво приложение. USB-то е такова животно, че хоста ако не го спреш може да те зарине с данни. Нищо че си да кажем UART на 9600.
Ако лузърът не може да обработва със максималната USB скорост просто няма решение. А то с UART бриджовете е точно така. Ако РС приложението иска да прати 10MB то ще почне да те залива с очевидно много по-голяма скорост, отколкото ти може да бриджваш. Нямаш и 10MБ памет да кешираш...

Чибито е така! Ако не ми вярваш провери... Нали каза че си подкарал точно бридж. Пробвай от компютър да изстреляш един голям файл по USB и да го получиш обратно по UART. Ако успееш ела ми се обади

Едит: всъщност има някакъв шанс да го прехвърли, но трябва да го настроиш да ползва queue и приоритета на усб нишката им да не е висок. Тъпичко малко са го направили. Като дойде прекъсване от УСБ че има някакви данни, се сигнализира pump нишката им. Тя спира всякакви УСБ прекъсвания и с полиране почва да тъпче в кю-то. Няма слийп, така че ще утрепи CPU usage-a...
Все пак важното е, че като се ползва кю, не изпускат данни. Подведох се, щото основно гледам други сорсове, а и Чибито във варианта с буфери също изпускат и тогава бриджа няма да бачка с големи файлове.

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

Всъщност то си зависи какво е приложението. Аз почти винаги работя с непрекъснати потоци от данни с константна скорост (от АЦП). Даже и да имам буфериране някъде по веригата, ако в крайна сметка не смогвам, препълването рано или късно ще гръмне. Но ако човек работи с непериодични пакети, които не са критични като синхронизация във времето, може би блокирането ще е по-удачния вариант, защото ще запази работоспособност.

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

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

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

Значи стандартно комуникацията по USB е с ендпоинти, чувал си предполагам, ако не си това са нещо като логически канали. Flow контролът за всеки ендпоинт е индивидуален. Специално за OUT каналите хоста преди да прати пита "ти искаш пакет или не". Ако девайса каже да - праща му се.

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

ST обаче са много умни и са наблъскали всичко в едно общо Фифо. Така практически няма как да има хардуерен flow control на ниво ендпоинт. Едва когато се напълни цялото фифото, контролера почва да отказва пакети. Проблемът е, че до тая ситуация се стига, ако лузера откаже да обработва един ендпоинт. Хоста, тъй като получава потвърждения предварително ще почне да тъпче докато не натъпче всичко.
Аз в USB стека няма какво да направя, защото не мога да вадя пакетите в произволен ред. Ако има пакети, по ендпоинт за който лузера не ми е дал буфери няма кво да правя. Или трябва да ги изхвърля или да чакам лузера да си ги поиска. Във втория случай блокирам останалите ендпоинти.
На всичкото отгоре достъпът е само на ниво 32-бита. Демек ако лузера пусне заявка за 1 байт, а са дошли 10, аз няма как да изкарам само 1 байт. Минимум 4. Отделно ако може да се вярва на коментарите в Чибито казват, че като се почне един пакет в един ендпоинт не бива се прекъсва. Въобще хардуерът на ST е на ниво ТНТМ от 80-те години. Поне да бяха оставили лесна възможност да спра един ендпоинт, а то и това е сложно...


А от стана на лузера почти нищо не може да се направи... и да го сигнализирам и да не го сигнализирам е все тая. Проблемът е че ВСИЧКИ хост приложения разчитат на flow контрола, защото това си е дефакто стандарт.

Лузъра просто трябва да подсигури, ендпоинта/ендпоинитите да се изпразват редовно. Демек да не оставя драйвера да се заталачи. За целта на лузъра му е необходим сигнал, че нещата са се сговнясали, демек софтуера му не издържа на трафика. Аз поне така си организирам нещата, че освобождаването на драйвера за USB ми е с много висок преоритет. Може би затова и не виждам проблем в имплементацията. Честно казано не виждам защо лузъра ще изоставя определен ендпоинт, а ще пощи останалите, каква му е далаверата от това?

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

Не е казано, че е един същ лузер. Все пак правим многозадачни системи...
Въпросът е, че един да е бавен. може да забави всички останали. Примерно препращаш към хардуерен UART и ако хоста праща на куп по много данни може да ти затлачи фифото за много време.

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

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

Ами незнам точно кои кюта визираш. Аз го пуснах през CDC драйвер, той се надгражда над серийния, който пък поддържа опашки. Мятам в едната и чета от другата. Като цяло работи, ама не съм го товарил кой знае колко, да не казвам хич...

OTGv1/usb_lld.v :

в usb_lld_serve_interrupt() са прекъсванията... RXFLVL е че има нещо получено, при което събуждат "pump" таска си...

Той ( usb_lld_pump() ) докато има RXFLVL вика otg_rxfifo_handler()

В otg_rxfifo_handler() ако данните са OUT пакети гледат от кой ендпоит са и в зависимост от out_state->rxqueued на съответния ендпоинт ги мятат към буфер (otg_fifo_read_to_buffer()) или към кю (otg_fifo_read_to_queue())

Това е...

Проблемът е, че като бачкат с буфери, ако няма място просто изхвърлят данните.
А пък кодът за опашките очевидно не е тестван:

доколкото разбирам от програмиране това винаги ще е 0 и няма как по-надолу кодът да работи

Сега се сещам, че за F4 работещия драйвер (или поне изглежда да работи) още е в трънка. Там въпросния ред е :



Което изглежда по-смислено.

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

Както и да е, аз няма да го ползвам тъй че ми е все тая кой им е баш актуалния код

Един въпрос - присвояването на 32 битова стойност атомична операция ли е?

да, на всички 32-битови платформи

Да на всяка архитектура тази операция е атомична, ако е по-малка или равна на размера на системната шина.

Тоест, 16 битовите команди нямат значение?

Не вярвам някой да ми помогне, ама поне да се оплача....

боря usb-то на едно F205 вече не знам колко си време. Общо взето тръгва инициализира и почвам да получавам прекъсвания.
Идва бъс ресет, идва enumeration done и после идват данни... Данните са валиден стандартен рекуест за set address. После идва още една дума в фифото за setup complete. Запомням си адреса и потвърждавам с нулев пакет. Идва прекъсване за трансфер complete на пращането ми и аз решавам да си сетна адрес в DCFG.
Обаче йок, само младшите 3 бита от адреса се приемат. Примерно DCFG e 00200003 аз съм получил адрес 47 (0x2f) демек трябва да запиша 0x002002f3. Но то става 00200073. Демек все едно си сетвам адрес 7 вместо 47.
От страна на хоста wireshark-a показва как сет адреса е минал успешно, обаче след това идват един куп заявки за четене на девайс дескриптора, които обаче от страна на STM не се виждат. Нормално е да не се виждат при условие че не съм си конфигурирал адреса...

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

Проблемът е защо не мога да си сетна адрес. Между другото DCFG според документацията има Reset value: 0x0220 0000, докато при мен първата двойка я няма, незнайно защо. То не се знае какъв й е смисъла щото е reserved. Но гледам че чибито си я пишат (те не променят направо пишат).

Та така, не ще и не ще... Сравнил съм де що има конфигурационни регистри, със сорса на Чибито и на STM-ската библиотека - няма нищо съмнително. На места има разминаване между сорсовете и в документацията та на тия места съм извъртял всички стойности (примерно търнъраундите на ahb-to, типа на phy интерфейса и т.н.). Пробвах и с тайминги, защото аз по принцип обработвам при първа възможност още като получа заявката и тръгвам да отговарям (не чакам глупавите им setup complete). Но и с изчакване пак не става....

На 32-битова архитектура може наведнъж да запишеш 32/16 или 8 бита. Демек атомично е.

Ех сега ако пишеш два пъти по 16 и наричаш това "32 бит" естествено не е атомична операция. Демек някой може да ти се вмъкне между писанията.