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 - Wasper

Stran: 1 ... 6 7 [8] 9
106
Distribuce / Vhodná distribuce pro hrátky s AI (Real-ESRGAN)
« kdy: 18. 12. 2022, 11:44:49 »
Zdravíčko vespolek,
Po třech dnech částečných neúspěchů přicházím s prosíkem o vynadání do lam a radu, jak to dělat správně.

Začal jsem si hrát s $SUBJ - https://github.com/xinntao/Real-ESRGAN . To, že to nejde na CPU jsem zjistil poměrně rychle, vyřešil jsem to přidáním 250GB SSD do herního kompu, kde mám nVidii 1650, nainstaloval čistý Debian 11, a začal si hrát, a narážím na jeden problém za druhým.
Nainstalovat cuda nebyl problém, pak jsem postupoval přesně podle zadání - Python, Miniconda, Pytorch, git clone ... podle postupu, vše OK.
Tak se těším, že pustím podle návodu, a dostavilo se dependency hell v Pythoním provedení, změna API v TorchVision 0.13., pak bylo potřeba ještě opravit načítání monochromu. To jsem po složitém kachnění nakonec odignoroval (a pak i opravil), ale stejně jsem se dostal k tomu, že polovina "upscalnutých" obrázků byla černých.

Postupně jsem prošel několika reinstalacemi, různými downgrady PyTorch, Pythona i OpenCV, pak už i komplet reinstallem, downgrade na Debian 10 (Python 3.7), pokus na Slackware 15 - v jedné konkrétní konfiguraci s dowgradnutým TorchVision mi to fungovalo na všechny vzorové obrázky, ale už jsem nedokázal zreplikovat, jak se k ní dostat. A když jsem v ní zkusil síť trénovat, tak stejně se to vyhroutilo.

Co se týče černých obrázků, došel jsem až na opencv - Obrázek se na cv2.imread() načetl správně (byly vidět v print(img) nenulové pixely i rozměr), až na to, že na cv2.imshow(img) to opět ukázalo černé okno. Dokachněno že v opencv 4.3.xxx byla podobná chyba, tak jsem zkoušel několik různých verzí, bez jakéhokoli úspěchu, všude černo.

Tak bych se rád zeptal - poradíte linuxovou distribuci, na které Vám to funguje na první dobrou? Případně setkali jste se s podobnými chybami a podařilo se vám je nějak překonat?

107
Vývoj / Re:Go - alternativa atomics pre prilezitostne zmeny?
« kdy: 14. 12. 2022, 20:58:42 »
Třeba x86 nemá ani instrukce pro atomické čtení/zápis
LOCK XCHG,
LOCK CMPXCHG
První měl už 8086 blahé paměti.

108
Vývoj / Re:Srovnání algoritmů na prvočísla
« kdy: 07. 12. 2022, 01:21:06 »
A jde o časouvou a ne pamět. Nárocnost
Můžu se zeptat, co je opravdu cílem cvičení? Obvykle v reálu jde o tradeoff mezi výpočtem a pamětí. Přesněji - co to je "velké vstupní n"? Protože mám pocit, že v tom máte zmatek a že ve skutečnosti se bavíte o nízkých desítkách bitů maximálně. (a pak nemá smysl mluvit o asymptotách). Pokud jde o velká čísla (u bezpečných šifer se bavíme řádově o kilobitech, pokud prvočíslo použijete na vytvoření eliptické křivky, tak ve stovkách bitů), pak vřele doporučuji pročíst zde https://en.wikipedia.org/wiki/Primality_test#Probabilistic_tests a optimálně ještě od Bruce Schneiera knížku Applied Cryptography.

Navíc ale ono taky záleží jaká operace, třeba násobení n-bitových čísel znamená n * (rotace + sčítání), takže tam pak máme nějaké ln(x) ke složitosti navíc.

Ktomu doplňme, že i na paměti záleží. Hustota prvočísel je x/ln(x). To znamená, že pro tabulku 64-bitových prvočísel (potřebných k faktorizaci 128bit čísel) potřebujete cca 3ExaByte, což není málo ;-)

