Hallo it would be fine if somebody could help me on the following problem: I have to send the decimal digits of a 5 Byte Hex value, that is currently stored in an array, via the serial interface. It is no problem to get the digits of a 4 Byte number but Keil or the controller do not allow double integer! any solution????
Any projected delivery date for "long long" (64 bit) support? (No, it's not a crazy thing to want to do with an 8-bit micro. To cite one example, IEEE 802 requires all statistics / event counters not to roll over for at least 57 minutes while counting their maximum rate. Counters that cannot achieve this duration in 32 bits must be 64 bits wide, per spec. For a Gigabit Ethernet device, that means most of the defined stats. It's not at all out of the scope of an 8051 to be embedded in a NIC card or what-have-you, and 1Gbps is a pretty routine rate these days. Not all long integers show up in astronomy programs and Bill Gate's bank accounts.)
"Any projected delivery date for "long long" (64 bit) support?" And 64 bit doubles please?
You may have to wait some time for 64-bit support. While you wait, the following link may be of interest: ftp.embedded.com/.../crenshaw98.txt
Thanks for the link. I use some similar C code to get by for now. Occasionally I toy with writing proper assembler subroutines to do the math, but I haven't so far. (One question that comes up: The DPTR can be incremented, but not decremented. So, when you're adding U64s in xdata, it would be very natural if they were little-endian. You'd just have a movx addc inc dptr loop. Keil is of course big-endian, but you can't do the same thing and "dec dptr" quite as easily. So, are there any neat 8051 assembler tricks for doing big integer math that's not all done in registers/data space? I'm not much of an assembler wizard.)
Of course, if you're making up your own 64-bit data type, you don't have to stick with Keil's big-endianism... I s'pose it depends on your application and whether 64-bit efficiency on its own is more important than the efficiency of "interfacing" to Keil's standard types?