Příspěvky

1351

Vývoj / Re:Přerušení v Linuxu

« kdy: 26. 07. 2020, 10:30:50 »

Takže tohle mě moc nepřesvědčilo. Kdybys řekl "věř mi, mám to vyzkoušené, tohle je lepší cesta", mělo by to pro mě (od tebe) větší váhu

Ale ony neexistuji univerzalni duvody proc se neco musi prave tak a ne jinak - nastesti v Linuxu a OSS obecne mame moznost volby, jak veci delat ruznymi zpusoby

Jeden duvod, se kterym jsme se setkali u psani nasich ovladacu pro V4L2 - ze kernel-space je dost nestabilni co se API tyce, takze pokud chces udrzovat svuj driver v kernelu, musis tomu venovat omnoho vice casu. Ale zrovna u V4L2 se tomu neda vyhnout a driver musi byt v kernelu.

S kazdou verzi kernelu je sance, ze se ti tvuj driver rozbije, a musis sledovat kam ten vyvoj speje - treba i co se tyce zpusobu reseni preruseni - tech zpusobu jak preruseni obslouzit je snad pet ruznych (od jednoduchych callbacku, po kernel thready ktere usinaj do pristiho preruseni)

1352

Vývoj / Re:Přerušení v Linuxu

« kdy: 26. 07. 2020, 10:10:58 »

Kdyby to chtel psat in-kernel jak by to rad Mirek

Já jenom dodám, že o tom prakticky nic nevím, takže jenom čistě laicky mi přišlo, že když mám v kernelu připravený základ, je snazší nad ním napsat nějaký tenký wrapper a vyexportovat si jednoduché jednoúčelové zařízení, se kterým už pak práce v userlandu bude triviální.

Spíš jsem se ptal, proč by se to tak udělat nemělo, rozhodně jsem se s tebou o to nechtěl hádat, na to jsem fakt v téhle oblasti úplný laik

Si to jednou zkus - problem neni napsat kod - ten udelas treba jednou (pokud jsi sikovnej a neudelas tam moc chyb), ale pak pro kazde zarizeni kde to bezi (rekneme RPi, Beaglebone, a ruzna cina) musis vytvorit ty upravy DT - coz je softwarova analogie k toho jak si ty dratky v hw pripojil.

Na tyhle jednoduchy veci nefunguje plug & play (to se nahrazuje tim DT) a kdyz se podivas na situaci kde PnP funguje (USB) a presto se voli psani userspace driveru (skrze libusb,libhid) - musi ti byt jasne ze psat neco v userspace je omnoho jednodussi. Muzes si volit jazyk, chyby ti nezpusobi pad OS, muzes resit veci interaktivne. Snad tohle postaci..

1353

Vývoj / Re:Přerušení v Linuxu

« kdy: 26. 07. 2020, 09:55:32 »

Takže správný postup by měl být, použít standardní SPI API pro SPI komunikaci a GPIO API pro čekání na interrupt.

Bingo!

Kdyby to chtel psat in-kernel jak by to rad Mirek, tak se z toho patlani spravneho DT s interruptem zblazni:
https://blog.stabel.family/raspberry-pi-4-device-tree/

Chápu to tak, že kernel musí obsahovat obecné GPIO API a specifický ovladač nebo nějaký definiční soubor (v rámci device tree?) pro RPi, takže ví, jak IRQ nakonfigurovat a když přijde, tak ho umí taky třeba ACKnout, což bych z user space dělal asi dost těžko...

Tak nejak.. delat polling interrupt flagu a acknout ho z userspace jde, pokud mate privilegia na pristup na dane adresy (mmio) nebo io porty, ale v ramci moderniho OS nemate sanci nastavit vektor preruseni, i kdyz vite kam ho zapsat, tohle musi resit kernel - protoze ten jedinej ma persistentni virtualni adresy (v x86 cs selektor).

Pred GPIO interruptem existoval navrh na IRQ API, kde v kernelu je kratky handler a jinak to funguje znova skrze poll():

https://lwn.net/Articles/127698/  (stejny zpusob pouziti, skrze poll)

1354

Vývoj / Re:Přerušení v Linuxu

« kdy: 24. 07. 2020, 20:34:21 »

Psat ovladac do jadra ma smysl jedine kdyby to zarizeni spadalo do existujicich trid zarizeni, ke kteremu existuje standardni linuxove API.

Já jsem dotaz pochopil tak, že to je přesně ten případ. V kernelu už základ SPI je, chci si tam jenom dodělat ten mechanismus probuzení userlandu.

