<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Efficient translate from 0x12345678 to 0x87654321</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/38228/efficient-translate-from-0x12345678-to-0x87654321</link><description> 
Dear all, 
I met a problem due to big-endian of 8051. The phenomenon is as
follows: 

 
32-bit value A[4] is in XDATA space 
Ex. offset 0 = 0x12; offset 1 = 0x34; offset 2 = 0x56; offset 3 =
0x78 

 
I used the following to get this value: 
 *((UINT32</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: Efficient translate from 0x12345678 to 0x87654321</title><link>https://community.arm.com/thread/114678?ContentTypeID=1</link><pubDate>Wed, 18 Feb 2009 04:57:10 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:bbb135a2-79d3-4167-8272-f2ce27be6815</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
As Per said, the format of the data sent to and received from the
flash drive should be defined in the &lt;b&gt;interface specification&lt;/b&gt;
for the drive.&lt;/p&gt;

&lt;p&gt;
it is then up to you to ensure that both your Windows driver
writes according to that specification, and your 8051 &amp;quot;driver&amp;quot; reads
according to that specification.&lt;/p&gt;

&lt;p&gt;
clearly, one of them is broken!&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Efficient translate from 0x12345678 to 0x87654321</title><link>https://community.arm.com/thread/101643?ContentTypeID=1</link><pubDate>Wed, 18 Feb 2009 04:37:06 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:d8504a46-5258-41ac-a729-a6c2b4ff0ba3</guid><dc:creator>liaoo hi</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks for all your information...&lt;/p&gt;

&lt;p&gt;
The story is:&lt;br /&gt;
- Windows application passes 1 array to flash drive. Here array is
like A[4] = {0x11,0x22,0x33,0x44};&lt;br /&gt;
- After reading flash and get that array to B array within
application, B[4] = {0x11,0x22,0x33,0x44};&lt;/p&gt;

&lt;p&gt;
- But within flash drive firmware(MCU is 8051) read this array
into 32-bit XDATA variable C&lt;br /&gt;
=&amp;gt; C=0x11223344 !&lt;br /&gt;
- if Application does the same task then AP got 0x44332211 because
(maybe) Intel CPU and OS is little-endian...&lt;/p&gt;

&lt;p&gt;
Thus application and firmware &amp;quot;see&amp;quot; different data and cause
conflict...&lt;/p&gt;

&lt;p&gt;
Of course application can be modified for this case but I just
want to know if firmware can solve this in efficient way(favor size)
because little GAP...&lt;/p&gt;

&lt;p&gt;
Thanks !&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Efficient translate from 0x12345678 to 0x87654321</title><link>https://community.arm.com/thread/89575?ContentTypeID=1</link><pubDate>Wed, 18 Feb 2009 00:42:17 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:34488c22-6191-4b02-9bed-22d5a9e5a420</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Calling the C51 big- or little-endian is a bit hard, given the
extreme lack of instructions larger than 8 bits.&lt;/p&gt;

&lt;p&gt;
In this case, it is a question of compiler vendor decisions, i.e.
if their 32-bit and 16-bit emulation should be big- or
little-endian.&lt;/p&gt;

&lt;p&gt;
But a big question for the C51 is: Where do you get your 32-bit
number from, and where is it going to be sent. In short - why does it
matter if the processor is big- or litt-endian?&lt;/p&gt;

&lt;p&gt;
For internal use, it shouldn&amp;#39;t matter unless you are about to
implement a big-number library or similar. When communicating using a
protocol you have to follow the standard of the protocol. When
designing new protocols, it is often better to define the protocol so
the little guy don&amp;#39;t need any conversions and possibly have the other
side (maybe a PC) swap the bytes. On the other hand, the swap time is
often not important - remember that making actual computations on a
32-bit number requires quite a number of assembler
instructions...&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Efficient translate from 0x12345678 to 0x87654321</title><link>https://community.arm.com/thread/101639?ContentTypeID=1</link><pubDate>Wed, 18 Feb 2009 00:12:33 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:fa535ddf-35c3-4981-bbd1-c86da9cd9779</guid><dc:creator>Non Keil Related</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;Compiler-generated code for this kind of thing &lt;b&gt;may&lt;/b&gt; well
not be inefficient at all...&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
The keyword there is surely &lt;b&gt;may&lt;/b&gt;. Due to compiler versions,
optimization levels etc, it cannot be guaranteed.&lt;/p&gt;

&lt;p&gt;
Whereas, a little (and simple) piece of assembler would have fixed
and predictable results.&lt;/p&gt;

&lt;p&gt;
Heck, for this function, it would be a case of passing parameters
in registers, shuffling around a bit and returning the result in
registers.&lt;/p&gt;

&lt;p&gt;
I sometimes think that the art of assembler is just fading away
:(&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Efficient translate from 0x12345678 to 0x87654321</title><link>https://community.arm.com/thread/77171?ContentTypeID=1</link><pubDate>Wed, 18 Feb 2009 00:01:41 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:6c29e4e9-737c-4210-861f-92620cb6cd5b</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;Probably the most efficient way (space wise) to do this is to
use a simple assembler function.&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Compiler-generated code for this kind of thing may well not be
inefficient at all - see: &lt;a href="http://www.8052.com/forum/read/162353"&gt;www.8052.com/.../162353&lt;/a&gt;&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Efficient translate from 0x12345678 to 0x87654321</title><link>https://community.arm.com/thread/55440?ContentTypeID=1</link><pubDate>Wed, 18 Feb 2009 00:00:06 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:6a393a97-e30f-4b40-bc1c-d91c72fb4de4</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
Are you sure that you have all the operator precedence &amp;amp;
association correct there?&lt;/p&gt;

&lt;p&gt;
For clarity if nothing else, I suggest you split it onto multiple
lines - that won&amp;#39;t necessarily add any overhead to the generated
code...&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Efficient translate from 0x12345678 to 0x87654321</title><link>https://community.arm.com/thread/55444?ContentTypeID=1</link><pubDate>Tue, 17 Feb 2009 22:53:03 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:6e057d7e-2683-4dc4-8f40-3839c7e3d341</guid><dc:creator>Non Keil Related</dc:creator><description>&lt;p&gt;&lt;p&gt;
Surely the access in little endian produces a result of
&lt;b&gt;0x78563412&lt;/b&gt;.&lt;/p&gt;

&lt;p&gt;
Probably the most efficient way (space wise) to do this is to use
a simple assembler function.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>