Citace: CPU
Pokud jde o známá prvočísla, pak existuje rovnice, která s konstantní (relativně malou)
nemáte prosím odkaz? Připadá mi to příliš dobré, aby to byla (obecně) pravda (aneb, proč se třeba při genrsa používají probability testy a ne ta rovnice), tak by mě zajímalo, o co jde a jaká to má ty "ale".

109
Arduino vám klidně přeloží i něco jako tohle:
...
Tak ono to staci napsat takhle a jde to i po bitech (prelozi se to na instrukce SBI a CBI, az na rezii loopu 4MHz), to same zjevne dela i WRITE z fastio. Navic volat to takhle v loop() je nestastne, nejen kvuli call a ret (to jsme na 2MHz), i kvuli  tomu ifu (dalsi 4 cykly, takze nesymetrickych 1,3MHz). Ale to uz se šťourame v detailech, podstatnejsi je ze z Arduino knihovnama to dá na nějakých 160kHz.
Navíc je fakt hloupé, že v referenci od toho digitalWrite vůbec není v notes and warnings poznámka, že je nešťastně pomalé a pro rychlejší přístup je třeba použít přímý přístup, to mi vadí mnohem víc než ta samotná pomalost. :)
Kód: [Vybrat]
#define nano_pin2port(pin) ( (pin)<8 ? &PORTD : (pin)<14 ? &PORTB : &PORTC )
#define nano_pin2mask(pin) ( (pin)<8 ? 1<<(pin) : (pin)<14 ? 1<<((pin)-8) : 1<<((pin)-14) )

__inline__ void nano_digital_write(int pin, int val)
{
    volatile uint8_t *out = nano_pin2port(pin);
    if (val) {
        *out |= nano_pin2mask(pin);
    } else {
        *out &= ~nano_pin2mask(pin);
    }
}

110
I to řízení IGBT lze jednoduše v Arduinu napsat - prostě použijete jen setup() a loop() a kód napíšete v čistém céčku.
Mno, cynicky poznamenám, že když na 16MHz Arduinu samotnej digitalWrite() sežere plus mínus (nedohledával jsem časování všech instrukcí, co neznám, dostalo 1 takt) 52 taktů, tak ono ani nic jiného nezbude ;-) přitom když se to napíše normálně, tak jsou to takty přesně dva, to už se něco časovat dá. Tam se spíš bojím čistě HW kvality, že jakákoli chyba čínského výrobku, když by se náhodou zasekl s jedničkou na výstupu, může být za 3f můstkem opravdu efektní.

BTW místo setup() a loop() radši vyhodit celé core.a z linkování a rovnou můžu použít standardní main().

Ostatně i viz odkaz od Jendy u Průšy - WRITE z Firmware/fastio.h je použito na 268 řádcích, digitalWrite jen 23.

111
Obcas sa desim toho, ked vidim, ze niekto si v arduine robi ovladanie kurenia, alebo projekty, kde zlyhanie moze mat fatalne nasledky.
Tak přiznávám bez mučení, tohle se týká i mě. Ale na svojí obranu musím podotknout, že maximální představitelná škoda, kterou je to hypoteticky schopné bez obsluhy napáchat, je vyplácání asi dvou kubíků vody z vodovodu přes vychlazovací smyčku, kterou ale ovládá mechanický termostatický ventil a tedy mimo dosah nespolehlivé čínské kopie.
Z čeho naopak mám (časem) strach je řídit tím IGBT na indukční pícku, to bude asi dost často barák bez proudu ;-)

Citace: Jakub Štech
Arduino (Wiring) je od začátku určeno pro umělce, kteří chtějí rozblikat/rozhýbat svoje výtvory, aniž by se při tom museli zbytečně něco učit. To neučení je naopak jeden z explicitních cílů a dodnes je to v projektu vidět,
Díky, takhle natvrdo řečeno mi to najednou zapadá do sebe a dává to smysl.

