Dekódování znaků

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.

Asix - podpora typů

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 :wink:

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” :slight_smile:

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…

Radius - já to pochopil. Jsem teď naštvanej z jiných věcí, tak mám nejapný poznámky. Přechod na Céčko mi radil už kde kdo. Ale protože jsem samouk, samá práce okolo i doma, tak mám málo času něco louskat. Sice to stále odkládám, ale zřejmě mě to nemine.

Hele, já Ti rozumím. Psal jsem dost dlouho v ASM cca. 5 různých procesorů a přestože některé byli lepší než jiné a i překladače měli různé široké možnosti abstrakce, nikdy to nebylo ono.

Pro představu co bys musel v asm udělat:

Z příchozího ID udělat N-bitové číslo (N je násobek 8 ). Pokud ID chodí jako jednotlivé decimální/hexa znaky tak je to násobení 10/16 s akumulací. Výsledek pak porovnáváš s tím co máš uloženo někde v eeprom/flash a to byte po bytu. Tam kde to souhlasí pokračuješ čtením dalších byte které reprezentují textovou informaci. kterou hodíš na lcd. Jinak přeskočíš na začátek další požky.

Tabulka se skládá z pevného počtu byte pro ID a pevného počtu byte pro TEXT. Pokud bys chtěl variabilní délku textu, musí tam být úvodní nebo ukončovací znak.

Ahoj. Tak jsem se dnes zase částečně propracoval dále. Tu řadu 18F prozatím nemám, takže budu objednávat. Pro přiblížení, co vlastně “leze” ze čtečky, jsem psal sice již výše, ale je to tohle: 02, 10 byte data, 2 byte CRC, 03. A leze to v ASCII, takže to po odfiltrování rovnou posílám na LCD. Fyzická data jsou z terminálu Herkules z mých 3 karet:
V ASCII: STX{30}{46}{30}{31}{35}{43}{41}{44}{39}{46}{36}{30}#ETX nebo v HEXA: #STX0F015CAD9F60#ETX
V ASCII: STX{30}{31}{30}{31}{32}{30}{45}{34}{34}{37}{38}{33}#ETX nebo v HEXA: #STX010120E44783#ETX
V ASCII: STX{30}{31}{30}{31}{32}{32}{43}{42}{34}{45}{41}{37}#ETX nebo v HEXA: #STX010122CB4EA7#ETX
Legenda: 02 je v ASCII start of text-STX, 03 je end of text-ETX, # vkladá jako označení řídících znaků zřejmě terminál Herkules.
V Putty to leze v hexa bez řídících znaků: 0F015CAD9F60 Nezkoušel jsem, zda to jde nastavit jinak, ale nepotřebuji to. Vrhám se do tabulek zatím pro 16 řadu, kde jsem, a to se přiznám bez mučení, nepochopil to násobení 16. To ASCII mám v MCU přeložený i do hexa, ale nějak mi uniká myšlenka. Protože ve výsledku nebudu testovat tolik karet (cca do 50), napadla mě možnost, třídit to pomocí CRC. Tedy pokud se mi nesejdou stejné, jakože určitě ano. Možná k tomu přidat ještě 1 byte ??? Nemám však prozatím fyzicky ID a jmén vlastníků karet. Můžete mi prosím ještě jednou polopatisticky vysvětlit, jak na to. Možná příklad …
Děkuji všem.

Uděláš si buffer a budeš ho číst po každém přerušení od UART. Až bude na konci poslední 3 ETX tak vyhodnotíš, že přišlo něco “platného” a pak podle zbytku vyhodnotíš kdo prošel.

Jak píše kolega přede mnou. Budou Ti chodit znaky. STX - ten vyresetuje přijímací algoritmus. Další znaky budeš zpracovávat tak, že ASCII HEX zkonvertuješ do BIN HEX.

Příklad jak v C

U8 Hex2Bin(U8 c)
{
U8 data x=c-48;
U8 code A]={0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0x0A,0x0B,0x0C,0x0D,0x0E,0x0F};
if(x>22) return 0xFF;
return A[x];    
}

Vysledeky téhle operace postupně uložíš do 6 byte, vždy horní a dolní 4bity.

Až příjde ETX, tak z těch 5 byte spočítáš CRC. Je to jen obyčený XOR všech 5 byte postupně přes sebe. Když pak udělaš ješte XOR s posledním byte (CRC) musí Ti vyjít 0x00. Mužeš to klidně počítat pruběžně, jako budou chodit ty dvojice znaků.

Těch 5 byte je ID.

CRC se Ti u takhle jednoduchého algoritmu může snadno sejít. To, že máš v systémů jen 50 ID neznamená, že jinde jich nemají tisíce, proto těch 5 byte.

Tabulka Tě nemine.

Násobení 16 je bitový posun do leva o 4 bity. Dá se tak kumulativně přidávat odspodu. A=(A<<4)+B;

Ahoj. Ještě info ke čtečce. Pokud je trvale přiložena karta, posílá ASCII znaky každých cca 100-200 ms dokola. Proto jsem pořešil čtení tak, že po načtení celého stringu, zablokuju další čtení, převedu do hexa a vyhodnotím správnost dle CRC. Konverzi do hexa už mám hotovou i s výpočtem CRC. Pokud to sedí, posílám na LCD vybrané ID v ASCII a do UARTU dle potřeb buď taky ASCII nebo v hexa. To, že se mi CRC může sejít je také jasné. Chtěl jsem si ušetřit práci :slight_smile:
Každopádně jsem potřeboval to násobení 16, které jsem už snad pochopil. Děkuji