Žirafoviny.cz

Tak záhada nebo nezáhada? dělá to co to má nebo nedělá?
nerozumím větě Citát:
tu proměnnou __lcde co přepíná řadiče v displeji, by měla pokaždé následovat nová inicializace, ne?

Těch displejů je asi tak 3 zasouvací místa typů a každej se chová trochu jinak, takže co se týče displeje (o kterým ani není uvedenej typ), těžko soudit.

Ale když jsme u těch proměnných, tak:

__lcde je definovaná jako Byte, ale používána je jako Bool (budiž, je pomocná, ale brr)

X a Y - 0 až 39 a 0 až 3 má být, je do čtyřiceti. S tím samozřejmě souvisí i následující podmínka.

Navíc - neznám teda Bascom - ale nějak tam nevidím zaokrouhlení na celý čísla těch generovaných proměnných, obvykle to bývala funkce tuším INT

A navíc se její hodnota má někde kopírovat na výstupy E a E1, což tam taky nikde nevidím. Jinak jsem mezitím zjistil, že LOCATE skutečně má hodnoty od jedniček, což je teda hnus.

A navíc se na těch "Ečkách" má potvrzovat pulsem (nevím teda odkud se vzala ta proměnná s dvěma podtržítkama a jestli náhodou nepatří k nějaký knihovně, říkám že Bascom neznám, a když to vidím tak ani nechci znát). A dost - prosím adminku, ať si to případně sloučí do jednoho příspěvku.

Uznávám, proměnná ___lcde by mohla být klidně BIT a fungovalo by to také dobře. V tomto případě ale nešlo o super hezký kód ale o jednoduchost

Proměnná ___lcde slouží k přepnutí signálů E1 a E2 a tím k přepínání mezi horní a spodní polovinou displeje.

Zaokrouhlování čísel netřeba, protože jsou deklarované jako BYTE a tudíž nemohou obsahovat desetinnou část, je to vždy celé kladné číslo.

A ano, příkaz LOCATE používá souřadnice od 1,1 do 39,4. Byť je to trochu neobvyklé, ale je to tak.

Asi jsem to napsala nejasně, jde o to, že program je funkční a v procesoru dobře funguje. Nicméně se chová trochu jinak, než jsem zamýšlela a čekala. Když jsem se pak hluboce zamyslela nad důvodem, tak jsem jedno pravděpodobné vysvětlení našla, ale nechci jej zatím zveřejňovat, protože o tom je tato otázka

Aha, takže záhada je spíš co je to ta otázka/neotázka, funguje dobře ale dělá něco jinýho než se čekalo.
Śel jsem do hospody na guláš, donesli mi segedín, byl výbornej, hádejte jestli problém byl v mým huhňání nebo číšníkově hluchotě
odpověď: guláš došel.

Sakra, tak to přece není. Kdyby byl program nefunkční, tak nejde přeložit a nebo jej procesor nebude umět provést. Tento program je formálně správně a překladač jej přeloží a procesor zpracuje.

Nicméně program se chová trochu jinak než jsem čekala a než by asi čekal kdokoli, kdo umí trochu Basic. Bascom totiž není nic jiného než trochu upravený Basic.

Takže ano, program v procesoru funguje a něco na displeji zobrazuje. Jenže zobrazuje něco jiného než se čeká a otázka proto zní, a zněla, proč tomu tak je?

Sakra tak proč píšeš že program funguje docela dobře, když zobrazuje něco jinýho než ty chceš? já tomu fakt nerozumím. Copak se dá říct třeba o nádražním tablu, když vypíše rychlík na Berlín místo motoráku do Frýdlantu, že pracuje docela dobře?

Ano, takové tablo funguje docela dobře, protože komunikuje, zobrazuje a něco vypíše. To, že je to chyba znamená, že není zcela v pořádku a je třeba jej opravit.

Kdyby takové tablo nefungovalo, tak nebude vypisovat nic.

