Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - František Ryšánek

Stran: 1 [2] 3 4 ... 44
16
Hardware / Re:Jak flashnout bricknuté AP přes RS232?
« kdy: 28. 08. 2020, 20:26:49 »
Po neúspěchu s RS232 ktery vypisoval jen klikyháky to nakonec to šlo přes to Raspberry Pi kde zapínáš přímo UART a máš tam pak port /dev/ttyS0 a i jsem tam nahral firmware přes LAN, vše proběhlo ok i dvě kontroly a pak se to vzdy zasekne na copy from FLASH to SDRAM. Možná špatná verze, ale dneska jsem se k tomu vratil a nějak mi nejde ten TFTP server v PC takže už na to nemam sílu se tomu věnovat 24 hodin, zkusim to zas jindy z jinýho zařízení a jdu dělat něco jinýho. Diky za rady.

Copy from Flash to SDRAM? A nemělo to bejt obráceně? :-) Jak dlouho jste to nechal v tom "zaseklém" stavu?

AirCA... to byly časy. Celé je to nějaký Atheros, rádio je 802.11abg (nikoli N, natožpak AC). A souhlas, WPA2 na tom chodí. Tuším mám někde v šuplíku jeden kus, na kterém byl Kamikaze. V těch dobách tahle Airca nebyla oficiálně podporována v upstream OpenWRT, ale tady v ČR bylo pár jedinců, kteří na tom provozovali komunitní nebo i komerční wifi služby, bylo k mání veřejné repo - stačilo stáhnout hotový image a jelo se.

Na dnešní dobu to má pro OpenWRT málo RAM a Flash (32 MB / 4 MB). Pokud najdete nějaký moderní ale ořezaný image bez LuCi (HTTP GUI) tak by se to mohlo ještě vejít. Každopádně doporučovaná RAM+Flash pro aktuální OpenWRT je dnes minimálně dvojnásobná.

Mám tady už asi rok "TP-Link Archer C7 v5", instalace aktuálního OpenWRT byla lebeda, jede to jako fík...

Kolik má ta Vaše deska nalítáno? Jestli by třeba nepomohlo, nahradit ten jedinej elyt za vstupním měničem nějakým polymerem. Případně, vidím tam nějaké volné footprinty dalších kondíků, přilepit tam třeba pár tlustých keramik po pár mikrofaradech (buď koupit, nebo oloupat fénem ze šrotových motherboardů, kolem patice CPU jich bejvá hejno). Ideálně se na to napřed / průběžně dívat osciloskopem - ale to není běžná hračka domácího kutila... A souhlas s Patrikem, AirCA je vážně už dost šrot, než aby stálo za ten čas, snažit se ji resuscitovat.

17
Port multiplier podle mého bude dost omezovat IOps, pokud byste chtěl z více disků ždímat maximum - na druhou stranu sekvenční rychlost z jednotlivého disku (ostatní se flákají) je normální = úzkým hrdlem je v tom případě disk.

Moje prakticke zkusenosti jsou, ze v souctu paralelnich pristupu je multiplier top na dvou rotacnich discich, od tri uz vykon klesa a na peti to bylo fakt marny - protoze se projevuje overhead prepinani (adresovani) koncovych zarizeni (a sata je half duplex). Nehodi se tedy na RAID, kde potrebujete vsechny disky naraz, spis na JBOD/LVM/SPAN/LINEAR rezim, kdy se pristupuje vyhradne k jednomu disku. (SAS port expander takove problemy nema, protoze uplink bejva X4 port a celkove je lepe vyreseni - sas je full duplex)

Mám to nasazené v málo zatíženém fileserveru / odkladišti, kde NEprovozuju LVM apod. napříč hromadou disků: provozuju tam stádečko postupně vzniknuvších mirrorů. Občas někdo z kolegů přijde "ty franto, neměl bys kus místa na fileserveru? potřebuju někam navždycky odsypat pár set GB dokumentačního HD videa jak nějaký stroj dělá furt to samé dokola" a já říkám "uhodls neměl, ale mám nějaké volné šuplíky. Kup si disky, vyrobím tvému oddělení mirror a vystavím ho na LANce". Je to zpozdilé, ale funguje to nakonec i organizačně. Halt malá firma. A pasuje to na 2 kanály HBA osazené x5 port multipliery (plus asi 4 kanály onboard jednotlivé). Dávám si samozřejmě záležet, aby dva disky v mirroru byly vždycky každý na jiném multiplieru. Na gigové LANce je zatím úzkým hrdlem ta LANka nebo klient.

