Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Thread

lpc2148 usb + gcc

lpc2148 usb + gcc

2006-02-06 by Dmitry Diky

Fellows,
Has anybody got any available examples (HID, virtual com, etc...) running ?

Cheers,
Dmitry.

Re: [lpc2000] lpc2148 usb + gcc

2006-02-06 by Bertrik Sikken

Dmitry Diky wrote:
> Fellows,
> Has anybody got any available examples (HID, virtual com, etc...) running ?

Yes, I got the examples working to the point where the USB device is
recognised by Windows, but have not extensively tested them.
The USB mass storage example (compiled with GCC) allows me to read a
file, but then appears to hang when windows tries to write to
the USB disk (to update last access time?).

Making the examples work with GCC involved byte-packing all USB related
structures and replacing compiler specific options with GCC equivalents.

I can tell you what to change in the keil USB examples, but I cannot
send you the actual source files.

I'm working on an open-source LPC USB stack now.

Kind regards,
Bertrik

Re: [lpc2000] lpc2148 usb + gcc

2006-02-06 by Bertrik Sikken

Dmitry Diky wrote:
> Fellows,
> Has anybody got any available examples (HID, virtual com, etc...) running ?

Yes, I got the examples working to the point where the USB device is
recognised by Windows, but have not extensively tested them.
The USB mass storage example (compiled with GCC) allows me to read a
file, but then appears to hang when windows tries to write to
the USB disk (to update last access time?).

Making the examples work with GCC involved byte-packing all USB related
structures and replacing compiler specific options with GCC equivalents.

I can tell you what to change in the keil USB examples, but I cannot
send you the actual source files.

I'm working on an open-source LPC USB stack now.

Kind regards,
Bertrik

Re: [lpc2000] lpc2148 usb + gcc

2006-02-07 by Dmitry Diky

Hi Bertrik,

> Making the examples work with GCC involved byte-packing all USB related
> structures and replacing compiler specific options with GCC equivalents.
Thanks a lot...

I looked into KEIL's examples and found __packed keyword which appeared in the 
from of 'long'. I'm puzzled there, for example:

char *a, *b;

*(__packed long *) a = *(long *)b;

how to interpret this???

Cheers,
Dmitry.

Re: [lpc2000] lpc2148 usb + gcc

2006-02-07 by Sean

Dmitry:

__packed means that there will be no gaps left around that 
variable.  Normally a long would be put on a 32-bit boundary, however the 
__packed attribute tells the linker not to leave any adjacent space.

Note that on the ARM7 chips if you attempt to access a halfword or word 
that is not aligned properly the behaviour is "undefined".  If 'a' is not 
properly aligned that statement would not work.  In this case this __packed 
instructs the compiler that 'a' may not be aligned, so read/write it as a 
series of 4 bytes instead of a directly as a 32-bit word.

I had a bug in my app this way that happened because of this.  It was 
strange, I traced it down to writing a value almost like this, and my debug 
code did:

void dummyCall(long *lp)
{
   foo = *lp;
}

long foo, bar, *lp;

HexDump(b,4);

lp = (long *)b
bar = *lp;
dummyCall(&bar);
*lp = bar;

HexDump(b,4);

What was happening is the first and last halves of the 4-byte segment at b 
were swapping (i.e. 0xAABBCCDD became 0xCCDDAABB) and I couldn't for the 
life of me figure out why, until I realized that b wasn't on a 4-byte boundary.

The reason for the dummy call was because otherwise the compiler is because 
when I did this:

bar = *lp;
*lp = bar;

The compiler actually didn't compile that code.

-- Sean

At 04:26 2/7/2006, you wrote:
Show quoted textHide quoted text
>Hi Bertrik,
>
> > Making the examples work with GCC involved byte-packing all USB related
> > structures and replacing compiler specific options with GCC equivalents.
>Thanks a lot...
>
>I looked into KEIL's examples and found __packed keyword which appeared in 
>the
>from of 'long'. I'm puzzled there, for example:
>
>char *a, *b;
>
>*(__packed long *) a = *(long *)b;
>
>how to interpret this???
>
>Cheers,
>Dmitry.
>
>
>SPONSORED LINKS
><http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=mfaAujKZXA2Z_vxre9sGnQ>Microcontrollers 
><http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=9jjd2D3GOLIESVQssLmLsA>Microprocessor 
><http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=OMnZuqMZX95mgutt4B-tDw>Intel 
>microprocessors
><http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=Malspbd0T4Rq3M4Q0nHrfw>Pic 
>microcontrollers
>
>
>----------
>YAHOO! GROUPS LINKS
>
>    *  Visit your group "<http://groups.yahoo.com/group/lpc2000>lpc2000" 
> on the web.
>    *
>    *  To unsubscribe from this group, send an email to:
>    * 
> <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>lpc2000-unsubscribe@yahoogroups.com 
>
>    *
>    *  Your use of Yahoo! Groups is subject to the 
> <http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.
>
>
>----------

Re: [lpc2000] lpc2148 usb + gcc

2006-02-07 by Dmitry Diky

Sean,
does it mean that 
	*(__packed long *) a = *(long *)b;
is actually 
	memcpy(a,b,4)
???

