Kā konkrēti izpaužas C++ valodas tuvums "dzelžiem".

[AndrisBB]

Ja runājam par GPIO vai citu interruptu apstrādi Linuxa kernelī, tad pat uz zem-gigaherca CPU, tas būs nanosekundēs.

 

Reku pat kāds pacenties un sazīmējis grafikus starp consjūmeru līmeņa RPi bez jebkādām optimizācijām, real-time kerneļiem un tevis pieminēto 8bitu mikrokontrolieri.

Starpība 10 vs 20 us. Ja optimizētu, tad nekādas starpības nebūtu, visdrīzāk būtu pat ātrāk.

Kam tieši tev vajag lielāku precizitāti?

 

Pat līdz jūzerspeisam Pitonā events nonāk 200 - 300 micro sekunžu robežās.

 

 

Tur jau galīgi jocīgam jābūt lai kautko taisītu Windowsā, iekš jūzerspeisa, uz x86, kam kautkāda saistība ar reālu laiku un vajag apstrādāt kādu signālu teiksim 10us robežās. Katrai problēmai savi risinājumi un rīki. Lasīt COM portu ar 1ms nobīdi šurpu/turpu pilnīgi neko nemaina un ir adekvāti.

 

 

Labots Septembris 3, 2022 - AndrisBB

[Grossmeister]

1 stundu atpakaļ, M_J teica:

Ja varētu runāt par tuvumu "dzelžiem" tad tikai un vienīgi assemblera gadījumā.

Exatly !

Labots Septembris 3, 2022 - Grossmeister

[M_J]

 

Negribas ar Tevi, Andri kašķēties, nešaubos, ka iekš procesora viss notiek nanosekundēs, tikai - kāds man no tā labums? Es tam vienkārši netieku klāt. Nemāku. Pa vidu ir operētājsistēma. Piemēram - ja gribēšu ieslēgt divus Mosfetus ar dažu nanosekunžu aizturi izmantojot, piemēram, Raspberry PI GPIO? Operētājsistēma man to, tā, pa vienkāršo, ļaus, jeb šī ideja vienkārši ir ārpus definīcijas apgabala? Ieslēgt/izslēgt gaismas diodi kaut kad -  ar +/- dažu desmitu milisekunžu precizitāti nav problēma, bet izdarīt prasīto ar nanosekunžu precizitāti? Vai ģenerēt divus sinhronus PWM signālus, tikai savstarpēji nobīdītus par dažām nanosekundēm? Nešaubos, ka dzelži to atļauj. Bet domāju, ka tā nav laba doma, mēģināt to realizēt uz Raspberry PI GPIO. Nesen uztaisīju nelielu programmiņu uz Raspberry PI, kas nolasa elektrības biržas cenas no internāta un slēgā patērētāju kontaktorus. Izmantojot  Raspberry PI GPIO. Izmantot GPIO sākotnēji likās laba doma, tagad tā vairs neliekas. Pārtaisu programmiņu, kur GPIO vairs netiks lietots.

Labots Septembris 4, 2022 - M_J

[AndrisBB]

Ar ko tad īsti atšķirsies uzrakstīt to tavu GPIO slēdzelešanas kodu draiverī salīdzinot ar atsevišķu firmvāri priekš MCU?

Interruptus, lai kautko darītu varēsi saregulēt tieši tāpatās (prioritātes utt). Skaidrs ka kamēr koda izpilde nonāk līdz tavam draiverim, tur būs salīdzinoši mazliet ilgāka aizture kā uz MCU, jo vienkārši vairāk koda, kas savā ziņā atkal kompensējas ar lielākoties ātrāku CPU. Tapēc jāskatās kāds konkrētu MCU utt un kāds CPU. Ja prioritātes saliktas pareizi, tad jūzerspeiss un updeiti pagaidīs.

 

Pirms 53 minūtēm , M_J teica:

Es tam vienkārši netieku klāt.

Kam tu netiec klāt? Drivera kodu raksti tāpat kā jebkuru citu, nokompilē un ielādē draiveri. Viss. Nu OK, mazliet jāpastudē kā rakstīt draivera kodu, bet nekas sarežģitāks kā rakties pa MCU reģistriem.

 