To co je v jadre neni zadnej "zaklad" SPI, ale plnohodnotny SPI driver. SPI je zbernice a nemuze resit kazdou periferii - stejne jako mas treba PCI, PCIe, atd. Ovladace PCI karet taky nejsou rozsirenim zakladu PCI driveru... jenom ho vyuzivaji jako jednu z komunikacnich cest.

Tazatel ale nenapsal co je to za periferii, takze se nechme prekvapit.

Btw pokud by na RPI nebo jinou platformu chtel psat ovladac ktery vyuziva spi/int z kernelu, tak spravna cesta by byla sparovanim onoho driveru na patricny SPI port a GPIO / interrupt skrze device tree, a to neni uplne vec pro zacatecnika.

1355

Vývoj / Re:Přerušení v Linuxu

« kdy: 24. 07. 2020, 20:15:18 »

SPI i I2C jsou master/slave zbernice, a jinak nez pollingem se s takovyma periferiema neda bavit. Pokud chce zarizeni neco rict, muze trpelive mlcet, az dostane slovo (polling), nebo se ozvat dodatecnym, out of band, signalem - prerusenim, na zaklade cehoz vyvola pozornost mastera aby ho zkontroloval.

Jasne, ale tohle je/bude v jádře, ne v userspace.

Blokujici zarizeni se da vytvorit jedine napsanim ovladace konkretni periferie (konkretniho cipu).

Tazatel chce jenom implementovat "user space driver", protoze vyvoj a ladeni je mnohokrat jednodussi. Pokud je srozumen s reakcni dobou / latencema a nevadi to dane aplikaci, tak bych to taky tak preferoval.

Těžko může implementovat jenom "user space driver", když chce funkcionalitu, kterou žádný (?) existující kernel driver nemá.

Pokud jsi root, tak v userspace si muzes napsat ovladac k cemu chces (klidne vyuzivajici mmap/dma) - samozrejme je tam silne omezeni, ze jedinym uzivatelem daneho zarizeni bude autorova aplikace, protoze to konecne pristupove API bude viditelne jenom pro userspace, vyjma par pripadu, ktere maji udelanej zpetnej tunel do jadra (napr. FUSE).

Treba to preruseni z gpio - viz strana 15:
https://elinux.org/images/c/c8/Userspace-drivers-csimmonds-elce-2018_Chris-Simmonds.pdf
A celkove obsluhu jednoducheho zarizeni lze pak udelat i v bashi.

Psat ovladac do jadra ma smysl jedine kdyby to zarizeni spadalo do existujicich trid zarizeni, ke kteremu existuje standardni linuxove API (napr. typu framebuffer, disk, komunikacni port, atd) a prave zarizeni, ktere je unikatni ze nic takoveho v jadre neni, se hodi spis na psani userspace driveru.

Typicky priklad pouzivajici userspace drivery - flashrom (kazdy model SPI flashky se implementuje trocha jinak) a taky je zpusob jejich pripojeni velice variabilni.

1356

Vývoj / Re:Software-only USB host

« kdy: 24. 07. 2020, 20:01:13 »

LS/FS: myslel jsem si to, ale tak treba jsem doufal, ze je nejaky fallback kdyz je po ceste LS HUB, aby na nem slapaly FS zarizeni.

imho "LS only" hub se podle standardu nepripousti

Proc to delat? Potrebuju to v podstate na nejaky vyvoj, a je rozdil jestli na nejakou desku navesim 2 draty USB, nebo resim jiny MCU (kdyz v produktu ma byt neco co nema OTG, to neni o bastleni par kusu kde si muzu koupit doslova co chci). A ten MAX to kompikuje uz uplne extremne-myslim. Nebudu zastirat, ze tam je i vyssi motivace - potrebuju odladit jedno problematicke USB-CDC zarizeni (mam podezreni, ze MCU odesle nejaka data, ktera host nepotvrdi, a vykasle se na retransmit, resp. neco se tam pokoni-nevim co, USB analyzator nemam, tak to asi nasypu do nejakeho FPGA, jakoze poslednich X prenosu).

Pokud na to nespechas, tak s FS/LS by to slo vytrasovat - mam Cypress FX3 devkit v roli analyzatoru (ale kamarad tvrdi ze tam jsou hlucha okna kdyz to prepina buffery - to jeste musim overit treba rychlym citacem.. ktery nemam) a nad raw streamem (16bit wide) mam udelany sw ktery dekoduje na zaklade triggeru ruzne protokoly (gpio, pwm, i2c, serial, spi) a nad protokoly je jeste povesena abstrakce odposlouchavaneho zarizeni.. takze to dumpuje pak uz i high-level veci.