Nebo je pro tebe "dobře" už to, že překladač ho vůbec přeloží a něco (cokoliv) to dělá? Pak by se tomu dalo rozumět. Třeba že
Citát:
není to samé jako
Citát:

Hmm. Pán bůh chraň před takovým pojetím "funkce"...
Chtěla bys navštívit takhle fungující třeba lékárnu? Dejte mi inzulín, dostanu glukózu, to neva, hlavně že to tu funguje, šup s tím do žíly

Pochopitelně, že to je rozdíl. Já ve svém programu ale takovou chybu nemám, ta chyba ji jinde. A kdyby tam ta chyba nebyla, tak můj program bude dělat přesně to, co dělat má.

Začínám mít pocit, že jsem asi fakt z jiné planety.

Citát:
To není hned potřeba, akorát programátor by neměl říct, že to funguje, a technik obecně, dokud to nedělá PŘESNĚ to co dělat má a to za všech vstupních výstupních napájecích meteorologických a politických podmínek.

Jinak Bascom je opravdu trochu svérázný sw, jednak odchylky chování různých verzí vůči hardwaru, jednak kvůli celkovému hurápřístupu autora a děsnýmu fuzzy fungování, proti čemuž se editor vůbec nijak nebrání. To klasický basiky třeba Qbasic nedovolil.

Vidím určitý rozdíl mezi tím, když řeknu, že program funguje dobře a nebo že funguje správně.

To první znamená, že prostě nějak běží a něco dělá, čili, že je formálně správně a ani překladač, ani procesor jej nevyhodnotí chybně.

Druhé znamená, že dělá přesně to, co se od něj chce.

Žirafko, chyby se dělí na dvě velké skupiny, a to chyby syntaktické (překlepy, chybějící znaky apod) a chyby sémantické (zavlečené). Na ty první vždy upozorní překladač, protože jak název napovídá, jde o chyby v syntaxi jazyka, které on dobře pozná. Na chyby sémantické upozorní jen zřídka a to ještě jen na ty základní (např. nedovolí zapsat do paměti definované pouze pro čtení apod), protože se jedná o chyby, které zpravidla detekovat nemůže, protože nenůže dost dobře tušit, co programátor přesně zamýšlí stvořit. Sémantické chyby jsou tedy právě chyby v logické konstrukci programu.

Říci o programu, který sice něco dělá, ale nedělá PŘESNĚ to co bylo zamýšleno, že funguje, skutečně nelze (a je jedno jestli nefunguje dobře nebo správně), z čehož zároveň plyne, že sémantické chyby jsou ještě horší chyby (taky dají většinou víc zabrat) než chyby syntaktické.

Navíc jsi nám ani v článku nepopsala co přesně bylo vlastně zamýšleno, takže buď můžeme podle zdrojového kódu jenom popsat co podle našeho mínění program dělá, a nebo můžeme naleštit křišťálovou kouli a pokusit se určit rozdíl mezi "dobrým" a zcela správným.

Ale o tom to přeci je, určit podle zdrojového souboru co má program dělat a případně se pokusit říci, co program dělá ve skutečnosti. Myslím si, že to je jednoduchý program na to, aby se to dalo odvodit.

No a až bude známé řešení, tak se zjistí, že hádky o chybách jsou sice přínosné (budu si to pamatovat pro příště) ale v tomto konkrétním případu trochu zbytečné. To však bude vidět až s tím řešením.

Citát:
No jo, jenže u Bascomu je to jako zatočit si s kolem štěstí
já si to snad nahraju do tý 2313.

Osobně hlavně nechápu, proč nejít rovnou do C na který je všude mraky examplů, knihoven a komunitní podpory, (když ten Bascom je stejně ze 3/4 "Cčko" - knihovny, definice proměnných, rozložení částí programu, částečně i syntaxe), a místo toho zvolit nějakej nestandard šitej horkou jehlou, kterej mě sice nic moc nenaučí (kromě obcházení jeho nedostatků), ale zato mi pok**ví vnímání obecných znalostí o technice, se kterou pracuju...??