Protams neviens nerakstīs draiveri, kas kautko dara ar nanosekunžu intervāliem, tas vienkārši noslogos CPU un tam neatliks laika darīt ko citu. Tapēc tagad gadndrīz visos CPU vēl nāk pa kādam iebūvētam MCU, ko vari izmantot tādiem mērķiem.

Bet ja runājam par milisekundēm, mikrosekundēm, tad tā arī nav nekāda problēma uz parasta CPU.

 

Rēķini arī to ka visām programmām userspeisā ir +- vienāda prioritāte, un programmu tur ir daudz.

Ja kerneļa schedulers ir nokonfigurēts ar 1ms time-slicingu, tad pat ja ļoti gribēsi, kernels nepārslēgsies biežāk uz tavu programmu kā tas intevāls, tāka neko precizāku par to arī nedabūsi. Realitātē kernels pat mēģinās godīgi sadalīt laiku starp tavu un citām programmām.

 

 

Labots Septembris 4, 2022 - AndrisBB

[M_J]

Pirms 38 minūtēm , AndrisBB teica:

Protams neviens nerakstīs draiveri, kas kautko dara ar nanosekunžu intervāliem, tas vienkārši noslogos CPU un tam neatliks laika darīt ko citu

Nu bet protams! Netaisos rakstīt nekādu draiveri nanosekunžu intervāliem. Tā "avene" man ir tikai priekš tam, lai nebūtu jāņem bleķa plāksne, jāurbj tajā caurumi un jāskrūvē tajos slēdžus un lampiņas un visādus "pulksteņus".  Tas taču ir grūti. Tagad slēdži un lampiņas ir uz ekrāna. Viegli pievienot jaunus slēdžus un lampiņas, izmest nevajadzīgos. Ar galveno tiek galā mikrokontrolieris. Ak jā - vēl avene slēdzas pie internāta un niekojas ar kaut kādu grāmatvedību.

[Anonīms Alkoholiķis]

pirms 6 stundām , Grossmeister teica:

Exatly !

Nē, 

Fpga vai pašam ar žileti un trulu naglu zīmēt silikonu.

[Jurkins]

pirms 9 stundām , TOoMoOT teica:

WIndowsam Task Scheduler.

Velns 😁, kā šitas neienāca prātā... laikam vecs palieku 😁.

Dotajā gadīumā nav svarīgi, cik ms šur vai tur.

 

 

[Raimonds1]

Vispār tas ir interesanti, kādas sarežģītības uzdevumus risina ar gigahercu procesoriem.

Aizsūtīt 2 skaitļus - laiku (minūti, datumu, gadu) un kaut kādu vērtību, 8 vai 16 bitu skaitli.

Saņemt tos 2 skaitļus ik pa minūtei (1440 x dienā) vai 480 x darba dienā.

Salikt tos stabiņā, grafikā, kaut kāda kolāžā.

 

[Jurkins]

Pirms 37 minūtēm , Raimonds1 teica:

Salikt tos stabiņā, grafikā, kaut kāda kolāžā.

Kādā vēl kolāžā 😁?

Man vislabāk patika @M_J rakstītais par "slēdžiem, lampiņām un pulksteņiem'' 👍.

[Pukinens]

pirms 5 stundām , Jurkins teica:

Velns 😁, kā šitas neienāca prātā... laikam vecs palieku 😁.

Dotajā gadīumā nav svarīgi, cik ms šur vai tur.

Tikai informācijai, varbūt kādam noder...

Influx TICK paketē ir tāds lielisks atsevišķi darbināms rīks "Telegraf" - datu iegūšanai, transformēšanai un noglabāšanai starp daudzām dažādām sistēmām.

https://www.influxdata.com/time-series-platform/telegraf/

[Anonīms Alkoholiķis]

Kada veiktspeja uz rp2040?

Labots Septembris 4, 2022 - Anonīms Alkoholiķis

[Jurkins]

Uzsildīsim mironi.😁

Pa brīviem brīžiem lasu gudras grāmatas 😁 (labāk būtu ēdis kodis)

 

const uint32_t d1{100};
const uint32_t &dr1 = d1;
const uint32_t &dr2 = d1;

