Aug 232011

It is one of the problems some network programmers meet while coding. While debugging executable files You may have noticed that, when seen in hexadecimal editor, some data in the files is ordered backwards. First you see the 1 and then several zeroes. But you know for sure, that the value you encoded for a constant is actually “1” instead of 01 00 00 00.This is what Little endian byte order actually is.Have a look in the decimal value 305,419,896 in HEX. It is 0x12345678. If your machine is Big endian, you will see this value stored in a binary file looking the same way it is. But if your machine is little endian, The value stored in the file will look like 78 56 34 12. The least significant byte will be in front, and the most significant will be in back.

The reason for this goes back in the computer’s past, when it was more important to make MATH really fast in spite of easiness. Imagine you have 1 physical address. This address has the value 01 00 00 00. If you need to read this address as byte, word or long integer. You will ALWAYS get the value 1, which is the real value. If you are using Big endian byte order, you will need to get the address + 4 if you need byte, address + 2 if you need word. The little endian byte order is still used in network equipment and serial interface dialog, so it’s good to know how to cope with it… or you will get really annoyed 😉

Also, there is the need for speed. If your processor has only 3 real registers (X, Y and Accumulator), than it’s easier to compute the values if they are little endian.

This is of course an ideal case of what is now known as 64 bit processor. One that can use 64 bit words and registers. In case you are using Big endian byte order you cannot use the multiplication but integer division, which is slower.

If you are Linux user but unsure what endianness your equipment uses, execute this:

If you want this byte order reversed and shown using simple math, use this Perl script:

This is just a rough example. There is easier way to make and explain it. Get the input value, the least significant byte can be obtained by getting the “modulo” of integer division from the input value, store this modulo in an array. After this subtract the modulo from this input value and divide the value by 256. This is the new input value. Repeat, until value is zero. Voila. You have an array of [most significant, less significant … least significant] bytes.

The script will only work on Long integers, but can easily be made to work with 64 bit words. Made It short, because it’s more easy to read. With Little endian, we will always see backward byte order:

And if you need to see how many bytes per integer and long integer is your equipment using, execute this:

I hope this explains the Little and Big endian byte order. You can check the articles I’ve used for more information.



 Posted by at 12:07 pm
Aug 152011

Datecs Fiscal printers FP 3530/3550 are also known as Citizen IDP 3530/3550, so if you have that printer instead of Datecs version – this little neat program will also work for you.

I wrote this code for a Cable TV operator in the city of Sofia (Bulgaria) long ago. It is closed now, but this code was running on 50 of their cash desks (all running Slackware Linux). I did some modifications but they are lost and not retrievable anymore. Most of this is tested on 3530. 3550 is also having paper feed cutter, this code cannot cut the paper, but It can be added quick if anyone can provide a FP3550 unit for testing.

The code is a bit old and is my first Perl script, a bit chunky and raw and also I wrote Perl at this days inspired by Pascal, so if you think you can better the code – feel free to post suggestions and links. I will appreciate them.

Basically, you need to set a symlink to your printer in /dev/ or change the line pointing to the device to /dev/ttyS0 or wherever your Fiscal printer resides on the machine.

 Posted by at 2:07 pm