Jiste by to slo rozsirit do realtime nekonecneho provozu (pac zatim to spis jedu k offline parsovani). Puvodne jsem tim dekodoval inicializaci a provoz Canon snimacu, a posledne jsem to vyuzil k urceni kde selze Avoton C2000.. kdyz to bylo poveseno na spi bios cipu (selze to pri zapisu na port 0x80 - protoze to je prvni LPC transakce, a ma to chciplej LPC clock)... taky to odhalilo mnoho pristupu nez se vubec udela onen resetovaci jump na F000:FFF0 a to, ze ta bios flashka ma partisny ktere maj rizeni pristupu, takze cpu/soc dela hw preklad adres.

To USB FS jsem se tam chystal dopsat, protoze bych rad mel trace k firmware updatu ruznych zarizeni - bez toho aniz bych musel resit OS-specific "usb wireshark" (coz by tobe mozna i stacilo).

1357

Vývoj / Re:Přerušení v Linuxu

« kdy: 24. 07. 2020, 18:03:20 »

Např. pokud by původní problém byl v tom, že nějaký hardware pomocí SPI pushuje hodnoty v nepravidelných intervalech a on na ně chce reagovat (soft)realtime, tak nepotřebuje žádné interrupty, bohatě mu stačí blokující znakové zařízení...

SPI i I2C jsou master/slave zbernice, a jinak nez pollingem se s takovyma periferiema neda bavit. Pokud chce zarizeni neco rict, muze trpelive mlcet, az dostane slovo (polling), nebo se ozvat dodatecnym, out of band, signalem - prerusenim, na zaklade cehoz vyvola pozornost mastera aby ho zkontroloval.

Blokujici zarizeni se da vytvorit jedine napsanim ovladace konkretni periferie (konkretniho cipu).

Tazatel chce jenom implementovat "user space driver", protoze vyvoj a ladeni je mnohokrat jednodussi. Pokud je srozumen s reakcni dobou / latencema a nevadi to dane aplikaci, tak bych to taky tak preferoval.

1358

Vývoj / Re:Software-only USB host

« kdy: 24. 07. 2020, 17:35:54 »

Predpokladam, ze to je uplne mimo USB spec, ale je mozne FS zarizeni ktere mi spravne signalizuje pres pullup ze je FS provozovat jako LS, tzn. na 1,5Mbps ? Ze bych mu vnutil LS komunikaci i kdyz je FS ?

Ne, to nejde. Ten pull indikuje jak se na nej ma mluvit. USB je ponekud lepsi "seriovy port" ve sve podstate, tj. kdyz tam posles neco pomaleji, nebo rychleji, tak se nedomluvis. Rychlost se meni jen u HS (480M USB2.0) a to smerem nahoru, zarizeni se identifikuje jako FS (12M) po resetu, aby bylo s nim mozne komunikovat s USB1.1 hostem (ktery umi jenom FS/LS).

1359

Vývoj / Re:Software-only USB host

« kdy: 24. 07. 2020, 17:13:29 »

Proc to hrotit tak na krev? Osobne bych pouzil SPI-USBhost mustek - MAX3421E

Ale jako cviceni a honeni ega by to bylo zajimavy.. mam tu tlustou a velice podrobnou knizku o USB :-)

S DMA se tady neda pocitat - vzdyt je to bitbang kdyz to chces na GPIO. Leda ze bys ty zapisove waveformy predpocital asynchronne, a nechal to dma tam tlacit pakety a zatim mel prostor na jiny kod, na prijem ale bude potreba busy-loop se zakazanym prerusenim, at je tam zcela presny casovani.

1360

Vývoj / Re:Přerušení v Linuxu

« kdy: 24. 07. 2020, 13:58:26 »

Pokud jde o vyčtení bufferu v přerušení a předání do aplikace, tak myslím, že v Linuxu se to obvykle řeší čtením souboru /dev/{fiktivní soubor implementovaný v kernel driveru}.

Ano to chápu, ale toto je jiný případ. Například mám po SPI připojen řadič a náhodně mě chodí data, je zbytečné neustále posílat dotaz, zda je něco v bufferu, když řadič má int PIN.

