Dekódování znaků

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

Proč vy Cčkaři pořád někomu předhazujete výhody Céčka?

To Johne pochopíš, až v něm začneš programovat. Do té doby je to zbytečná diskuze.

Lebo to spadnutie závoja utkaného z ASM, ktorým sme mali sami dlhé roky zastrený zrak a zubami nechtami sme si ho pred očami dobrovoľne držali, tú krásu z poznania jednoduchosti, prehľadnosti a udržiavateľnosti pri zachovaní obdobného výkonu prajeme každému.
Sme ako misionári, ktorí sami okúsili výhody C-čka oproti ASM a preto sa naše poznanie a skúsenosť snažíme šíriť pre blaho ľudstva ďalej, aj napriek upaľovaniu na pomyslených hraniciach neveriacimi a netečnými.

Nikdy totiž nevieme, aké nové srdce možno i náhodne čítajúce ten ktorý príspevok sa odhodlá vyskúšať krásne krajiny užitočnosti a efektivity.

Nie každému musí byť naša misia po vôli. No čo i len jedna jediná hodina času ušetrená pri používaní C-čka jeho novým adeptom stojí za tú námahu.
Odmietať naučiť sa cca 29 základných príkazov v siedmych skupinách

  1. definovanie a deklarovanie funkcií: main(), funkcia(…), return

  2. aritmeticke a binárne operátory: =, +, -, *, /, &, |

  3. spôsoby porovnania" ==, !=, >, <, &&, ||

  4. bitové rotácie: <<, >>

  5. definovanie premenných: static, uint8_t, int8_t, uint16_t, int16_t, uint32_t, int32_t

  6. podmienkové príkazy: (if, else, else if), (switch, case)

  7. cykly: for( ; ; ), while ()

už umožňujúce robiť zmysluplné programy veľkého rozsahu, miesto mnoho desiatok až stoviek pseudokódových skratiek a to pre každú rodinu procesorov zvlášť, hraničí s tvrdohlavosťou.

Námietky na rýchlosť a efektivitu výsledného kódu som si vďaka vlastnej počiatočnej nedôverčivosti odskúšal a výsledky boli viac ako prekvapivé v prospech C-čka. Systémovo naspäť k ASM by som už nikdy nešiel.

Jasné, že keď som minulý rok som robil s ATmega1284 grafickú mnoho fontovú VGA kartu 272x240 pixlov 16 color bez potreby externej pamäte alebo iných programovateľných súčiastok, tak kód pre generovanie video signálu bol písaný v ASM. Zvyšok (fonty, obrázky, UART) v čistom C-čku. Ale to je za cca 12 rokov jediný projekt, kde to malo v ASM zmysel. Aj keď po podrobnejšom oboznámení sa s FT811 už dnes považujem celú tú námahu za stratu času.

Krásu štruktúr, pointrov a ďalších vychytávok je možné odhaľovať postupne podľa potreby. Tých 29 “príkazov” na dlhý začiatok bohate stačí.

Robím k veľkej spokojnosti v GCC na AVR.

A že sa dá v C aj pekne zapotiť? Isto. A pri programovaní v akom jazyku nie :slight_smile:

Velmi pěkně a poeticky napsáno Martine. Jo, prostě misionáři :slight_smile:

K té Tvé VGA kartě bych doplnil, že si nemyslím, že to byla ztráta času. Obdobný projekt jsem řešil s ARM. Jen jsem se dostal na rozlišení 640x480, grafika/text, za použití pouze C. FT8xx je moc fain a není drahý, ale pokud nepotřebuješ barevnou grafiku a dělá se toho víc kusů, i ty 200Kč stojí za to ušetřit :wink: