Lpc2000

Hi,

I'm in the process of connecting a EPSON S1D13A05 display controller to
the LPC2210.  The 16-bit S1D13A05 will operate in big endian mode (the
only mode available without external ready signal) but the LPC2210 is
litte endian (thanks to Micron Engineering for pointing this out).  

Will a hardware byte-swap solve all "endian" problems (LPC D0..D7 ->
Epson D8..D16 and LPC D8..D16 -> EPSON D0..D7)?

I don't see any problems with this but it's a tricky thing to do, so
maybe someone out there might have done this?

Best regards,
Pieter Verstraelen



[Non-text portions of this message have been removed]

Pieter Verstraelen ha scritto:

>Hi,
>
>I'm in the process of connecting a EPSON S1D13A05 display controller to
>the LPC2210.  The 16-bit S1D13A05 will operate in big endian mode (the
>only mode available without external ready signal) but the LPC2210 is
>litte endian (thanks to Micron Engineering for pointing this out).  
>
>Will a hardware byte-swap solve all "endian" problems (LPC D0..D7 ->
>Epson D8..D16 and LPC D8..D16 -> EPSON D0..D7)?
>
>I don't see any problems with this but it's a tricky thing to do, so
>maybe someone out there might have done this?
>  
>
Not with ARM but normally I do hardware byte swap with Renesas 16 bit 
microcontrollers and ethernet MAC chips (that are little endian because 
they interface directly to ISA bus on PCs architectures). Endianess is a 
common problem.

>Best regards,
>Pieter Verstraelen
>
>
>
>[Non-text portions of this message have been removed]
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>


  ----------

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.16/225 - Release Date: 09/01/2006


[Non-text portions of this message have been removed]

> >I don't see any problems with this but it's a tricky thing to do, so
> >maybe someone out there might have done this?
> >
> >
> Not with ARM but normally I do hardware byte swap with Renesas 16 bit
> microcontrollers and ethernet MAC chips (that are little endian
because
> they interface directly to ISA bus on PCs architectures). Endianess is
a
> common problem.

So, does this hardware byte swap solve all endian problems?  Can you use
the Ethernet MAC chip without changes to the code?  
I think 8 and 16 bit access (to a 16 bit device with swapped data lines)
is not a problem but a 32 bit access (to a 16 bit swapped device) might
go wrong.

Best regards,
Pieter Verstraelen

Pieter Verstraelen ha scritto:

>>>I don't see any problems with this but it's a tricky thing to do, so
>>>maybe someone out there might have done this?
>>>
>>>
>>>      
>>>
>>Not with ARM but normally I do hardware byte swap with Renesas 16 bit
>>microcontrollers and ethernet MAC chips (that are little endian
>>    
>>
>because
>  
>
>>they interface directly to ISA bus on PCs architectures). Endianess is
>>    
>>
>a
>  
>
>>common problem.
>>    
>>
>
>So, does this hardware byte swap solve all endian problems?  Can you use
>the Ethernet MAC chip without changes to the code?  
>I think 8 and 16 bit access (to a 16 bit device with swapped data lines)
>is not a problem but a 32 bit access (to a 16 bit swapped device) might
>go wrong.
>
>Best regards,
>Pieter Verstraelen
>
>  
>
Suppose to write the DWORD d=0x01020304

A little endian machine interface on 8 bit bus will write lsb first so 
will write on the bus: 0x04, 0x03, 0x02, 0x01
interfacing on a 16 bit bus (without swapping) it will write 0x0403, 0x0201
so swapping MSB and LSB data port will solve the problem.
The little endina advantage is that data will be write always in the 
same order independently from their size.

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


  ----------

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.16/225 - Release Date: 09/01/2006


[Non-text portions of this message have been removed]

> So, does this hardware byte swap solve all endian problems?  Can you use
> the Ethernet MAC chip without changes to the code?

The byte swapping of bus high/low bytes only makes bus endianess happy.  You
still need to concern yourself with CPU endianess of code.  If code was
written targeting a little endian CPU there should be no problem.  Possibly
if code targeted a big endian CPU there may be no issues, but depends on the
code.  Computer networks are big endian, and endianess issues related to
network byte order may only show up closer to the application layer.  It all
depends on the code.


Joel

Joel Winarske ha scritto:

>>So, does this hardware byte swap solve all endian problems?  Can you use
>>the Ethernet MAC chip without changes to the code?
>>    
>>
>
>The byte swapping of bus high/low bytes only makes bus endianess happy.  You
>still need to concern yourself with CPU endianess of code.
>
Yes and this is all needed.

>  If code was
>written targeting a little endian CPU there should be no problem.  Possibly
>if code targeted a big endian CPU there may be no issues, but depends on the
>code.  Computer networks are big endian, and endianess issues related to
>network byte order may only show up closer to the application layer.  It all
>depends on the code.
>  
>
Joel, all data related to ethernet level is endiness corrected by 
writing to the mac chip and this solves the hw chip interfacing problem 
that was the original question.

>
>Joel
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>


  ----------

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.16/225 - Release Date: 09/01/2006


[Non-text portions of this message have been removed]

> >>So, does this hardware byte swap solve all endian problems?  Can you use
> >>the Ethernet MAC chip without changes to the code?
> >>
> >>
> >
> >The byte swapping of bus high/low bytes only makes bus endianess happy.
> You
> >still need to concern yourself with CPU endianess of code.
> >
> Yes and this is all needed.

I haven't looked at his code in question, so I listed the potential
possibilities.  If network byte order isn't handled in a portable way, and
code was developed for big endian, he most likely will still have byte order
problems.

Joel