18
No... flek - re - tuty, proč ne rovnou takhle?
mozna kvuli cene ~3kkc ? ;-) Delock 54667, 54668
:-) auvejs, na cenu jsem nekoukal. Ale tak... uznejte že je to exot :-) Kupodivu ten dvouport je dražší než čtyřport... v SWS vidím cenu ještě o stovku-dvě nižší, než je minium na Heurece.

Padl tady dotaz na "SATA port multipliery". Netvrdil bych, že to pojede na jakémkoli SATA HBA čipu - ale pravda je, že moje praktické zkušenosti jsou hodně chabé. A viděl jsem to často zmíněno u HBA čipsetů jMicron. Dokonce mám v jednom nenáročném fileserveru kartu DeLock 89384, která obsahuje dvoukanálový HBA a dva multipliery po pěti portech, ve výsledku 10x SATA. Nenarazil jsem zatím na problém. Jsou na tom pověšené točivé disky.

Port multiplier podle mého bude dost omezovat IOps, pokud byste chtěl z více disků ždímat maximum - na druhou stranu sekvenční rychlost z jednotlivého disku (ostatní se flákají) je normální = úzkým hrdlem je v tom případě disk.
 

19
Aha. Tak něco jako tohle?

https://www.suntech.cz/produkt/432371-digitus-redukce-z-m-2-2230-2242-2260-2280-sata-na-sata/

https://www.aliexpress.com/i/33027957415.html

No... flek - re - tuty, proč ne rovnou takhle?

https://www.delock.de/produkte/1740_M-2/54667/merkmale.html   (Jmicron dvoukanál)

https://www.delock.de/produkte/1740_M-2/54668/merkmale.html   (Marvell čtyřkanál)

Ledaže by ten M2 slot byl z rubu desky, to by byl asi pešek...

Ještě aha, pardon:
https://www.aliexpress.com/i/33027957415.html
...původně jsem si myslel, že ten šváb na destičce je SATA expander,
ale to je zřejmě hloupost, JMB585 je pětiport SATAIII řadič na PCI-e x2 gen.3.
Je možné, že to bude míň topit než ten čtyřportový Marvell? :-)

20
N2800 byl ještě in-order. Po něm přišel BayTrail a bylo to rázem o dost lepší, a dnešní Gemini Lake je zase o kus dál. Ale to jenom pro úplnost - proti i5 jistě nelze nic namítat, hlavně když má deska ke všemu to správné napájení (na trhu bohužel dost vzácné). Koukám i5-8500T je dokonce šestijádro... hezký kousek :-)

21
...
Cinan ma adaptery za par korun:

https://www.aliexpress.com/item/33050056272.html  - bacha, toto je do slotu MiniPCI-e, do M.2 pasovat nebude.
Podobně znám tady u nás od DeLocku toto: https://www.delock.de/produkte/G_41305/merkmale.html?setLanguage=en
Mám jeden kus v servisu a funguje, použil jsem ho asi dvakrát na nějaké ladění.

https://www.aliexpress.com/item/4000675291835.html  - toto vypadá sjízdně. Pro srovnání, prakticky totéž má/měl DeLock: https://www.delock.de/produkte/G_62584/merkmale.html?setLanguage=en  A ještě jsem našel na Alíkovi jednu variantu s kšandou: 
https://www.aliexpress.com/i/4000187518540.html?spm=a2g03.12057483.1000001.8.7c7820e7mt7exk