std::cout << "d1 = " << d1 << std::endl;
std::cout << "dr1 = " << dr1 << std::endl;
std::cout << "dr2 = " << dr2 << std::endl;
std::cout << "&d1 = " << &d1 << std::endl;
std::cout << "&dr1 = " << &dr1 << std::endl;
std::cout << "&dr2 = " << &dr2 << std::endl;

 

Viss kārtībā. Rezultāts:

 

d1 = 100
dr1 = 100
dr2 = 100
&d1  = 0xda6dbff840
&dr1 = 0xda6dbff840
&dr2 = 0xda6dbff840

 

Tagad izdaram muļķību... pievienojam rindu:

 

(const_cast<uint32_t&>(dr1))++;

 

Rezultāts:

 

d1 = 100
dr1 = 101
dr2 = 101
&d1 = 0xda8d7ff8c0
&dr1 = 0xda8d7ff8c0
&dr2 = 0xda8d7ff8c0

 

Lasu, ka reference visu savu dzīves laiku norāda uz vienu un to pašu mainīgo. Nu tā arī ir - 0xda8d7ff8c0. Bet kāpēc 100 un 101?

 

Ja dara šādi:

 auto d2 = (const_cast<uint32_t&>(dr1))++;

tad:

 

d2 = 100

 

 

[Anonīms Alkoholiķis]

Labāk tiešām būtu kodis, bet vari vel paspet nezaudēt iekavēto.. 

 

Ja liec rindas bez konteksta kur ko iespraud, tad debago pats.

[Jurkins]

Nu piedodiet...

#include<iostream>
#include<stdint.h>

int main(void)
{
    const uint32_t d1{100};
    const uint32_t &dr1 = d1;
    const uint32_t &dr2 = d1;
  
    std::cout << "d1 = " << d1 << std::endl;
    std::cout << "dr1 = " << dr1 << std::endl;
    std::cout << "dr2 = " << dr2 << std::endl;
    std::cout << "&d1 = " << &d1 << std::endl;
    std::cout << "&dr1 = " << &dr1 << std::endl;
    std::cout << "&dr2 = " << &dr2 << std::endl;

    auto d2 = (const_cast<uint32_t&>(dr1))++;
  
    std::cout << "d1 = " << d1 << std::endl;
    std::cout << "d2 = " << d2 << std::endl;
    std::cout << "dr2 = " << dr2 << std::endl;
    std::cout << "&d1 = " << &d1 << std::endl;
    std::cout << "&dr1 = " << &dr1 << std::endl;
    std::cout << "&dr2 = " << &dr2 << std::endl;

    return 0;
}

Rezultāts:

 

d1 = 100
dr1 = 100
dr2 = 100
&d1 = 0xa94b9ffd4c
&dr1 = 0xa94b9ffd4c
&dr2 = 0xa94b9ffd4c
d1 = 100
d2 = 100
dr1 = 101
dr2 = 101
&d1 = 0xa94b9ffd4c
&dr1 = 0xa94b9ffd4c
&dr2 = 0xa94b9ffd4c

Labots Decembris 26, 2022 - Jurkins

[AndrisBB]

Palaid gdb un apskaties

[AndrisBB]

d1 arī ir 101, tik tas ka tu tur nodarbijies ar visādu figņu

auto d2 = (const_cast<uint32_t&>(dr1))++;

Un kompilātors tādu neparedz. Optimezējot abās vietās viņš izdrukā hārdkodētu #100

 

std::cout << "d1 = " << d1 << std::endl;

        movw    r1, #:lower16:.LC0
        movt    r1, #:upper16:.LC0
        movw    r0, #:lower16:_ZSt4cout
        movt    r0, #:upper16:_ZSt4cout
        bl      std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)
        mov     r3, r0
        movs    r1, #100
        mov     r0, r3
        bl      std::basic_ostream<char, std::char_traits<char> >::operator<<(unsigned int)
        mov     r3, r0
        movw    r1, #:lower16:_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
        movt    r1, #:upper16:_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
        mov     r0, r3
        bl      std::basic_ostream<char, std::char_traits<char> >::operator<<(std::basic_ostream<char, std::char_traits<char> >& (*)(std::basic_ostream<char, std::char_traits<char> >&))

 

[Jurkins]

Skaidrs, ka ar figņu. Nu man patīk 😁.

Tas nozīmē, ka šādi var konstanti izmainīt?

[AndrisBB]

