Lpc2000

I have a pointer to an unsigned 32 bit value in an array[512] of 
unsigned chars (actually the partition table of a CF).  When I point 
to the value using GCC, it seems that the code is assuming I am 
pointing at the high word and that the low word precedes the high word 
in memory.

I think I am pointing at the low word and the high word should follow.

The byte order within the two 16 bit words is correct.

Any thoughts about what I am doing wrong.  I can see the sector dump 
and I can see the results of extracting values and the results are 
wrong.  Bytes work and 16 bit words work but 32 bit words do not.

Richard

rtstofer wrote:

>I have a pointer to an unsigned 32 bit value in an array[512] of 
>unsigned chars (actually the partition table of a CF).  When I point 
>to the value using GCC, it seems that the code is assuming I am 
>pointing at the high word and that the low word precedes the high word 
>in memory.
>
>I think I am pointing at the low word and the high word should follow.
>
>The byte order within the two 16 bit words is correct.
>
>Any thoughts about what I am doing wrong.  I can see the sector dump 
>and I can see the results of extracting values and the results are 
>wrong.  Bytes work and 16 bit words work but 32 bit words do not.
>
>  
>

You might have a hardware problem where you are byte swapping?  Try 
running an IDENTIFY_DRIVE (0xec) command on the CF.  This will send you 
back a bunch of bytes structured as:

=============== begin ==================
struct DriveID {
  Word Signature;
  Word NumCylinders;
  Word Reserved1;
  Word NumHeads;
  Word NumUnBytePerTrack;
  Word NumUnBytePerSector;
  Word NumSectorsPerTrack;
  DWord NumberSectorsPerCard;
  Word Reserved2;
  char SerialNumber[20];
  Word BufferType;
  Word BufferSize;
  Word EccBytesPassed;
  char FirmwareRev [8];
  char ModelNumber [40];
  Word Max1SectorRW;
  Word DWnotSupported;
  Word Capabilities;
  Word Reserved3;
};
=============== end ===================

Try looking at the text string: ModelNumber.  That will tell you if byte 
swapping is the problem.

I ran into byte swapping issues between the IDE registers and the Data 
register while working with a big-endian controller (MC68EZ328).

IIRC, something tells me that the drive data is Big-Endian on the CF and 
IDE drives...


TomW


>Richard
>
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

The currently released board LPC-P2138 has LED address 0x3000, and 
BUTTON a address 0x18000. The schematic shows LED pins on 12,13 what 
gives 0x1800 mask, and buttons on 15,16 (really is 16,17)

Welcome any feedback!

robert

Hi, 

> The currently released board LPC-P2138 has LED address 
> 0x3000, and BUTTON a address 0x18000. The schematic shows LED 
> pins on 12,13 what gives 0x1800 mask, and buttons on 15,16 
> (really is 16,17)
> 
> Welcome any feedback!

You're not making any sense.  What's the problem?

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors

> 
> You might have a hardware problem where you are byte swapping?  
Try 
> running an IDENTIFY_DRIVE (0xec) command on the CF.  This will 
send you 
> back a bunch of bytes structured as:
> 
> =============== begin ==================
> struct DriveID {
>   Word Signature;
>   Word NumCylinders;
>   Word Reserved1;
>   Word NumHeads;
>   Word NumUnBytePerTrack;
>   Word NumUnBytePerSector;
>   Word NumSectorsPerTrack;
>   DWord NumberSectorsPerCard;
>   Word Reserved2;
>   char SerialNumber[20];
>   Word BufferType;
>   Word BufferSize;
>   Word EccBytesPassed;
>   char FirmwareRev [8];
>   char ModelNumber [40];
>   Word Max1SectorRW;
>   Word DWnotSupported;
>   Word Capabilities;
>   Word Reserved3;
> };
> =============== end ===================
> 
> Try looking at the text string: ModelNumber.  That will tell you 
if byte 
> swapping is the problem.
> 
> I ran into byte swapping issues between the IDE registers and the 
Data 
> register while working with a big-endian controller (MC68EZ328).
> 
> IIRC, something tells me that the drive data is Big-Endian on the 
CF and 
> IDE drives...
> 
> 
> TomW

Yes, for the firmware revision and model ASCII strings the chars are 
in big endian word order.  NumberSectorsPerCard is also in big 
endian word order.

But, I'm at the next step: reading LBA sector 0.  Here the sector 
dump shows the data in little endian word and byte order.  In fact, 
when I point a WORD pointer (16 bit) into the buffer, I get the 
right answer: LSB MSB in ascending order.

The hangup seems to be when I point a DWORD pointer at some 
location.  It picks up those two bytes in ascending order and then 
backs up and picks up the two bytes ahead of the pointer as the 
MSW.  I was expecting LSW MSW in ascending order where I am pointing 
at LSW.  What I get is MSW LSW even though I am pointing at LSW.

Curious!  The bytes are in the proper order.  Alignment issue?

My workaround?  Use something like memcpy to get the data into the 
structure.

Richard

Well, it isn't really endianness that causes the glitch, it is 
alignment.  The ARM requirement for alignment of, call them half-words 
and words, is not consistent with the layout of the various disk 
parameter blocks.

Getting from the sector layout to a nice, neat, data structure is 
going to be a PITA!

Richard

If you use an "__attribute__((packed))" structure with GCC, the compiler 
assumes it is not aligned and reads everything one byte at a time (even 
if it is aligned).

Richard Duits.


rtstofer wrote:

> Well, it isn't really endianness that causes the glitch, it is
> alignment.  The ARM requirement for alignment of, call them half-words
> and words, is not consistent with the layout of the various disk
> parameter blocks.
>
> Getting from the sector layout to a nice, neat, data structure is
> going to be a PITA!
>
> Richard
>
>
>
>
>
>
> SPONSORED LINKS
> Microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=tsVC-J9hJ5qyXg0WPR0l6g> 
> 	Microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=DvJVNqC_pqRTm8Xq01nxwg> 
> 	Pic microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=TpkoX4KofDJ7c6LyBvUqVQ> 
>
> 8051 microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=8051+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=1Ipf1Fjfbd_HVIlekkDP-A> 
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>

--- In lpc2000@yahoogroups.com, Richard Duits <yahoo@r...> wrote:
>
> If you use an "__attribute__((packed))" structure with GCC, the 
compiler 
> assumes it is not aligned and reads everything one byte at a time 
(even 
> if it is aligned).
> 
> Richard Duits.

Thanks!  I'll give it a try right now.
Richard

--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@p...> wrote:
>
> --- In lpc2000@yahoogroups.com, Richard Duits <yahoo@r...> wrote:
> >
> > If you use an "__attribute__((packed))" structure with GCC, the 
> compiler 
> > assumes it is not aligned and reads everything one byte at a 
time 
> (even 
> > if it is aligned).
> > 
> > Richard Duits.
> 
> Thanks!  I'll give it a try right now.
> Richard
>

Initially I had no success but on reflection I realized the example 
was too large to test.

I created a small structure

struct frame {
 unsigned char b;
 unsigned short w; // misaligned
 unsigned int d; // misaligned
} __attribute__ ((packed));

and worked with that.  The __attribute__ does solve my problem.  Now 
I need to rework the structures...

Thanks!
Richard