Fungovat by to teoreticky mělo, ale správně uvádíte pár otazníků. Tady je jediná možnost: vyzkoušíte a uvidíte :-/ Kromě zádrhelů s BIOSem se velmi teoreticky můžou vyskytnout zádrhele v pinoutu (na PCI-e oproti staré PCI méně pravděpodobné) a u čínské produkce z Alíku občas potkáte problémy s kvalitou výroby. DeLock je sice taky číňan, ale sídlem v Německu, na kvalitu si vcelku dohlíží a máte tady v ČR kde uplatnit reklamaci.

Spíš ale dumám: nebylo by jednodušší, prostě použít větší desku? MicroATX namísto miniITX.
Škoda že se desky s 19" napájením nechytly víc. ATX zdroje pro ITX jsou bída, už dlouho, zejména pro ATOMové desky... Ačkoli pro nějaký i5 už by mě srdce tolik nebolelo, použít něco s ventilátorem (SFX / TFX / BTX). Anebo kašlat na miniaturizaci a použít nějaký kvalitní tichý 300W zdroj ve formátu PS/2 ATX. Já jsem se před časem kousnul a spáchal jsem něco po svém, ale to prosím nepovažujte za seriózní doporučení.

BTW... domácí server... jaké jsou nároky na výpočetní výkon? Nějaký ATOM by tomu nestačil?

22
Sítě / Re:opticke linky telekomu
« kdy: 11. 08. 2020, 18:41:24 »
...já se obávám, že mapy sítí všeho druhu jsou jednak obchodní tajemství, jednak bezpečnostně citlivá informace :-)

Za mých mladých let si pamatuju, jak se ISP navzájem trumfovali, kdo má víc POPů, a tuším kdosi nezávislý v ČR vydal publikaci "mapy internetu", kde bylo pár hrubých topologií tehdejších ISP. Pokud mohu soudit, ta doba je pryč. Je to tak dvacet let zpátky.

Je tu několik málo subjektů s vlastní meziměstskou optikou, často podél nějakých průmyslových sítí - a obchodují spolu navzájem. Pronajímají si navzájem jednotlivé trasy, kde mají zrovna hluché místo. A jsou místa či oblasti, kde nemá optiku nikdo, takže si není ani od koho najmout... a kvůli jednomu zákazníkovi se nikomu kopat nechce, dneska stejně jako před dvaceti lety.

23
@Thielas: máte moje sympatie - s tou nutkavou potřebou "vědět jak to funguje pod kapotou, jakože fakt vespod" a s příchylností k C/C++. Mně dalo hodně, když jsem se párkrát hrabal v nějakých věcech v Linuxu. Buď čistá systemařina, nebo jsem potkal pár periferií (a pracovních zadání), kde mělo smysl spíchnout jednoduchý driver v kernelu... a přestože jsem předtím potkal Borland C/C++ v DOSu a Windows, tak teprve seznámení s Linuxovým programovacím ekosystémem (C/C++, kernel a user space) přineslo pravé "prozření" :-) Občas šel kolem i nějaký projektík blízko PC HW, kde jsem uplatnil pár rutinek v ASM. Zkoušel jsem před lety škodit i nějaké primitivní systémoviny ve Windows, ale moc se mi pod Win32 nelíbilo - zrovna když jsem trochu čuchl do kernelu, tak přišly Win7 a povinnost podepisovat ovladače, a i v user space je Win32 API docela řehole, přestože zatím není zamčené podpisem...

Ono je možná romantické, kutit si něco v ASM na holém železe, ale dávno pryč je doba, kdy si člověk mohl sám napsat vlastní vesmír. Dneska spíš používáte cizí tvorbu a občas najdete skulinu, kterou zatím nikdo nezpracoval, tak si třeba nějakou maličkost střihnete, v kontextu toho prostředí, které v potu tváře vytvořily a odladily stovky lidí pred Vámi.

Pokud se týče otázky "jakou školu", zvažte nějaký obor, který má ve štítu vymalováno "mechatronika". Sympaticky vypadá třeba TU Liberec - sice jsem slyšel, že je to dost husté študium, ale tak asi tam nejdete proto, abyste se pět let flákal (nebo unikl vojně, jako za mého mládí) a důležité je hlavně se nepo.. předem. Asi na každé vejšce se vyskytují pitomosti - jeden z možných přístupů je, pokud vidíte, že jako celek to asi nedorazíte, tak si vybrat věci, které Vám přijdou užitečné, a těch obrazit co nejvíc.