Protože C prostě nechápu, nejde mi to do hlavy. Basic je na pochopení o dost jednodušší. A knihoven a příkladů je k němu také hodně, jen to chce vědět, kde hledat. Hodně toho je v Polsku a také přímo IDE má v sobě hromadu příkladů i knihoven.

Že by byl šitý horkou jehlou se mi nezdá, a o tom pokřivení vnímání obecných znalostí o technice by se asi také dalo diskutovat.

To je jenom mentální blok, to jsem měl dlouhou dobu taky, ve skutečnosti člověk používá nejčastěji jen asi osm různých příkazů, a nějaký datový typy a jejich délka (jako např. short, double nebo long) ho vůbec nemusí zajímat, když si na začátek napíše a používá datové typy ve znění např. uint8_t (z nichž je hned patrné o co jde). Ten Bascom se od C téměř vůbec neliší (jak jsem už psal), ale než si to člověk připustí... S přepsáním toho kódu nahoře do C bys neměla sebemenší problém.

A navíc jeden zkušený starý programátor mi kdysi prozradil, že
Citát:
Ale pššt, to je tajemství...

A stejně to C už umíš, když píšeš PHP... jenom o tom nevíš.

PHP != C a přesto s ním dost zápasím, rozhodně nelze říci, že to jde snadno. V Bascomu je všechno o dost jednodušší, protože má jasnou a přehlednou syntaxi.

Proměnné si na začátku nadefinuji a pak je to už jedno, dá se udělat i přetypování, ale to jsem ještě nikdy nepotřebovala. Proměnná může být Bit, Byte, Integer, Word, Long, Single, Double a String.

Oproti C je přímo optimalizovaný pro AVRka a 8051, počítá s málo paměti a nepočítá se s tím, že se program bude přenášet na tisíce různých platforem (což je výhoda C), pokud překladači řeknu, že má program přeložit pro jiný procesor, tak to udělá a nemusím v programu změnit vůbec nic, pokud tedy nelezu do nějakých specifických registrů nějak "nespecificky", ale kdo takovou konstrukci používá, tak většinou ví co dělá a proč to dělá.

Nechtěla jsem se hádat o tom, který jazyk je lepší, žádný není lepší, každý má něco. Za chvilku tu někdo vytáhne Fortran, Cobol, Algol, Aidu, čistý stroják a co já vím co ještě

Však se nikdo nehádá, já v tom C taky nejsem kdovíjakej přeborník, donedávna jsem jel čistě ASM, a tvoje důvody zcela chápu. Pravda je ovšem taková, že C má mezi programovacími jazyky zcela vyjímečnou a zásadní pozici, plynoucí z jistorie, protože stálo u zrodu prakticky všeho, co dnes běžně používáme (minulost tvoří současnost atd). Dává možností jako žádný jiný jazyk (při zachování kompaktnosti) - i vizionářům, kteří jinak při vyřčení slova "standard" propadají panice a prchají hrůzou. Byl totiž podobnými vizionáři stvořen a osvědčil se, i proto se z něj stal standard.

Aidu na jednočipy jsem asi ještě neviděl?
Jinak souhlas s tím, že bascom není tak špatný aby ho bylo nutno zavrhovat, špatná je na něm hlavně ta lajdáckost se kterou ho autor(ři) navrhujou. Chybovost a nejednoznačnost syntaxe, špatná dokumentace novinek a změn.

Já taky ne, zrovna tak jako Fortran a zbytek jazyků z toho přehledu. Bylo jen takové rýpnutí, ačkoli kdo ví, třeba se někdo najde a Aidu pro jednočipy stvoří

S nejednoznačností syntaxe jsem se asi ještě nesetkala anebo mi to nedošlo či nevadilo, nevím.

Protože se "soutěž" nesetkala s úplným pochopením a nadšením, tak sem dám rovnou i řešení.

Program by měl po LCD modulu náhodně zobrazovat náhodně vybrané znaky a písmenka abecedy. Předpoklad byl, že to bude vypadat nějak takto:



