I have this function in xilinx for giving output to Seven segment.
int result;
XIo_Out32(XPAR_SSG_DECODER_0_BASEADDR, result);
The function gets the int result and puts the output to seven segment as a hex value. So basicly, if i give result = 11; I would see A as a result in seven segment. To see a decimal value on sseg, one approach is to change the verilog code behind this and change the whole concept of the sseg. Another approach is to write a function that changes decimal value into a hex value. I've been searching for a good code block for this but it seems that every one of them, prints the values digit by digit with a loop. I need the whole value as a block. Unfortunately i cannot use the C++ libraries so i have primitive C code. Is there any known algorithms for converting?
Apparently, you want to convert symbol codes from ASCII to the ones from the 7-segment display character set. If so, you may create a simple mapping, maybe an array of codes indexed by ASCII character id. Then, you'll be able to call your function like:
XIo_Out32(XPAR_SSG_DECODER_0_BASEADDR, 'A');
Be careful to implement the mapping table for the whole ASCII range.
EDIT
Sorry, I've got your question wrong. You'll have to manually convert hexadecimal number to an array of decimal symbols. You may do it by dividing your number by increasing powers of 10 (10^0, 10^1, 10^2, etc) and thus get an array of remainders, which is a decimal representation of your number. You may use snprintf as H2CO3 recommends, but I would recommend against it in some of the embedded applications where RAM is limited; you may even be unable to use sprintf-like functions at all.
Related
I am receiving hex data from a serial port.
I have converted the hex data to corresponding int value.
I want to display the equivalent character over GTK label.
But if we see character map there are control characters from 0x00 to 0x20.
So i was thinking of adding 256 to the converted int value and show the corresponding Unicode character to label.
But i am not able to convert int to Unicode. say if i have an array of ints 266,267,289...
how should i convert it to Unichar and display over GTK label.
I know it may seems very basic problem to you all but i have struggled a lot and didn't find any answer. Please help,
The GTK functions that set text on UI elements all assume UTF-8 strings. A single unsigned byte representing a Unicode code point with value > 127 will not form a valid UTF-8 string if written out as an unsigned byte. I can think of a couple of ways around this.
Store the code point as a 32-bit integer (which is essentially UTF-32) and use the functions in the iconv library, or something similar, to do the conversion from UTF-32 to UTF-8. There are other conversion implementations in C widely available. Converting your unsigned byte to UTF-32 really amounts to padding it with three leading zero bytes -- which is easy to code.
Generate a UTF-8 string yourself, based on the 8-bit code point value. Since you have a limited range of values, this is easy-ish. If you look at the way that UTF-8 is written out, e.g., here:
https://en.wikipedia.org/wiki/UTF-8
you'll see that the values you need to represent are written as two unsigned bytes, the first beginning with binary 110B, and the second with 10B. The bits of the code point value are split up and distributed between these two bytes. Doing this conversion will need a little masking and bit-shifting, but it's not hugely difficult.
Having said all that, I have to wonder why you'd want to assign a character to a label that users will likely not understand? Why not just write the hex number on the label, if it is not a displayable character?
I need to generate a pin number, between 0 and 9999;
0's are important since I'm gonna use this pin to encrypt some files, and encrypting with '0024' is different than encrypting with '24'
I'm using an unsigned int and it's isn't working..
Is the only way an array?
You can't. An int is an integer, and for integers it really doesn't make sense to talk about leading zeros. They don't exist, an integer (in the mathematical sense, which is what int is trying to model on a computer) basically cannot have leading zeros. See comments for more pedantry about this, I tried to simplify it reasonably but might have failed since I'm just a lowly programmer and not a mathematician.
All the bits available for the int are used to store actual value bits, none are available to store that kind of representational information.
It sounds as if you want a string, or an array of digits.
Convert your integer value as a string and do formatting so it will return integer with leading zero in string format.
im looking for a base conversion function in c that could do conversions from bases 2 up to 36, including bases with characters A-Z.
For now i just found on the web functions that deal with base 2, ten and hex and a bit limited.
For this project, it would probably help to understand how bases work. In any case, let's walk through a process for how one might convert to, say, base twelve. This should be the simplest method to implement.
First up, we have our decimal number, since that's an easy place to start. Let's say, I dunno, 1452 is our number. We'll also need an array of characters for what each character is, since that'll be a lot easier than a straight ASCII conversion, where the number characters and letter characters are separated.
int dec=1452;
int toBase=12;
char outputs[36]={'0','1','2','3','4','5','6','7','8','9','A','B','C','D','E','F','G','H','I','J','K','L','M','N','O','P','Q','R','S','T','U','V','W','X','Y','Z'}
Following that, we probably will only be OUTPUTTING the result in another base - it doesn't make sense to store it multiple ways, and makes your conversion process simpler by only converting from one base to any other given. We could store the result in a character array, but again, we already have the number stored - no point.
For this method I'm going to describe, we'll need a buffer variable to keep track of our number as we convert parts of it.
int buf=dec;
Next up, we'll start counting spaces back in the base we're going to, 12, and see what each space is worth. We'll continue until we pass our number, then backtrack one. We'll also need to save what space we're on for a for loop from that to the first space later.
int space=0;
while(Math.pow(toBase,space))<buf){
space++;
}//Braces added for clarity
space--;
Now, this is the main calculation loop, where we'll output the result. Again, the original number is still stored in 'dec,' so we don't need to worry about loss of data or changing it at all.
int i;
for(i=space;i>=0;i--){//We have set up the for loop to check each space as we progress
int modResult=buf%Math.pow(toBase,i);//Gets the number that goes in this space of the resulting base number
buf-=modResult*Math.pow(toBase,i);//We have that, so take it out of the number
printf("%c",outputs[modResult]);
}
Because of the way we're doing this, going from the top space to the bottom, modResult will never be higher than the highest number our base can go in. With this, your program will output to console the resulting number. Also, keep in mind that this only outputs the number - for the purposes of storage and calculation, it's much simpler to use the built-in functions that use base 10. Furthermore, be careful that your toBase variable never goes above 36.
As a further note, I numbered the digits (spaces), from right to left, starting at zero, because the far right space is 1, represented by your base to the zeroth power. Hope this helps.
I am just learning C and in my class this is a part of our first program.
The full description of the function I am trying to implement:
if that's tl;dr, a key point is that I am not allowed to use functions from other libraries (so something like srtol is ruled out).
int parseHexString(char *hexString, int *integerRead); The first
parameter is a null terminated C string, that represents a hexadecimal
integer. This function parses this string, accumulating the integer
value it represents. This integer value is placed at the location
pointed to by the second parameter, integerRead. If a bad hexadecimal
character, thus an invalid hex value, is encountered, this function
stops looking at further characters within the string and returns -1.
If a good hex value is parsed, it returns 0.
The correct way to implement this function looks at the first
character within the string first and does not use a stack to
accomplish the parsing. Your first assembly language program will need
to implement what this function accomplishes, so you will save
yourself time by implementing this function the correct way.
For this function, do not call any functions from any libraries; as an
exception, for debugging purposes only, you may use printf(). It will
help our grading if you remove your debugging code before you submit
your assignment.
I am NOT just looking for a full implementation of this function, just some tips or hints to get me started.
I feel as though there is some intuitive way of doing this, but right now I am blanking. I'm concerned with how I am supposed to start at the first character of the string and then go forward from there to convert it to decimal.
How about:
Get the length of the string
Walk the string from left to right
For each character:
Check if it's a valid hex character
Add its decimal value multiplied by 16^x, where x is the number of characters left on the right
In ASCII, i wonder how is 65 translated to 'A' character?
As far as my knowledge goes, 65 can be represented in binary but 'A' is not. So how could this conversion happen?
Everything in a computer is binary. So a string in C is a sequence of binary values. Obviously that is not much use to humans, so various standards developed, where people decided what numerical values would represent certain letters. In ASCII the value 65 represents the letter A. So the value stored is 65, but everyone knows (because they have read the ASCII spec) that value corresponds to the letter A.
For example, if I am writing the code to display text on the screen, and I receive the value 65, I know to set certain pixels and delete other pixels, so that pixels are arranged like:
#
# #
#####
# #
# #
At no point does my code "really know" that is an "A". It just knows that 65 is displayed as that pattern. Because, as you say, you cannot store letters directly, only binary numbers.
It is just a 'definition'. ASCII defines the relationships between integer values and characters. For implementation, there is a table (you can't see it) that does this translation.
EDIT:
Computers just 0/1. A stream of characters is just a bunch of 0/1 streams: 0110010101... There is a contract between human and computer: 8 bits are represented as a character (okay, there are Unicode, UTF-8 and etc). And, 'A' is 65 and so on.
In C/C++ and any other languages, strings are just handled like integer arrays. Only when you need to display strings, that numbers are 'translated' into character. This translation is done by either hardware or software:
If you write a function that draws character, you're responsible to draw 'A' when the input is 65.
In the past, say that we're in DOS, the computer draws 'A' on the number 65. That relationship is usually stored in the memory. (At that time where no graphics, only text, this table can be tweaked to extend characters. I remember Norton DOS utilities such as NDD/NCD changed this table to draw some special characters that were not in the regular ASCII code.)
You may see this sort of contract or definition in everywhere. For example, assembly code. Your program will be eventually translated into machine code: that is also just a bunch of 0 and 1. But, it is extremely hard to understand when only 0 and 1 are shown. So, there is a rule: say 101010 means "add", 1100 means "mov". That's why we can program like "add eax, 1", and it'll be ultimately decoded into 0/1s.
'A' IS 65. It's just that your display device knows that it should display the value 65 as an A when it renders that value as a character.
The ASCII table is just an agreed upon map of values and characters.
When the computer is instructed to write a character represented by a number to the screen it just finds the numbers corresponding image. The image doesn't make any sense to the computer, it could be an image that looks like an 'A' or a snowman to the user.
So how could this conversion happen?
This conversion is merely called character encoding. The computer only understands bytes and humans (on average =) ) only understands characters. The computer has roughly said a mapping of all bytes and all characters which belongs to those bytes so that it can present the data in a human friendly manner. It's all software based (thus not hardware based). The operating system is usually the one who takes care about this.
ASCII is one of the oldest character encodings. Nowadays we should be all on UTF-8 to avoid Mojibake.
Everything in a computer is stored as a number. It's how software interprets those numbers that's important.
ASCII is a standard that maps the number 65 to the letter 'A'. They could have chosen 66 or 14 to represent 'A', but they didn't. It's almost arbitrary.
So if you have the number 65 sitting in computer memory somewhere, a piece of code that treats that piece of memory as ASCII will map the 65 to 'A'. Another piece of code that treats that memory as an entirely different format may translate it to something else entirely.
The code for converting the ASCII value entered to corresponding character is
int a;
printf("enter the ASCII value : ");
scanf("%d",&a);
printf("%d is the ASCII of %c",a,a);
Its based on a lookup table invented back in the 60's.