Bohužel asi je to asi dneska trend. Když jsem začínal, tak třeba k Atari bylo dost příruček (které jsme pokoutně kopírovali kde to šlo), ale třeba pro audio to začínalo vysvětlením funkce (Pokey, 4 kanály, děličky, posuvné registry) a pak popis jednotlivých registrů a pár jednoduchých příkladů.
Dnešní ekvivalent (a bohužel i to, co se učí děti) je "připoj na tyhle kolíky v DIN repráček a napiš v BASICu příkaz SOUND 100,20,5". A pochopit, co je za tím (a že zatím je něco netriviálního, s čím je potřeba počítat, počínaje spotřebou DS1820 při samplování, přes možnosti SPI/1w/I2C, jak reálně funguje vykreslování einku, že do toho serva jde PWM, že u toho ultrazvuku počítám dobu, než se vrátí echo apod.) se moc nenosí,  a když to člověka už zajímá, musí to složitě hledat.

Jako za mě jednoznačně malé bezvýznamné plus za referenci Atmelu. Zato Waveshare by zasloužilo...

112
Tak arduino jako HW ani jako libky ci IDE jsem nikdy nepouzil.. vzdy je to vlastni deska, vlastni kod a prime programovani.
Tak to chápu. Mě zatím Arduina celkem vyhovují (začínám znovu po hodně letech bastlit a už na to tak dobře nevidím, abych desky pro SMD kreslil ručně a pak to pájel pistolkou se smyčkou ze zvonkáče jako dřív, takže hotová deska docela pomůže), nakoupenou jich mám pěknou zásobu neoriginálních od Číňana tak různě za 1-2 eura a na nějakej větší podraz jsem zatím nenarazil (nepočítaje veselé historky z natáčení jako včerejší noc příjemně strávenou studiem referenčního manuálu, Arduinových knihoven a pak i assembleru, co leze z překladače ve snaze přijít na to, proč je výstup na e-Ink přes SPI nekompatibilní s použitím USART0 na debug - nakonec důvodem bylo to, že Nano získává 3.3V z FTDI, a ten eInk když překresluje, tak žere docela velké špičky, takže to celé šlo do resetu...), až na to, že jsem tak trochu nečekal, že doba pokročila a neoptimální jsou už knihovny na osmibity, no ;-)
Ale OK, beru to, že nejsem až tak divnej a tu obsluhu si napíšu vlastní.

BTW jak to tak čtu, je tu vlastně něco sehnatelného mezi Atmelem a RPi Zero, kde se dá snadno začít si hrát? Ta malina je třeba príma třeba na časosběrnou kameru, ale na malou meteostaničku mi přijde jako kanón na vrabce (a tam ani těch 200mA spotřeby v klidu moc nepotěší). Do myčky nebo ke kotli bude Arduino asi v pohodě, ale už třeba s tím einkem je dost trouble, když se nevejde do paměti ani videoramka, které jsou potřeba navíc dvě (ne, že by to nešlo to dorenderovávat za běhu, ale je to pakárna).

113
Ja na XMEGA resil podobnou obskurnost, kde byl soubeh preruseni a potreba atomickeho cteni 5B (dva 16bit kaskadovane pocitadla a jeste bajt ze sw pocitadla), s tim ze se externi hodiny do pocitadla nesmi zastavit. Nakonec to dopadlo tak, ze sampluji 2x a hlidam monotonnost, pokud je tam vada, tak znova. Tj v bodu preteceni (na kterekoliv urovni kaskady) vznika jitter (nelze nikdy ziskat otisk ktery by byl na hrane).
Tak koukám, že těch vtipností je tam víc. Já tu honím každý takt, pak si chci dodělat výstup na displej, tak koukám, jak se inicializuje SPI (aneb nastavit MOSI a SCK na out) až jsem radší kouknul do přeloženého assembleru a jsem zděšen - to je fakt u Arduina normální, že mapování čísla PINu na port a bit (digitalPinTo*()) nejsou dělané přes nějakou magii v hlavičkách, kterou kompiler v nejběžnějším případě port# konstanta odoptimalizuje pryč, ale přes lookup tabulky v programové raměti? :-(
No jdu si dát radši panáka, a začínám mít čím dál větší úctu ke každému, kdo se tímhle musí živit....