Nicméně skutečně je mírně odlišná a výsledek vypadá takto:



Proč tomu tak je přesně nevím, ale předpokládám, že je to chyba, či spíše vlastnost, pseudonáhodného generátoru který generuje čísla v určitých, daných, rozestupech. Není mi ovšem jasné, proč generování čísel od 1 do 4 funguje správně, ale od 1 do 40 funguje jinak. Jak vypadá generátor uvnitř nevím, takže těžko usuzovat.

Aha.
Protože rnd generátor bascomu používá dvoubajtovou interní proměnnou rndseed. Tvoje proměnná by měla být taky typu word, navíc tím ohraničením rozsahu konstantou se (asi) nevyhovující čísla zahazujou a použije další v pseudořadě.
Klasické verze basicu vracely proměnnou rnd mezi 0 a 1, ty pak stačilo příslušnou konstantou vynásobit.
Bascom píše
Citát:
Nejlepší by bylo použít šum z A/D převodníku, ale co mu dát na vstup.

Už jsem jednou psal že to tam posíláš nezaokrouhleně, bůhví co s tím ta knihovna všecko dělá a kde to nakonec přeteče. Zkus správnější

a pak se uvidí.

Jak se tak koukám, když si nechám generovat simulátorem v programu proměnné rnd bez ohraničení
Citát:
tak má nejradši rnd mezi 20000 a 60000, jednobajtová nikdy.
Nebo s tím ohraničením hodnoty konstantou dělí ten word /modulo konstanta?

Citát:
jejda, na to narazíš hned, jak zkusíš cokoliv s timery.

Až budu mít čas a náladu (tedy hlavně tu náladu), tak to zkusím. Sice moc nevěřím tomu, že to nějak pomůže, ale zázraky se občas dějí.

1234

https://dip.felk.cvut.cz/browse/pdfcache/hadacmar_2010bach.pdf

příspěvky mizí při odeslání

???

Citát:

Jak jako že mizí při odeslání?

No napsal jsem text o tom sw generátoru čísel, pak chci vyplnit kolik je pět a osm, a než kliknu na odeslat, je pole pro zprávu prázdný jak evangelická kaple.

No jo, ale proč tomu tak je, to je záhada. Pro nepřihlášené lidi se stránka sama od sebe neobnovuje, protože to není třeba, takže bych chybu viděla spíše někde jinde

Žirafko, to asi nebude souviset s obnovováním stránky, taky musím na kontrolní otázku odpovídat v průměru tak 5x, než to napošestý projde. Speciálně nemá podle zběžného pozorování systém rád slova s diakritikou (asi), třeba odpověď "osm" mi odmítnul jen jednou za celou dobu - ale třeba to nesouvisí ani s diakritikou, kdoví...

Co se týče odpovědi na Bascom otázku, první zkus to nejjednodušší co jsem psal, tj. zaokrouhlit vygenerované číslo. Až když to nezabere tam se můžem dohadovat dál o generátoru, ale osobně si myslím že je chyba v tom, že do proměnné definované jako Byte zapíšeš čtyřbajtový Float (a překladač tě klidně nechá, zmetek jeden).

A ještě k tomu obnovování - ať už to souvisí nebo ne, celkově to není ani tak příliš dobrý nápad. Lidi klikají na tlačítko „Odpovědět” s myšlenkou, že chtějí psát odpověď, a ne s myšlenkou „Tak, a teď na to mám patnáct minut” (nebo na kolik je ten reload nastaven). Stačí, aby se v průběhu psaní ozval metabolismus, nebo telefon (nebo obojí), a po návratu např. za 12 minut… atd, dál není těžký průběh uhodnout.

U nepřihlášených lidí se stránka sama neobnovuje, to je už nějakou dobu vyřešené. U přihlášených se po 910 sekundách sama obnoví, to proto, aby se dalo poznat, že vypršela session. Mne to samotnou nenapadlo, bylo to na popud čtenářstva a teďka nevím, jak se k problému postavit.

