Dekódování znaků

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:

Uz len preto ze a asm to zaberie tisic riadkov bude to neprehladne. A spravis na tom kopec casu. V Cecku by to bolo rychlejsie.

Res tvrdis ze nemas cas na studium.
V asm to budes robit 100h v C by si sa 50h ucil cecko a 30h to napisal. Tak ze by si usetril cas a navyse sa naucil Ccko.

Projekty ktore som mal a stali zato som nakoniec prepjsal do C cka aby som sa vnich po case zorientoval a vedel robit upravy.

Ahoj. Tak jsem dnes úspěšně dokončil moje slavné dekódování RFID. Šel jsem na to od píky, tj. třídím karty podle všech 5 byte. Následně přiřazuju texty, tj. jména uživatelů. Na rovinu se přiznám, že to bylo peklo :frowning: , protože jsem pro cca 48 uživatelů + 2 testovací karty, naplnil skoro celou 4kb paměť v 16F648A. Zasekl jsem se na stránkování s různým “posouváním” textů. Pagesel trochu “natáhlo” program. Nakonec mi dost pomohlo makro pro obsluhu LCD. Každopádně všem děkuji za nakopnutí a skvělé rady. S tím Céčkem musím něco udělat :open_mouth:

Macro prodlužuje program. Co je v macru se přidává do programu po každém “zavolání” macra. Lepší je call a return.

Ano, ale to nemusí pokaždé vadit. Spíš se divím že nezkusil tu 18F řadu jak jsme se bavili původně, větší projekty jsou na 16F právě kvůli tomu stránkování většinou dost opruz i bez dat, a on s daty pracuje - stačí jeden zapomenutý pagesel a začnou “se dít věci”.

Mikop: Zkus si to na nějakou tu 18F zpětně portovat, uvidíš že budeš příjemně překvapený.

Zase je to otom ze keby to mal v cecku tak to ma presunute na tu 18 raz dva. Hlavne ze mu to chodi. Problem nastane o 6mesiacov s 49uzivatelom.
Inak gratulujem.

ZASE C
Já píšu v asm pro zábavu. Udělal jsem věci v asm a věřím že v c by “hned”, ale …

  1. Mám zábavu a nemusím se bavit s tou slepicí se kterou mám společné zvonkové tlačítko

  2. Od toho se odvyjí zbytek.

  3. Platí pravidlo č 1

  4. Když toto vše projde tak si udělám asm podle sebe jak chci já a NE jak mi ho předloží překladač C. Když chi 1 vteřínu strojového času ta bude a tak to bude. Zbytek co píšou v asm si domyslí.

honza3> Pokud potřebuješ na projektu “propálit” co nejvíc času a imponuje Ti představa, že to máš plně pod kontrolou pak… Zbytek si domyslí Ti co píšou v C :wink:

Honzo, chápu plně tvůj postoj, ale shodou okolností jsme probírali tohle téma teď se známým, ocituju ti tady co jsem mu dneska psal:

Takže shrnutí: C určitě není nástroj hodný zatracení a dělat v C neznamená automaticky vzdávat se ASM. Je to (obojí) prostě jenom nástroj, volba je na každém - ovšem odmítání určitého nástroje prostě jenom tak ze zásady připomíná vohnouta dělníka který i na šroubky bere kladivo, protože šroubování přeci zdržuje.

K tomu co píše Mahoney a jeho kámoš mohu jen poznamenat, že dokud jsem nezačal používat 32bity, kde píšu výhradně v C, tak na x51 jsem krátké, ale časově kritické kousky kódu psal v ASM (tak 1-5%) a zbytek v C a tím jsem vyždímal z MCU maximum. Pokud ale někomu stagnace vyhovuje… :wink:

Myslím, že nebude, tak hloupej, aby používal všude to Macro. Macro stačí vložit 1x do subrutiny a pak už je tam kde je třeba jí volat CALL/RET.

Co se týče dekodování šel bych přes strukturovanou tabulku:
KOD karty, NEXT (offsetem),JMENO : (5+1+X) a pokud se omezí délka jména třeba na 18 znaků, tak je to 24B na kartu při 50 kartách = max.1200 B.
Pokud budou řazené podle kodu dá se hledání částečně zoptimalizovat např podle prvních 1 nebo 2 B kodu karty - za určitých podmínek to může ušetřit jak čas tak paměť.

Ahoj všichni. Jsem docela překvapen, jak se to tady “rozjelo”. Ale jak jsem psal výše, pořešil jsem vše v asm, protože Céčku to prozatím nedávám, ale čeká mě to!!!
Dekódování 5B ID se trochu scvrklo, protože 1B má jen dvě možnosti (87 nebo 43). 2B je vždy 00. Jejich ověření je tudíž na pár řádků. Začne to “houstnout” od 3B. Zde je tabulka největší. LCD je 2 x 8 znaků, aby texty nebyly tak dlouhé.
Co se týká makra pro volání zobrazení na LCD, používám toto:
;-----------------------------------
LCDout MACRO LCDout
MOVLW LCDout
PAGESEL WR_DATA
CALL WR_DATA
ENDM

LCDW MACRO LCDW
PAGESEL WR_CMD
CALL WR_CMD
ENDM
;-----------------------------------
Vlastní volání zobrazení je následující a pro LCD 2 x 8 znaků:
;-----------------------------------
PAGESEL CLS_LINE1
CALL CLS_LINE1

LCDout	'P'
    ...
    ...

RETURN

;-----------------------------------

Myslím si, že je to kratší než použít tohle:

;-----------------------------------

PAGESEL	C_LCD
CALL	C_LCD		; volej podprogram C_LCD - vynuluj LCD

CALL	LINE1		; nastav kurzor na prvni pozici radku 1

MOVLW	'P'		; vloz znak do LCD
CALL	WR_DATA	; volej podprogam WR_DATA, zapis data do LCD
    ...
    ...
RETURN

;-----------------------------------

Ještě jednu informaci o formátu karet. Zkoušel jsem je číst na 3 různých čtečkách a pokaždé byl hexa string tototžný. Lišily se jen drobnosti, jako start bit nebo něco navíc či méně, např. chybělo CRC. Avšak kódy, které jsem dostal z docházkového systému, byly naprosto odlišné, tudíž mi to nefungovalo. Po konzultacích s kolegy od docházkového SW, mi je převedli do fyzického tvaru, tak jak jsou na jedntlivých kartách a jede to.