# Gui float data from micro controller

I am building a framework for a data acquisition system where the controller sends a (integer/float) data in to the GUI. I have done some ground work on data types and compilers and found out that each integer/float takes 2/4 bytes each.

My doubt is that how to club this integer/float byte in to one and show them as the real integer/float value in GUI.

This is a part of GUI programming I trust, but all data communication were sending data in byte and later clubbing those and displaying as float/int.

eg case:

• step1: controller sends float data to the GUI.
• step2: Controller and compiler splits the data in to 4 bytes.
• step3: Gui recieves 4 Bytes.
• step4: Gui converts Receieved 4 bytes in to float and displays it on the GUI.

I need more clarity on step 4.

So if we need a float/integer in the GUI, how should we club the data coming from the communication ports (USB/uart)?

This would be helpful to build my understanding and clear my doubts, if you suggest your opinions.

• Step 4 is a software problem. – Ignacio Vazquez-Abrams Nov 14 '13 at 7:56
• As a side comment. You used the tag PIC. And PICs (maybe not the latest) have no floating point support in hardware. Any computations using float need a lot of cycles to execute. Are you sure that fixed point decimal is not enough here? It would be a lot more efficient in this case. – Blup1980 Nov 14 '13 at 8:43
• Assuming you're using C, the relevant term here is union. You want to union a char array and your float. – Connor Wolf Nov 14 '13 at 11:56
• Hi I am grateful to all of you for your inputs.I am having no trouble regarding sending the data via pic controller usb and it is in bytes..and 64 Bytes in one format.So i trust the Gui must categorize the data in to 4 bytes and reconstruct the number. Is the pic controller little endian?. – Rookie91 Nov 15 '13 at 4:36

How the value types are represented in memory depends on the architecture (little/big endian for example) and on the standards it complies to.

Example: The IEEE Standard for Floating-Point Arithmetic (IEEE 754) is a technical standard for floating-point computation established in 1985.

From a micro controller perspective, the easiest way to send this kind of data is just to send it in this native (in memory) representation using pointers or unions.

On the PC/GUI side, you may have additional resources/libraries that help you with byte-sequence to type conversions. However you perform the conversion, you just have to make sure it uses the same rules/standard.

Lets take an 16-bit unsigned integer ´i´ with the assigned value of 1000 for example:

i = 1000


The little endian representation would be

0xE8 0x03


in memory. So when you want send this value as a serial byte stream just cast ´i´ to ´byte´ and send two bytes starting from that address.

Your GUI software could perform the cast in the other direction, given that it uses the same standard for the type representation. If it uses big endian, you may have to interchange byte order first.

btw: What kind of GUI/language are you referring to? For example C#/.NET provides extensive mechanisms for type conversions using the BitConverter class.

EDIT Since the author mentioned that he uses C#, here some additional info:
Note that C# itself doesn't define the endianness. Endianness is decided by hardware. However, most platforms that use .NET are LITTLE endian. If you want to be sure, you can check the endianness of the system with the ´BitConverter.IsLittleEndian´ field to tell you how it will behave.

Assuming that your micro controller uses little endian (like all(?) atmel controllers for example), you could convert the bytes given from the 16-bit unsigned int example above using:

    UInt16 value = BitConverter.ToUInt16(new byte[] { 0xE8, 0x03 }, 0);


Otherwise, you may have to revert the byte order first.

• so you need to know the endian type in the software right?. Well I am using Visual studio C sharp. – Rookie91 Nov 15 '13 at 5:59
• Yes, see my EDIT to the answer. I included an example using C#. – Rev1.0 Nov 15 '13 at 7:54
• Wouldn't 1000 be represented in little endian as 0x03 0xE8? The 0xE8 being in the lower address as it's the least significant byte. – m.Alin Nov 15 '13 at 8:48
• Little endian means that the least significant byte is stored in the smallest MEMORY address. Think of a sequential memory layout where the first byte resides at a lower address that the next. So the byte that comes first is located at the lower address. – Rev1.0 Nov 15 '13 at 9:12

you might want to consider fixed-point numbers in many ways depending on the data you expect to deal with in your application

• just 8-bit fraction x its value would be x/255
• 8-bit integer x with 8-bit fraction y and its value x+y/255
• 8-bit fraction x times 2 to the power of 8-bit integer y, (x/255)*2^y
• 8-bit fraction x times 10 to the power of 8-bit integer y, (x/255)*10^y
• all the above but with 16-bits for x and y

check this library application https://www.allegro.cc/manual/4/api/fixed-point-math-routines/

another way is to use the IEEE float point

There is no such thins as "conversion" because "byte" is not a number representation.

Hex, int, float are representations. Thus 4 bytes can be represented as :

• a unsigned integer from 0 to 4294967295
• a signed interger from - −2147483648 to +2147483647
• a float

Thus if you have a 4 byte float, and you send those four bytes. Then you put them back together and that's it. There is no need to convert anything. 4 bytes are 4 bytes.

But, you have to tell your compiler, that the variable containing the 4 bytes has to be interperted into a float. (You did not specify which language you are using . Thus I will assume "C"). You have to do a casting to float on your variable.

• Also, there are multiple fixed-point formats that can be represented in 4 bytes. – Ignacio Vazquez-Abrams Nov 14 '13 at 8:37

You can send any type of data through the serial line. On receiving the data will all be a bunch of bits packed into packets (depending on the protocol). The task of the software on the receiving side is to correctly interpret the received data.

Obviously, other than the data you need to send information about the type of data. Eg: If is byte A is received next byte will be byte B (data) and after that byte C (data) will be received...