Lpc2000

>Again, I have kids to feed and a company to run.  Sorry.

I notice this keeps coming up.  Name your price, then.  Sounds like it
may become a preffered option for those with no budget for hardware
analysers.  Guess philips missed the proverbial boat somewhere in
their usb implementation.  The rest of us'll stick to the ftdi &
cp2101 chips, I guess.  Ethernet keeps looking better and better...

Steve

Steve, 

[Context of USB stack for LPC214x]

> >Again, I have kids to feed and a company to run.  Sorry.
> 
> I notice this keeps coming up.  Name your price, then. 

As I said in the original post, my plans for the USB stack are not yet
fully formed.  It might never come to market, or it might, depending
upon interest and other factors.

> Sounds like it may become a preffered option for those with no budget
> for hardware analysers.

A USB analyzer can tell you what's happening on the bus as it sees
it--it can't tell you what's wrong when you tickle the USB protocol
engine on the 214x.

> Guess philips missed the proverbial boat somewhere in
> their usb implementation.  The rest of us'll stick to the ftdi &
> cp2101 chips, I guess.  Ethernet keeps looking better and better...

USB has some nice features in that power is provided to the adapter.
POE is a contender, but POE isn't readily available.  Ethernet has its
own problems, such as setting the device address (for instance).

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

>From: "Paul Curtis" <plc@...>

...
>USB has some nice features in that power is provided to the adapter.
>POE is a contender, but POE isn't readily available.  Ethernet has its
>own problems, such as setting the device address (for instance).

It looks like National is going to push poe hard.
I attended a seminar a jear ago and the already provided
solutions for poe.
I dont like poe because you need special transformers.
In the moment they are hard to get and expensive.
When the industry is going to accept poe this may change.

Cheers
Michael

--- In lpc2000@yahoogroups.com, Steve Franks <stevefranks@i...> wrote:
>
> >Again, I have kids to feed and a company to run.  Sorry.
> 
> I notice this keeps coming up.  Name your price, then.  Sounds like it
> may become a preffered option for those with no budget for hardware
> analysers.  Guess philips missed the proverbial boat somewhere in
> their usb implementation.  The rest of us'll stick to the ftdi &
> cp2101 chips, I guess.  Ethernet keeps looking better and better...

Philips didn't miss anything and LPC2148 USB is working as it says in 
the Philips documentation.
We made at Olimex ->  USB mouse, USB mass storage, USB audio HID 
devices codes which works without problem whatsoever (don't ask for 
sources these are commercial projects :)

The only problem I can think of with LPC2148 USB is that everybody 
these days rely to use somebody's else code and not to read the 
datasheets and write one by himself.

This is why *everybody* start writting LPC2148 USB code based on KEIL 
Mass-storage demo code which is useless piece of crap as it doesn't 
handle the interrupt flags properly and the code may suddently freeze 
up (actually it's perfect for "demo" it shows something and is useless 
for anything else, so well done Keil!).

C'mon guys use your heads :) I know Internet made it too easy now and 
when you get new project first thing is to search for ready made code 
examples which to re-use but this is definitely not the best approach!

just my 2 cents..