Kapēc lai nevarētu? Tu paņem random adresi atmiņā un izmaini tās saturu, kā lai kompilātors par to zin?

Tikpat labi tu vari tai adresē ierakstīt ko vien vēlies.

 

const_cast<uint32_t&>(dr1) = 0xdeadbeef;

vai uzreiz

uint32_t *p = (uint32_t *)0xa94b9ffd4c;
*p = 0xdeadbeef;

 

Tu jau nemaini konstanti, bet saturu kautkādā atmiņas adresē. 

Nav jau tā ka tapēc ka tu kautko nodefinē par const, tad CPU to adresi kautkā īpaši aizsargās pret izmaiņām. Viss tas const tāds kompilēšanas laika mājiems kompilātoram, ka to nevajadzētu mainīt caur mainīgo, bet ja tu pa taisno maini, tad ko tur kompilātors var izdarīt. Viņš jau nezin kāda adrese tieši tai konstantei būs runtaimā, lai neļautu mainīt.

[AndrisBB]

Uzliec static_cast un tev neļaus viņu mainīt.

Grūti iedomāties kur reālā dzīvē tev būtu jāizmanto const_cast. Tas vairāk kautkādos ekstrēmos gadījumos, kur tev jāstrādā jau ar esošu vecu sūdkodu.

[Jurkins]

OK, paldies, skaidrs.

Tas, ka paņemot adresi pa taisno var ierakstīt, ko grib, bija skaidrs. Nesavilku abas lietas kopā.

[AndrisBB]

Nu ja tu izmanto static_cast, tad kompilators redzēs ka tu `kāsto` constanti, tapēc neļaus `kāstot` viņu uz ne-konstanti. const_cast vienkārši to ignorē un pārkāsto uz parastu pointeri, ko pēctam tu vari izmainīt.

[Jurkins]

Par tiem "cast" ir ok, bet interesanti, kāpēc tā konstante c1 paliek kā bija 100, bet references 101. Ja, piemēram, uzraksta

2*c1, tad sanāk 200, bet 2*cr1 sanāk 202. Jeb kompilators "atceras", ka šamā bija 100?

 

Kā var vscode dabūt asmu, man tas disassembly logs ir tukšs. Debagojot pa soļiem arī.

[AndrisBB]

Es taks tev iepostoju kapēc. Tu viņu definēji kā const, tapēc compilātors iekompilē hārdkodētu vērtību. Pats saturs mainīgajā jau izmainās.

 

pirms 2 stundām , AndrisBB teica:

 movs    r1, #100

Viņš vienkārši visur kur tu izmanto d1 izprintē 100, jo tam nav jāmainās.

Pirms 14 minūtēm , Jurkins teica:

Kā var vscode dabūt asmu, man tas disassembly logs ir tukšs. Debagojot pa soļiem arī.

Pareizi kompilēt vajag, ar vajadzīgajiem flagiem.

Te vari debugot https://www.onlinegdb.com/online_c++_compiler

Ieliec te un apskaties kāda ir starpība start to kur tu printē d1 un kur tu printē pārējos

https://godbolt.org/

Kā arī kas izmainas ja tu noņem const no d1

Labots Decembris 26, 2022 - AndrisBB

[Raimonds1]

Tāds jautājums.

Procesoram ir frekvence. Megaherci, gigaherci datoram.

 

Vai ir iespējams ārēji, ar signālu palaist un apstādināt skaitītāju, kas noskaita 2 vai 4 vai 15 pamatprocesora taktis un attēlo šo te skaitli. Start-Stop, 2 taktis no 4 gigahercu procesora.

 

Paldies par atbildi.

 

Kaut ko meklēju pats, bet tur pārsvarā ir par koda izpildes laiku

https://levelup.gitconnected.com/8-ways-to-measure-execution-time-in-c-c-48634458d0f9

tas nav tas

[AndrisBB]

OS visulaiku maina procesora frekvenci.

Meklē Dynamic Frequenct Scaling

[Jurkins]

pirms 2 stundām , AndrisBB teica:

Ieliec te

Jāpalasa kāda gudra grāmata 😁 par asmu. Zināšanas par avr asmu manāmi nepalīdz.

[HIGH-Zen]

C++ tuvums dzelžiem sāk izpausties ar to, ka to pamazām sāk aizstāt tādas valodas kā Rust.

