Příspěvky

46

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 ;-)

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".

47

Vývoj / Re:Atmel ATmega328 (a další z rodiny) a atomické čtení

« kdy: 30. 11. 2022, 18:53:08 »

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);
    }
}


48

Vývoj / Re:Atmel ATmega328 (a další z rodiny) a atomické čtení

« kdy: 30. 11. 2022, 05:50:35 »

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.

49

Vývoj / Re:Atmel ATmega328 (a další z rodiny) a atomické čtení

« kdy: 28. 11. 2022, 19:19:08 »

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 ;-)

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

50

Vývoj / Re:Atmel ATmega328 (a další z rodiny) a atomické čtení

« kdy: 28. 11. 2022, 04:19:23 »

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).

51

Vývoj / Re:Atmel ATmega328 (a další z rodiny) a atomické čtení

« kdy: 26. 11. 2022, 06:22:13 »

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

52

Vývoj / Re:Atmel ATmega328 (a další z rodiny) a atomické čtení

« kdy: 25. 11. 2022, 10:00:55 »

hmm vypadla mi tam negace, a editnout to nejde

53

Vývoj / Re:Atmel ATmega328 (a další z rodiny) a atomické čtení

« kdy: 25. 11. 2022, 09:51:43 »

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ě.

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ě. :(


54

Vývoj / Atmel ATmega328 (a další z rodiny) a atomické čtení

« kdy: 24. 11. 2022, 17:34:54 »

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

55

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.

56

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ě.

57

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?

58

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.

59

Hardware / Re:Vliv teploty na chybovost disků

« kdy: 29. 09. 2022, 16:05:00 »

Nevím, jestli je to lepší příměr než co tu padlo nebo bylo odkazováno, ale v principu bych si to dokázal takhle představit (jen si nejsem jistý, jestli opravdu dává smysl i ten příměr, že částici, která už skoro pronikla membránou, může v průniku zadržet nebo pozastavit jiná větší částice z druhého prostoru tím, že do ní narazí).

Tak velikost molekul jsou zlomky nanometru, střední volná dráha molekul ve vzduchu je 68nm.
https://sk.wikipedia.org/wiki/Stredn%C3%A1_vo%C4%BEn%C3%A1_dr%C3%A1ha

60

Hardware / Re:Vliv teploty na chybovost disků

« kdy: 29. 09. 2022, 15:48:54 »

Edit: Pěkně kecám, on ten rozdíl není jen teoretický. On je velmi praktický - právě kvůli tomu, že jde o parciální tlaky He, musí mít ten He disk tak robustní obal.

Cemu rikate robustni? He disk fakt neni tlakova nadoba a ten plech se nebouli ani jednim smerem.
Kdyby tam dali membranu a udelali z He disku tlakomer, tak pri beznem pouziti by byla rovna.. nevyboulena ani jednim smerem.

Ze začátku nebude, časem (jak/pokud to helium začne unikat, ale pokud se tam neudělají větší póry kterejma by to N2/O2 vyrovnaly) to helium prostě uteče a ten podtlak tam bude (ja vím, není to intuitivní).

Nevyboulenej ten disk bude, protože z druhé strany na něj tlačí něco jiného zhruba stejným tlakem. Je výhoda, že to dělá naše atmosféra. ve vakuu by to asi chtělo mechanicky vyztužit, nebo tak něco, každopádně únik helia by to nezvedlo (modulo nějaké efekty z deformace).

U disku zalezi jedine na druhu a zpracovani materialu - aby nebyl moc porovitej.

Souhlas, přesně o to jde. Přes ten materíál se prostě tlačí pod tlakem cca 0.1MPa helium pryč a on ho tam musí celou dobu životnosti udržet dostatek, aby to dokázalo udržet hlavičky nad plotnou.