114
hmm vypadla mi tam negace, a editnout to nejde :(

115
Jen u té vaší metody cli() sei() musíte mít jistotu,
Což u vlastního programu mám (navíc cli sei jsou 2 takty, mov r,r cli mov r,r takty tři). Ale tam ten dotaz nesměřoval, to o co se snažím je se pokud možno zákazu interruptu vyhnout úplně.

Citace: Jenda
Příklad jak to dělá Arduino funkce millis (což je v podstatě tazatelův případ -- běží interrupt co každou 1ms inkrementuje čítač)
Jasný, u timeru je to celkem snadné (a stejně, konkrétně ten bych řešil radši nějak takhle, což za předpokladu, že se během 255 milisekund dostane alespoň na 10 cyklů času pro hlavní program bude fungovat)
Kód: [Vybrat]
unsigned int8_t tm_lo,tm_hi;

do {
    tm_lo = timerms_low;
    tm_hi = timerms_high;
} while (tm_lo != timerms_low);
což sice dá o jeden tik navíc, ale odpadne tam 5 cyklů ze 7mi se zakázaným interruptem.

Ale zatím mi pro obecné čtení () nejlepčí přijde konstrukce stylu
Kód: [Vybrat]
volatile int8_t data_valid;
volatile int nejaka_data;
// interrupt
nejaka_data++;
data_valid =0;

// hlavni program
int8_t mask = 1 << thread_id;
int data;
....
do {
    data_valid = mask;
    data = nejaka_data;
} while (data_valid & mask);
[/quote]
to že se to znovunačte i v případě, že mezitím dojde k běhu jiného threadu a ten bude něco číst asi vadit nebude. Jen holt jsem tak trochu doufal, že tam je něco jako LD HL,(mem) jako u Z80, které jsem si nevšiml, a která by pomohla docela hodně. :(

116
Zdravím, rád bych se zeptal - je na Arduinu nějaká lepší možnost než zákaz interruptů, jak atomicky přečíst int16_t popř int32_t?
Konkrétní příklad
Kód: [Vybrat]
volatile int msec;

/* interrupt rutina */
msec++; if (msec > 999) msec = 0;

/* main loop */
while (1) {
    ledka(OFF);
    while (msec < 900) ;      // <---- nekonzistence
    ledka(ON);
    while (msec >= 900) ;
    Serial.printf("je cas %i\n", msec);
}
Tenhle fragment zobrazuje casy 0 0 0 768 0 0 0 768 0 768 0.
Důvod je nasnadě, prvně se načítá low byte, pak high, a když se doprostřed trefí interrupt, který (už načtený) lo změní z 255 na 0, ale ještě nenačtený high naincrementuje z 2 na 3, tak v podmínce se porovnává 1023 < 900 a projde to dál.
OK, ale co s tím? jedna možnost je samozřejmě to obalit nějakým
Kód: [Vybrat]
int my_msec;
cli();
my_msec = msec;
sei();
To samozřejmě fungovat bude, jen se mi to moc nelíbí, reálně chci používat interrupty v množství nemalém (na druhou stranu ty 2 takty navíc asi moc nebolí), ale přecejen, není nějaké čistší řešení? Konkrétně u timeru by se to ošklivě dalo řešit tak, že si ten low byte přečtu znova a porovnám, u složitějších věcí nějakým bytem navíc, kde se nastaví dirty apod.
Ale kam směřuju otázkou - neexistuje něco snadnějšího? Koukal jsem na instrukční set a nic použitelného jako load dvou registrů neobjevil, ale je možné, že jsem slepej/blbej/oboje ;-)

P.S. To výše je jenom nejjednodušší příklad na osvětlení. Že do toho while je dobré dát __asm__ __volatile__ ("sleep") vím, a že to problém omezí, ale úplně nevyřeší (když přiletí interrupt od seriáku a hned pak od timeru, tak se taky může trefit nedobře) vím taky. A že volatile v interruptu se má načíst do lokální proměnné a pak zase po inkrementaci zapsat zpět taky...

117
Sítě / Re:Pasivní Wi-Fi repeater na 5km spoj
« kdy: 12. 11. 2022, 01:46:37 »
Mimochodem mám zkušenost kdy se mě v autě zasekl spínač světla v kufru a baterka se vybila úplně do nuly a ačkoliv byla jen půl roku stará, tak byla na vyhození. Čekal bych v zimě při provozu jen na solár stejný výsledek.
Ano, popis je třeba zde: https://cs.wikipedia.org/wiki/Sulfatace_(akumul%C3%A1tor) a částečně se to dá zkusit zachránit když nebyla vybitá příliš dlouho, pomocí několik cyklů s hodně pomalým nabíjením (200-500mA) jednosměrně usměrněným napětím a paralelně svítit do malé žárovky (2-5W/12V) obvykle pomohlo. (málokdy do plné kapacity, ale rok až dva se s tím ještě obvykle jezdit dalo)

Zrovnatak by bylo v zimě bláznovství nechat to olovo vybít na té retranslaci do nuly, prostě jak napětí klesne pod nějakou mez (nechce se mi to teď dohledávat, ale rychlý pohled do wikipedie mi dává +- za pravdu), tuším 12,2V při zanedbatelné zátěži), tak prostě dál nevybíjet a počkat, až to ten solár zase dobije.