Palec nahoru za intenzivní angličtinu. Já se do ní taky kdysi zakousl při škole po svém. Četl jsem všelijaké knížky se slovníkem v ruce, pak jsem se začal bavit s lidmi v internetech... hezká doba to byla. Teď na starší kolena se snažím podobně opřít do němčiny, taky mám bolestné základy odbyté ze školy, přesto ta němčina už jde o poznání víc ztuha :-) asi protože nemám čas tolik číst... nebo je to věkem? (spíš ne) Proč vůbec němčina: protože to dává smysl v mém zaměstnání. Němci reagujou přívětivěji, když vidí snahu a nemusí se sami trápit angličtinou. Kdybych neměl potřebu, protože s němci kšeftuju, tak bych tuhle řeč jenom tak pro srandu králíkům nepěstoval.

Mimochodem, pokud jste na střední neměli fyziku (?) tak doporučuji zkusit to trochu dostudovat, pokud chcete zkusit technickou VŠ (strojní nebo mechatroniku). Ony ty středoškolské základy nejsou kdovíjaká rychta. Pokud budete mít rok volněji, a tempo si budete určovat sám, a blbosti budete přeskakovat (populárně naučné zmínky o teorii relativity a tak) tak to učivo fyziky z gymplu za čtyři roky myslím není kdovíjaký masakr, ani na to není potřeba kdovíjak vysoká matika. Jsou to dvě až čtyři učebnice... Důležité myslím nakonec je, pobrat základní principy newtonovské fyziky. Dá se říct, že učebnice fyziky pro gympl by se zřejmě dala číst trochu jako takové "už vím proč", jenom možná trochu méně zábavné a čtivé. Jak říkám, školometskou buzeraci přeskakovat :-) Co já si pamatuju, tak třeba když jsem se v dospělém věku dávno po škole snažil aplikovat základní vzorce pro oscilační děje (které znám původně jako 2*pi*sqrt(LC) z elektroniky) na mechaniku, konkrétně hydro-pneumatické soustavy, tak jsem s tím zápasil pomocí gonimetrických funkcí a prvních dvou semestrů VŠ matiky už po svém, tohoto se střední škola ani nedotkla - a asi bych to nepotřeboval ani na nějakém mechatronickém studiu. Fakt je, že fyzika ve škole měla něco do sebe. Při práci s rovnicemi si dávat bacha, zda to sedí jednotkově, apod. Tyhle "řemeslné fígle" bych se možná "na vlastní pěst" učil trochu těžko :-)

Možná se zkuste začít rozhlížet po nějakém relevantním zaměstnání. Klidně jako vedlejšák při škole. Totiž zaměstnání (s trochou štěstí) poskytne jednu věc, kterou ve škole a v soukromí tak často nepotkáte: reálné problémy k řešení. Od maličkostí, po rozsáhlé věci, kde Vás časem napadají všelijaké monstr-projekty... spousta problémů, různě rozsáhlých, kde si můžete vybrat, do čeho se pustíte, a nad čím mávnete rukou... a každý vyřešený problém, na kterém jste něco odpracoval, přinese šlehu dopaminu. Jde taky o to, vybírat si takové problémy, které je šance v nějakém dohledném čase vyřešit.

Bohužel dneska ve spoustě IT firem jste za kacíře, když vezmete do ruky šroubovák.
Mně se podařilo usadit ve firmě (směrem do průmyslových počítačů a sítí), kde mám jako pracovní pomůcku osciloskop, pájecí+odsávací stanici a nějaké další věci, zdědil jsem starší Sitemaster (FDR), pár přípravků jsem si postavil... přesto jsem pracovně bastlíř spíš na okraj. V malé firmě, práce všeho druhu. To že si smím umazat ruce pájením, assemblerem a všelijakými semi-custom sondami, to je v zásadě moje aktivita, ve které mi zaměstnavatel nebrání, ba dokonce mám pocit, že mě v ní v přiměřené míře podporuje :-) Považuji se v tomto ohledu za šťastného zaměstnance.