Best regards
Tsvetan
---
PCB prototypes for $26 at http://run.to/pcb (http://www.olimex.com/pcb)
PCB any volume assembly (http://www.olimex.com/pcb/protoa.html)
Development boards for ARM, AVR, PIC, MAXQ2000 and MSP430  
(http://www.olimex.com/dev)

Dear Tsvetan

As a professional developer for win/linux application i cannot let your 
comment
pass by without disagreement ;-)

>C'mon guys use your heads :) I know Internet made it too easy now and
>when you get new project first thing is to search for ready made code
>examples which to re-use but this is definitely not the best approach!
>

Imho this is what sepperates a good from a slow developer.
First thing when writing an application is to study which
piece of code can I reuse.
Then if I cannot find something I start to write my own code.

If seen many developers but in the end even the most talented ones
(to which I do not belong) copy where they can. So they also
introduce much less bugs.
Only a beginner tries to write all himself.

Cheers
Michael

--- In lpc2000@yahoogroups.com, "tsvetanusunov" <tusunov@m...> wrote:
> C'mon guys use your heads :) I know Internet made it too easy now and 
> when you get new project first thing is to search for ready made code 
> examples which to re-use but this is definitely not the best approach!

Well said.  I could not agree with you more.

Ok.
I really need a USB code running in gcc and a don't have children but 
want to someday.
So, I'' post all my findings here, and what i got. Hopefully somebody 
will try this, do some more progress and share it back here.

As far as I know the main problem porting keil USBMEM to gcc is the 
__pack attribute.
I know keil code is not that complete, but once it is up and running 
will be easier to work in robustness.

Since I don't know if there is some problem in posting the whole code, 
i'm telling what i've changed.

hopefully i did not forget any changes, but if so, ask.



//----------------------------------------------------------------------------------------------------------
*makefile*
be sure that your compiler flags include:
  -fpack-struct

//----------------------------------------------------------------------------------------------------------
*diskimg.c*
replace :
  const unsigned char DiskImage[MSC_ImageSize] __at MSC_ImageStart = {
with:
  const unsigned char DiskImage[MSC_ImageSize] = {
i haven't analised the MSC doe yet, but so far i thing this is harmless

//----------------------------------------------------------------------------------------------------------
*usbhw.h*
add this line:
    #define __irq __attribute__((interrupt))

//----------------------------------------------------------------------------------------------------------
*mscuser.c
*replace:
  BYTE  Memory[MSC_MemorySize] __at MSC_MemoryStart;   // MSC RAM
with:
  BYTE  Memory[MSC_MemorySize];   // MSC RAM
*
*//----------------------------------------------------------------------------------------------------------
*usbcore.c*
replace:
  (BYTE *)pD += ((USB_CONFIGURATION_DESCRIPTOR *)pD)->wTotalLength;
with:
  pD = (USB_COMMON_DESCRIPTOR*)(((BYTE *)pD) + 
((USB_CONFIGURATION_DESCRIPTOR *)pD)->wTotalLength);
and
replace:
  (BYTE *)pD += pD->bLength;
with:
  pD = (USB_COMMON_DESCRIPTOR*)(((BYTE *)pD) + pD->bLength);
both appears twice in the file
I'm in this point now, but i think this generates good code.

//----------------------------------------------------------------------------------------------------------
*usbhw.c*
replace:
  *((__packed DWORD *)pData) = RX_DATA;
  pData += 4;
with:
      DWORD w;
      w = RX_DATA;
      *pData++ = (w    )&0xff;
      *pData++ = (w>>8 )&0xff;
      *pData++ = (w>>16)&0xff;
      *pData++ = (w>>24)&0xff;
and
replace:
  TX_DATA = *((__packed DWORD *)pData);
  pData += 4;
with:
      DWORD x;
      x  =  (*pData++);
      x  |= (*pData++)<<8;
      x  |= (*pData++)<<16;
      x  |= (*pData++)<<24;
      TX_DATA = x;

//----------------------------------------------------------------------------------------------------------
*usbuser.c*
replace:
   #define P_EP(n) ((USB_EP_EVENT & (1 << (n))) ? USB_EndPoint##n : NULL)
with:
   #define P_EP(n) ((USB_EP_EVENT & (1 << (n))) ? (void*)USB_EndPoint##n 
: NULL)
and
replace:
   const void (* USB_P_EP[16]) (DWORD event)=
with:
   const void (* const USB_P_EP[16]) (DWORD event)=

//----------------------------------------------------------------------------------------------------------
*usbuser.h*
replace:
   extern const void (* USB_P_EP[16]) (DWORD event)=
with:
   extern const void (* const USB_P_EP[16]) (DWORD event)=

//----------------------------------------------------------------------------------------------------------

Mauricio






























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

Tsvetan wrote:

>>C'mon guys use your heads :) I know Internet made it too easy now and
>>when you get new project first thing is to search for ready made code
>>examples which to re-use but this is definitely not the best approach!

I agree with Tsvetan on some points.
It is true that with Internet (and this Yahoo group) it almost seems
easier to google and aks questions than just looking at datasheets.

Michael Rubitschka wrote:

> If seen many developers but in the end even the most talented ones
> (to which I do not belong) copy where they can. So they also
> introduce much less bugs.
> Only a beginner tries to write all himself.

Well, as Michael said, copy where you can.
But you have to know what you copy. The Keil code has perfect examples,
it's defenitely not a 'useless piece of crap' als Tsvetan calls it. It
serves a purpose - All my code serves a purpose if it's a demo or a piece
of product level code does not matter. There defenitely is a difference in
quality  ...

Why should I take a lot of time to reinvent the wheel (USB stack, TCP/IP
stack). It takes a lot of studying, understanding - and misunderstanding -
the specs followed by designing, writing and testing large pieces of code.
I rather copy someone else's bugs than create my own in this case ;-)

I am also not re-inventing stuff like a PC, an Operating System, a
compiler, floating point routines or even my own programming language (in
fact I did all of this, just to back up the theoretical stuff I learned).

But copying 'example' code and adding all needed to make it 'product
grade' can be a pain in the ... and create some monsters that are
impossible to maintain.
In that case just go ahead and write your own code. Just don't loose the
good ideas from the example code you got.
Maybe that's what you should do with the Keil code ...

    Rob

Keil has the following copyright notice plastered everywhere in their 
USB code.

   This file is part of the uVision/ARM development tools.
   Copyright (c) 2005 Kiel Software. All rights reserved.

You don't even have permission to adapt the code for a commercial 
project using Keil tools. If you are using an evaluation version of 
their tools you don't even permission to commercialise your own code 
with your own copyright.

If you had permission to use and port their USB code then

1) You don't need a hardware analyser.
2) You don't need to throw out their excellent C structures.

