[ANNOUNCEMENT] NXP's Port of LUFA, USB XMEGAs

[Dean Camera]

Hi all,

Some of you may have noticed that NXP has released their own official
port of LUFA to their LPC devices, called "nxpusblib" (see
http://www.lpcware.com/content/project/nxpusblib). This new port of
LUFA is being actively developed and maintained by NXP, who are
working in parallel with my own efforts to develop the LUFA core. This
means that while NXP's library uses a modified LUFA codebase, support
for the new fork related to its use on NXP's silicon is the
responsibility of NXP's support staff.

General LUFA questions relevant to all devices may still be posted
here, however in the interests of reducing mailing list noise I would
prefer questions specific to NXP's own fork be posted on the NXP
"LPCWare" forums instead. This will allow the NXP support engineers to
answer any questions users may have in a moderated area of their own
design and choosing.


On a bit of slightly unrelated news, as of last week I have the
current LUFA trunk compiling and running on the new USB XMEGA devices
in a very - emphasis on the VERY - limited manner. Over the next two
weeks I will be focusing solely on my University thesis (as this is
the last piece of coursework I have to finish before my double degree
is complete) however after this I intend to continue on with my LUFA
work and complete the XMEGA port.

Cheers!
- Dean

[Opendous Support]

WOW, NXP has missed the point:

"Permission to use, copy, modify, and distribute this
software and its documentation for any purpose is
hereby granted without fee, provided that it is
USED IN CONJUNCTION WITH NXP SEMICONDUCTORS MICROCONTROLLERS"

LUFA is great because it is well-written, well-supported, widely
used, aims to be complete in terms of all the USB classes, and most
importantly can be ported to other architectures. If I wanted my code
to be locked-in I could just purchase any of dozens of proprietary
solutions or use the 'free' Keil USB stack NXP distributes in the LPC
demo libraries. It is one thing for a register definition file to
include such a constraint since register include files are
architecture-specific but constraining the whole library defeats
LUFA's appeal.

When I heard that LUFA would be ported to a Cortex-M3 architecture I
got excited and put my own porting efforts on hold. Now that I just
finished prototyping some LPC18xx hardware (www.MicropendousX.org) I
discover I have to start again. If a better solution appears while I
am porting LUFA to the LPC18xx myself then I can and will jump ship.

I decided to use the LPC18xx because it has all the capabilities I
will need for several upcoming projects. It has HS USB _with_ PHY and
Host, EBI, Ethernet, proper I2S (32-bit 192kHz), fast FLASH (SPIFI),
fast start-up (<10ms), a version with FPU (LPC43xx), DIY'ability
(LQFP-100 version), and all in a small TFBGA-100 package. It was a
very close call between the LPC18xx and the SAM3U.

I urge NXP to reconsider their approach. NXP products can stand on
their own. Without the theoretical possibility of porting my code to
another architecture should requirements change I see no reason to
invest time, money, and effort into using "nxpusblib".

Thank you,
Matt,
Opendous Inc.

> --
> You received this message because you are subscribed to the Google Groups "LUFA Library Support List" group.
> To post to this group, send email to lufa-s...@googlegroups.com.
> To unsubscribe from this group, send email to lufa-support...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/lufa-support?hl=en.
>
>

[Dean Camera]

> WOW, NXP has missed the point:

That condition in the NXP license of their port was specified by me as
part of the agreement made between myself and NXP, so I can take the
blame for that restriction. As I was licensing LUFA to NXP for their
own free use (removing the possibility of myself collecting commercial
licenses from its users) I had to ensure that the licensed code would
not then be re-sold or licensed by NXP to other silicon vendors,
preventing me from producing and selling my own competing ports in the
future.

On the plus side, this means that users of the NXP code get a free
open source library that they can extend and modify for their own
uses, instead of binary blobs that require expensive licensing
contracts from third party vendors.

Cheers!
- Dean

On Nov 8, 10:16 pm, Opendous Support <opendous.supp...@gmail.com>
wrote:

[Opendous]

Are you able to guarantee that "nxpusblib" will maintain the same API
as LUFA?

[Dean Camera]

There's no legally binding requirement for them to do so, however it
appears they are keen to remain as API compatible as possible - if not
at the low level, at the class driver level at least (both could be
the case - I'd have to examine the code to be certain). I've been
getting some small amounts of feedback from the NXP team as to what
LUFA's deficiencies are in regards to the ARM architecture, so that
when I begin my planned redesign of the core I can make it more
friendly across all the different architectures.

Cheers!
- Dean

[Mattaw]

Great to hear - that explains quite a lot. I hope you can finish your
thesis and then we can look at getting some of the other architectures
working as well.

Matthew

NB It will be great to see what the NXP crew think as improvements to
LUFA for ARM operation.

[Opendous]

The API-compatibility would have been acceptable if it wasn't for
the licensing nightmare in the rest of the library.

The library makes use of libraries from Code Red which are licensed
only for use with their tools. In other words, you can only use
nxpUSBlib with LPCxpresso.

Why is this a problem? Would Linux be Linux if you were only
allowed to compile it with Red Hat's version of gcc?

Without a makefile and gcc the library is no different than any
closed-source offering. NXP has missed the point.

[Kaspar Bumke]

I have to say that as a happy LUFA-user on Atmel's who is considering trying out some ARM chips for USB device design the licensing as described in this thread is putting me of considering using nxpUSBlib although it would be awesome if I could start developing on ARMs without having to learn another API.

I understand why Dean has put these restrictions on NXP but I must say I am a bit confused about what I would do if I wanted to make a commercial design using a (possibly non-NXP) ARM with nxpUSBlib given these restrictions. The Code Red restrictions sound even worse.

[Mattaw]

Just wait a bit - I have done a successful port to FM3, and when Dean
is finished with his thesis it should be merged. I then will probably
look at the STM series of ARM3's. There is also a plan in the works to
do a more portable version of LUFA which will be great.

Matthew

[Opendous]

LUFA is great and ports to other architectures will make it even
better.

Any contribution you make to Open Source and LUFA will be
appreciated. A port of LUFA to the LPC1800 would be tremendously
valued.

It is only nxpusblib which, uses LUFA as a base, that misses the
point of Open Source by creating a licensing quagmire.