Firem, které dělají echtovní vývoj hardwaru, není u nás mnoho - mám z nich povětšinou pocit, že stojí na zapálených jednotlivcích, kteří se nebáli, začít se vývojem elektroniky živit na vlastní pěst, což je v mých očích ta nejobtížnější cesta vůbec... znám totiž taky pár lidí, kteří to zkusili, a vycouvali.

Bohužel technický a společenský pokrok a specializace znamenají, že masová elektronika je už tak miniaturizovaná, zapečená a levná, že na ní prakticky není co kutit a téměř ani opravovat - smíte ji trochu programovat, když vám to výrobce dovolí, v nějakém prostředí hodně vysoké úrovně. Mobil je pěstní klín. Součástky jsou levné, lidská práce drahá, zejména ta kvalifikovaná = nevyplatí se vyvíjet pro jednotlivé kusy. I v průmyslu, kde jsou ceny zařízení relativně vysoké, je cena práce vlastně ta nejhorší nákladová položka. Úspory z rozsahu výroby jsou opravdu děsivé svinstvo. Vývoj probíhá v pár "továrnách na čokoládu" v několika centrech různě po světě, tady u nás spíš ne - a obecně vývojáři mívají dost tvrdý chleba, ať už jako spoluvlastníci firem / živnostníci, nebo jako zaměstnanci.

Takže člověk kterého už živí něco jiného, může bastlit leda jako koníčka, což soukromě může lézt do peněz, chce to mít doma trochu prostoru na práci, rodina si připadá odstrčená atd... Dokonce mizí z trhu některé součástky, ze kterých jsem jako kluk bastlil. Prostě vývoj jde dál. Zatím nám nesebrali operační zesilovače a nohaté tranzistory, ale vidím, jak ty staré časy mizí...

Příležitost vyvíjet nebo opravovat nějaký hardware tady u nás je fakt už jenom v oblastech Embedded a MaR, kde ještě potkáte integraci nižší úrovně, menší počty vyrobených kusů, a díky vítězství "vendor lock-in" nad standardizací také pestré prostředí, kde se vyskytují potřeby tu a tam něco přiohnout / zintegrovat / dovyrobit nějakou periferii... nebo aspoň provést do hloubky diagnózu. Zároveň se v "průmyslu" ještě točí nějaké peníze za fajnové know-how v těchto oborech. Pokud se Vám nepovede vymyslet nějaký svůj fajnový produkt a rozjet kolem něj živnost, nebo se přitočit někam, kde Vás využijí s vývojem HW jako zaměstnance, tak je tu myslím dost velká spousta "integrátorských" pozic, kde stavíte z nekonečné lego-stavebnice, a je po Vás rajtováno, abyste ke každému dílku měl CE prohlášení o shodě, podložené zkouškou v souladu s XY normami, výrobce nejlíp aby měl ISO9001... Je třeba říct, že i ve "skládačkové" projekci/integraci průmyslového MaR (v nejširším slova smyslu) jsou potřeba asi hlavně léta zkušeností a "mezioborového" rozhledu - načichnout "inženýrským fortelem" a nadhledem prostě chvíli trvá, čerstvě z vejšky zejm. bez nějakého vedlejšáku při škole je člověk prostě zelenáč :-)

https://knihy.nic.cz/files/edice/Porty__bajty_osmibity.pdf
No - tvle...
Jenom jsem to proletěl - to je maso... !

24
Software / Re:Existuje PLC S7 simulator s TCP/IP (open/free)?
« kdy: 28. 07. 2020, 19:09:01 »
Existuje softwarový Profinet Master Simulator (komerční software), který vyrobí nějaký ten provoz na síti - zejména pokud mu dodáte taky nějaké profinetové slavy. S originálním Siemensím PLCčkem to má společného opravdu jenom ten Profinet (formát dat na LANce).

25
Vývoj / Re:Přerušení v Linuxu
« kdy: 26. 07. 2020, 21:22:53 »
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)

Díky za ten odkaz... moc hezké čtení, v podstatě to shrnuje všechny moje námitky :-)