In fact the C structures are essential for productive debugging.

There have been some comments about what needs to be done to port the 
code to GCC (assuming you have permission). These comments are really 
close to the mark.

I have no intention of letting myself become vulnerable to copyright 
issues. I see Keil as having made strategic decisions they intend to 
gain commercially from. I am not going to subvert that.

It is standard practice for companies to produce an SDK (Software 
Development Kit) for developers to make productive use of their product 
line. Developing from scratch using a data sheet is not commercially 
sane for this level of complexity. In effect Keil has done the work for 
Philips (if they allow you to adapt their examples). Of course if 
Philips got the message that their product sales will suffer without an 
independent SDK then they may rethink the absence.

John Heenan

--- In lpc2000@yahoogroups.com, Steve Franks <stevefranks@i...> wrote:

>
> >Again, I have kids to feed and a company to run.  Sorry.
> 
> I notice this keeps coming up.  Name your price, then.  Sounds like it
> may become a preffered option for those with no budget for hardware
> analysers.  Guess philips missed the proverbial boat somewhere in
> their usb implementation.  The rest of us'll stick to the ftdi &
> cp2101 chips, I guess.  Ethernet keeps looking better and better...
> 
> Steve
>

John Heenan wrote:

>I have no intention of letting myself become vulnerable to copyright 
>issues. I see Keil as having made strategic decisions they intend to 
>gain commercially from. I am not going to subvert that.
>
>It is standard practice for companies to produce an SDK (Software 
>Development Kit) for developers to make productive use of their product 
>line. Developing from scratch using a data sheet is not commercially 
>sane for this level of complexity. In effect Keil has done the work for 
>Philips (if they allow you to adapt their examples). Of course if 
>Philips got the message that their product sales will suffer without an 
>independent SDK then they may rethink the absence.
>  
>
I think that the issue most of these companies just don't understand is 
that they pollute their own copyright with their policies.  They 
blatently slap copyright notices on everything in sight, regardless of 
their right it do so or not.  When it comes to REAL STUFF that they 
actually wrote, and is something that they really really want to 
protect, they've overloaded the user with so many bogus copyright claims 
that the end user just doesn't care anymore.

To people who do know what a legal copyright is, the "copyright 
anything" behavior just shows how ignorant a company is and leaves the 
question of "is anything truely copyrightable"?

Figure it this way, if they are asserting copyright over materials that 
cannot be copywrited, do you think they can tell the difference if you 
use their "copyrighted" code?  They probably have no clue as to what 
they could prosecute as a copyright violation...

Regards,

TomW







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

Copyrighted or not, I don't think about using this code as my product 
code, but, it is pointed by the philips site as an sample code for their 
USB device.
And to write my own code, I think that would be very usefull to be solid 
rock in the USB and device specific details. Since I don't want/ cannot 
buy an USB analyzer and the Philips manual is a little bit obscure, the 
best way is to have a functional unit to evaluate.



But about library code, Microchip is very good. They have virtually any 
kind of sample code to use for free with their microcontrollers.


Mauricio

John, 

> Keil has the following copyright notice plastered everywhere in their 
> USB code.
> 
>    This file is part of the uVision/ARM development tools.
>    Copyright (c) 2005 Kiel Software. All rights reserved.
> 
> You don't even have permission to adapt the code for a commercial 
> project using Keil tools. 

Wrong.  According to their EULA:

"EXAMPLE CODE: In respect of any Example Code identified in the Schedule
KEIL hereby grants you, provided you comply with the terms of clause
1(iv), additional non-exclusive, non-transferable licences to; (a) use
and modify the source code form (if supplied) of any such Example Code,
for the sole purposes of internal testing, evaluation, and incorporation
into, and the development and testing of, Licensed Products; and (b)
reproduce and distribute the Example Code, or derivatives thereof, only
in object code form, and only as part of Licensed Products."

So, you can redistribute derivates as object code as part of a Licensed
Product.  The next clause in the EULA defines a Licensed Product.

The Licensed Product is defined by the EULA so:

"LIBRARIES: In respect of any Language Libraries and Helper Libraries
(together "Libraries") identified in the Schedule, KEIL hereby grants
you, provided you comply with the terms of clause 1(iv), additional
non-exclusive, non-transferable licences to; (a) develop applications
which incorporate the Language Libraries and substantial additional
functionality, or which use the Helper Libraries (the permitted
combinations of such applications and Libraries are referred to in this
Licence as "Licensed Products"); (b) compile and link the Libraries with
such Licensed Products; and (c) reproduce and distribute the Licensed
Products."

Hence, you can freely use their example code if you compile it and
distribute it in object code only, as a valid licensed user of the Keil
software.

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

tsvetanusunov wrote:
> --- In lpc2000@yahoogroups.com, Steve Franks <stevefranks@i...> wrote:
>>
>> >Again, I have kids to feed and a company to run.  Sorry.
>>
>> I notice this keeps coming up.  Name your price, then.  Sounds like it
>> may become a preffered option for those with no budget for hardware
>> analysers.  Guess philips missed the proverbial boat somewhere in
>> their usb implementation.  The rest of us'll stick to the ftdi &
>> cp2101 chips, I guess.  Ethernet keeps looking better and better...
> 
> Philips didn't miss anything and LPC2148 USB is working as it says in
> the Philips documentation.
> We made at Olimex ->  USB mouse, USB mass storage, USB audio HID
> devices codes which works without problem whatsoever (don't ask for
> sources these are commercial projects :)
> 
> The only problem I can think of with LPC2148 USB is that everybody
> these days rely to use somebody's else code and not to read the
> datasheets and write one by himself.
> 
> This is why *everybody* start writting LPC2148 USB code based on KEIL
> Mass-storage demo code which is useless piece of crap as it doesn't
> handle the interrupt flags properly and the code may suddently freeze
> up (actually it's perfect for "demo" it shows something and is useless
> for anything else, so well done Keil!).
> 
> C'mon guys use your heads :) I know Internet made it too easy now and
> when you get new project first thing is to search for ready made code
> examples which to re-use but this is definitely not the best approach!
> 
> just my 2 cents..

I won't mind working on an open-source USB stack. In fact, I already
started a bit. I'd like to see a USB-stack released under a license
that allows hobby and commercial use in source and binary form, but
with the requirement that any improvements and additions to the
stack are also made open-source to be integrated back.
It looks like the LGPL is a good match for that.

Basic design ideas (mostly fairly obvious):
* layered approach:
  * USB HW layer that talks to the actual hardware
  * USB core layer that knows how to handle basic USB structures and
    can handle endpoint 0 (ep 0 is special)
  * USB application layer
* Interrupt driven. Basically there are just two interrupt types:
  * device status interrupt (frame, connection state changes, etc.)
  * endpoint interrupts (EP buffer received/transmitted)
* USB core layer is independent of USB application layer
  * USB application layer installs callbacks for the interrupts
    (device status and endpoint) and for USB descriptors.
* No support for DMA yet to keep things simple.

The stack should be completely free from anything that prohibits
open-source use (e.g. ambiguous copyrights). So for now I started
to work just from the datasheet, hopefully re-inventing the wheel
for the last time.

It seems that the USB controller in the LPC214x is at least partially
identical to the Philips PDIUSBD11/12 and ISP118x USB device
controllers. Does anyone know of any suitable free source code
to re-use?

Kind regards,
Bertrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD3MVuETD6mlrWxPURAo/hAJ9t9WXcDz2x4rP8RDlXnWjdhueNGwCfWBET
4dFAKPteN5BMmu7SO6KPswM=
=Pp+N
-----END PGP SIGNATURE-----

The D12 examples contain USB specification chapter 9 code.  It looks nearly
identical to portions of the Keil copyrighted code.  I would be on the
lookout for the USB specification chapter 9 code.

My thoughts on an open source stack:

I see three layers to software:
1. Application (end point) CDC ACM serial, MassStorage, etc.
2. Common Stack (endpoint 0 handling, USB Chp 9 related)
3. Hardware dependent code.  Interrupt code, RTOS hooks, etc.

The top two layers should be 100% portable.

Without a USB hardware analyzer implementing the common stack and USB
specification chapter 9 is near useless.

I have interest in the upcoming LPC23xx OTG enabled parts.  AFAIK, there is
no open stack floating around for embedded OTG controllers other than Linux.
This will become a concern for Phillips when they need to sell these parts.
In light of this it might be worthwhile researching OTG controllers prior to
developing stack.  It would make the stack far more useful down the road.
Perhaps Phillips might provide some preliminary info such as what current
product their OTG controller IP for the LPC23xx is based off of.


Joel

Does the upcoming LPC23xx implement something similar to the ISP1362, but
hardwired with a single OTG port?

What is the timeline for engineering samples on the LPC2300 series?

Regards,
Joel Winarske