Interesting article for NXP

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Luis Digital on Sun Jun 26 07:25:02 MST 2011
Hello all,

Via 32bitmicro.com came to this interesting article:
[B]How To Succeed in the MCU Business Without Really Trying[/B]

In the article tell us the importance of the support on hardware.

In my case I could say that the documentation from NXP is terribly bad, but the IDE runs on Linux.

I think if NXP provides better documentation, and prices compared to those of STMicroelectronics, could be the undisputed leader.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by domen on Sun Jul 03 23:27:35 MST 2011
I won't go into endless thread about what they could or could not do, but current state of examples is not something I would be proud of.

bla bla bla.... Keil extends you a royalty-free right to reproduce
*      and distribute executable files created using this software for use
*      on NXP Semiconductors LPC microcontroller devices only. Nothing else
*      gives you the right to use this software.

EXECUTABLE

While it would be a very crappy move on their part to try to sue someone because he improved their code, they do have this option, and I'm not betting my future on them being nice.

There are more sides to every story, and this one is mine. I might understand why they do what they do, but I don't have to like it.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Wed Jun 29 02:21:36 MST 2011

Quote: domen
Protip NXP: fix your examples when you get the problem explained and the solution written.

Look before you leap (or shout) ...
The thread you are referring to explains how to fix the USB stack.
That stack is not owned by NXP but by Keil - as clearly stated in the header of the file. NXP is licensed to incorporate Keil's USB stack with their example code.
I new there was a reason why Code Red supplies the USB stack from Betrik Sikken with their examples.

So any complaints or changes should be addressed to Keil, not NXP.

Also, do not forget that these are just examples.
These examples are there to show how the peripherals in the chips can be addressed. So no parameter checking, no - or limited - results checking etc.

For NXP to incorporate changes presented in this forum into their code, they need to look at the changes provided, adapt the changes to their current environment, test the changes and publish them.
This is out of the scope of the team that creates these example programs.

Quote:
provide some way centralized way for users to share their fixes

Have you any idea what a mess that would give?
I made, and published, some changes on the I2C example to make it more 'production proof': a few bug fixes and enhancements for error handling. I had a lot of request for changes because users preferred a different way of doing things.
Any idea what would happen when you just provide users with something like a CVS or Subversion archive where they can just 'hack around' ...

You need real project management and control in order to prevent this from becoming just a big mess.
If you feel happy doing this, please go ahead and do so. Nothing hinders you in creating a sourceforge project for this :rolleyes:

Quote:
Oh, and finally fix the license, so we can legally do that!

Huh?
I have seen a lot of examples being quoted, changed and published.
The NXP way of handling this (as far as I know) is that as long as you leave the copyright messages intact and clearly state that you made some changes to it (preferably with these changes clearly marked) they will not do anything.
As said I made some changes to the I2C driver and published them on my site (here). I have mentioned this a number of times on this forum and up to now NXP has not asked me to remove this because of the copyrights.

As long as you do not sell or promote this as your own work and as long as it is being used for the lpc microcontrollers you will be OK.
Do not expect NXP to change the copyrights on the examples. NXP has a large legal department where things like this are being defined and it is very hard or even impossible to change this. In no way a department or a group is allowed to change these copyright rules themselves. This all has to do with liability and (I like this word) [I]indemnification[/I].

Regards,

Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by domen on Tue Jun 28 23:25:15 MST 2011
Protip NXP: fix your examples when you get the problem explained and the solution written: http://knowledgebase.nxp.com/showthread.php?t=388

Or failing that, provide some way centralized way for users to share their fixes. Oh, and finally fix the license, so we can legally do that!

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Mon Jun 27 23:43:11 MST 2011

Quote: KTownsend
Or maybe I'm just so used to it I know where to look now, but I wouldn't call it 'bad'.

Ah, this sound like someone from my generation (built in the good old 60s)
I thought I was an exception on the rule that we just 'plug & pray' to get our application working. This may of course have to do with the fact that way back in '85 I had training practice (or as the Americans say 'I was an intern') at Philips Semiconductors as an IC tester. I have learned to read data sheets and create test programs to verify if the chips are working accordingly. This means I had to study the data sheet, write a program, submit it for test, wait a day or so, study the results and then fine-tune the program.

I still have objections about grabbing he example code and using it in my own programs so I always make sure it is tested and adapted to my particular needs.

So first read the User Manual, try to figure out how I think the thing should work and then have a look at the example code to see if I would do the same.

Quote: Luis Digital
I have an idea. We have all contributed to the documentation and examples, indicating failure of writing (spelling) errors in data or code, and so on.

Can we go further? Can we tell which things should move / change?

Hee, Luis is back.
Looks like you had an off day when you wrote that first post - that did certainly not sound like the Luis I have learned to know on this forum :)
No worries mate - we all have our moments...

It is perfectly OK for us to say what could be changed or moved.
We are all still learning - even NXP - and they already promised to include some of my changes in their next versions.

And of course there are also Embedded Artists and Code Red.
I completely had forgotten about their sample code.

If you own an EA Base Board you can download their samples from the support section of their website - they provide some nice examples for the peripherals on the board and also have a library for the on-chip peripherals.