User space chápu jako prostor, který je od hardwaru naschvál poněkud izolován, běží nad nějakou abstrakcí stroje s jednotným softwarovým rozhraním. User space je prostředí relativně lenivé, pokud se týče doby odezvy a její garance, ale na druhou stranu nijak děsivé pro programátora - a v zájmu stability systému toho user space zas tak moc nesmí.

ACKování IRQ je věc, kterou se patří dělat v "IRQ kontextu", což je z hlediska plánování procesů/tasků atd. poměrně vyjímečné místo s výsadními právy, zejména vysokou prioritou běhu, např. tam může být zakázáno další přerušení (nebo lze znovu rekurzivně přerušit jen IRQ linkou o vyšší prioritě). Pointa je v tom, že kromě ACKnutí interruptu standardním způsobem hostitelovu řadiči přerušení (tzn. charakteristicky pro danou platformu počítače) mívají jednotlivé periferie svá vlastní pravidla, jak je třeba v dané periferii HW-specificky zašťourat, aby (v kontextu naší debaty) dočasně zmlkla, tzn. aby po návratu obsluhy přerušení (ISR) nebyla obsluha volána okamžitě znovu toutéž periferií. Viz level-triggered IRQ na PCI, tam se snad ani nic "genericky" neACKuje. Druhá varianta je, že pokud IRQ řádně neACKnete HW-specifickým způsobem, periferie už nikdy další interrupt nepošle (toho bych se bál u edge-triggered IRQ) - ale tato varianta je obecně snad méně časově kritická, a zrovna tenhle druh ACKu by se dal odložit do nějaké té "obsluhy druhé úrovně" (ACK je proveden nějakým relativně standardním = řádně plánovaným taskem, v kernelu nebo i v user space).

Chci říct, že ISR kontext a user space jsou dost protichůdná prostředí. ISR kontext má přednost i před kernelovými tasky. Naopak mít v user space zakázané interrupty? Z toho mám trochu husí kůži... Plánovač procesů potřebuje povolené interrupty ke svému provozu. Nemám teď úplně jasno, jak "drahý" je odskok do normální kernelové obsluhy IRQ, vs. co by znamenalo, mít obsluhu navíc v adresním režimu user space (jestli by ten context switch byl nutně těžkotonážnější).

V tom historickém kontextu na LWN se správně píše, že se věc komplikuje u sdílených IRQ linek, a že ohledně zmíněného HW-specifického ACKování v samotné periferii byl i nějaký návrh, toto pro jednodušší případy popsat nějakým structem, který by se dal předat při inicializaci user-mode driveru z user space do kernelu, a generická obsluha (ISR) v první linii v kernelu by podle tohoto "receptu" provedla základní držhubný ACK, aby se interrupt mohl odblokovat (například pro další  periferie sdílející tutéž linku). Pokud mohu soudit, neujalo se to...

Tzn. request_irq(IRQ,*obsluha) podle mého patří právem do kernelu, v user space bych se tohoto nedožadoval :-) Mimochodem v kernelu request_irq() nezapisuje přímo do tabulky vektorů, se kterou pracuje CPU LAPIC - kernel má jednotnou super-obsluhu, která se zavěsí na všechna IRQ obsluhovaná LAPICem, a teprve tahle superobsluha volá obslužné rutiny (callbacky) registrované jednotlivými drivery (kernelovými moduly). Je to pravda už hodně dávno, co jsem to ve zdrojákách našel - snad se na tom moc nezměnilo :-) Dovedu si představit, že tahle superobsluha umí čítat počty interruptů (pokud to nedělá hardware LAPICu) a mám pocit, že přímo tahle superobsluha umí po ukončení "užitečné" obsluhy taky zavolat plánovač, tzn. v tom případě není pravda, že je plánovač probouzen pouze konkrétním časovačem (a procesy, které se procesoru dobrovolně vzdají tím, že usnou/zablokují se).

Hergot to jsem zase ujel...

26
Vývoj / Re:Přerušení v Linuxu
« kdy: 26. 07. 2020, 08:54:46 »
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.

Joahaa! konečně chápu zadání, díky...

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.

