I just extracted the problematic part of my program, I use RFID.h and SPI.h,
I just want to know how to read on a RFID card (written with an android phone)
I only write one letter : R, G, B, Y, ... (represent color) , on an Android tool I can See at sector 04 : ?TenR? When the "R" after Ten is the string that I wanna read :
char buffer_data[8];
rfid.read(0x04,buffer_data);
String myString = String(buffer_data);
Serial.println(myString);
I only want to know how to output => "R" (text on the RFID card at sector 04) : It output something like that :
22:05:15.885 ->
22:05:15.885 -> &⸮
22:05:15.885 -> ⸮⸮
With other cards (Y, B char inside) same output...
Screenshot with card data (Mifare classic 1k (716B writable)):
The lib RFID.h with rfid.read doest not work...
https://github.com/song940/RFID-RC522
don't use this lib !
The lib https://github.com/miguelbalboa/rfid is better, up to date, and can read most of tag types !
This is the fixed code to read the first text char on NTAG215 :
if (rfid.PICC_IsNewCardPresent()) {
if ( ! rfid.PICC_ReadCardSerial()) {
return;
}
Serial.println("");
String str;
byte buffer_data[18];
byte size_data = sizeof(buffer_data);
rfid.MIFARE_Read(4,buffer_data,&size_data);
str=String((char *)buffer_data);
Serial.println(str.charAt(9));
}
Ouput the first letter on the tag (if you write text data with Android NFC tools app ) only on NTAG215 (other tag = different adresses/position)!
I assume that the "square" refers to the ASCII number printed to stdout.
I would want to find out, what read_char is in HEX, so instead of printing it as a character to stdout, print the hex representation of it and see what value you get. It's difficult to give you more accurate troubleshooting steps with the limited system information available.
Related
Good afternoon, I'm facing a problem on my c code and I don't know what is causing it.
Every time I try to print characters like these: "┌──┐" my program simply prints some strange characters, like on this screenshot:
I'm using Qt Creator on Windows, with Qt version 5.5.0 MSVC 64 bits. The compiler is the Microsoft Visual C++ Compiler 12.0 (amd64).
I tried changing the locale but with no success. The only way I found to print these characters was to define them as int variables with the ASCII code and printing them, but it led to some really extensive and ugly coding, like this:
int cSupEsq = 218; //'┌'
int cSupDir = 191; //'┐'
int cInfEsq = 192; //'└'
int cInfDir = 217; //'┘'
int mVert = 179; //'│'
int mHor = 196; //'─'
int espaco = 255; //' '
int letraO = 111; //'o'
//Inicia limpando a tela da aplicação
clrscr();
//Linha 1
printf("%c", cSupEsq);
for (i = 1; i < 79; i++) { printf("%c", mHor); }
printf("%c", cSupDir);
Is there any way I can make the program treat these characters correctly? What could be causing this problem?
Your solution to use the OEM code points is the right way to go, codepage 850/437 is the default code page for the console and therefore should work. You could also use SetConsoleOutputCP to ensure the correct code page is used for the console.
Having said that, what is happening when you do not use your workaround is that the source file is being saved using a different codepage ie. not codepage 850/437. The in memory representation of the source code is Unicode (probably UTF-8), when you save the file the in memory representation of the characters are mapped to the target code page for the file.
What you can do is to save the file using the 850/437 codepage as the target, I don't know how you do this in Qt Creator (If you can at all), in Visual Studio for example you can select the down arrow on the Save button and select "Save with encoding", you can then proceed to select the target codepage, in your case code page 850. This will ensure that the in memory code points are mapped correctly to the file to be compiled.
I hope that helps explain the issue.
It shouldn't be necessary to print the characters one at a time. Instead, you can use an escape sequence:
printf("\xDA\xBF\xC0\xD9\xB3\xC4\xFF");
I am using SEGGER emWin on an embedded system.
I have downloaded a Korean font: Korean True Type Font
And converted the font to C language data statements.
When I printed the text: 한국어 ("Korean"), nothing printed out.
The hex code for the text (UTF-8) is: \xED\x95\x9C\xEA\xB5\xAD\xEC\x96\xB4
I opened up the font in the Font Creator and noticed the glyph at offset 0xED does not match the first glyph in the text. Also, there are no glyphs at offset 0xED95 or 0x95ED.
I converted the file using 16-bit Unicode.
The hex code for the text was determined by using Google Translate, then copying the text into Notepad, saving the text as UTF-8 and then opening up the text file with a hex editor.
How do I get the hex string to print the appropriate glyphs?
Am I having a Unicode vs. UTF-8 issues?
Edit 1:
I am not calling any functions to change the encoding, as I am confused on that part.
Here's the essential code:
// alphabetize languages for display
static const Languages_t Language_map[] =
{
{"Deutsch", ESG_LANG_German__Deutsch_},
{"English", ESG_LANG_English},
{"Espa\303\361ol", ESG_LANG_Spanish__Espanol_},
{"Fran\303\247ais", ESG_LANG_French__Francais_}, /* parasoft-suppress MISRA2004-7_1 "octal sequence needed for text accents on foreign language text" */
{"Italiano", ESG_LANG_Italian__Italiano_},
{"Nederlands", ESG_LANG_Dutch__Nederlands_},
{"Portugu\303\252s", ESG_LANG_Portuguese__Portugues_}, /* parasoft-suppress MISRA2004-7_1 "octal sequence needed for text accents on foreign language text" */
{"Svenska", ESG_LANG_Swedish__Svenska_},
{"\xED\x95\x9C\xEA\xB5\xAD\xEC\x96\xB4",ESG_LANG_Korean}, // UTF-8
// {"\xFF\xFE\x5c\xD5\x6D\xAD\xB4\xC5", ESG_LANG_Korean}, // Unicode
};
for (index = ESG_LANG_English; index < ESG_LANG_MAX_LANG; index++)
{
if (index == ESG_LANG_Korean)
{
GUI_SetFont(&Font_KTimesSSK22_12pt);
}
else
{
GUI_SetFont(&GUI_FontMyriadPro_Semibold_22pt);
}
if (index == language)
{
GUI_SetColor(ESG_WHITE);
}
else
{
GUI_SetColor(ESG_AMR_BLUE);
}
(void) GUI_SetTextAlign(GUI_TA_HCENTER);
GUI_DispStringAt(Language_map[index].name,
(signed int)Language_position[index].x,
(signed int)Language_position[index].y);
}
//...
void GUI_DispStringAt(const char GUI_UNI_PTR *s, int x, int y) {
GUI_LOCK();
GUI_pContext->DispPosX = x;
GUI_pContext->DispPosY = y;
GUI_DispString(s);
GUI_UNLOCK();
}
The GUI_UNI_PTR is not for Unicode, but for "Universal":
/* Define "universal pointer". Normally, this is not needed (define will expand to nothing)
However, on some systems (AVR - IAR compiler) it can be necessary ( -> __generic),
since a default pointer can access RAM only, not the built-in Flash
*/
#ifndef GUI_UNI_PTR
#define GUI_UNI_PTR
#define GUI_UNI_PTR_USED 0
#else
#define GUI_UNI_PTR_USED 1
#endif
The emWin is performing correctly.
The system is set up for UTF-8 encodings.
The issue is finding a truetype unicode font that contains all the glyphs (bitmaps) for the Korean language. Many fonts claim to support Korean, but their glyphs are in the wrong place for unicode.
I'm a beginner in "C" programming.
I'm planning to convert the input file into a different format / output file using some kind of static configuration file.
For e.g:
Input File content:
HDRUS15Jan2014153600MY22Jan2014000000KUL
DTLUSANZABC Private Company, Arizona 53213.
DTLMYKULJS Sdn Bhd, Kuala Lumpur 49000 .
Output File content:
ANZ15Jan2014153600
ABC Private Company, Arizona 53213.
KUL22Jan2014000000
JS Sdn Bhd, Kuala Lumpur 49000 .
Hints:
The input file format is fixed length and HDR & DTL keywords are the line identifiers.
I wanted to avoid implementing the hardcoding of extracting the content, instead i wanted to have a kind of configuration file...based on the configuration file the input file content will be extracted and construct the output files.
This concept will allow me to produce additional information in the output file in future without modifying the source code.
I will be just changing the configuration file...
any thoughts will be appreciated.
why you don't use any well known data representaion format like json or xml for your input? by using this kinds of formats you will have no problems with future changes
json will be a good choice and there are implememtaions for c (libjansson etc.)
EDIT
ok, then store your configuration data in file, use some format (i prefer json...)
you will need offset and len infomration:
[
{
offset: 0,
len: 10
}
{
offset: 10,
len: 10
}
]
then you can read this file in your programm and use the information to parse your input:
int offset = getOffset(0);
int len; = getLen(0);
int i;
for(i = offset; i<len; i++)
{
doSomething(input[i]);
}
I have two states; one is a specific instance of the other, more general, state.
I believe that the right way to avoid entering both states simultaneously is to implement lookahead with k>1, but I can't find any examples of how to do this.
The Ragle user's guide says:
In both the use of fhold and fexec the user must be cautious of combining the resulting machine with another in such a way that the transition on which the current position is adjusted is not combined with a transition from the other machine.
I'm not entirely sure what this means, except perhaps "don't try to read past the end of the current expression".
My machine looks like this:
seglen16 = any{2} >{ swab(p, &len, 2); len = len - 2; };
action check {len--}
buffer = (any when check)* %when !check #{ printf("[%d]:%d\n", len, *p); };
# JPEG Markers
mk_app0 = 0xFF 0xE0;
mk_appx = 0xFF (0xE0..0xEF);
marker = 0xFF ^0x00;
nonmarker = !marker - zlen;
# JPEG APP Segments
seg_app0_jfif = mk_app0 seglen16 "JFIF" 0x00 buffer #{ printf("jfif app0\n"); };
seg_appx_unk = mk_appx nonmarker* #{ printf("unknown app content\n"); };
seg_app = (seg_app0_jfif | seg_app1_exif | seg_appx_unk);
# Main Machine
expr = (mk_soi #lerr(bad) nonmarker* seg_app* nonmarker* mk_eoi);
I want to tokenize a JPEG header, skipping unknown segments and handling well-known segments like JFIF. The JPEG application segment app0 starts with 0xFFE0. If app0 contains JFIF data, the app0 marker will be followed by a two-byte length and the string "JFIF\0". This means I need 7 bytes of lookahead when identifying application segments.
I want to tokenize a JPEG header, skipping unknown segments and handling well-known segments like JFIF. The JPEG application segment app0 starts with 0xFFE0. If app0 contains JFIF data, the app0 marker will be followed by a two-byte length and the string "JFIF\0".
All right.
This means I need 7 bytes of lookahead when identifying application segments.
Why? You can make the "unknown" pattern apply to all segments except the ones that are known using the general pattern:
seg_app0_jfif = mk_app0 seglen16 "JFIF" 0x00 buffer #{ printf("jfif app0\n"); };
known_segment = (seg_app0_jfif | seg_app1_exif);
unknown_segment = ((mk_appx nonmarker*) - known_segment) #{ printf("unknown app content\n"); };
seg_app = (known_segment | unknown_segment);
Doing it this way doesn't require lookahead. Ragel generates the appropriate states and transitions, handling both patterns simultaneously until enough of the input has been processed to disambiguate them. The finishing action on unknown_segment will occur only if it is not a known_segment, which seems like behavior you're trying to achieve.
have wrote this app which reads input from console.
for(; ; )
{
GetNumberOfConsoleInputEvents(stdinInput, &numEvents);
if (numEvents != 0) {
INPUT_RECORD eventBuffer;
ReadConsoleInput(stdinInput, &eventBuffer, 1, &numEventsRead);
if (eventBuffer.EventType == KEY_EVENT) {
if(eventBuffer.Event.KeyEvent.bKeyDown)
{
printf("%c",eventBuffer.Event.KeyEvent.uChar.AsciiChar);
dataBuffer[bufferLen++] = eventBuffer.Event.KeyEvent.uChar.AsciiChar;
dataBuffer[bufferLen] = '\0';
if ( dataBuffer[bufferLen] == 99 || eventBuffer.Event.KeyEvent.uChar.AsciiChar == '\r' ) {
printf("User Wrote: %s\n",dataBuffer);
memset(dataBuffer,0,sizeof(dataBuffer));
bufferLen = 0;
}
}
}
}
}
It puts the data on a buffer and then it prints out the buffer. The problem occurs when im using Shift or CapsLock to write Capital letters or ! # # $ % characters. Then it prints out NOTHING.
Ive tried something with the VK_LSHIFT code but didn't worked.
Also if try to write something in other language than English it prints out something like this ▒├╞▒├╞▒├│▒├│ It cannot recognize the other language.
Can someone give me a hint on how to fix those problems ?
Thanks!
ReadConsoleInput returns events for each keystroke. For example, if you type SHIFT+A to get a capital A then you'll receive four key events: SHIFT down, A down, A up, SHIFT up.
The SHIFT key does not have a corresponding ASCII code so eventBuffer.Event.KeyEvent.uChar.AsciiChar is set to zero. This zero terminates the string you are building in dataBuffer so you don't see anything typed after the SHIFT key.
The simplest fix is to ignore any key event with an ASCII code of zero.
Additionally, if you want this to work well with foreign languages you might do better to use ReadConsoleInputW and eventBuffer.Event.KeyEvent.uChar.UnicodeChar. Better yet, compile it all as a Unicode app.