Pokud na to driver není hotový, tak bude potřeba si driver napsat, alespoň nějaký minimální. A když už se člověk maže se základním driverem (a obranou kernelu proti out-of-tree driverům, prakticky asi bude potřeba si zkompilovat především celý kernel ze zdrojáků, a pak tam svůj driver naroubovat do stromu) tak bych rovnou veškerý bit-banging nechal v kernelovém driveru, vůči user space pak stačí jenom obsluhovat syscally... zrovna u SPI asi nestačí read() a write(), spíš nějaké to ioctl() - protože ta sběrnice není "jednoduchá roura".

Linux má koukám jakousi generickou podporu pro SPI, standardní API do user space i uvnitř kernel space. Dokonce ve zdrojákách vidím modul zvaný spi-bitbang. Tzn. máte k dispozici generické vyšší vrstvy, rozhraní do user space je hotové, máte k dispozici knihovnu bitbanging rutin, jenom si musíte dopsat svůj relativně lehký modulek, který to všecko slepí dohromady a parametrizuje na Vaši mapu GPIO pinů v RPi. Ve vanilce je několik modulů, které bitbanging knihovničku využívají = můžete použít jako example. Viz Kconfig, hledejte výskyty "select SPI_BITBANG".

Spíš mě ale zaráží, našel jsem zmínky, že RPi obsahuje hardwarový SPI řadič, tam pak samozřejmě bitbanging není potřeba, ale: copak k tomu není dávno hotový driver? Neválí se něco hotového na Githubu? Nebo je to použité=zabrané na nějaké režijní účely? Nejsem znalcem RPi...

Ale tazatel nechce implementovat samotne SPI, ale dodatecny notifikacni mechanizmus vyuzivajici preruseni - jakozto optimalni reseni vuci amaterismum typu busy-loop a polling! Samozrejme ze RPI ma hw SPI a linux ma sve genericke SPI API.

1361

Vývoj / Re:Přerušení v Linuxu

« kdy: 23. 07. 2020, 13:59:19 »

Obsluhovat preruseni v userspace je jen takova iluze / abstrakce, aby se nereklo. Bude to mit nejake latence, ktere musite vykryt napr. bufferovanim dat v one externi periferii. Hodi se to leda k cekani a aktivni probouzeni na ojedinelou udalost, ale aby nekdo s tim delal realnou obsluhu zarizeni, na to to uz nebude.

1362

Studium a uplatnění / Re:IT od nuly

« kdy: 23. 07. 2020, 12:25:26 »

9 dňový kurz za 1200 eur dobrá ryža na štátnych peniazoch, keď ešte aj rok štúdia na vysokej škole stojí menej €€€ a študent tam má Javu 1 - 2 celé semestre + kopu iných zaujímavých kurzov.

Je to asi zbytočné vysvetľovať niekomu, kto sa evidentne nevyzná. 1200€ je zhruba cena 5 dňového kurzu Javy v Gopase, čo je
najväčšie školiace stredisko v Čechách a na Slovensku. Z ceny kurzu treba zaplatiť dane, réžiu, administratívu, manažment a lektora.
Nik tam nejazdí na drahých autách, ani nemajú vily. Väčšina z nás to robí preto, že nás to bavi, nie pre peniaze.

1200e x 20 lidi x 4 tydny = 96000e / 2.5M CZK mesicne. I kdyby lektor mel 250K CZK a pronajem stal 250K CZK, tak je to porad 2M CZK cista ryza... a tohle je jenom jeden kurz.

1363

Hardware / Re:AMD vs Intel pre programátora + problem optimalizacie

« kdy: 16. 07. 2020, 17:49:04 »

Napis im na support, ladit komercni binarni appku moc neni ve tvych dispozicich.

A u win si budes muset overit, zda ta verze co mas umi slusne planovat, s tim ti tady nikdo moc neporadi, spletl sis trocha web :-)

1364

Hardware / Re:AMD vs Intel pre programátora + problem optimalizacie

« kdy: 16. 07. 2020, 17:37:49 »

Tak holt si tu appku musis otevrit v profileru a podivat se na slaba mista, co trvaj dele.

Ale pokud je to binarka, tak to klidne mohlo byt kompilovano skrze icc a ten produkuje pro AMD zcela blbej kod (ale ten by vytezoval cpu na 100%).

Nemas tam treba OS, ktery se s temi Epyc cpu nerozumi a prehazuje treba procesy mezi cipama? Je to Epyc1 nebo Epyc2 ?

1365

Hardware / Re:AMD vs Intel pre programátora + problem optimalizacie

« kdy: 16. 07. 2020, 17:22:35 »

Spis to vypada jako problem s konektivitou.

CPU nevytizene na 100% znamena, ze to na neco ceka... typicky IO... disk nebo sit, vyber si.