Strana 15 nedořekla jedno sladké tajemství: poll() je třeba volat na pseudosoubor "value" v tomtéž adresáři.
A k tomu terminologická vysvětlivka: syscall poll() nedělá hloupé olizování, ale čeká na událost (aneb hlavně že jsme zmátli nepřítele.)

Trochu jsem se začetl, tady jsou k tomu nějaké další střípky:

https://www.kernel.org/doc/Documentation/gpio/sysfs.txt
(hledejte klíčové slovo "edge")

https://blog.frantovo.cz/c/355/GPIO%20v%C2%A0Raspberry%20Pi%20jako%20soubory

https://www.raspberrypi.org/forums/viewtopic.php?t=7509

...a jenom velmi na okraj (popravdě tam o IRQ není vlastně nic):

https://www.ics.com/blog/gpio-programming-using-sysfs-interface

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.

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... prostě ten interrupt se na nejnižší úrovni musí obsloužit a ACKnout v kernelu (aby se nezacyklil) a pokud tato podpora v kernelu existuje, tak user space dostane už jenom výslednou relativně nezáludnou událost. BTW, asi chápu, proč jsou ty GPIO interrupty edge-triggered (nikoli level-triggered).

27
Vývoj / Re:Přerušení v Linuxu
« kdy: 24. 07. 2020, 12:44:07 »
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...

28
Bazar / Re:Sháním knihu PC FAND krok za krokem
« kdy: 15. 07. 2020, 20:13:00 »
Tomu říkám retro. Kdo v tomhle ještě něco údržbuje? On PC-FAND přežil Y2k ? Ale když některé podniky udržují v provozu prostředí historických mainframů virtualizované/emulované na moderních PC, tak asi proč ne PC-FAND...

29
Hardware / Re:KVM s DisplayPortem a USB?
« kdy: 15. 07. 2020, 20:09:54 »
Obecné problémy:

DP a HDMI jsou o dost háklivější na rušení, než staré dobré VGA. Tam sice rušení třeba taky vidíte, ale nezhasne Vám to obraz.