118
Sítě / Re:Konec poskytovatele 365internet.cz
« kdy: 11. 10. 2022, 14:14:16 »
dnesni evropska/celosvetova ekonomika neni zrovna na nejlepsi zdavotni urovni a nejaka zazracna pojistovna ji z toho urcite nevytahne :(
Nezlobte se, ale ne. Doba je zlá, zdražují se vstupy, zdražují se pohonné hmoty a tím pádem doprava, zdražují se energie a to až několikanásobně. Mám plné pochopení pro skláře, kterému se zdražil plyn pětkrát, stejně tak mám pochopení pro slévárnu, kamioňáka, nebo i pekaře.

Poněkud méně už mám pochopení pro přeprodejce, kterému se ten hlavní vstup tak jako nezměnil, pokud už by se změnil, ví to s předstihem takže může podle toho změnit ceny, který má na měsíční bázi příjmy zajištěné (modulo nějaké procento neplatičů, s jehož navýšením se dalo od loňského podzimu počítat předem, u některých naopak dokonce získává vatu dopředu na bázi ročního předplatného) a přesto z nějakého důvodu neplatí (klidně tomu říkejte platí částečně) právě za svůj core business, na kterém je existenčně závislý, a zjevně dlouhodobě. (V opačném případě by se to neřešilo tady, ale na ČTU). Tam je něco hodně špatně.

119
Sítě / Re:Konec poskytovatele 365internet.cz
« kdy: 10. 10. 2022, 19:11:34 »
Zase tady michate dve rozdilne veci. Ve velkoobchodu (B2B) to funguje jinak jak pro koncoveho zakaznika (B2C) !!
[...]
A oznameni CETINu opomnelo zamerne fakt ze jeste den predem uhradili cast faktur ............ jasna manipulace s verejnym minenim .....
Pane podnikateli, devadesátky už dávno skončily. Neexistuje nic jako "uhradili část faktur", ani v B2B. Buď jsou po splatnosti, nebo nejsou. Chcete snad říct, že nejsou?

120
Odkladiště / Re:jak moc je whatsapp end-to-end?
« kdy: 01. 10. 2022, 23:34:33 »
Podle mě, pokud něco zašifrujete a předáte druhé straně, existuje pravděpodobnost, že to třetí strana rozšifruje.
To by ale nemělo být (v rozumném čase) u kvalitních šifer možné. Na druhou stranu, těch možností, proč E2E neplní očekávání, může být víc. Např.
- Klient ještě před zašifrováním provádí analýzu a výsledek posílá postraním kanálem Velkému Bratrovi. V dnesni dobe celkem běžné o tom uvažovat, Ona se nějaké záminka najde https://twitter.com/matthew_d_green/status/1423071186616000513  - bez auditu klienta to vyloučit nemůžete
- I pokud je implementace klienta bez poskvrny, pořád má provider pod rukou distribuci klíčů. Kontrolujete to?
- Cloud backup konverzace? etc.

Jinak během pár minut kachnění lze narazit na tohle https://courses.csail.mit.edu/6.857/2016/files/36.pdf - tam jsou myslím odpovědi na původní otázku.

Stran: 1 ... 6 7 [8] 9