ENG 6min:

ENG 23min:

 

[AndrisBB]

Reāli jau ja runā 'tuvāk dzelžiem' tad 90% gadījumā tāpat ir runa par C.

C++ tas lielākoties jau mazliet 'augstākā' līmenī, var teikt sistēmas programmēšanā.

Maz ticams ka Rust aizstās C vēl ilgu laiku.

Ar C++ (vietās kur to izmanto) cits stāsts. Ja raksta jaunu kodu, tad kapēc ne Rust?

Vai arī ja mācās programmēt, tad kapēc mācīties C++, ja var mācīties Rust?

 

Linux kernelī ir integrēts Rust, bet vēl ļoti tālu no reāla pielietojuma. Tur C dominēs vēl ilgu laiku.

Ubuntu tagad aizvieto core-utils ar Rust versijām. Bet tas jau vairāk sistēmas līmenis.

 

Reāli, ja strādā embedded lauciņā, tad bez C/C++ tāpat neiztikt, tas vienkārši nav iespējams. Šur tur parādās kautkas iekš Rust, tāka to arī daudzmaz jāzin.

Bet nu to pašu arī var pateikt par Pitonu.

Tāka reāli standarta komplekts 'C/C++, Pitons, Bash' vēl dominēs vismaz manu atlikušo programmētāja karjeru.

Rust zināšana pagaidām ir bonuss.

 

Pārējās valodas pa lielam nav svarīgas. Bet nu ja var rakstīt C++, tad saprast un iemācīties jebkuru citu valodu (kas reāli aktuāla dzežū jomā) aizņem 2 dienas.

[HIGH-Zen]