KVM nemívají galvanicky izolované vstupy, ať už jde o DP, HDMI, nebo staré dobré VGA. Takže stačí pár metrů dlouhý stůl na dílně, a budete řešit zemní smyčky. Největší peklo je to u počítačů napájených centrálním rozvodem "bezpečného malého napětí" (u nás typicky 24V) kde je pracovní zem spojená s ochrannou a s referenčními zeměmi signálových portů :-( Prostě větší KVM = zarušený signál.

Z toho mi plyne, že DP nebo HDMI má smysl tahat skrz KVM tak na 1-2 metry, dál ne. Na šestimetrovém stole už bych se bál, že to nebude prakticky moc použitelné. Rád bych se pletl.

Možná nejlépe průchozí řešení by nakonec byla redukce DP/VGA nebo HDMI/VGA a analogový VGA KVM switch. Ono to může být znát i na ceně kabeláže pro toho pavouka. Když točíte desítky počítačů denně, potřebujete kabely pravidelně měnit, protože konektory nevydrží dlouho.

Další možnost je IP KVM = hardwarové krabičky, ale to je cenově zase někde jinde. Mohlo by to řešit problémy se zemními smyčkami a délkou kabelů.

Tytéž problémy vídáme u "KVM extenderů" na CAT5 kabeláži. Dvě krabičky, vysílač a přijímač, přenesou VGA + USB na nějakou vzdálenost po CAT5 - ale není to galvanicky izolované, má to jenom diferenciální budič a přijímač, ovšem bez oddělení referenční země. Je to analogový přenos nad 4x twistovým párem, nikoli IP KVM nad Ethernetem.

Pokud někdo víte o razantním řešení tohoto pekla, dejte vědět.
KVM nad optikou existuje, ale je drahé.
Znal jsem člověka, který se vykašlal na počítače a internety a šel šéfovat do pekárny...

30
1. na stravenky se nevrací normálně

Jojo... na jednom předchozím pracovišti se soukromé dluhy mezi kolegy
půjčené v hotovosti vracívaly ve stravenkách :-D

2. musíš na ně myslet, nosit je ssebou, vytahovat je z peněženky, počítat...
3. teď ani nevím, dá se zbytek nákupu po stravence zaplatit kartou?
4. zaměstnavatel za tu stravenku zaplatí víc => místo 1000 ti mohl dát třeba 1100 (i když část je daňově uznatelný náklad, takže těžko říct, jak by to vyšlo zdaněný)

...popravdě nám teď zaměstnavatel zavedl stravenkové karty, takže vracení na stravenku odpadlo. Ale pořád je tam denní limit asi 500 Kč, takže se člověk v krámě musí zamyslet. Vlastně už 800, ale nad 500 si musím pamatovat pin, a ten si nepamatuju. A kartu neberou všude - třeba malí obchodníci můžou brát papírové stravenky, za které následně nakoupí někde v sámošce... tohle s kartou nejde.

Stravenky jsou takové "podřadné peníze", které při shodné nominální hodnotě poskytují menší svobodu užití (směnitelnost). Rozuměl bych tomu, že u lidí s opravdu nízkým příjmem asi mají motivovat k nákupu jídla - nejde za ně nakoupit chlast, nejdou naházet do automatů, nejde v nich zaplatit přemrštěný nájem. U vrstev s průměrným a nadprůměrným příjmem je to pro uživatele (zaměstnance) čistý opruz. Pokud nežiju od vejplaty k veplatě, tak prostě utratím stravenky za cokoli, za co utratit jdou, a tím pádem mi ekvivalent v hotovosti zůstane v druhé kapse (na účtu) - jenom s tím mám starání navíc. Možná mě to má motivovat k tomu, abych měl každý den teplé jídlo? Zajisté z hospody... ale tam bych chodil stejně, v kuchyni jsem dost neschopnej (minimálně časově neefektivní).

Měli jsme donedávna opodál jednu školní jídelnu, která vařila i pro veřejnost, ovšem stravenky nebrala. Takže jsem mohl hledat v okolí snesitelnou hospodu, která bere stravenky, nebo jít do velmi slušné školní jídelny za půlku či třetinu, ovšem za hotové. Přebytky stravenek se dají utratit v nemnoha velkých sámoškách, které jsou buď daleko, nebo mě nelákají sortimentem / cenami apod. Dvě slušné sámošky, co mám přes ulici, stravenky neberou. Utratit stravenky znamená cestovat kamsi autem, přitom omezení na 500-800 Kč denně.

Pokud se týče srovnání na výplatní pásce, tak je tam ta nuance, že z hodnoty stravenky si řádově půlku platím sám, ze svého čistého příjmu. Kdybych dnes odmítl stravenky, dostanu na účet bez řečí tu svoji cca půlku v hotovosti, a zaměstnavatel mi možná přisype "svůj příspěvek na stravenky" snížený o všechny daně a "daně", které z toho bude muset odvést. V zásadě bych se zřekl té úlevy na daních. O kolik by to bylo všechno jednodušší, kdyby "příspěvek na stravu" byla odečitatelná položka v daňovém přiznání (paušální snížení základu daně). Když už teda stát chce dělat hodného strýčka.

Ona je ve finále otázka, jak si mocipáni vyhodnotí, že jejich relevantní voličská základna stravenky vnímá, a jestli jim to pořád ještě stojí za to. Tu a tam vnímám jakési mediální pokusné balónky, možná hlavně od posledních voleb.
Je myslím dost jasné, kdo nominálně vydělává na procentech za provedenou stravenkovou platební operaci. Pokud mohu soudit, zaměstnanec ani stát na stravenkách nominálně přímo škodní nejsou. Možná díky tomu se to tak dlouho udrželo.

Modulo všelijaké jalové konotace s rovnou daní, superhrubou mzdou, zjednodušením daňových přiznání, celkovou daňovou zátěží a souvisejícími dalšími pokusnými balónky z poslední doby... od "revoluce" jsem viděl už všelijaké kotrmelce v daňové legislativě, ale nevybavuju si, že by se mi někdy snížily daně.

Stran: 1 [2] 3 4 ... 44