We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi guys, Does anyone know how to make the Keil tool generate little endian code? Is that possible? I am using uVision 1.32 Can newest version of Keil tools generate little endian code? Thanks, Anh
Isn't the endianness of your compiler an arbitrary decision on your part? Why not support both? No. It isn't and it wasn't. Having that option REQUIRES that we: 1. Create double the number of libraries (since a big endian and a little endian library are required). 2. Add features and correct problems in 2 places. 3. Double efforts on ANSI compliance and regression testing. 4. Make massive changes (that may introduce bugs) to a very stable development tool chain. I don't think that this is justified. Anyone using an 8051 because of its blazing data processing performance has probably chosen the wrong microcontroller. Jon
I'm currently working on an 8051 with a custom register interface that was designed to be little endian I have a similar situation, except that my device has 32-bit little endian registers. My solution was simply to define functions along the lines of RegRead (addr) RegWrite (addr, val) RegOrEq (addr, val) RegAndEqNot (addr, val) etc When the endianness of your device matches the endianness of your processor/toolchain, these functions can become macros with straightforward assignments, and the compiler handles the details. #define RegRead(addr) *addr #define RegWrite(addr, val) *addr = val; #define RegOrEq (addr, val) *addr |= val; #define RegAndEqNot (addr, val) *addr &= ~val; When the endianess of your device does not match the toolchain, you write a function. Note that you do not need to explicitly byte swap as a separate operation from access. These functions know they're moving to swapped registers, and can do both jobs at the same time. Let's say you read a 16-bit value, returned in R6/R7. Your device is in xdata space. You'll have a routine that looks something like: init DPTR mov @DPTR to R7 inc DPTR mov @DPTR to R6 Notice that while the DPTR is moving from lower addresses to higher, the store into the bytes of the result, as determined by the sequence of the code, is moving from higher to lower. This order costs no more than reading the registers in the "correct" order, and results in swapping the bytes while they're read. If the device were big endian, the routine would be the same, only with the registers used in the opposite order: init DPTR mov @DPTR to R6 inc DPTR mov @DPTR to R7 Either way, the execution cost is the same. Software can internally deal with the values always big-endian, and the Reg* routines flip them only on actual hardware access.