Upřímně mám sto chutí to všechno vrátit tak, jak to bylo, ale je to asi věc názoru a diskuse.

Redakční systém jede v UTF-8 a vstupy očekává v témže kódování, pokud mu nějaký prohlížeč předloží něco jiného, tak se mu to moc líbit nebude. Co určitě nepřijme jsou mezery před a za slovem. Zlaté obrázky

To bylo první co jsem kontroloval, prohlížeč si to automaticky nastaví podle stránky, takže UTF-8 tam bylo.

A ty ten script máš napsanej taky v UTF-8, nebo se to omylem při nějaké editaci zblblo? Z vlastní zkušenosti vím, že tohle se stane velmi snadno... Jo a všiml jsem si, že to dělá když je výsledek 10 a víc

pokus

Aha, ono je to možná ještě jinak... ty tam míváš i mínus Tohle nemůžeš slabozrakým dělat, 12px Arial je na 1980x1200 hrozně malý písmo, a ty znaménka prostě nejsou pořádně vidět :-/

Ano, je tam i mínus. Nenapadlo mne tady čekat nějakou zradu. Mimochodem, situaci může velmi zjednodušit odčítačka obrazovky Ačkoli zrovna XOOPS není pro tento typ použití úplně ideální.

Základní poznatek:

RND vnitřně generuje jako Integer/Word a to se nedá pomocí INT nijak zaokrouhlit, protože neobsahuje desetinnou část a překladač vrátí chybu, že Integer neobsahuje desetinnou část

Je zajímavé, že na simulátoru se to chová trochu jinak, než v reálném procesoru a jako výsledek generátoru řádků vrací vzestupnou sekvenci 1 2 3 4 1 2 3 4... což v reálu nedělá.

Pokud si nechám vypsat vnitřní proměnou ___RSEED tak vidím, že generátor nejraději generuje pětimístná čísla, jen občas skočí do čtyřmístných.

Bohužel se mi nedaří najít knihovnu RND, aby bylo vidět, jak to ta příšera vlastně zaokrouhluje.

Pokud změním dimenzování X a Y na Word nebo Integer, tak se to chová, na simulátoru, pořád stejně. Ještě to musím zkusit na reálném procesoru, což je poněkud komplikace, ale asi mi to nedá.

V reálném procesoru se to také chová stejně, je jedno, jestli je proměnná X a Y dimenzovaná jako BYTE nebo WORD.

A generátor generuje proměnnou Y opravdu jako posloupnost 1, 2, 3, 4 a pak zase do kolečka. Ověřila jsem si to přímo na displeji.

Zajímavé je, že pokud se koukám přímo na generovaná čísla v to pomocné proměnné, tak jsou čísla opravdu dosti různorodá. Něco zlobí při těch převodech, ale kdo a co...

Dneska již končím, mám toho za dnešek dost a ještě ke všemu je pořád hnusné vedro :-/

Dyť to píšu hned v pondělí, že ta funkce dává výsledek ve dvou bajtech.
O těch metodách od Hadače jsi četla? buď nechat prát se dva časovače nebo hardwarově zapojit na ADC šumící Zenerku.
Ne že by na tom záleželo, ale tohle mělo už ZX Spectrum řešeno líp.

Možná tam jenom nastav trochu větší monospace na tu captchu, to by mohlo stačit, proporcionální písmo se na to fakt nehodí.

To je dobrá blitka ten „produkt”, RND má podle vžitých konvencí generovat čísla od 0 do 1 (na kolik desetinných míst už je pak dané konkrétním systémem/překladačem, ale vždy minimálně 5).

Když z toho padá Word, budeš to muset nějak ořezat na ten Byte, než to číslo narveš do Locate funkce. Ale to je ti myslím jasný.

Mě na tom „fascinuje”, že tě klidně nechá přiřazovat Word do oktetový proměnný a ani nehlesne. Nebo warningy nečteš? Generuje to vůbec nějakej .lst soubor?

