Sign in
Search lpc2000
Subscribe to lpc2000
lpc2000 by Keywords
2106 | ADC | ARM7 | Atmel | Bootloader | CAN | CrossStudio | CrossWorks | DDS | ECos | Ethernet | ETM | FIFO | FLASH | FPGA | GCC | GDB | GNU | GNUARM | GPIO | I2C | IAP | IAR | JTAG | Kickstart | LCD | Linux | LPC | LPC-E2294 | LPC2000 | LPC2100 | LPC2104 | Lpc2106 | Lpc210x | LPC2114 | LPC2119 | LPC2124 | LPC2129 | Lpc2138 | LPC213x | LPC21xx | LPC2210 | LPC2212 | LPC2214 | LPC2292 | LPC2294 | LPC2xxx | LPC3128 | MCB2100 | Olimex | Philips | PWM | Rowley | RTC | RTOS | SPI | SSP | UART | UART0 | UART1 | ULINK | USB | Watchdog | Wiggler
Ads
Discussion Groups
Discussion Groups | LPC2000 | RE: OLimex laziness?!
Discussion group dedicated to the Philips LPC2000 family of ARM MCUs
Confused re: endianness - rtstofer - Oct 18 1:40:00 2005
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
(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )
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
(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )
Re: Confused re: endianness - Tom Walsh - Oct 18 2:33:00 2005
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..."
----------------------------------------------------
(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )
>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..."
----------------------------------------------------
(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )
OLimex laziness?! - rseku - Oct 18 4:19:00 2005
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
(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )
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
(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )
RE: OLimex laziness?! - Paul Curtis - Oct 18 5:15:00 2005
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 need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )
> 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 need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )
Re: Confused re: endianness - rtstofer - Oct 18 9:44:00 2005
>
> 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
(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )
> 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
(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )
Re: Confused re: endianness - rtstofer - Oct 18 14:23:00 2005
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
(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )
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
(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )
Re: Re: Confused re: endianness - Richard Duits - Oct 18 14:31:00 2005
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 >
> ------------------------------------------------------------------------
> >. > ------------------------------------------------------------------------
(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )
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 >
> ------------------------------------------------------------------------
> >. > ------------------------------------------------------------------------
(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )
Re: Confused re: endianness - rtstofer - Oct 18 16:32:00 2005
--- In lpc2000@lpc2..., 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
(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )
>
> 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
(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )
Re: Confused re: endianness - rtstofer - Oct 19 13:05:00 2005
--- In lpc2000@lpc2..., "rtstofer" <rstofer@p...> wrote:
>
> --- In lpc2000@lpc2..., 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
(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )
>
> --- In lpc2000@lpc2..., 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
(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )