Ahoj.
Mám dotaz, zda existuje nějaká finta v asembleru pro dekodování bytů. Konkrétně se mi jedná o situaci, kdy mám 3-5 byte dat v hexa a potřebuji to přiřadit jménu pro LCD. Mám použít tabulku nebo nějak roztřídit byte? Je to pro zobrazení RFID karty ke jménu uživatele. V tom vedru mi to už nemyslí … Díky za nakopnutí. Mikop
Ahoj, málo ses rozepsal co přesně vlastně tvoříš, jak to má vypadat (coby návrh systému, vnější desgn nás samozřejmě nezajímá 
) a jak to přesně má fungovat.
Obecně: To, co tu zhruba popisuješ, se obvykle řeší tak, že mikrořadič (v nějaké čtečce, terminálu apod) tohle vůbec neřeší - jen získá číslo karty a odešle ho po nějaké sběrnici či datové lince nadřízenému systému, a až ten provádí vyhodnocení a případně zasílá zpět z vyhodnocení získaná data / povely (např. u dveří, jestli se mají odjistit / otevřít či ne, apod… naopak např. docházkový terminál typicky žádná data zpět nezajímají, ten jenom odesílá).
Nadřízený systém může být buď nějaká výkonnější komunikační jednotka (bývá v ní často ARM nebo něco podobného “vícebitového” a s větší pamětí), nebo přímo k tomu určené PC (např. nějaké IPC, server apod). Jde především o to, že počet uživatelů se může měnit, stejně tak jejich oprávnění, těch dat může být celkem hromada.
Pokud tvoříš nějaký “mikrosystém” např. doma pro jedny dveře do dílny a víš, že počet uživatelů a jejich akcí bude celkem malý a neměnný, můžeš to samozřejmě narvat do jednočipu všechno - tam mi pak ale neladí “jeho potřeba” s něčím komunikovat, tu v takovém případě mít nebude (samozřejmě kromě čtečky karet apod).
Jinak k tomu co ses ptal - samozřejmě tabulkou a jejím postupným procházením po znacích, ale to se dá vážně jen v případě malého počtu záznamů, jinak by vyhodnocení a následná navázaná akce mohly trvat neúměrně dlouho.
Ahoj. Díky za odpověď. Vytvářím mobilní LCD čtečku RFID s modulem RDM6300. Procesor PIC16F628A nebo 88. Čtečka pošle v TTL data (02, 10byte, CRC, 03), které zpracuji v MCU a zobrazím na LCD. Chodí mi i posílání zpracovanych dat z MCU na UART zase ven. Pro někdy. Kód karty není problém, ale potřeboval bych k tomu číslu přiřadit jméno z nějaké vnitřní tabulky. Cca 40 uživatelů. Klasickou tabulku dám, ale nikdy jsem neřešil více byte. RFID čtečka sice posílá více dat, ale pro tento EM4100 125kHz je výstup 26bite, tj. MSB + 3 byte + LSB. A reálně se používají jen ty 3 byte.
PS. To, jak se dekódují a přenášejí data ze čteček a následně zpracovávají v nadřízené jednotce samozřejmě vím, dělal jsem více jak 5 let aktivně přístupové a docházkové systémy a nárazově i nyní. To, co se snažím vytvořit, je co nejmenší mobilní provedení. Karty i přívěšky mají již smazaná čísla a potřebuji ověřit jméno pro obsluhu na místě a ne u PC, kde to není problém.
No to nemáš vůbec zač 
Pokud můžu doporučit: EM4100 používá pro ID 32 bitů (+ 4 paritní) - využívej to všechno. Měli jsme v praxi případy, že si klienti (což byly firmy, které buď dodávaly nebo si samy nainstalovaly přístupáky) vybrali jen několik bajtů z toho ID, a pak se strašně divili když si po čase dokoupili další karty odjinud, že “zničehonic” nemají unikátní ID a mají víc “stejných” karet. Dokonce jsme měli jeden “príma” případ, kdy si z toho ID počítali hash a až ten vyhodnocovali, ale počítali ho špatným algoritmem, takže opět byl výsledek neunikátní. Sranda k popukání (obzvlášť když máš jako technik dohledávat “proč to nefunguje”).
Dál se zeptám: Kam to teda posíláš, když říkáš že přes UART ti to běhá také?
Jinak teda počítej se mnou (pro ten PIC, dejme tomu že si budu myslet, že tvoříš offline terminál, kdyby nebylo spojení s nadřazeným systémem): třeba 56 klientů (ať je nějaká rezerva) * 8 bajtů + “\n” (nebo něco podobného, prostě ať víš, kdy je konec řetězce a neprohledáváš donekonečna; C používá \0 ) = 560B ve flash jenom tabulka, takže vzhledem k tomu, že pomocí ADDWF PCL,F můžeš skákat jen o 127 adres bude už trochu pakárna (+ případně ještě zohlednit stránkování flash paměti). Píšeš to aspoň v C?
Další nevýhoda je, že jakákoliv aktualizace užavetelských data = přeprogramování PICu pokud budou ve flash, a nebo použít externí EEPROM a mít v programu funkce, které to budou umět updatovat skrze ten UART. Máš tam aspoň tu EEPROM?
K tomu porovnávání: V paměti máš pole znaků, záznamy v něm jsou pokaždé zakončené tím “\n”, a v RAM máš někde uložené číslo, které jsi právě vyčetl z nějaké karty. Pak se bude dít to, že vezmeš první záznam z flash, a jeho první bajt porovnáš s prvním bajtem vyčteného. Pokud se budou shodovat, vezmeš druhý bajt z obojího a opět porovnáš, pokud se budou shodovat tak… toto pořád dokolečka, dokud buď a) dojde k neshodě - v takovém případě nemusíš záznam už dál porovnávat, není to on, a můžeš vzít další záznam, na kterém začneš provádět to samé zase od začátku - nebo b) dokud nenarazíš na “/n”. Pokud jsi došel až k \n, tak víš že onen záznam je ten, který hledáš, další záznamy už nemusíš prověřovat. Po záznamech v tabulce skáčeš tak, že před ADDWF PCL,F přičteš ještě index záznamu, což bude pořadí záznamu * 10 (velikost záznamu) - a samozřejmě dáváš pozor na přetečení a podobné srandy.
Přiřazení jména by šlo udělat třeba tak, že tam budeš mít ještě jednu tabulku, ve které budou ona jména, a podle (předchozího získaného) indexu záznamu jen přiřadíš jméno. Nebo to třeba nemusí být další tabulka, může to být po sobě v té jedné a v případě shody záznamu jen pokračuješ dál - struktura dat uložených v paměti je jen na tobě, aby se ti to dobře zpracovávalo i programovalo.
Je to trochu srozumitelné?
Díky za odpovědi. O té duplicitě při 3 bytech samozřejmě vím. Setkal jsem se s tím dokonce i u Dallas čipů DS1990A, kde to taky ořezali na 3 byte a divili se, že mají stejné ID, když výrobce garantuje jedinečnost. Proto to ještě rozvedu. Je to trochu jako hec pro jednoho známého. Má malou firmu a potřebuje pro ostrahu, aby mohla ověřit kartu zaměstnance kdekoliv po areálu i mimo něj. Fluktuace zaměstnanců není skoro žádná a navíc to bude víceméně jednorázová záležitost, jak naučit zaměstnance “správným návykům” 
Co se týká aktualizace dat, tak to tím pádem nebude tak horké. Navíc mám na vstupu RX tu čtečku. Musel bych napsat ještě SW UART. Protože je kladen důraz na miniaturizaci, chtěl bych použít Flash MCU místo externí Eeprom. Teda kdyby se to nevlezlo, tak ji použiju. Data (ID) se nikam neposílájí, jen na LCD. Z UARTu MCU to mám připravené, ale nepoužívám to. Je to vlastně něco jako personifikační jednotka, ale pouze zobrazuje ID a uživatele. Jinak ke čtečce RDM6300 stačí přidat MAX 232 a posílat data rovnou do COM portu. Formát dat jsem psal výše. Píšu to v asm, protože Céčko nedávám. To porovnání jsem tak nějak myslel, ale potřeboval jsem nakopnout, jak dál.
PS. Těch ID byte z karty bude nakonec zřejmě opravdu více.
Aha… no pokud ty karty nemá potištěné fotkou zaměstnance, jménem a podpisem tak to stejně asi nebude mít ten efekt - ostraha bude bez fotky a podpisu schopná jen určit, že “tahle karta patří člověku jménem X.Y.”, ale už ne to, že to je přesně ten člověk, který stojí před nimi a tu kartu drží. To je schopná provést až podle fotky na té kartě, jinak ne - i přesto, že ten člověk bude tvrdit, že to on je. On ten člověk klidně může držet kartu někoho jiného a vědět koho karta to je, tedy jaké jméno má říct - známe lidi, jak jde o nějakou levotu tak jsou zpravidla velmi vynalézaví. Záleží samozřejmě co to je za firmu za zaměstnance a jde taky o celkovou kulturu a klima ve firmě - neznám ani jedno z toho, hovořil jsem pouze obecně a hypoteticky.
Jinak tedy ještě k technické stránce věci - když tedy ASM (nic proti, já jsem taky spíš “assemblerák”, i když teda v C něco málo /a blbě/ píšu), tak by stálo za zvážení, jestli to nepřestěhovat na 18F - např. takový PIC18F1320 zůstává dostatečně miniaturním a přidává lepší komfort práce - paměti je více a je v souvislých blocích, odpadá pagesel a pro práci s tabulkami je daleko lépe vybaven (má na ně speciální instrukce a registry).
Já to tedy zkusím s tím PIC18F1320. Ještě jsem s řadou 18F nic nedělal, tak asi budu ještě otravovat, ale uvidíme. Budu teď do konce týdne mimo, tak se když tak ozvu. Díky
V pohodě, klidně se ptej. Jsem zrovna shodou okolností “na marodce” (záda) a možná budu i příští týden - uvidíme - takže bych eventuálně měl čas a dokázal pomoci i prakticky (s kódem atd).
18F řady se vůbec neboj, práce s nimi je lepší, ale pár odlišností samozřejmě mají (tedy krom toho že jsou asi o třetinu dražší) - jako třeba že adresy skoků atd jsou výhradně sudé (protože mají šířku instrukčního slova 16 bitů), nebo že mají dvě úrovně přerušení a je třeba to buď správně nastavit, nebo vypnout… ale v klidu, nic dramatického se nekoná, to v pohodě zvládneš / zvládnem.
Něco málo na začátek k pročtení (týká se toho inst. slova):
Link1 zde z fóra
Link2 zde z fóra
Za mě bych už asi nic s PIC16 v ASM nedělal. PIC18 tolik usnadní programování, že i v assembleru se dobře píše. Ale já jsem se už tak rozežral PIC24 a C, že bych si asi na asm pořádně nevzpomněl.
Mám oblíbený PIC18F23K22 a PIC18F13K22, jsou za super cenu v TME.
Nevěděl jsem co má přesně za programátor, tak jsem mu ty novější typy právěže nechtěl radši moc doporučovat - např. Pickit 2 „v defaultu” umí jen ten 18F13K22 a 18F23K22 už neumí (dá se to samozřejmě upravit)… Navíc novější typy bohužel bývají více zabugované přímo na čipu (mají zpravidla „hustší” errata sheety, takový 18F26K22 mě v tomto vyloženě zklamal), starší brouci byly odladěnější a nemusely se moc dělat kdovíjaké workaroundy - to se ovšem týče i 16F řady. Navíc 18F13K22 už je 20pin, nebude vývodově kompatibilní s 16F628A a s 16F88, nevíme jestli už nemá hotový nějaký návrh HW.
To je fakt, že zabugovanost nových čipů je poměrně obsáhlá. Hlavně mi přijde, že to vůbec neřeší a nové revize co by dané chyby řešily se jaxi nedělají.
Kluci díky za podporu. Dostanu se k tomu až příští týden. Desku mám sice hotovou pro 18 pin, ale to se dá předělat. Spíš jde o to, že nemám nic z řady 18F. Tedy myslím. Co se týká programátoru, koupil jsem před lety Presto, protože má za tu cenu skvělou podporu. A navíc, jak mají ve sloganu: Bez PRESTA se obejdete. Z Prahy do Ostravy taky dojdete pěšky… Když jsem pročítal problémy s různými programátory, jevil se mi jako velice dobrý.
V pohodě, nemáš zač. Co se mě týče jsem pořád marod, takže čas zatím bude, pak na to mrknem jak se k tomu dostaneš.
Jestli máš desku už hotovou tak je asi zbytečné to předělávat, ten 18F1320 (či 18F1330) pro tvé účely v pohodě postačí (čas jsou peníze, těch 30 korun úspory za to při tom jednom kusu nestojí). Presto je výborný programátor, ovšem nativně umí jen typy s Vpp 13V (tedy ty starší), i když program UP podporuje i novější typy - takže co se týče novějších typů brouků, je potřeba číst datasheety a na Vývod Vpp mezi programátor a brouka dát odpor 2k, aby se napětí srazilo (2k2 už ne, to už by bylo moc, takže dát si za sebe 2x 1k odpor). PIC18F1320 je starší typ a má Vpp 13V, tady odpor potřeba nebude.
Presto používám v práci na 18F řadách, odpor 1k na MCLR a 9V zenerka k tomu. Už to naprogramovalo tak 10 000,- brouků. Akorát odchází po čase ty propojovací káblíky a dutinky na jumpery.
Je to daleko lepší programovadlo jak Pickit3 a Mplab IPE dohromady.
V C na pár řádek, v ASM si to užij
A jaký je prosímtě přesně smysl tvého sdělení, když on C nedělá? Nějak mi ten význam uniká…
No ja to chápem tak, že zmyslom je: “aby si to užil”
No právě, jen plané porýpávání, které nikam nevede. Taky bych to zřejmě dovedl napsat v C, ale nemachruju s tím tady, protože když tazatel v C nedělá a je jasný že asi ani hned tak nebude, tak je mu program psanej v C houby platnej - takže se radši snažím reálně pomoci v ASM, to bude lepší než nějaké virtuální básnění o… no vlastně o čemkoliv.
Ale aby na to vůbec došlo a nepohádalo se to tady (jako obvykle?) ještě dřív, než se vůbec začne něco řešit. Víc vzájemné ohleduplnosti by tu rozhodně neuškodilo. Na to že máme být chytrá komunita se chováme často dost hloupě a antikomunitně.
Ahoj. Jen jsem sem mrknul, protože se mi vyskytli úplně jiné sousedské problémy mimo tento chat. Budu tím pádem pokračovat minimálně až od příštího týdne. Každopádně se to tady rozjelo úplně jiným směrem.
PS. Radius - Jak píše Mahoney výše, nemachruju a pokud něco vím, i když to není to pravé ořechové, snažím se pomoct. To je snad smysl tohoto fóra. Tedy alespoň si to myslím. Ale když je to tak jednoduché v Céčku, nechceš poslat podklady a vystřihnout to pro mě levou zadní? Zrovna teď by mi to i píchlo. Ale třeba jsi to myslel jen jako konstatování, tak sorry. Díky všem
Ta poznámka měla být impuls k tomu, aby se vývojář zamyslel, jestli zrovna teď není čas přejít na C. Pokud to totiž neudělá a bude řešit tuhle (a podobné) třídy problémů i nadále v ASM, rozhodně si to programování moc “neužije”, protože dělat tabulky a podobné věci v assembleru je skutečně pruda.
Pro rýpaly - v C je to jen o nadefinování struktury s položkami {ID, Jmeno, Přijmení, Telefon, blalala…} a pak jen prohledání pole struktur podle ID. Pole může být hardkódováno do programové paměti nebo čteno z externí eeprom.
S C samozřejmě rád poradím…