v tomhle případě to nerve word do bajtu, protože s tím parametrem "hranice" kde má hodnotu 40, to bajt nepřeleze.

Že to bajt nepřeleze ještě neznamená, že to nemůže vrátit 16bit proměnnou se samýma nulama na začátku, ne? Co to teda vrací? Jednou že Word, pak zase že ne… Já vím že nula je furt nula, ale při alokování paměti ta nula asi bude trochu hrát roli, a když pak nějaká knihovní funkce šáhne kam nemá, tak se budou dít věci…

Citát:

To bys musela mít k dispozici zdroják té displejové knihovny (Locate je její funkce?) abys viděla, co se tam jak uvnitř děje - což asi nemáš, takže jsme u toho zas, tady ten smrad prostě vane ze všech stran. Už o tom produktu nechci nic vědět, z celýho mám dojem že kdybys to psala v C, tak už ti displej dávno běhá a touhle dobou dokončuješ už i práce třeba na nějakým SPI, I2C nebo sériovým přenosu.

Práce s SPI či I2C je v Bascomu snadná, stejně jako klasický UART a podobně.

Mimochodem, celé toto vzniklo proto, že jsem chtěla vyzkoušet, jak funguje komunikace s LCD modulem a jestli je ten displej vůbec funkční. Přeci jenom pochází z Aukra a tak bylo možné ledasco.

Program svůj účel splnil, prokázal, že modul je v pořádku a to je to hlavní. Zbytek diskuse je jen zajímavá nadstavba nad původním úkolem.

Jinak překladač pochopitelně chyby hlásí. Hlásí je přímo v okně IDE a asi je i někam píše, ale to je mi celkem jedno. Pokud narazí na chybu, tak napíše kde je a dost často napíše i o jakou chybu jde. Třeba u toho pokusu s příkazem INT na proměnou INTEGER napsal, že to je chyba, protože INTEGER nemá desetinou část. Odhalí i překlepy a podobné chyby. A pokud narazí na chybu, tak se překlad zastaví a nejde ani spustit simulátor, celkem logicky, protože se program nepřeloží a tak není co simulovat.

A kupodivu k otestování displeje nebyla funkce rnd přímo nijak nezbytná
K těm chybovým hlášením, překladač je vypíše do protokolu s číslem dotyčného řádku, přičemž se často stane, že nějaké zapeklité chybě, která nevzniká syntaxí ale až v následných souvislostech, přidělí nějaké vysoké číslo neexistujícího řádku.

Něco jsem zkusila a věřím, že teďka již problémy se čtením příkladů nebudou

To je pravda, ale naštěstí se to stává jen občas, protože moje programy rozhodně nejsou moc složité.

No, bascom to dokáže udělat i u "programu" o pěti řádcích. Myslím to, že reaguje chybovým hlášením týkajícím se něčeho úplně jiného a občas lokalizovaným k řádku, který tam vůbec nexistuje. Až se mi to povede, uvedu příklad.

Tak to se nechám překvapit. Ale třeba to není chyba, třeba je to vlastnost

tak třeba při definování aliasů typu např. "výstup 1 alias portb.2, tlačítko2 alias pind.2, tlačítko 3 alias pind.3" překladač protestuje hláškou že datové typy nejsou definovány na úplně jiným řádku, dále pak že u cyklu IF-THEN chybí END IF atd.
musí se definice aliasů s výstupy napsat do jiného řádku než definice aliasů vstupů.
ještě před časem jedna zákeřnost byla ale zase jsem to zapomněl.

Ta chyba bascomu něco alias pin/alias port je způsobená použitím oddělovače čárka místo dvojtečky. Čárka je přípustná ve vícenásobných definicích proměnných, ale ne aliasů. Překladač na to neupozorní ale hlásí pak fiktivní chyby v následujících řádcích způsobené neexistencí příslušné proměnné.

Tak to je zajímavá zrada. Až pustím Bělouše, tak to schválně zkusím.

tyhle zrady jsou spíš otravné než zajímavé...

To se přeci nevylučuje