Code Red also delivers samples with the LPCXpresso software (in C:\nxp\lpcxpresso<version>\Examples\NXP). This used to be a copy of the NXP code but it has evolved since.
Some of the examples I was looking for I found in there. For the lpc17xx there is an archive with LPCXpresso176x examples that are great to try "before moving onto the more complex LPCXpresso examples produced by NXP" ...
They also adopted, and adapted, the LPCUSB library from Bertrik Sikken for the RDB1768 board, the secondary USB bootloader from NXP has been adapted for Bertrik's LPCUSB stack and there is also an EFSL implementation for SD card.

So I guess this shows that we are being heard. Of course we have to mean something to the community to be listened to :D

Any ideas are welcome, I am just now starting to create a set of examples for my new lpc1754 board and I am open for suggestions.
But do keep in mind that if you have 100 software developers they will come up with 101 ways in which they want things to be implemented :eek:

Regards,

Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Luis Digital on Mon Jun 27 18:44:16 MST 2011
I have an idea. We have all contributed to the documentation and examples, indicating failure of writing (spelling) errors in data or code, and so on.

Can we go further? Can we tell which things should move / change?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ktownsend on Mon Jun 27 18:15:09 MST 2011
Following along with the chorus here, I'd say "terribly bad" is a pretty big overstatement. I've always found NXP does a reasonable job with their documentation, particularly compared to some of their competitors or other companies in the semiconductor industry.

The documentation and examples aren't perfect, but it's a lot better than it was not so many years back where the approach was: here's your chip, here's the User Manual ... now go at it in a corner by yourself figuring it all out and writing your code. The samples NXP has been providing for their recent MCUs have made adopting these new chips far less painful than in the past, and as an added bonus all the LPCXpresso examples are GCC compatible (whereas in the past everything tended to use Keil or IAR).

There's always room for improvement ... but one of the reasons I stick with NXP (aside from familiarity with the peripherals) is because I find the documentation generally pretty good. Or maybe I'm just so used to it I know where to look now, but I wouldn't call it 'bad'.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Mon Jun 27 07:42:30 MST 2011
I also disagree with Luis.
The documentation is not terribly bad - yes, there are bugs and yes it seems to take ages for these bugs to be fixed (or even to get them officially confirmed by NPX) but I would say the documentation is "usable".

One thing in the article does however make some sense:

Quote:

The more new chips you design and build, the more you complicate your own business.

I forgot how many lpc1xxx variants there are those days - too many to count. I think it is an overkill to have such a wide product range. Will all these chips stay alive or will only the popular ones remain?
The old 8051 type of controllers are a good example. The 80C552 was (is) a larger chip that was available for a very long time. Farnell still has over 600 of these on stock (that's almost more than the amount of lpc1754's they have :eek:)

But then, in the next paragraph in the article it reads:

Quote:

Nobody wants to buy the fastest chip in the product line; they want the slowest one, knowing they can upgrade down the road. Thus, it’s important to offer a few “overkill chips,” that are more powerful (and likely more expensive) than necessary, even if few customers will actually buy them. They prove that your MCU product line has room to grow.

So here Jim Turley is telling us that the vendors should offer chips that have too many features and that only few customers will buy these chips.
If I was a chip vendor these chips would be phased out of production very fast - and didn't he also mention longevity ...

Software, as Jim writes, is indeed the key selling argument for a chip.
For the lpc1114 and the 1343 there are great examples of how to use most of the peripherals and the free LPCXpresso IDE combined with the very cheap LPC-Link debugger are key selling arguments.

But where are those examples for the other chips???
I just swapped my lpc1343 for a 1754 and I am missing all those samples.
The PWM module has no example code and I had some problems programming it. There even is no simple Blinky example to do some basic testing of my newly developed hardware and, this I think is the worst part, the register defined in the LPC17xx.h file are not always compatible with the LPC13xx.h variant - for some of the peripherals it is even unclear to me if they are the same as the peripherals in the LPC13xx chips (uart, ssp, i2c, ...)

There are ports for uCOS-II and for FreeRTOS, the latter is even promoted through NXP's website and there are also samples for the more complex peripherals like USB (device & host) and samples for SD card access through SPI - even if these are not original NXP sources it's great that these sources are all available through NXP.

So I think NXP is doing a fair job. The cooperation with Code Red (LPCXpresso IDE, Red Suite, and Red Probe) and Enbedded Artists (LPCXpresso boards and base board) is very nice.

There still is room for improvement: more (complete) example code, some documentation with that code and some bug fixes in the documentation (I'd be more than happy to do this for NXP :D) would have saved me some headaches.

Regards,

Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by frame on Mon Jun 27 05:13:25 MST 2011
I do agree with igorsk. I've seen much worse documentations.
I demand completeness, correctness and comprehensibility.

Just two real-life examples:

My company had a long mail discussion with a big 8-Bit uC-supplier (with 'M') about the longevity of it's flash and eeprom memory. It finally turned out, they never actually tested the MCU's in question before, only after our request. In the end, the statement was "we guarantee this number of erase/write cycles, and update the datasheet soon".

A project manager I know changed the uC of one of his products to that of another vendor (from 'M' to 'A'), because of the very promising datasheet. Beside of delivery problems, the size of the errata sheet of the uC in question rose to 5 times its size before starting the project. He is a little unhappy at the moment. Having contributed substantially to the errata sheet does not much to raise his mood. Fact is, the product does not live up to the datasheet.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by igorsk on Mon Jun 27 04:14:02 MST 2011
"You keep using that word. I do not think it means what you think it means."

While NXP docs are not perfect (who is?), I definitely wouldn't say they're "terribly bad". If you want "terribly bad", try docs for some chinese chip :)