Cheers,
Dmitry.
Show quoted textHide quoted text
On Tuesday 07 February 2006 13:25, Sean wrote:
> Dmitry:
>
> __packed means that there will be no gaps left around that
> variable.  Normally a long would be put on a 32-bit boundary, however the
> __packed attribute tells the linker not to leave any adjacent space.
>
> Note that on the ARM7 chips if you attempt to access a halfword or word
> that is not aligned properly the behaviour is "undefined".  If 'a' is not
> properly aligned that statement would not work.  In this case this __packed
> instructs the compiler that 'a' may not be aligned, so read/write it as a
> series of 4 bytes instead of a directly as a 32-bit word.
>
> I had a bug in my app this way that happened because of this.  It was
> strange, I traced it down to writing a value almost like this, and my debug
> code did:
>
> void dummyCall(long *lp)
> {
>    foo = *lp;
> }
>
> long foo, bar, *lp;
>
> HexDump(b,4);
>
> lp = (long *)b
> bar = *lp;
> dummyCall(&bar);
> *lp = bar;
>
> HexDump(b,4);
>
> What was happening is the first and last halves of the 4-byte segment at b
> were swapping (i.e. 0xAABBCCDD became 0xCCDDAABB) and I couldn't for the
> life of me figure out why, until I realized that b wasn't on a 4-byte
> boundary.
>
> The reason for the dummy call was because otherwise the compiler is because
> when I did this:
>
> bar = *lp;
> *lp = bar;
>
> The compiler actually didn't compile that code.
>
> -- Sean
>
> At 04:26 2/7/2006, you wrote:
> >Hi Bertrik,
> >
> > > Making the examples work with GCC involved byte-packing all USB related
> > > structures and replacing compiler specific options with GCC
> > > equivalents.
> >
> >Thanks a lot...
> >
> >I looked into KEIL's examples and found __packed keyword which appeared in
> >the
> >from of 'long'. I'm puzzled there, for example:
> >
> >char *a, *b;
> >
> >*(__packed long *) a = *(long *)b;
> >
> >how to interpret this???
> >
> >Cheers,
> >Dmitry.
> >
> >
> >SPONSORED LINKS
> ><http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&
> >w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=9
> >5&.sig=mfaAujKZXA2Z_vxre9sGnQ>Microcontrollers
> > <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w
> >2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95
> >&.sig=9jjd2D3GOLIESVQssLmLsA>Microprocessor
> > <http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontro
> >llers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c
> >=4&s=95&.sig=OMnZuqMZX95mgutt4B-tDw>Intel microprocessors
> ><http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontroll
> >ers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4
> >&s=95&.sig=Malspbd0T4Rq3M4Q0nHrfw>Pic microcontrollers
> >
> >
> >----------
> >YAHOO! GROUPS LINKS
> >
> >    *  Visit your group "<http://groups.yahoo.com/group/lpc2000>lpc2000"
> > on the web.
> >    *
> >    *  To unsubscribe from this group, send an email to:
> >    *
> > <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>lpc2000-u
> >nsubscribe@yahoogroups.com
> >
> >    *
> >    *  Your use of Yahoo! Groups is subject to the
> > <http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.
> >
> >
> >----------
>
> Yahoo! Groups Links
>
>
>

Re: [lpc2000] lpc2148 usb + gcc

2006-02-07 by Sean

Dmitry:

Probably yes, check out the assembler listing file when you compile the 
source code.  I don't have the Keil compiler so I can't check it.  I'd 
assume it either did a memcpy or perhaps STMIA/LDMIA assembler instructions.

If you needed to do that in gcc then I believe that memcpy(a,b,4) would 
achieve the same result.  I don't know if there is any direct equivalent to 
__packed in gcc when casting variables.

IIRC isn't left-hand side casting behaviour "undefined" as per the C 
specifications?  I know it's convention to allow left-hand casting, but I 
don't think it's part of the C specifications.

In gcc you can do structure packing like this:

// Master Boot Record
typedef struct {
          unsigned char fill[0x1be];      // boot code
          PARTENTRY partitions[4];        // partition table
          unsigned char sig_55;           // 55h boot signature
          unsigned char sig_aa;           // AAh boot signature
} __attribute__((packed)) MBR, *PMBR;

-- Sean


At 05:40 2/7/2006, you wrote:
Show quoted textHide quoted text
>Sean,
>does it mean that
>       *(__packed long *) a = *(long *)b;
>is actually
>       memcpy(a,b,4)
>???
>
>Cheers,
>Dmitry.
>
>On Tuesday 07 February 2006 13:25, Sean wrote:
> > Dmitry:
> >
> > __packed means that there will be no gaps left around that
> > variable.  Normally a long would be put on a 32-bit boundary, however the
> > __packed attribute tells the linker not to leave any adjacent space.
> >
> > Note that on the ARM7 chips if you attempt to access a halfword or word
> > that is not aligned properly the behaviour is "undefined".  If 'a' is not
> > properly aligned that statement would not work.  In this case this __packed
> > instructs the compiler that 'a' may not be aligned, so read/write it as a
> > series of 4 bytes instead of a directly as a 32-bit word.
> >
> > -- Sean
> >
> > At 04:26 2/7/2006, you wrote:
> > >Hi Bertrik,
> > >
> > > > Making the examples work with GCC involved byte-packing all USB related
> > > > structures and replacing compiler specific options with GCC
> > > > equivalents.
> > >
> > >Thanks a lot...
> > >
> > >I looked into KEIL's examples and found __packed keyword which appeared in
> > >the from of 'long'. I'm puzzled there, for example:
> > >
> > >char *a, *b;
> > >
> > >*(__packed long *) a = *(long *)b;
> > >
> > >how to interpret this???
> > >
> > >Cheers,
> > >Dmitry.

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.