Es C++ vietā lietoju Objekt Paskālu, tajā jūtos daudz produktīvāks. Te jāpiezīmē, ka pārsvarā veidoju GUI programmas (Win, Linux). Mans standarta komplekts ir C, Object Pascal, Python un dažādi Beisiki (t.sk. Basic to C), kā arī nelielas izvirtības ar Nim, Lua u.tml.. C++ (arī C# un Java) noder tikai tik daudz, lai papētītu citu projektus, ko tas tur dara.

 

Ar Rust līdz šim kaut kā nebiju saskāries.

Labots Maijs 30 - HIGH-Zen

[AndrisBB]

Katrs privātām vajadzībām jau var lietot ko grib. Bet nu ja strādā industrijā, tad realitāte ir tāda, ka jālieto tas, ko lieto tajā.

90% gadījumu tas būs C/C++.

 

Rust ar šād tad kāds lieto, īpaši jaunākos projektos. Nav jau arī tā ka tas būtu kautkas īpaši jauns, lietoja jau vismaz 10 gadus atpakaļ.

Mazliet jāpierod, bet nav ne vainas. Mācīšanās ziņā tas pats vien būs kas ar C++, tikpat sarežģits.

Jārēķinās arī ar to ka ja reizēm lieli C++ projekti var kompilēties stundām, tad Rust aizņem vēl vairāk laika.

 

 

Ir pat vesela OS rakstīta iekš Rust. Lielākoties strādā.

https://www.redox-os.org/

 

 

[AndrisBB]

No tādiem interesantākiem projektiem:

Mecha Comet UI un daļa applikāciju iekš Rust

https://mecha.so/comet

https://github.com/mecha-org

[HIGH-Zen]

Pirms 55 minūtēm , AndrisBB teica:

Katrs privātām vajadzībām jau var lietot ko grib.

Jā, ja projekts ir tavs, tad vari pats izlemt ko lietot. Paņem vajadzīgās datubāzes (OLAP) bibleni, kurai SDK ir C, uztaisi bindingus priekš paskāla un pitona un vari raustīt datubāzi pēc sirds patikas un izveidot GUI iekš Object Pascal vai Python PySide6. (iekš C++ tā būtu elle, C vēl varbūt varētu mocīt IUP GUI).

 

Piemēram gatavie prototipi viens no otra maz atšķiras (no kreisās Pascal, Python):

Labots Maijs 30 - HIGH-Zen

[raivix95]

Tas Google radītais Carbon projekts, ar ko viņi gribēja padarīt C tautai draudzīgāku, ir nonācis mēslainē vai tiek attīstīts?

[AndrisBB]

Padarīt C 'tautai draudzīgāku'?

Ir vēl vienkāršāka valoda par C?

(droši vien domāji C++)

[Jurkins]

Kāpēc tautai vajag rakstīt C? Tak lai raksta feisbukā vai instagramā.

[HIGH-Zen]

Jā, jamais droši domāja šo https://en.wikipedia.org/wiki/Carbon_(programming_language)

...Carbon was created to be a C++ successor...

The language is expected to have an experimental MVP version 0.1 in late 2026 at the earliest and a production-ready version 1.0 after 2028.

 

Kaut ko lēnām kustina.

[AndrisBB]

Problēma ar 'tīru' C ir ka reizēm tas ir pārāk vienkāršs, lai kautko izdarītu, nākas rakstīt ļoti daudz C. 😂

Bet nu lai saglabāte saderību ar 'veco' C, neko tur daudz neizmainīsi.

 

Būtu C+, tad būtu cita runa.

Pastāv protams visādi GLib GObject utt. Bet tur atkal savas problēmas.

 

Parasti jau gan strādājot 'tuvāk dzelžiem', valodas izvēlei ir visai maza nozīme, lielākoties jau pati 'problēma' kuru risina ir 100x sartežģitāka par valodām.

Labots Maijs 30 - AndrisBB

[HIGH-Zen]

pirms 9 stundām , AndrisBB teica:

reizēm tas ir pārāk vienkāršs, lai kautko izdarītu, nākas rakstīt ļoti daudz C.

Tāpēc es dodu priekšroku jau gatavajām C bibliotēkām, kur man pašam nekas nav jāraksta. Tik vien cik uzģenerēt bindingus priekš Pascal vai Python.

 

Tādā ziņā Zig izskatās interesants, tajā var importēt C biblenes pa taisno (to māk arī BCX Basic kas ir Basic to C translator).

[AndrisBB]

Lielākoties gatavās bibliotēkas var importēt tad, ja tu strādā pie sava projekta un tāda lieta kā licenzes, tevi neuztrauc.

Bet ja tu strādā pie reāliem komerciāliem produktiem, tad tu tik vienkārši nevari lietot katru random bibliotēku, katrai sava licenze. Kādam tas viss ir jāmenedžē, jāpārbauda vai pēkšņi nav mainijusies licenze un tev tagad jāmaksā par to bibliotēku, jā-opensourco utt.

Var sanāk tā ka tu pāris gadus ražo produktu un pēķšņi kāds iesniedz prasību, ka tu esi izmantojis viņu kodu utt.

 

Skaidrs ka nav jau arī tā ka pilnībā neizmantotu, bet jābūst pietiekoši uzmanīgam.

pirms 3 stundām , HIGH-Zen teica:

Tādā ziņā Zig izskatās interesants, tajā var importēt C biblenes pa taisno

Faktiski jebkurā kompilējamā valodā tu vari izmantot C bibliotēkas, it īpaši ja sakrīt ABI (application binary interface), bez kautkādiem īpašiem bindingiem.

 

 

Nu un protams ja tev jātaisa kautkas puslīdz nopietns, tad vienkārši tādas bibliotēkas neeksistē.

Ko tev dod bibliotēkas ja pimēram tev vajag uztaisīt produktu, teiksim kameru, kura sāk ierakstīt ātrāk par 100ms sākot no Boot time?

Nāksies izdomāt visādus custom risinājumus.

Sākt bootot CPU no sākuma kautkādā RTOS, kas setupo dzelžus, attēlu sensorus un to kalibrācijas, sāk enkodēt teiksim h265 un glabāk kautkur iekšs RAM. Tikai tad sāk būtot Linuxu kerneli un jūzerspeisu vai kādu citu custom OS.

'Pārņemt' esošo video strīmu un sāk likt kautkādā diskā utt.

Nekādas bibliotēkas tev tur nepalīdz, nāksies rakstīt ļoti daudz C kodu 😂 

Labots Maijs 31 - AndrisBB

[binary]

Nekādu problēmu, to visu var ar mcu iebūvēto "visual python" izdarīt.

Pat nevajag daudz koda rakstīt, iebūvētais chatgpt reāllaikā pēc vajadzības uzģenerēs.

Labots Maijs 31 - binary